Müşahidə yığını

1) Niyə müşahidə yığını lazımdır

Sürətli RCA və MTTR azalması: simptomdan səbəbə dəqiqə ərzində.
SLO-nəzarət: səhvlərin/gizli ölçülməsi, səhv büdcə ilə alertinq.
Relizlərə nəzarət: kanareya hesablamaları, metrik avtomatik rollback.
Təhlükəsizlik və audit: giriş yolları, anomaliyalar, Legal Hold.
FinOps-şəffaflıq: saxlama/sorğu dəyəri, cost-per-SLO.

Metodologiyalar: Golden Signals (latency/traffic/errors/saturation), RED, USE.

2) Əsas yığın arxitekturası

Laylara görə komponentlər

Yığım/agentlər: Exporters, Promtail/Fluent Bit, OTel SDK/Auto-Instr, Blackbox-probes.
Шина/ingest: Prometheus remote_write → Mimir/Thanos, Loki distributors/ingesters, Tempo/Jaeger ingesters.
Saxlama: obyekt S3/GCS/MinIO (uzun soyuq), SSD (isti sıra).
Sorğular/Vizuallaşdırma: Grafana (panellər, SLO-widgets), Kibana (əgər ELK).
İdarəetmə: Alertmanager/Qrafana-alertlər, xidmət kataloqu, RBAC, gizli menecer.

Yerləşdirmə nümunələri

Managed (Grafana Cloud/bulud xidmətləri) - həcmdə tez və daha bahalı.
Self-hosted in K8s - tam nəzarət, istismara ehtiyac və FinOps.

3) Məlumat standartları: vahid «müşahidə sxemi»

3. 1 Metrika (Prometheus/OpenMetrics)

Məcburi etiketlər: 'env', 'region', 'cluster', 'namespace', 'service', 'version', 'tenant' (əgər multi-tenant varsa), 'endpoint'.
Adı: 'snake _ case', '_ total', '_ seconds', '_ bytes' şəkilçiləri.
Histoqramlar: sabit 'buckets' (SLO yönümlü).
Kardinallıq: 'user _ id', 'request _ id' etiketlərə daxil edilmir.

3. 2 Logi

Format: JSON; 'ts', 'level', 'service', 'env', 'trace _ id', 'span _ id', 'msg'.
PII: agentdə maskalanma (PAN, tokenlər, e-mail və s.).
Loki-etiketlər: yalnız aşağı kardinallıq ('app', 'namespace', 'level', 'tenant').

3. 3 Marşrutlar

OTel semantika: 'service. name`, `deployment. environment`, `db. system`, `http.`.
Sampling: p99 hədəf yolları - 'always _ on '/tail-sampling, qalanları -' parent/ratio '.
ID-nin daxil edilməsi: 'trace _ id/span _ id' -ni log və metriklərə (labels/fields) atın.

4) Korrelyasiya M-L-T (Metrics/Logs/Traces)

Alert qrafikindən (metrika) → 'trace _ id' → xüsusi marşrut üzrə filtrlənmiş loqlar.
Track (yavaş span) → span intervalında xüsusi arxa tərəfin metrik sorğusu.
Panellərdəki Drilldown düymələri: dəyişənlər ('$env', '$service', '$trace_id') ilə «yuvalara» və «yollara».

5) OpenTelemetry Collector: istinad paypline

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) Alerting: SLO və multi-burn

Fikir: alertim «CPU> 80%» səviyyəsində deyil, Error Budget istehlakındadır.

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) Daşbordlar: qovluqların strukturu

00_Overview platforması: SLO, p95, 5xx%, capacity, aktiv hadisələr.
10_Services - RPS, p95/p99, səhvlər, buraxılışlar (annotasiyalar).
20_Infra - K8s/nodes/storage/network, etcd, nəzarətçilər.
30_DB/Queues — PostgreSQL/Redis/Kafka/RabbitMQ.
40_Edge/DNS/CDN/WAF - ingress, LB, WAF qaydaları.
50_Synthetic - aptaym və headless ssenariləri.
60_Cost/FinOps - saxlama, sorğular, isti/soyuq, proqnoz.

Hər panel: təsvir, vahidləri, sahibi, runbook-link, drilldown.

8) Log: LogQL Practicum

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) Trass: TraceQL və fokuslar

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

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

10) Sintetika və aptaym

Blackbox-exporter: ≥ 3 regiondan HTTP/TCP/TLS/DNS testləri/ASN.
Headless: login/deposit script cədvəli.
Quorum-alertlər: 2 regionun ≥ uğursuzluq görürsə, işləmək.
Status-səhifə: avtomatik yeniləmələr + əl şərhləri.

11) Saxlama və retrenşn

Metrik: isti 7-30 gün (sürətli sıra), downsampling/recording rules, soyuq - obyekt saxlama (ay).
Loki: 3-7 gün isti, sonra - indeks ilə S3/GCS (Loki chunk store/ELK ILM).
Marşrutlar: 3-7 gün 'always _ on' + seçim üçün uzun müddət saxlama (tail-sampled/rədd).

