Observability: metrics, logs и events

Вы научитесь различать сигналы observability, связывать телеметрию с состоянием Kubernetes и диагностировать деградацию по нескольким независимым источникам.

• metrics, logs, traces и Events
• Metrics API и Metrics Server
• Prometheus, Alertmanager и Grafana
• структурированные логи и correlation IDs
• симптом → гипотеза → evidence

Metrics — числовые временные ряды для трендов, SLI и alerting. Logs — дискретные записи событий приложения. Traces показывают путь запроса через сервисы и длительность spans. Kubernetes Events — короткоживущие сообщения controllers и kubelet о смене состояния объектов.

Сигналы дополняют друг друга, но не взаимозаменяемы. Metric показывает масштаб и время проблемы, trace локализует задержку, log объясняет конкретное выполнение, Event связывает симптом с reconciliation Kubernetes.

kubectl top читает resource metrics из Metrics API, который обслуживает Metrics Server. Эти CPU/memory samples предназначены для autoscaling и оперативного обзора; они не являются долговременным monitoring backend и не заменяют Prometheus.

kube-state-metrics преобразует состояние Kubernetes objects в Prometheus metrics, но не измеряет CPU контейнера. Node exporter описывает host, kubelet/cAdvisor — containers, приложение — собственные business и request metrics.

Prometheus обнаруживает targets, выполняет scrape и хранит time series. Recording rules предварительно вычисляют запросы, alerting rules создают alerts, Alertmanager группирует и маршрутизирует уведомления, Grafana визуализирует данные.

OpenTelemetry Collector принимает metrics, logs и traces через receivers, обрабатывает их processors и отправляет exporters. Kubernetes Attributes Processor добавляет namespace, Pod name и UID, что позволяет коррелировать сигналы после пересоздания Pod.

Начинайте с пользовательского результата: availability, latency, error rate и saturation. SLI является измерением, SLO — целевой границей за окно времени, error budget — допустимой долей неуспеха. Alert должен быть actionable и иметь owner и runbook.

Не алертите на каждый restart или CPU spike. Используйте симптомы, длительность и burn rate; dashboard отвечает на исследовательский вопрос, но не является заменой alerting.

• Добавляйте единые labels: service, environment, cluster, namespace и version
• Пишите структурированные logs в stdout/stderr и не помещайте в них secrets
• Передавайте trace/correlation ID между сервисами
• Контролируйте cardinality: не используйте user ID или request ID как metric label
• Задавайте retention, sampling и стоимость до массового сбора
• Проверяйте не только сбор, но и доставку alerts
• Учитывайте, что Events имеют ограниченный срок хранения

Metrics Server должен быть установлен по модулю 9. Сохраните manifest как observability-lab.yaml. Sidecar logger нужен только для учебного сопоставления container logs.

apiVersion: v1
kind: Namespace
metadata: {name: lab-observe}
---
apiVersion: apps/v1
kind: Deployment
metadata: {name: web, namespace: lab-observe}
spec:
  replicas: 2
  selector:
    matchLabels: {app: web}
  template:
    metadata:
      labels: {app: web}
    spec:
      containers:
        - name: web
          image: nginx:1.29-alpine
          ports: [{name: http, containerPort: 80}]
          readinessProbe:
            httpGet: {path: /, port: http}
            periodSeconds: 5
          livenessProbe:
            httpGet: {path: /, port: http}
            periodSeconds: 10
          resources:
            requests: {cpu: 20m, memory: 32Mi}
            limits: {memory: 64Mi}
        - name: logger
          image: busybox:1.37.0
          command: ["sh", "-c", "while true; do echo "level=info component=logger message=heartbeat"; sleep 10; done"]
          resources:
            requests: {cpu: 5m, memory: 8Mi}
            limits: {memory: 16Mi}
---
apiVersion: v1
kind: Service
metadata: {name: web, namespace: lab-observe}
spec:
  selector: {app: web}
  ports: [{name: http, port: 80, targetPort: http}]

kubectl apply -f observability-lab.yaml
kubectl rollout status deployment/web -n lab-observe --timeout=120s
kubectl get pod -n lab-observe -l app=web -o wide
kubectl logs -n lab-observe -l app=web -c logger --prefix --tail=20
kubectl events -n lab-observe --for deployment/web
kubectl get endpointslice -n lab-observe -l kubernetes.io/service-name=web
kubectl top node
kubectl top pod -n lab-observe --containers
kubectl port-forward -n lab-observe service/web 8080:80

Критерий: два Pod Ready, EndpointSlice содержит два ready endpoint, logs имеют container prefix, Events объяснимы, top показывает каждый контейнер. Port-forward выполняется в отдельном терминале.

Для кластера минимум с 4 CPU и 8 GiB RAM установите stack в отдельный namespace monitoring. Chart 88.0.1 зафиксирован для воспроизводимости; перед production проверьте release notes, storage, retention, RBAC, ingress и backup. Команды port-forward блокируют терминал и выполняются по одной.

helm show chart oci://ghcr.io/prometheus-community/charts/kube-prometheus-stack --version 88.0.1
helm upgrade --install monitoring oci://ghcr.io/prometheus-community/charts/kube-prometheus-stack --version 88.0.1 --namespace monitoring --create-namespace --rollback-on-failure --wait --timeout 10m
kubectl get pod -n monitoring
kubectl get prometheus,alertmanager,servicemonitor,prometheusrule -n monitoring
kubectl port-forward -n monitoring service/monitoring-kube-prometheus-prometheus 9090:9090
curl -fsS 'http://127.0.0.1:9090/api/v1/query?query=up'
kubectl port-forward -n monitoring service/monitoring-grafana 3000:80

kube-prometheus-stack устанавливает Prometheus Operator, Prometheus, Alertmanager, Grafana, exporters, rules и CRDs. CRDs могут не удаляться с helm uninstall и требуют отдельного lifecycle; major chart upgrade читайте по UPGRADE.md.

Сломайте readiness path. Новые Pods останутся Running, но исчезнут из ready endpoints; rollout ожидаемо получит timeout. Сопоставьте Conditions, Warning Events, EndpointSlice и logs, затем выполните rollback.

kubectl patch deployment web -n lab-observe --type=json -p='[{"op":"replace","path":"/spec/template/spec/containers/0/readinessProbe/httpGet/path","value":"/missing"}]'
kubectl rollout status deployment/web -n lab-observe --timeout=45s
kubectl get pod -n lab-observe -l app=web
kubectl describe deployment web -n lab-observe
kubectl events -n lab-observe --types=Warning
kubectl get endpointslice -n lab-observe -l kubernetes.io/service-name=web -o yaml
kubectl logs -n lab-observe -l app=web -c web --tail=20 --prefix
kubectl rollout undo deployment/web -n lab-observe
kubectl rollout status deployment/web -n lab-observe --timeout=120s
kubectl delete namespace lab-observe

Диагностическая цепочка: пользовательский симптом → Deployment/Pod Conditions → traffic endpoints → resource saturation → logs → traces → recent changes. Отсутствие ошибки в одном сигнале не доказывает исправность системы.

• Чем Metrics Server отличается от Prometheus?
• Что измеряет kube-state-metrics?
• Почему request ID опасен как metric label, но полезен в logs и traces?
• Чем Event отличается от application log?
• Как SLI связан с SLO и error budget?
• Почему Running Pod может не получать traffic?

Модуль освоен, если вы выбираете сигнал под вопрос, коррелируете его по Kubernetes metadata и доказываете причину деградации минимум двумя источниками evidence.