Бақылау стегі

1) Бақылау стегі не үшін қажет

Жылдам RCA және MTTR төмендеуі: симптомнан себебіне минутына.
SLO-басқару: қателерді/жасырындылықты өлшеу, қате бюджет бойынша алертинг.
Релиздерді бақылау: канареялық құрылғылар, авто-rollback өлшемдері бойынша.
Қауіпсіздік және аудит: қол жеткізу жолдары, аномалиялар, Legal Hold.
ФинОпс-ашықтық: сақтау/сұрау құны, cost-per-SLO.

Әдіснамалар: Golden Signals (latency/traffic/errors/saturation), RED, USE.

2) Стектің базалық сәулеті

Қабаттар бойынша компоненттер

Жинау/агенттер: Exporters, Promtail/Fluent Bit, OTel SDK/Auto-Instr, Blackbox-probes.
Шина/ingest: Prometheus remote_write → Mimir/Thanos, Loki distributors/ingesters, Tempo/Jaeger ingesters.
Сақтау орындары: объектілік S3/GCS/MinIO (ұзақ суық), SSD (ыстық қатарлар).
Сұраулар/визуализация: Grafana (панельдер, SLO-виджеттер), Kibana (егер ELK болса).
Басқару: Alertmanager/Графана-алерты, сервис-каталог, RBAC, құпия-менеджер.

Орналастыру үлгілері

Managed (Grafana Cloud/бұлтты сервистер) - көлемде жылдам және қымбат.
Self-hosted in K8s - толық бақылау, пайдалануды қажет және FinOps.

3) Деректер стандарттары: бірыңғай «бақылау схемасы»

3. 1 Өлшемдер (Prometheus/OpenMetrics)

Міндетті лейблдер: 'env', 'region', 'cluster', 'namespace', 'service', 'version', 'tenant' (егер мульти-тенант болса), 'endpoint'.
Атауы: 'snake _ case', '_ total', '_ seconds', '_ bytes' суффикстері.
Гистограммалар: бекітілген 'buckets' (SLO-бағытталған).
Түбірлігі: 'user _ id', 'request _ id' лейблдерге қосылмайды.

3. 2 Логтар

Пішімі: JSON; міндетті өрістер 'ts', 'level', 'service', 'env', 'trace _ id', 'span _ id', 'msg'.
PII: агентте бүркемелеу (PAN, токендер, e-mail және т.б.).
Loki-лейблдер: тек төменгі кардиналдылық ('app', 'namespace', 'level', 'tenant').

3. 3 Трассалар

OTEL семантикасы: 'service. name`, `deployment. environment`, `db. system`, `http.`.
Сэмплинг: мақсатты жолдар p99 - 'always _ on '/tail-sampling, қалғаны -' parent/ratio '.
ID ендіру: 'trace _ id/span _ id' дегенді логиндер мен өлшемдерге (labels/fields) тастаңыз.

4) M-L-T корреляциясы (Metrics/Logs/Traces)

Алерт кестесінен (метрика) → сүзілген логтар бойынша 'trace _ id' → нақты трасса.
Трассадан (баяу спан) → спан аралығындағы нақты бэкендтің метрикасын сұрату.
Айнымалыларды ('$env', '$service', '$trace_id') алмастырумен «логтар» және «трассалар» панелдеріндегі Drilldown түймешіктері.

5) OpenTelemetry Collector: эталондық пайплайн

yaml receivers:
otlp:
protocols: { http: {}, grpc: {} }
prometheus:
config:
scrape_configs:
- job_name: kube-nodes static_configs: [{ targets: ['kubelet:9100'] }]

processors:
batch: {}
memory_limiter: { check_interval: 1s, limit_mib: 512 }
attributes:
actions:
- key: deployment. environment value: ${ENV}
action: insert tail_sampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code: { status_codes: [ERROR] }
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/payments","/login"] }
- name: probabilistic type: probabilistic probabilistic: { sampling_percentage: 10 }