• Rollover ölçüsü və vaxt; sorğular üçün büdcə (kvota/limit).
• Prod/stage və təhlükəsizlik məlumatları üçün ayrı-ayrı siyasətlər.

12) Multi-tenant və giriş

'tenant '/' namespace '/Spaces, indeks-nümunələri və icazələri bölün.
Billing üçün resursları etiketləyin: 'tenant', 'service', 'team'.
İdxal daşbordları/alertlər - xüsusi komandaların məkanlarında.

13) Təhlükəsizlik və uyğunluq

TLS/mTLS agentlərdən bekendlərə, xüsusi sağlamlıq üçün HMAC.
RBAC oxumaq/yazmaq, bütün sorğular və alertlər audit.
kənarda PII-redaksiya; loqlarda sirlərin qadağan edilməsi; DSAR/Legal Hold.
İzolyasiya: həssas domenlər üçün ayrı-ayrı klasterlər/nişanlar.

14) FinOps: müşahidə dəyəri

Etiketlərin kardinallığını və məntiqini ingest (sorğularda deyil) azaldır.
Kritik yollar üçün sampling yolları + hədəf always-on.
ağır aqreqasiya üçün Downsampling/recording rules.
Soyuq obyektə nadir giriş arxivi.
Метрики: `storage_cost_gb_day`, `query_cost_hour`, `cost_per_rps`, `cost_per_9`.

15) CI/CD və müşahidə testləri

CI-də metrik/log lintinqi: «partlayış» kardinallığının qadağan edilməsi, histoqramların/vahidlərin yoxlanılması.
Contract-müşahidə testləri: məcburi ölçülər/log sahələri, 'trace _ id' middleware.
Canary: qraflarda relizlər, SLO-auto-rollback.

16) Nümunələr: sürətli sorğular

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' -ni Tempo UI/dashboard linki kimi verin.

17) Yığını keyfiyyəti: çek siyahısı

• Metrik/yuva/trass və ölçü vahidlərinin razılaşdırılmış sxemləri.
• 'trace _ id' log və metriklərdə, panellərdən drilldown.
• Multi-burn SLO-alertlər (quorum/multi-window).
• Downsampling, sorğu kvotaları, addım/diapazon limitləri.
• Retrenshn və saxlama sinifləri sənədləşdirilmiş və tətbiq olunur.
• RBAC/audit/PII-redaktə daxildir.
• Dashboard: sahibi, runbooks, ≤ 2-3 ekran, sürətli cavab.
• FinOps-dashboard (həcmləri, dəyəri, top danışanlar).

18) Tətbiq planı (3 iterasiya)

1. MVP (2 həftə): Prometheus → Mimir, Loki, Tempo; OTel Collector; əsas daşbordlar və SLO-alertlər; blackbox sınaqları.
2. Scale (3-4 həftə): tail-sampling, downsampling, multi-region ingest, RBAC/Spaces, FinOps-dashboard.
3. Pro (4 + həftə): SLO auto-rollback, əsas yolların headless-sintetikası, Legal Hold, SLO portfeli və hesabat.

19) Anti-nümunələr

«SLO olmadan gözəl qrafiklər» - heç bir hərəkət → fayda yoxdur.
Yüksək kardinallığı olan etiketlər ('user _ id', 'request _ id') - yaddaş və dəyər partlayışı.
JSON olmadan və 'trace _ id' olmadan qeydlər - heç bir korrelyasiya yoxdur.
Simptomlar əvəzinə resurslara görə alertlər - səs-küy və on-call tükənməsi.
Retenshn siyasətinin olmaması - xərclərin nəzarətsiz artımı.

20) Mini-FAQ

Nə seçmək lazımdır: Loki və ya ELK?
Çətin axtarış/faset üçün ELK; Loki - grep kimi ssenarilər üçün daha ucuz və daha sürətli. Hibrid tez-tez istifadə olunur.

Hər kəsin marşrutlara ehtiyacı varmı?
Bəli, heç olmasa tail-sampling ilə əsas yollarda (login, checkout, payments) - bu RCA-nı kəskin sürətləndirir.

Sıfırdan necə başlamaq olar?
OTel Collector → Mimir/Loki/Tempo → əsas SLO və blackbox testlər → sonra dashboard və burn-alert.

Yekun

Müşahidə yığını müxtəlif alətlər toplusu deyil, razılaşdırılmış sistemdir: vahid məlumat standartları → M-L-T korrelyasiyası → SLO-alertinq və sintetika → təhlükəsizlik və FinOps. Sxemləri, etiket və retenshn intizamını düzəldin, OTel qoşun, drilldown və auto-rollback əlavə edin - və başa düşülən dəyərlə idarə olunan etibarlılıq əldə edəcəksiniz.