Audit logs for receiver/github

[justinianvoss22]

Component(s)

receiver/github

Is your feature request related to a problem? Please describe.

It looks like the GitHub receiver is being used for metrics only right now. I have been doing research on GitHub's audit logs that are used to keep track of events in an enterprise, organization, or user events. In order to access these logs, one must have a GitHub Enterprise Cloud account. https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise

Describe the solution you'd like

I have been working on an implementation that incorporates polling for logs. I see that there is a PR for a web hooks implementation so I wonder if a mode config option could be used to select polling or web hook events to be used. For now, I am polling using the REST API endpoints that include /audit-log to get logs for organizations and enterprises. For user events, I am using events/public for user logs. Let me know if there are other event logs that are useful.

Describe alternatives you've considered

I have considered using only webhooks instead of polling, but I am waiting for the contribution of the web hook config files to be merged through to see what that would look like.

Additional context

No response

[github-actions[bot]]

Pinging code owners:

• receiver/github: @adrielp @andrzej-stencel @crobert-1 @TylerHelmuth

  See Adding Labels via Comments if you do not have permissions to add labels yourself.

[andrzej-stencel]

This sounds like a valuable addition. I'm in favor of incorporating logs support to the GitHub receiver.

[adrielp]

Agreed @andrzej-stencel - Thanks @justinianvoss22 for opening this. There was I think a similar proposal with #32505 which was asked to be incorporated in #27460 which is now all being incorporated into the GitHub Receiver as previously determined in the SIG call and mentioned in this comment. Super happy to take contributions to accelerate the delivery of this functionality.

@andrzej-stencel / @crobert-1 - and anyone else, what's the best way to close out those components proposals & link back to the decision for this to enable clarity to end-users on the direction of the GitHub receiver, enabling faster iteration?

[crobert-1]

what's the best way to close out those components proposals & link back to the decision for this to enable clarity to end-users on the direction of the GitHub receiver, enabling faster iteration?

I've added the receiver/github label to the issues you've referenced. It's a pretty common issue we run into where we have lots of overlapping issues and discussions. I think your comment is a great way to handle this kind of issue though, just linking and connecting related issues as much as possible for context references. I'm open to more suggestions though.

[justinianvoss22]

I'll work on creating a PR from my fork with my changes and you can take a look at it and give feedback.

[adrielp]

Thanks @justinianvoss22! If you haven't already, please take a look at the Contributing Guidance for OTEL