exporters:
otlphttp/mimir: { endpoint: "https://mimir/api/v1/push" }
otlphttp/tempo: { endpoint: "https://tempo/api/traces" }
loki:
endpoint: https://loki/loki/api/v1/push labels:
attributes:
env: "deployment. environment"
service: "service. name"

service:
pipelines:
metrics: { receivers: [prometheus, otlp], processors: [memory_limiter, batch], exporters: [otlphttp/mimir] }
logs:   { receivers: [otlp], processors: [batch], exporters: [loki] }
traces:  { receivers: [otlp], processors: [memory_limiter, attributes, tail_sampling, batch], exporters: [otlphttp/tempo] }

6) Алертинг: SLO және multi-burn

Идея: алертим «CPU> 80%» деңгейінде емес, Error Budget тұтынуында.

promql
5-minute error rate err_ratio_5m =
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m]))

Quick burn (1m window)
(err_ratio_1m / (1 - SLO)) > 14. 4

Slow burn (30m)
(err_ratio_30m / (1 - SLO)) > 2

promql latency_p95 =
histogram_quantile(0. 95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

7) Дашбордтар: папка құрылымы

00_Overview - платформа: SLO, p95, 5xx%, capacity, белсенді оқиғалар.
10_Services - RPS, p95/p99, қателер, релиздер (аннотациялар) сервистері бойынша.
20_Infra - K8s/нодтар/сторидж/желі, etcd, бақылаушылар.
30_DB/Queues — PostgreSQL/Redis/Kafka/RabbitMQ.
40_Edge/DNS/CDN/WAF - ingress, LB, WAF ережелері.
50_Synthetic - аптайм және headless-сценарийлер.
60_Cost/FinOps - сақтау, сұрау салу, ыстық/суық, болжам.

Әрбір тақтасы: сипаттамасы, бірліктері, иесі, runbook-сілтемесі, drilldown.

8) Логи: LogQL практикум

logql
API errors
{app="api", level="error"}     = "Exception"

Nginx 5xx in 5 minutes
{app="nginx"}      json      status=~"5.."      count_over_time([5m])

Extract Fields
{app="payments"}      json      code!=""      unwrap duration      avg()

9) Трассалар: TraceQL және фокустар

{ service. name = "api" }      duration > 500ms

{ name = "HTTP GET /order" }      child. span. name = "SELECT" & child. duration > 50ms

10) Синтетика және аптайм

Blackbox-exporter: ≥ 3 аймақтан HTTP/TCP/TLS/DNS сынамалары/ASN.
Headless: кесте бойынша login/deposit сценарийі.
Quorum-алерты: егер 2 өңірдің ≥ істен шыққанын көрсе іске қосылу.
Статус-бет: автоматты жаңартулар + қолмен түсініктемелер.

11) Сақтау және ретеншн

Метрика: ыстық 7-30 күн (жылдам қатарлар), downsampling/recording rules, суық - объектілік сақтау орны (айлар).
Логи: ыстық 3-7 күн, содан кейін - индексі бар S3/GCS (Loki chunk store/ELK ILM).
Трассалар: 3-7 күн 'always _ on' + іріктемелер үшін ұзақ сақтау (tail-sampled/жарамсыз).

• Өлшемі мен уақыты бойынша ролловер; сұрау салуларға арналған бюджет (квоталар/лимиттер).
• prod/stage және қауіпсіздік деректеріне арналған жеке саясаттар.

12) Мульти-тенанттық және қол жетімділік

'tenant '/' namespace '/Spaces, индекс-үлгілер және рұқсаттар бойынша бөліңіз.
Биллинг үшін ресурстарды таңдаңыз: 'tenant', 'service', 'team'.
Импорттық дашбордтар/алерттар - нақты командалар кеңістігінде.

13) Қауіпсіздік және комплаенс

Агенттерден бекендтерге дейін TLS/mTLS, жеке денсаулық үшін HMAC.
RBAC оқуға/жазуға, барлық сұрау салулар мен тәуекелдерді аудиттеуге арналған.
PII - шетіндегі редакция; логтарда құпияларға тыйым салу; DSAR/Legal Hold.
Оқшаулау: сезімтал домендер үшін жеке кластерлер/неймспейстер.

