-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
googlecloudpubsubreceiver: Accept Cloud Logging logs routed to pub/sub #23184
Comments
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
Sorry for the delay. I will set aside some time, and shift some attention back to OTel (not stale) |
@kamalmarhubi could you explain why setting the encoding to |
@alexvanboxel the format from GCP when setting up a log sink is not OTLP, it's JSON-encoded LogEntry messages. I guess the most surprising thing to me about trying with Also I should mention that I've implemented this, though am not yet using it in production, and it would need some tidying before it could be merged. I've pushed up a draft in #25175 for you to look at whenever you have time. (I'm about to be on vacation for a couple of weeks, so no rush!) |
Okay, it's been a while; I meant the raw_text; having this in the receiver makes sense. Let me investigate (I'll have a look at your draft) |
@alexvanboxel have you had a chance to take a peek? |
Adding comment on the PR |
Add a new `cloud_logging` encoding, which allows the receiver to consume messages from a Pub/Sub topic that's used as the destination of a Cloud Logging sink. refs open-telemetry#23184
Follow along open-telemetry/opentelemetry-specification#3774 for making sure the receiver aligns with the description. |
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
This commit addresses the need to accept logs from Google Cloud Platform into an OpenTelemetry pipeline. The goal is to introduce the `cloud_logging` encoding option for the receiver, allowing users to seamlessly integrate Cloud Logging logs into their OpenTelemetry pipeline. issue open-telemetry#23184 Co-authored-by: Alex Van Boxel <[email protected]>
**Description:** This commit addresses the need to accept logs from Google Cloud Platform into an OpenTelemetry pipeline. The goal is to introduce the `cloud_logging` encoding option for the receiver, allowing users to seamlessly integrate Cloud Logging logs into their OpenTelemetry pipeline. **Link to tracking Issue:** #23184 **Testing:** Added tests for parsing LogEntries **Documentation:** Added the option to the README.md Co-authored-by: Kamal Al Marhubi <[email protected]>
…etry#29299) **Description:** This commit addresses the need to accept logs from Google Cloud Platform into an OpenTelemetry pipeline. The goal is to introduce the `cloud_logging` encoding option for the receiver, allowing users to seamlessly integrate Cloud Logging logs into their OpenTelemetry pipeline. **Link to tracking Issue:** open-telemetry#23184 **Testing:** Added tests for parsing LogEntries **Documentation:** Added the option to the README.md Co-authored-by: Kamal Al Marhubi <[email protected]>
Thank you, @djaglowski, for merging the issue. This related ticket can be closed. |
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
@open-telemetry/collector-contrib-triagers, can this be closed? This has been merged some time ago. |
Component(s)
receiver/googlecloudpubsub
Is your feature request related to a problem? Please describe.
There are logs in GCP that we'd like in our OpenTelemetry pipeline. GCP's supported way to send logs to other destinations in near real-time is via Pub/Sub. Logs are encoded as LogEntry messages in protojson format.
Our immediate use case: so that our traces cover as much of the request path as possible, we want to include Google Cloud Load Balancer (GCLB) spans. GCP doesn't have an obvious way to get spans out of the GCLB, but it does have a way to log all requests. So, we currently process GCLB logs into spans. We've routed our GCLB logs to a Pub/Sub topic, and at the moment process those into spans using a custom consumer that exports spans to our otelcol deployment.
I'd like to remove that custom component, and replace it with the OpenTelemetry Collector using the logtospanconnector proposed in #23182 (whether upstreadmed or not).
But the problem of accepting logs from GCP into an OpenTelemetry pipeline is a lot more general than my precise use case though. For example, one might want to have AuditLog events flow through their unified pipeline.
There's already a googlecloudpubsubreceiver, but it seems designed to use Pub/Sub as a message queue to between collector deployments. I'd like to extend it to be an entrypoint for Cloud Logging logs too.
Describe the solution you'd like
I'd like to be able to specify
cloud_logging
as an encoding for the receiver.Describe alternatives you've considered
We've already done most of the work for this, so we'd likely shift our current use case over to a custom build of the collector if this or something similar doesn't get upstreamed.
Additional context
Doing this correctly probably needs a bit more work on the resource semantic conventions for GCP.
I'm open to this being a new receiver, but given that the existing receiver exists and has multiple encodings, I figured it wasn't worth duplication of the PubSub subscriber code.
The text was updated successfully, but these errors were encountered: