Course summary
Six things to remember
| # | Takeaway |
|---|---|
| 1 | External collectors work: Bring your own collectors, let Grafana Cloud store |
| 2 | Match method to source: Prometheus → remote write, InfluxDB → exporter, etc. |
| 3 | OpenTelemetry is universal: OTLP works for both metrics and logs |
| 4 | HTTP API is flexible: Any HTTP client can send logs |
| 5 | Mimir stores metrics: Prometheus-compatible, scalable |
| 6 | Loki stores logs: Query with LogQL, correlate with metrics |
Quick reference
| Your source | Method | Destination |
|---|---|---|
| Prometheus | Remote write | Mimir |
| InfluxDB | InfluxDB exporter | Mimir |
| Graphite | Telegraf / OTel | Mimir |
| OpenTelemetry metrics | OTLP | Mimir |
| OpenTelemetry logs | OTLP | Loki |
| Any HTTP client | HTTP API | Loki |
Script
Here’s what to remember from this course.
First, using external collectors is a valid approach when you have existing infrastructure. You don’t have to use Grafana tools for collection…bring your own and let Grafana Cloud handle storage. Just remember that Grafana recommends Alloy or integrations for new deployments.
Second, for metrics, match the method to your source. Prometheus uses remote write. InfluxDB uses the exporter. Graphite uses Telegraf or OpenTelemetry. Native OpenTelemetry uses OTLP.
Third, for logs, OTLP is the modern choice if you’re on OpenTelemetry. HTTP API is the flexible choice for custom integrations.
Finally, all roads lead to the same place. Mimir stores metrics and Loki stores logs. Once your data is there, you get all of Grafana Cloud’s visualization, alerting, and analysis capabilities regardless of how you sent it.