Дашборды инфраструктуры

1) Зачем это нужно

Единая картина состояния: от кластера и сетей до баз данных и очередей.
Быстрые RCA и пост-мортемы: связка метрик ↔ логов ↔ трасс.
SLO по сервисам и платформе: контроль над доступностью и латентностью.
ФинОпс-прозрачность: объем/стоимость по сервисам, tenant’ам и средам.
Комплаенс/безопасность: статус патчей/уязвимостей, доступов, аномалий.

Методологии: Golden Signals (latency, traffic, errors, saturation), RED (Rate, Errors, Duration) для запросов, USE (Utilization, Saturation, Errors) для ресурсов.

2) Принципы хорошего дашборда

Действуемость (Actionable): каждая панель отвечает на «что делать дальше».
Иерархичность: обзор → домены → deep dive → raw.
Шаблоны/переменные: `cluster`, `namespace`, `service`, `tenant`, `env`.
Единые единицы: мс для латентности, %, RPS, операций/с, байты.
Консистентный таймпикер: по умолчанию 1–6 часов, быстрые пресеты 5м/15м/24ч.
Drilldown: из панели на логи (Loki/ELK) и трассы (Tempo/Jaeger).
Владение: на дашборде указан владелец, SLO, runbook, контакт в on-call.

3) Структура папок и роли

00_Overview — верхнеуровневый обзор платформы.
10_Kubernetes — кластеры, ноды, workloads, HPA/ВПА, контейнеры.
20_Network_Edge — Ingress/Envoy/Nginx, LB, DNS, CDN, WAF.
30_Storage_DB — PostgreSQL/MySQL, Redis, Kafka/RabbitMQ, объектное хранилище.
40_CICD_Runner — пайплайны, агенты, артефакты, registry.
50_Security_Compliance — уязвимости, патчи, RBAC, audit events.
60_FinOps_Cost — стоимость по сервисам/tenant/кластеру, утилизация.
99_Runbooks — ссылки на инструкции и SLO-карточки.

Роли: Platform-SRE (полный доступ), Service-Owner (свои пространства), Security/Compliance, Finance/FinOps, View-only.

4) Обзорный дашборд платформы (Landing)

Цель: за ≤30 сек понять, все ли в порядке.

• SLO платформа (доступность API edge): целевое значение, фактическое, эра ошибок, burn-rate.
• Латентность p50/p95/p99 по основным входным точкам.
• Ошибки 4xx/5xx и топ-эндпоинты с регрессиями.
• Сатурация ресурсов (CPU, RAM, сеть, диск) — p95 по кластерам.
• Инциденты/алерты (активные) и последние релизы.
• Стоимость/час (приближенно) и тренд по неделе.

Шаблоны переменных: `env`, `region`, `cluster`, `tenant`.

5) Kubernetes: кластеры и ворклоады

1. Кластер/ноды

Утилизация CPU/Memory, pressure (memory/cpu), диск IO, inode.
Подсистемы: kube-api, etcd, контроллеры; kubelet health.

2. Ворклоады

RPS/RPM, latency p95, error rate, restarts, throttling, OOMKills.
HPA таргеты vs фактические метрики.

3. Сетевой путь внутри кластера

eBPF/Netflow: top talkers, drops, retransmits.

4. События K8s

Rate по Warning/FailedScheduling/BackOff.

promql
API (5xx) errors by sum by (service) (rate (http_requests_total{status=~"5"..}[5m]))

Latency p95 histogram_quantile (0. 95, sum by (le, service) (rate(http_request_duration_seconds_bucket[5m])))

Throttling CPU контейнеров sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m]))

6) Edge, сетка и DNS

• Ingress/Envoy/Nginx: RPS, p95, 4xx/5xx, upstream_errors, active_conns.
• LB/Anycast: распределение трафика по зонам, failover события.
• DNS: латентность резолва, NXDOMAIN/SERVFAIL rate, hit-ratio кеша.
• CDN/WAF: блокировки по правилам, аномальный трафик (боты/скрейперы).

promql sum(rate(nginx_http_requests_total[5m])) by (status)

7) Базы данных и сторидж

PostgreSQL/MySQL: qps, latency, lock waits, replication lag, бэкапы/провалы.
Redis: hit ratio, evictions, память, медленные команды.
Kafka/RabbitMQ: lag по consumer-группам, rebalances, unacked messages.
Объектное хранилище: запросы, ошибки, egress, lat p95.

promql
Replication lag in seconds max by (replica) (pg_replication_lag_seconds)

Slow Queries> 1s rate (pg_stat_activity_longqueries_total[5m])

promql
Lag by group max by (topic, group) (kafka_consumergroup_lag)

8) CI/CD и артефакты

Pipeline overview: успешность/время выполнения, очередь раннеров.
Deployment health: версии, canary/blue-green статус, время прогрева.
Регистри образов: размер, последние push’и, утилизация.

promql
Rate (ci_pipeline_success_total[1h] )/rate (ci_pipeline_total[1h]) success rate

9) Безопасность и комплаенс

