Loki для логов
Тема дорожной карты · Kubernetes
Grafana Loki — горизонтально масштабируемая мультитенантная система агрегации логов, разработанная специально для Kubernetes-сред; хранит только метаданные-метки логов, а не полнотекстовые индексы, что позволяет снизить затраты на хранение. Loki собирает логи из Pod'ов Kubernetes через агент Promtail или OpenTelemetry Collector, которые читают файлы логов контейнеров из пути /var/log/pods/ на узле и пересылают их с метками namespace, pod, container и app. Потоки логов запрашиваются с помощью LogQL — языка запросов Loki — непосредственно в дашбордах Grafana, обеспечивая корреляцию логов с метриками Prometheus на одной временной оси и сокращая переключение контекста при реагировании на инциденты. Grafana Loki интегрируется с Alertmanager через правила ruler, позволяя срабатывать оповещениям на основе логов наряду с оповещениями на основе метрик в едином стеке наблюдаемости. Развёртывание Loki в Kubernetes-кластере, как правило, выполняется через Helm-чарт grafana/loki-stack, объединяющий Loki, Promtail и Grafana в единую установку.
Как это работает
Loki для логов даёт видимость поведения кластера и нагрузок через метрики (Prometheus, kube-state-metrics, cAdvisor), логи (kubelet шлёт stdout/stderr контейнера в log-агенты типа Fluent Bit / Vector / Loki) и трейсы (OpenTelemetry collectors + Jaeger/Tempo). Три сигнала коррелируют через labels — namespace, pod, container — так что во время incident response вы можете перейти от аномалии метрики к конкретным логам и трейсам.
Когда применять
Настройте Loki для логов до масштабирования за одну команду или горстку сервисов — отладка проблем distributed system без метрик, логов и трейсов невозможно медленная. Используйте Prometheus + Grafana stack для self-hosted; managed-альтернативы (Datadog, New Relic) снижают операционную нагрузку при большей цене. SLO и alerts идут из того же metric pipeline; проектируйте вместе.
Типичные ошибки
Observability-ловушки: cardinality explosion (high-cardinality labels вроде user-id взрывают Prometheus storage); слишком много alerts (alert fatigue заглушает реальные проблемы); log volumes без retention policies (стоимость storage идёт в спираль); tracing только на API-границе (пропускаете медленные внутренние вызовы). Тюньте по мере роста трафика; observability-решения на низком масштабе не выживают 10x роста.