kube-prometheus-stack covers metrics, but most teams eventually want logs and traces in the same Grafana instance, and want their monitoring configuration managed the same GitOps way as everything else in the cluster.
This category is reserved for integration guidance: adding Loki for log aggregation and Tempo with OpenTelemetry for distributed tracing alongside the existing Prometheus/Grafana setup, and managing ServiceMonitors, PrometheusRules, and Alertmanager config declaratively through ArgoCD or Flux.
The common thread across these integrations is keeping everything queryable from the same Grafana instance and manageable through the same Git-based workflow, rather than bolting on a separate vendor dashboard for every telemetry type. This matters most for teams that have already invested in kube-prometheus-stack for metrics and want logs, traces, and deployment automation to follow the same operational model instead of introducing a second way of doing things.
Deploy and manage kube-prometheus-stack declaratively through ArgoCD or Flux — handling the CRD ordering problem, syncing values.yaml from Git, and keeping upgrades reviewable.
Read ArticleYes — via remote_write to any Prometheus-remote-write-compatible backend, or by running Loki and Tempo alongside it for logs and traces inside the same Grafana instance.
No — they're deployed as separate components alongside kube-prometheus-stack and connected to Grafana as additional data sources; Prometheus's own configuration is untouched.