14) ФинОпс: бақылау құны

Ингест (сұрауларда емес) лейблдер мен логиканың түбегейлігін төмендетеміз.
Сыни жолдар үшін трассалар + мақсатты always-on сэмплингі.
Ауыр агрегациялар үшін Downsampling/recording rules.
Суық объектіге сирек қол жеткізуді мұрағаттау.
Метрики: `storage_cost_gb_day`, `query_cost_hour`, `cost_per_rps`, `cost_per_9`.

15) CI/CD және бақылау тестілері

CI-дегі метриктердің/логтардың линтингі: кардиналдылықтың «жарылысына» тыйым салу, гистограммаларды/бірліктерді тексеру.
Contract-бақылау тестілері: міндетті метриктер/логтардың өрістері, 'trace _ id' middleware.
Canary: бағандардағы релиздердің аңдатпалары, SLO-авто-rollback.

16) Мысалдар: жылдам сұраулар

promql topk(10, sum by (route) (rate(http_requests_total{status=~"5.."}[5m])))

promql sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m])) > 0

promql max by (topic, group) (kafka_consumergroup_lag)

(Loki → Tempo): 'trace _ id' дегенді Tempo UI/дэшбордқа сілтеме ретінде беріңіз.

17) Стек сапасы: чек-парақ

• Метрикалардың/логтардың/трассалардың және өлшем бірліктерінің келісілген схемалары.
• 'trace _ id' логтар мен метриктерде, панельдерден drilldown.
• Multi-burn SLO-флаппингсіз алерталар (quorum/multi-window).
• Downsampling, сұрау квоталары, қадам/диапазон лимиттері.
• Ретеншн және сақтау сыныптары құжатталған және қолданылады.
• RBAC/аудит/PII-редакция қосылған.
• Дашбордтар: иесі, runbooks, ≤ 2-3 экран, жылдам жауап.
• ФинОпс-дашборд (көлемі, құны, топ-сөйлеушілер).

18) Енгізу жоспары (3 итерация)

1. MVP (2 апта): Prometheus → Mimir, Loki, Tempo; OTel Collector; базалық дашбордтар және SLO-алерттар; blackbox-сынамалар.
2. Scale (3-4 апта): tail-sampling, downsampling, мульти-аймақ ingest, RBAC/Spaces, FinOps-дашбордтар.
3. Pro (4 + апта): SLO бойынша auto-rollback, негізгі жолдардың headless-синтетикасы, Legal Hold, SLO портфелі және есептілік.

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

«SLO жоқ әдемі графиктер» - әрекет жоқ → пайда жоқ.
Кардиналдылығы жоғары лейблдер ('user _ id', 'request _ id') - жадының және құнының жарылысы.
JSON жоқ және 'trace _ id' жоқ логтар - корреляция жоқ.
Ресурстар бойынша алерталар симптомдардың орнына - шу және on-call күйуі.
Ретеншн-саясаттың болмауы - шығындардың бақылаусыз өсуі.

20) Mini-FAQ

Не таңдау керек: Loki немесе ELK?
Күрделі іздеу/фасеттер үшін ELK; Loki - grep-ұқсас сценарийлер үшін арзан және жылдам. Гибридті жиі қолданады.

Барлығына трассалар керек пе?
Иә, ең болмағанда негізгі жолдарда (login, checkout, payments) tail-sampling - бұл RCA-ны күрт жылдамдатады.

Нөлден қалай бастауға болады?
OTel Collector → Mimir/Loki/Tempo → базалық SLO және blackbox-сынамалар → содан кейін дашбордтар мен burn-алерталар.

Жиынтығы

Бақылау стегі - шашыраңқы құралдар жиынтығы емес, келісілген жүйе: бірыңғай деректер стандарттары → M-L-T корреляциясы → SLO-алертинг және синтетика → қауіпсіздік және FinOps. Сызбаларды, лейблдер мен ретеншн тәртібін бекітіңіз, OTel қосыңыз, drilldown және auto-rollback қосыңыз - және сіз түсінікті құнмен басқарылатын сенімділікке ие боласыз.