Инфраструктурага мониторинг жүргүзүү

Инфраструктураны көзөмөлдөө

1) Максаттары жана алкагы

• Колдонуучудан мурда мүчүлүштүктөр жөнүндө эскертүү (эрте детекция).
• Түпкү себебин аныктоо (from symptom to cause).
• SLO-гейтинг релиздерди жана auto-rebound колдоо.
• Пост-окуя талдоо (evidence as data).

Колдоо принциптери: Observable by design, азыраак ызы-чуу - көбүрөөк сигналдар, реакцияларды автоматташтыруу, бир чындык панели.

2) Triad байкоо

Метрика (убакыт): ылдамдыгы/суроо-талап/каталар/каныккандыгы (USE/RED).
Логи: контекстте окуя деталдаштыруу; сыр/PII камтылган эмес.
Tracks: себептик байланыштар менен бөлүштүрүлгөн мамиле.

• Профилирование (CPU/heap/lock/io), системалык деңгээл үчүн eBPF.
• Events/аудит (K8s Events, конфигурацияларды/сырларды өзгөртүү).

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

SLI (көрсөткүч): 'availability', 'error _ rate', 'p95 _ latency', 'queue _ lag'.
SLO (максаты): "ийгиликтүү суроо ≥ 99. 9% 30 күндүн ичинде".
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. CPU/Load/Steal, RAM/Swap, Disk IOPS/Latency, Filesystem.
2. Network/LB/DNS: RTT, топтомдор/тамчылар, backlog, SYN/Timeout, health-probes.
3. Kubernetes/Orchestrator: API Server, etcd, контроллерлор, scheduler; pod/түйүндөр, 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`.
Podd: 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) Alerting түзүлүшү

Tier-1 (пейдж): SLO таасир окуялар (жеткиликтүүлүгү, 5xx, жашыруун, кластердик маанилүү компоненттердин иштебей).
Tier-2 (билет): сыйымдуулуктун бузулушу, SLO таасир жок каталардын өсүшү.
Tier-3 (маалымат): тенденциялар, болжолдуу кубаттуулук, мөөнөтү өтүп бара жаткан сертификаттар.

Эскалациялоонун эрежелери: жымжырттык убактысы/дубликаттарды кысуу, on-call ротациясы, "күн-күн".

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) Логи: чогултуу, нормалдаштыруу, retenshn

Стандартташтыруу: JSON-логи: 'ts', 'level', 'service', 'trace _ id', 'user/tenant'.
Pipeline: агент (Fluent Bit/Vector) → буфер → индекси/сактоо.
Редакция: PII/сырларды четине жашыруу.
Retenshn: тез сактоо класс (7-14 күн), "муздак" архив (30-180 күн).
Семантика: error budgets/депрекейттер - өзүнчө каналдар.

12) Соода жана OpenTelemetry

Кирүү пункттарын (gateway), кардар → чалуулар кызматы, DD/кэш/кезек куралы.
Тез багыттоо үчүн 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/Домен: күбөлүктөрдүн мөөнөтү/CAA/DNS ден соолук.
Регионалдуулук: негизги өлкөлөрдүн/провайдерлердин үлгүлөрү (багыттоо/блок баракчалар).
Синтетика да жашыл ички телеметрия менен, колдонуучу үчүн жеткиликтүү эмес болсо, алертика керек.

14) Profile & eBPF

Continuous profiling: ысык өзгөчөлүктөрүн аныктоо, бөгөт коюу.
eBPF: Системалык окуялар (syscalls, TCP retransmits), минималдуу overhead менен прода.
Профилдик алерталар баракчасыз (тикеттер), ал эми релизден кийинки регрессиялар үчүн - кайтаруу сигналы сыяктуу.

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 окуу/эрежелерди өзгөртүү/datasors.
Сырлар: экспорттоочулардын/агенттердин токендери - Secret Manager аркылуу.
Изоляция: кардарлардын/тенанттардын метрикасы - өзүнчө мейкиндиктерге/лейблдерге.
Бүтүндүк: GitOps (мердж-ревю) аркылуу агенттердин/имараттардын кол тамгасы, конфиги.

18) Каржы жана кубаттуулугу (FinOps)

Квоталар жана бюджеттер; анормалдуу өсүү үчүн аллергия.
Right-sizing: суроо-талаптарды/чектерди талдоо, CPU/RAM утилдештирүү, маанилүү эмес тапшырмалар үчүн спот-инстанциялар.
"Cost per request/tenant" катары KPI натыйжалуулугу.

19) Анти-үлгүлөрү

Атайын SLI жок гана инфраструктуралык метриктер.
100 + alertov "бардык жөнүндө" → сокур on-call.
Logi бир гана булагы катары (метрика жана Trace жок).
Мутабель дашборддор жок версиялоо/ревю.
Синтетика жоктугу: "баары жашыл", бирок фронт жеткиликтүү эмес.
Релиздер менен байланыш жок: "X учурда эмне өзгөрдү" деп жооп бере албайсың.

20) киргизүү чек-тизмеси (0-60 күн)

0-15 күн

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

16-30 күн

критикалык жагдайлар боюнча синтетика кошуу.
Кирүү/критикалык кызматтарда сооданы (OTel) киргизүү.
Dashboard "Per-release" жана error-budget burn-эрежелери.

31-60 күн

Advanced сигналдар менен DD/кезек/кэш жаап.
Жогорку-CPU кызматтары үчүн eBPF/профилдөөнү киргизүү.
GitOps эрежелери/dashboard/alerts, үзгүлтүксүз ызы-чуу тазалоо.

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

Негизги кызматтардын SLO камтуу ≥ 95%.
MTTA/MTTR (максаты: мин/он мүнөт).
Авто-аракет же тез артка кайтаруу менен жабылган Tier-1 алерталарынын үлүшү.
"Пайдалуу "/" ызы-чуу "alertov катышы> 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ге чейин бирдиктүү контур куруп, аны релиздерге жана артка кайтарууларга байлап, платформа алдын ала айтууга болот, тез жана үнөмдүү болот.