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

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, НРА/ВПА, контейнери.
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 алерти. Це дасть передбачуваність, швидкість реакції і прозорість вартості на рівні всієї платформи.