Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GitHub pipeline observability #22

Draft
wants to merge 26 commits into
base: main
Choose a base branch
from

Conversation

johannes-b
Copy link
Contributor

@johannes-b johannes-b commented Jan 9, 2025

This package provides the artifacts to configure GitHub pipeline observability in Dynatrace using Monaco.
Besides, it contains a how to guide to configure GitHub to send the relevant data to Dynatrace.

The artifacts include:

  • OpenPipeline configuration in the SDLC.event scope
  • 2 Dashboards for GitHub pipeline/PR observability
    • GitHub Pull Request monitoring
    • GitHub Workflows monitoring

Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Copy link

@stefaneberl stefaneberl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please double check the usage of join and joinNested.

Example 5 of https://docs.dynatrace.com/docs/discover-dynatrace/references/dynatrace-query-language/commands/aggregation-commands#summarize describes a way to use summarize instead of join, which reduces the amount of data read by half.

Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Signed-off-by: Johannes Bräuer <[email protected]>
Copy link

@stefaneberl stefaneberl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More comments will follow.

},
"enabled": false
},
"query": "fetch events \n| filter event.kind == \"SDLC_EVENT\" \n| filter event.category == \"task\" \n| filter event.type == \"change\" \n| filter event.provider == \"github.com\"\n| sort timestamp desc\n| summarize { statuses = collectArray(event.status) }, by: { task.id, task.name, start_time, number, vcs.repository.name, vcs.ref.base.name, vcs.ref.base.revision, vcs.ref.head.name, vcs.ref.head.revision, ext.vcs.change.pull_request.url } \n| filter not in(statuses[0],array(\"merged\",\"closed\")) \n| filter in(vcs.repository.name, $Repository) \n| filter in(vcs.ref.base.name, $Branch)\n| summarize count()",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the PR ID & full repo URL be sufficient for aggregation?
I'm a bit hesitant to have vcs.ref.base.revision in, especially since a user can rebase their PR & force push. I'm not sure if this will stay stable here.

In addition, certain filters, e.g. vcs.repository.name and the like should be applied before aggregating, limiting the number of records to aggregate.

},
"enabled": false
},
"query": "fetch events \n| filter event.kind == \"SDLC_EVENT\" \n| filter event.category == \"task\" \n| filter event.type == \"change\" \n| filter event.provider == \"github.com\"\n| filter in(vcs.repository.name, $Repository) \n| filter in(vcs.ref.base.name, $Branch)\n| sort timestamp desc\n| summarize { statuses = collectArray(event.status) }, by: { task.id, task.name, start_time,number, vcs.ref.base.name, vcs.ref.base.revision, vcs.ref.head.name, vcs.ref.head.revision, ext.vcs.change.pull_request.url } \n| filter not in(statuses[0],array(\"merged\",\"closed\")) \n| fieldsAdd OpenedPrDuration = toTimestamp(now()) - toTimestamp(start_time) \n| summarize max(OpenedPrDuration)",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to above. I think certain summarize by attributes may change over the lifetime of a PR. I would consider the PR ID & the full URL to the repo as unique

},
"enabled": false
},
"query": "fetch events \n| filter event.kind == \"SDLC_EVENT\" \n| filter event.category == \"task\" \n| filter event.type == \"change\" \n| filter event.provider == \"github.com\"\n| sort timestamp desc\n| summarize { statuses = collectArray(event.status), actions = collectArray(vcs.change.state) }, by: { task.id, task.name, start_time,number, vcs.repository.name, vcs.ref.base.name, vcs.ref.base.revision, vcs.ref.head.name, vcs.ref.head.revision, ext.vcs.change.pull_request.url } \n| filter not in(statuses[0],array(\"merged\", \"closed\")) \n| filter contains(toString(actions),\"reopened\")\n| filter in(vcs.repository.name, $Repository) \n| filter in(vcs.ref.base.name, $Branch)\n| summarize count()",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The filter applied after the summariz should be reconsidered. It would make sense to apply it before the aggregation.

Furthermore, there is a sort timestamp desc, which is IMHO not necessary, or at least I don't see it.

},
"enabled": false
},
"query": "fetch events \n| filter event.kind == \"SDLC_EVENT\" \n| filter event.category == \"task\" \n| filter event.type == \"change\" \n| filter event.provider == \"github.com\"\n| filter in(vcs.repository.name, $Repository) \n| filter in(vcs.ref.base.name, $Branch)\n| sort timestamp desc\n| summarize { statuses = collectArray(event.status) }, by: { task.id, task.name, start_time, ext.vcs.change.pull_request.number, vcs.ref.base.name, vcs.ref.base.revision, vcs.ref.head.name, vcs.ref.head.revision, ext.vcs.change.pull_request.url, vcs.change.id } \n| filter not in(statuses[0],array(\"merged\",\"closed\")) \n| fields \nIn_open_status = toTimestamp(now()) - toTimestamp(start_time),\nPR = ext.vcs.change.pull_request.number, \nTitle = task.name,\nURL = ext.vcs.change.pull_request.url,\nHeadName = vcs.ref.head.name, \nHeadRevision = vcs.ref.head.revision, \nBaseName = vcs.ref.base.name, \nBaseRevision = vcs.ref.base.revision,\nCreatedAt = start_time, \nGlobalId = vcs.change.id \n| sort In_open_status desc",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the sort timestamp desc necessary?

I think the summarize by attributes should be reconsidered, similarly to my previous comments.

@martin-hoelbling
Copy link

Tested the Monaco setup (prerequisites steps 1-5) and deployed configuration incl. merge - everything works as expected.

@stefaneberl
Copy link

During a meeting with @johannes-b on Feb 19th, it was agreed on to optimize the dashboard queries at a later stage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants