Docs feedback: Consolidate and update some of the OTelCol documentation in Alloy docs

[clayton-cornell]

URL

https://grafana.com/docs/alloy/latest/collect/opentelemetry-to-lgtm-stack/

Feedback

Slack discussion points out some work to be done with the Alloy OTelCol docs.

Internal link: https://raintank-corp.slack.com/archives/CSN5HV0CQ/p1727343874642999

Summary of the Slack discussion:

We see some Alloy users thinking that the recommended way to send OTel logs to Grafana Cloud or Loki is to convert OTel logs to Loki inside Alloy and then send those logs using Loki’s logproto protocol (example here). If most Alloy docs clearly state that OTel data should be forwarded using the OTLP exporter, some pages may still be misleading. I identified the following:

1. The Collect OpenTelemetry data and forward to Grafana still recommends to convert OTel data in Alloy rather than using the Grafana Cloud OTLP Endpoint.
   • I’m wondering if this page could be merge with Collect OpenTelemetry data as the goal is very similar and this page has the right guidance.
   • Reply from dev team: we already have there information on how to configure sending to OTLP endpoint. The part about sending to Loki is for Grafana Enterprise and Grafana Open Source. Could be users who run Loki themselves.
2. The otelcol.exporter.loki reference page could state that the recommended way to send OTel logs to Loki is the Loki OTLP Endpoint / Grafana Cloud OTLP Endpoint
   • Reply from dev: this is local docker-compose tutorial that starts local Loki instance. It could be useful for those that want to run Loki themselves. Also, I'm not sure if the local Loki exposes OTLP endpoint that can be used locally for docker-compose tutorial.
3. The tutorial “Send Logs to Loki” could have a section dedicated to OTel Logsin addition to the Loki format section

• there's a docker-based tutorial in Loki that overlaps with Alloy docs: https://grafana.com/docs/loki/latest/send-data/alloy/examples/alloy-otel-logs/

[ptodev]

We will need a similar clarification for otelcol.exporter.prometheus as well.

I think also in this example we should say that it's better to avoid converting to Prometheus metrics where possible since it can be awkward.

It might make it simpler and easier to write and read docs if we simply use Grafana Cloud as an example, and if we include a link that says "if you'd like to run your own database, please follow these steps". And it would be great if those steps are in the Loki/Mimir/Tempo doc namespaces. That way the Alloy team can focus on Alloy config rather than running databases locally. It'd also avoid repetition.

[github-actions[bot]]

This issue has not had any activity in the past 30 days, so the needs-attention label has been added to it. If the opened issue is a bug, check to see if a newer release fixed your issue. If it is no longer relevant, please feel free to close this issue. The needs-attention label signals to maintainers that something has fallen through the cracks. No action is needed by you; your issue will be kept open and you do not have to respond to this comment. The label will be removed the next time this job runs if there is new activity. Thank you for your contributions!