Инфрақұрылым мониторингі

Инфрақұрылым мониторингі

1) Мақсаттар мен шеңбер

• Қателер туралы пайдаланушыдан бұрын ескерту (ерте детекция).
• Негізгі себебін анықтау (from symptom to cause).
• SLO-гейтинг релиздері мен авто-кері қайтуды қолдау.
• Инциденттен кейінгі талдауды азықтандыру (evidence as data).

Тірек қағидаттары: Observable by design, аз шу - көп сигналдар, автоматтандырылған реакциялар, бірыңғай шындық панелі.

2) Бақылау триадасы

Метрика (timeseries): жылдамдық/сұраныс/қателер/қанығу (USE/RED).
Логи: контексті бар оқиғалық нақтылау; құпиялары жоқ/PII.
Трестер: себеп-салдарлық байланыстармен бөлiнген қатынастар.

• Профильдеу (CPU/heap/lock/io), жүйелік деңгей үшін eBPF.
• Оқиғалар/аудит (K8s Events, конфигурацияларды/құпияларды өзгерту).

3) SLI/SLO/SLA - сапа тілі

SLI (көрсеткіш): 'availability', 'error _ rate', 'p95 _ latency', 'queue _ lag'.
SLO (мақсат): "сәтті сұраулар ≥ 99. 30 күнде 9%".
Error Budget: рұқсат етілген ауытқу; автоматты тоқтату релиздері үшін пайдаланылады.

yaml service: "api-gateway"
slis:
- name: success_rate query_good: sum(rate(http_requests_total{status!~"5.."}[5m]))
query_total: sum(rate(http_requests_total[5m]))
slo: 99. 9 window: 30d

4) Мониторинг қабаттарының картасы

1. Хосттар/VM/тораптар: CPU/Load/Steal, RAM/Swap, Disk IOPS/Latency, Filesystem.
2. / LB/DNS желісі: RTT, пакеттер/дроптар, backlog, SYN/Timeout, health-probes.
3. Kubernetes/Orchestrator: API-сервер, etcd, бақылаушылар, scheduler; pending/evicted, throttling, kube-events.
4. Қызметтер/контейнерлер: RED (Rate/Errors/Duration), readiness/liveness.
5. Дерекқорлар/кэштер: QPS, lock wait, replication lag, buffer hit, slow queries.
6. Кезектер/шиналар: consumer lag, requeue/dead-letter, throughput.
7. Сақтау орны/бұлт: провайдерлерден S3/Blob қателер мен latency, 429/503.
8. Периметр шекаралары: WAF/Rate Limits, бағыттар бойынша 4xx/5xx, CDN.
9. Синтетика: сценарийлерді HTTP-тексеру (депозит/шығару), TLS/сертификаттар.
10. Экономика/сыйымдылық: cost per service, utilization, headroom.

5) Whitebox и Blackbox

Whitebox: сервистер ішіндегі экспорттаушылар/SDK (Prometheus, OpenTelemetry).
Blackbox: әртүрлі өңірлерден (availability, latency, TLS expiry) сыртқы сынамалар.
«Сырттағы белгі» + «ішіндегі диагностика» біріктіріңіз.

yaml modules:
https_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"

6) Kubernetes: негізгі сигналдар

Кластер: `apiserver_request_total`, `etcd_server_has_leader`, etcd fsync.
Узлы: `container_cpu_cfs_throttled_seconds_total`, `node_pressure`.
Поды: Pending/CrashLoopBackOff, OOMKilled, қайта карталар.
Жоспарлар/лимиттер: Requests vs Limits, PodDisruptionBudget, HPA/VPA.
Желі: NetworkPolicy дроптар, conntrack exhaustion.

Дашборды: «Cluster health», «Workload saturation», «Top erroring services».

7) ДБ және кезектер

PostgreSQL/MySQL: replication lag, deadlocks, slow query %, checkpoint I/O.
Redis/Memcached: hit ratio, evictions, rejected connections.
Kafka/RabbitMQ: consumer lag, unacked, requeue, broker ISR, disk usage.

8) RED/USE өлшемдері және бизнес-корреляциялар

RED: `rate` (RPS), `errors` (4xx/5xx), `duration` (p95/p99).
USE (ресурстар үшін): Utilization, Saturation, Errors.
Өніммен байланысыңыз: депозиттер/төлемдер табысты, фрод-жалаулар, конверсия - бұл канареялық релиздегі «күзетшілер».