Патчи и уязвимости: доля нод/образов с критическими CVE, среднее «время до патча».
RBAC и секреты: неуспешные попытки доступа, обращения к секретам.
Аудит-события: входы/изменения в критичных компонентах, drift.
WAF/DLP/PII-редакция: блокировки правил, ошибки маскирования.

10) Логи и трассы: сквозной обзор

Сводка ошибок из логов (Loki/ELK): top exceptions, новые сигнатуры.
Кнопка «Перейти к логам с фильтрами» (LogQL/ES query).
Трассы: top slow spans, процент запросов без trace-контекста.

{app="api", level="error"}     = "NullReference"
{app="nginx"}      json      status="5.."      count_over_time([5m])

11) FinOps: стоимость и утилизация

Стоимость по сервисам/тенантам/кластерам (по данным биллинга/экспортеров).
Горячие/холодные узлы: idle ресурсы, rightsizing рекомендации (CPU/Mem).
Data egress, L7 запросы и их стоимость.
Динамика: неделя/месяц, прогноз.

• cost_per_rps, cost_per_request, storage_cost_gb_day, idle_cost.
• коэффициент эффективности: `RPS / $` или `SLO-минуты / $`.

12) SLO, ошибки и burn-rate

SLO карточка на каждом дашборде домена: цель, период, ошибки (budget).
Burn-rate алерты (две скорости: быстрая/медленная).

promql
Bad budget: 5xx as a fraction of sum (rate (http_requests_total{status=~"5"..}[5m])) traffic
/
sum(rate(http_requests_total[5m]))

Burn-rate (fast channel ~ 1h)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14. 4

13) Стандарты визуализации

Тайпсы панелей: time-series для рядов, stat для KPI, table для top-N, heatmap для латентности.
Легенды и юниты: обязательны; укороченные лейблы, SI-формат.
Цветовые зоны: зеленая/желтая/красная по SLO/threshold (единообразно).
Описание панели: что измеряем, источник, runbook-ссылка, владелец.

14) Шаблоны панелей (быстрый старт)

(A) API Overview

KPI: `RPS`, `p95`, `5xx%`, `error_budget_remaining`.
Top endpoints by error/latency.
Drilldown в логи `trace_id=$trace`.

(B) Node Health

CPU/Memory/Disk/Network — p95 по нодам, список «горячих».
Pressure, throttling, dропы пакетов.

(C) DB Health

TPS, latency p95, locks, replication lag, slow queries.
Бэкап-статус/последний успех.

(D) Kafka Lag

Lag по группам, скорость потребления vs продюсинг, rebalances.

(E) Cost & Util

Cost/hour по сервисам, idle %, rightsizing hints, прогноз.

15) Переменные и тэги (рекомендуемый набор)

`env` (prod/stage/dev)

`region`/`az`

`cluster`

`namespace`/`service`/`workload`

`tenant`

`component` (edge/db/cache/queue)

`version` (release/git_sha)

16) Интеграция с алертингом и инцидент-менеджментом

Правила в Alertmanager/Графана-алертах с ссылками на нужный дашборд и уже подставленными переменными.
P1/P2 по SLO-критериям, auto-assign на on-call.
Аннотации релизов/инцидентов на графах.

17) Качество дашбордов: чек-лист

• Владелец и контакт.
• SLO/thresholds задокументированы.
• Переменные работают и ограничивают объем запросов.
• Все панели с юнитами и легендой.
• Drilldown в логи/трассы.
• Панели укладываются в 2–3 «экрана» (без скролла на километр).
• Время ответа запросов ≤2–3 c (кэш, downsample).
• Нет «мертвых» панелей и deprecated-метрик.

18) Производительность и стоимость самих дашбордов

Downsampling/recording rules для тяжелых агрегаций.
Кэширование (query-frontend/репитер) и лимиты на range/step.
Ангар тестов: нагрузка на TSDB/кластеры при типовых дашборд-запросах.
Санация лейблов (низкая кардинальность), отказ от wildcards.

19) План внедрения (итерации)

1. Неделя 1: Лэндинг + K8s/Edge обзоры, базовые SLO, владельцы.
2. Неделя 2: DB/Queues, интеграция логов и трасс (drilldown), burn-rate алерты.
3. Неделя 3: FinOps-дашборды, rightsizing рекомендации, отчет по стоимости.
4. Неделя 4+: Security/Compliance, автогенерация SLO-карточек, регрессионные тесты дашбордов.

20) Мини-FAQ

Сколько дашбордов нужно?
Минимум 1 обзор + по одному на домен (K8s, Edge, DB, Queues, CI/CD, Security, Cost). Остальное — по зрелости.

Что важнее — метрики или логи?
Метрики для симптомов и SLO, логи для причин. Связка через `trace_id` и консистентные лейблы.

Как не «утонуть» в панелях?
Иерархия, явные владельцы, гигиена метрик, регулярные ревью и удаление «мертвых» панелей.

Итог

Инфраструктурные дашборды — это не «красивые графики», а управленческий инструмент: SLO-контроль, быстрое RCA и осознанный FinOps. Стандартизируйте переменные, визуальные шаблоны и владельцев; обеспечьте drilldown к логам/трассам и автоматизируйте burn-rate алерты. Это даст предсказуемость, скорость реакции и прозрачность стоимости на уровне всей платформы.