Observability: metrics, logs і events

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

• metrics, logs, traces та Events
• Metrics API і Metrics Server
• Prometheus, Alertmanager і Grafana
• структуровані logs та 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.

Не створюйте alert на кожен 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.