9) Алертинг құрылымы

Tier-1 (пейдж): SLO-ға әсер ететін тосын оқиғалар (қолжетімділік, 5xx, жасырындылық, кластерлік критикалық компоненттердің істен шығуы).
Tier-2 (тикет): сыйымдылықтың тозуы, SLO әсер етпейтін қателердің өсуі.
Tier-3 (ақпарат): трендтер, болжамды сыйымдылық, мерзімі өтіп бара жатқан сертификаттар.

Эскалация ережелері: тыныштық уақыты/көшірмелерді қысу, on-call, «follow-the-sun» ротациясы.

yaml route:
group_by: ["service","severity"]
receiver: "pager"
routes:
- match: { severity: "critical" }
receiver: "pager"
- match: { severity: "warning" }
receiver: "tickets"

10) Prometheus ережелерінің мысалдары

10. 1 SLO табалдырығы бар 5xx қателері

yaml groups:
- name: api rules:
- alert: HighErrorRate expr:
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m])) > 0. 005 for: 10m labels: { severity: "critical", service: "api-gateway" }
annotations:
summary: "5xx > 0. 5% 10m"
runbook: "https://runbooks/api-gateway/5xx"

10. 2 Өртеу error-budget (multi-window burn)

yaml
- alert: ErrorBudgetBurn expr:
(1 - (
sum(rate(http_requests_total{status!~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
)) > (1 - 0. 999) 14 for: 5m labels: { severity: "critical", slo: "99. 9" }
annotations: { summary: "Fast burn >14x for 5m" }

10. 3 Жүйелік қанығу (CPU Throttling)

yaml
- alert: CPUThrottlingHigh expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1 for: 10m labels: { severity: "warning" }
annotations: { summary: "CPU throttling >10%" }

11) Логи: жинау, қалыпқа келтіру, ретеншн

Стандарттау: JSON-логтар: 'ts', 'level', 'service', 'trace _ id', 'user/tenant'.
Пайплайн: агент (Fluent Bit/Vector) → буфер → индекс/сақтау орны.
Редакция: шетінде PII/құпияларды бүркемелеу.
Ретеншн: жылдам сақтау сыныбы (7-14 күн), «салқын» мұрағат (30-180 күн).
Семантика: error budgets/депрекейттер - жеке арналар.

12) Трейдерлер және OpenTelemetry

Кіріс нүктелерін (gateway), клиент → қоңырау қызметі, ДҚ/кэштер/кезектерді құралдаңыз.
Жылдам навигация үшін метриканы Trace атрибуттарына (Exemplars) байланыстыру.
Орталық шлюз ретінде OTel Collector: сүзу, семплинг, таңдалған бекендтерге экспорттау.

yaml receivers: { otlp: { protocols: { http: {}, grpc: {} } } }
processors: { batch: {}, tail_sampling: { policies: [ { name: errors, type: status_code, status_codes: [ERROR] } ] } }
exporters: { prometheus: {}, otlp: { endpoint: "traces. sink:4317" } }
service:
pipelines:
metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }
traces: { receivers: [otlp], processors: [tail_sampling,batch], exporters: [otlp] }

13) Синтетика және сыртқы тексерулер

Бизнес-сценарийлердің HTTP-жүгірісі (логин, депозит, шығару, сатып алу).
TLS/Domain: CAA/DNS health.
Аймақтық: негізгі елдерден/провайдерлерден сынамалар (бағыттау/блок-парақтар).
Синтетика, егер пайдаланушыға қолжетімсіз болса, тіпті жасыл ішкі телеметрия кезінде де алерті болуы тиіс.

14) Профильдеу және eBPF

Continuous profiling: ыстық функцияларды, блоктауды анықтау.
eBPF: жүйелік оқиғалар (syscalls, TCP retransmits).
Парақсыз бейінді алерталар (тикеттер), ал релизден кейінгі регрессиялар үшін - кері қайтару сигналы ретінде.

15) Дашбордтар және «шындық панелі»

1. Platform Overview: SLI/SLO негізгі сервистер бойынша, error-budget, алерта.

2. API RED: Маршруттар бойынша RPS/ERRORS/DURATION.

3. K8s Cluster: control-plane, узлы, capacity headroom.

