Prometheus и kube-state-metrics

Prometheus — де-факто стандартная система сбора метрик и оповещений для Kubernetes, собирающая временные ряды данных из инструментированных приложений, компонентов Kubernetes и node exporter'ов для обеспечения наблюдаемости в реальном времени по всему K8s-кластеру. Проект prometheus-operator развёртывает экземпляры Prometheus и управляет ими с помощью CRD Prometheus, Alertmanager, ServiceMonitor и PodMonitor, позволяя командам декларативно настраивать цели сбора метрик, автоматически обнаруживающие Pod'ы и Service'ы по селекторам меток без ручных изменений конфигурации. Ключевые встроенные метрики Kubernetes включают kube_pod_container_resource_requests, container_cpu_usage_seconds_total и apiserver_request_duration_seconds_bucket, обеспечивающие работу дашбордов Grafana из Helm-чарта kube-prometheus-stack. recording rules Prometheus предварительно агрегируют дорогостоящие запросы в новые временные ряды, а alerting rules запускают уведомления Alertmanager в PagerDuty, Slack или по электронной почте при превышении порогов — высокой частоты ошибок или OOMKill. Prometheus интегрируется с HPA через custom-metrics-apiserver и prometheus-adapter, обеспечивая автомасштабирование Deployment на основе специфичных для приложения метрик, а не только CPU и памяти.

Как это работает

Prometheus и kube-state-metrics даёт видимость поведения кластера и нагрузок через метрики (Prometheus, kube-state-metrics, cAdvisor), логи (kubelet шлёт stdout/stderr контейнера в log-агенты типа Fluent Bit / Vector / Loki) и трейсы (OpenTelemetry collectors + Jaeger/Tempo). Три сигнала коррелируют через labels — namespace, pod, container — так что во время incident response вы можете перейти от аномалии метрики к конкретным логам и трейсам.

Когда применять

Настройте Prometheus и kube-state-metrics до масштабирования за одну команду или горстку сервисов — отладка проблем 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 роста.

Как это работает

Когда применять

Типичные ошибки

Связанные понятия

Полезные ресурсы