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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

opentelemetry-collector vs grafana-agent #642

Closed
psyhomb opened this issue Jun 10, 2021 · 9 comments
Closed

opentelemetry-collector vs grafana-agent #642

psyhomb opened this issue Jun 10, 2021 · 9 comments
Labels
frozen-due-to-age Locked due to a period of inactivity. Please open new issues or PRs if more discussion is needed.

Comments

@psyhomb
Copy link

psyhomb commented Jun 10, 2021

What's the main difference between opentelemetry-collector and grafana-agent projects?

Thanks 馃檪

@rfratto
Copy link
Member

rfratto commented Jun 10, 2021

Hi, thanks for your question.

The Grafana Agent is strongly tied to the Prometheus ecosystem and its related projects, which we've picked for its history of stability and performance under high load. The tie to that ecosystem gives it a narrow focus, centering around first-class support for Prometheus, Cortex, Grafana Loki, and Grafana Tempo. Relying on stable protocols allows us to solve higher-level problems such as the out-of-box user experience. Grafana Agent ships with a set of 11 Prometheus exporters (tools that expose metrics), allowing you to collect metrics from common applications without having to install extra tools. The Grafana Agent defers to Grafana for interaction with telemetry data from tools outside of the Prometheus ecosystem.

The OpenTelmetry Collector has a much broader scope, aiming to translate telemetry data from multiple input and output protocols. Adding this translation within the collector allows users to arbitrarily switch between backend projects and vendors. However, the translation adds necessary complexity, and is very challenging to do in a completely generic and correct way. For example, the Prometheus team recently reported that the OpenTelemetry Collector is not currently compliant with the Prometheus remote_write protocol. The OpenTelemtry team is working on fixing the compliance issues.

OpenTelemetry is split into different categories. At the moment, only its Traces signal is ready for use. Given its strong adoption, the Grafana Agent uses it for collecting spans to send to Grafana Tempo.

Both projects have an interest in scalability. The Grafana Agent currently supports sharding your telemetry ingestion load (scraping service, hashmod, host filtering), with a focus on being able to scale both inside and outside of Kubernetes. OpenTelemetry is working on scalability too, but within the context of Kubernetes by using an Operator.

Hope this helps!

@psyhomb
Copy link
Author

psyhomb commented Jun 10, 2021

Thank you so much for your detailed explanation.

@psyhomb psyhomb closed this as completed Jun 10, 2021
@RichiH
Copy link
Member

RichiH commented Jun 11, 2021

This is good. Maybe add it as a README.md/FAQ.md?

@songjiayang
Copy link

hi @RichiH , today grafana agent also can collect metrics銆乴ogs and traces, so what鈥榮 the really defferent between them.

@modulitos
Copy link

Just to update, I believe OpenTelemetry Collector is now compliant with the Prometheus remote_write protocol:

https://prometheus.io/blog/#agent-collector
open-telemetry/opentelemetry-collector#2961

In addition to tracing, as mentioned above, it also looks like metrics is ready to use (although support depends on which language-specific SDK you need): https://opentelemetry.io/docs/reference/specification/status/

@songjiayang
Copy link

songjiayang commented Sep 15, 2022

hi @modulitos thank your comment.

I do a test with OTel Collector ( receiver is prometheus, exporter is prometheusremotewrite) , but I found the Collector don't support exemplars yet.

here is my test code https://github.com/grafanafans/prometheus-exemplar/blob/remote_prometheus/config/otel-collector.yaml#L7

@rfratto
Copy link
Member

rfratto commented Sep 15, 2022

Hi all, a lot has changed since my original comment last June. As noted, OpenTelemetry Collector is now fully compliant with the remote_write protocol. The OpenTelemetry Collector contrib distribution also now contains integration-like receivers, such as the MySQL receiver.

Grafana Agent still remains primarily interested in providing first-class support for sending telemetry data to Prometheus, Grafana Loki, Grafana Mimir, and Grafana Tempo. We do this by using upstream code directly, allowing us to avoid potential tradeoffs one might find in OpenTelemetry Collector's approach of converting everything into a common format.

However, we are considering changing our strategy for how we support OpenTelemetry Collector. Stay tuned for an announcement later this month. As a small spoiler: we are considering allowing users to optionally use all of OpenTelemetry Collector inside Grafana Agent. This would give users the choice of which ecosystem to use, either opting for the native ecosystem (like Prometheus) or a generic one (like OpenTelemetry).

I'll post back with an update later this month once we've made that announcement. The announcement should make it more obvious what the future of Grafana Agent looks like and how it'll be possible for us to enable OpenTelemetry Collector as an option.

@rfratto
Copy link
Member

rfratto commented Sep 29, 2022

I'll post back with an update later this month once we've made that announcement. The announcement should make it more obvious what the future of Grafana Agent looks like and how it'll be possible for us to enable OpenTelemetry Collector as an option.

Here it is!

@steveoliver
Copy link

Thanks @rfratto for the follow-up. Aside from Flow mode (which is a much nicer DX than static mode) and the Web UI (which is also very nice), what advantages does Grafana Agent have over OTEL Collector for Grafana users (assuming they're all in on OTEL)?

@github-actions github-actions bot added the frozen-due-to-age Locked due to a period of inactivity. Please open new issues or PRs if more discussion is needed. label Mar 24, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
frozen-due-to-age Locked due to a period of inactivity. Please open new issues or PRs if more discussion is needed.
Projects
None yet
Development

No branches or pull requests

6 participants