4. DB/Cache: lag/locks/slow query %, hit ratio.

5. Queues: backlog/lag, бас тарту/қайталау.

6. Per-release: метриктерді дейін/кейін салыстыру (канареялық терезелер).

7. FinOps: cost per namespace/service, idle/oversized ресурсы.

16) Инциденттер, алерт-шу және эскалациялар

Дедупликация: сервис/себеп бойынша топтастыру, каскадтарды басу.
Тыныштық/maintenance: релиздер/миграциялар барлығын қызыл бояуға тиіс емес.
Runbooks: диагностика қадамдары және кері қайтару «түймесі» бар әрбір қауіпті алерт.
Postmortem: таймлайн, не үйрендіңіз, қандай сигналдар қосылды/тазаланды.

17) Мониторингтегі қауіпсіздік

RBAC ережелерді/датасорларды оқу/түзету үшін.
Құпиялар: экспорттаушылардың/агенттердің токендері - Secret Manager арқылы.
Оқшаулау: клиенттердің/тенанттардың метрикасы - жеке кеңістікке/лейбге.
Тұтастығы: GitOps (мердж-ревью) арқылы агенттердің/билдтердің, конфигілердің қолы.

18) Қаржы және сыйымдылық (FinOps)

Квоталар мен бюджеттер; аномальды өсуге алерталар.
Right-sizing: сұрауларды/лимиттерді талдау, CPU/RAM кәдеге жарату, сыни емес тапсырмалар үшін спот-инстанциялар.
Тиімділік KPI ретінде «Cost per request/tenant».

19) Қарсы үлгілер

Теңшелетін SLI-сыз тек инфрақұрылымдық метриктер.
100 + алерт «барлығы туралы» → соқырлық on-call.
Логи жалғыз дереккөз ретінде (метрикасыз және трейсингсіз).
Нұсқасыз/ревьсіз мутабельді дашбордтар.
Синтетиканың жоқтығы: «бәрі жасыл», бірақ фронт қол жетімді емес.
Релиздермен байланыс жоқ: «Х сәтінде не өзгерді» деп жауап беруге болмайды.

20) Енгізу чек-парағы (0-60 күн)

0-15 күн

3-5 негізгі сервистер үшін SLI/SLO анықтау.
Базалық экспорттаушыларды/агенттерді қосу, JSON-логтарды стандарттау.
Tier-1 параметрлерін баптау (availability, 5xx, p95).

16-30 күн

Сыни сценарийлер бойынша синтетиканы қосу.
Кіріс/сыни сервистерде трейстерді (OTel) қосу.
«Per-release» және error-budget burn-ереже дашбордтары.

31-60 күн

ДБ/кезек/кэшті озық сигналдармен жабу.
High-CPU сервистері үшін eBPF/бейіндеуді енгізу.
Ережелер/дашбордтар/алерталар үшін GitOps, тұрақты шу тазалау.

21) Жетілу метрикасы

Негізгі сервистердің SLO жабу ≥ 95%.
MTTA/MTTR (мақсаты: мин/он минут).
Авто-әрекетпен немесе жылдам қайтарумен жабылған Tier-1 алерталарының үлесі.
«Пайдалы «/» шулы »тәуекелдердің қатынасы> 3:1.
Барлық «ақша» жолдарын синтетикамен жабу = 100%.

22) Қосымшалар: шағын үлгілер

Prometheus - мәртебе-сыныптар бойынша қолжетімділік

yaml
- record: job:http:availability:ratio_rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Grafana - канареяларға арналған кеңес

expr: histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket{version=~"stable    canary"}[5m])) by (le,version))

Alertmanager - кезекшілік және тыныштық

yaml receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true inhibit_rules:
- source_match: { severity: "critical" }
target_match: { severity: "warning" }
equal: ["service"]

23) Қорытынды

Мониторинг - бұл графиктердің жиынтығы емес, SRE операциялық жүйесі: сапа келісімшарты ретінде SLI/SLO, шындық көзі ретінде метрика/трейс/логи, басқарылатын сигнал ретінде алерта, «пайдаланушы дауысы» ретінде синтетика, өзгеріс тәртібі ретінде GitOps. Хосттан API-ге дейін бірыңғай контур жасаңыз, оны релиздерге және кері қайтуға байлаңыз - және платформа болжамды, жылдам және үнемді болады.