Müşahidə: log, metrika, izləmə

Müşahidə: log, metrika, izləmə

1) Niyə lazımdır

• Metriklər - simptomlara görə SLI/SLO və alertinq üçün kompakt aqreqatlar.
• Tracking - səbəb-nəticə sorğu zəncirləri (end-to-end).
• Logi - araşdırma və audit üçün ətraflı hadisələr.

Məqsəd: sürətli RCA, qabaqlayıcı risklər və error budget çərçivəsində idarə olunan etibarlılıq.

2) Memarlıq prinsipləri

Vahid kontekst: hər yerə 'trace _ id', 'span _ id', 'tenant _ id', 'request _ id', 'user _ agent', 'client _ ip _ hash' atırıq.
Standartlar: SDK/agentlər üçün OpenTelemetry (OTel), JSON-log formatı (kanonik, sxemli).
Simptomlar> səbəblər: CPU-ya görə deyil, istifadəçi simptomlarına görə alertim (gecikmə/səhv).
Siqnalların əlaqəsi: metrikadan → spana (exemplars) → 'trace _ id' -ə qədər.
Təhlükəsizlik və məxfilik: loqlarda PII maskalama, in transit/at rest şifrələmə, audit üçün dəyişməz jurnallar.
Multi-icarə: ad/açar/siyasət boşluqlarının ayrılması.

3) Siqnalların taksonomiyası və sxemləri

3. 1 Metrika

Xidmətlər üçün RED (Rate, Errors, Duration) və infrastruktur üçün USE (Utilization, Saturation, Errors).
Типы: counter, gauge, histogram/summary. Latentlik üçün - sabit bucket ilə histogram.
Exemplars: «isti» histoqram binalarında 'trace _ id' linki.

name: http_server_duration_seconds labels: {service, route, method, code, tenant}
type: histogram buckets: [0. 01, 0. 025, 0. 05, 0. 1, 0. 25, 0. 5, 1, 2, 5]
exemplar: trace_id

3. 2 Tracking

Span = 'name', 'start/end', 'attributes', 'events', 'status' ilə əməliyyat.
Dözümlülük üçün W3C Trace Context.
Nümunə: əsas (head) + dinamik (tail) + «əhəmiyyət» qaydaları (səhvlər, yüksək p95).

3. 3 Logi

Yalnız strukturlaşdırılmış JSON; səviyyələri: DEBUG/INFO/WARN/ERROR.
Məcburi sahələr: 'ts _ utc', 'level', 'message', 'trace _ id', 'span _ id', 'tenant _ id', 'env', 'service', 'region', 'host', 'labels {}'.
Qadağandır: sirlər, tokenlər, PAN, şifrələr. PII - yalnız tokenləşdirilmiş/maskalanmış.

json
{"ts":"2025-10-31T12:05:42. 123Z","level":"ERROR","service":"checkout","env":"prod",
"trace_id":"c03c...","span_id":"9ab1...","tenant_id":"t-42","route":"/pay",
"code":502,"msg":"payment gateway timeout","retry":true}

4) Yığım və nəqliyyat

Agentlər/ixracatçılar (daemonset/sidecar) → düyün bufer → şin/ingest (TLS/mTLS) → siqnallar saxlama.
Tələblər: back-pressure, retrajlar, deduplikasiya, kardinallığın məhdudlaşdırılması (labels!), «log storms» -dan qorunma.

Metrik: pull (Prometheus uyğun) və ya OTLP vasitəsilə push.
Tracking: OTLP/HTTP (gRPC), kollektor tail-samplers.
Log: lokal toplama (journald/docker/stdout) → parser → normallaşdırıcı.

5) Saxlama və retensiya (tiered)

Metrik: isti TSDB 7-30 gün (downsample ilə), daha uzun müddət üçün aqreqatlar (90-365 gün).
Tracking: 1-7 gün tam, sonra aqqreqatlar/span «vacib» xidmətlər; indeksləri saxlamaq üçün 'service', 'status', 'error'.
Logi: isti indeks 7-14 gün, isti 3-6 ay, arxiv qədər 1-7 il (komplayens). Audit - WORM.

Xərclərin optimallaşdırılması: downsampling, DEBUG filtrasiya, etiket kvotaları, trass üçün sampling.

6) SLI/SLO, alertinq və vəzifə

SLI: əlçatanlıq (% uğurlu sorğular), gecikmə (p95/p99), 5xx payı, məlumatların təzəliyi, uğurlu gob payı.
SLO: SLI hədəfi (məsələn, 99. 9% uğurlu ≤ 400 ms).
Error budget: 0. 1% «səhv hüququ» → fichfries/eksperimentlər qaydaları.

• `ALERT HighLatency` если `p99(http_server_duration_seconds{route="/pay"}) > 1s` 5мин.
• `ALERT ErrorRate` если `rate(http_requests_total{code=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0. 02`.
• Silos-alertlər (CPU/Disk) - yalnız paging olmadan köməkçi kimi.

7) Siqnalların korrelyasiyası

Metrika «qırmızı» → tıklayın exemplar → konkret 'trace _ id' → baxın «yavaş» span → açın log eyni 'trace _ id'.
Relizlərlə korrelyasiya: 'version', 'image _ sha', 'feature _ flag' atributları.
/ ETL məlumatları üçün: 'dataset _ urn', 'run _ id', lineage ilə əlaqə (müvafiq məqaləyə baxın).

8) Sampling və kardinallıq

Metriklər: etiketləri məhdudlaşdırın ('user _ id', 'session _ id' olmadan); qeydiyyat zamanı kvotalar/validasiya.
Tracking: head-sample (girişdə) və tail-sample (kollektorda) qaydaları ilə birləşdirin: «hər şey 5xx, p99, səhvlər - 100%».
Log: səviyyələri və drosselizasiya; tez-tez təkrarlanan səhvlər üçün - yığma hadisələr (dedupe açarı).

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_code: ERROR rate_allocation: 1. 0
- type: latency threshold_ms: 900 rate_allocation: 1. 0
- type: probabilistic hash_seed: 42 sampling_percentage: 10

9) Təhlükəsizlik və məxfilik

In Transit/At Rest: şifrələmə (TLS 1. 3, AEAD, KMS/HSM).
PII/sirləri: göndərilmədən əvvəl dezinfeksiyaedici, tokenizasiya, maskalanma.
Giriş: ABAC/RBAC oxu; rolların bölünməsi producers/readers/admins.
Audit: log/trass dəyişməz giriş jurnalı; ixrac - şifrələnmiş formada.
Multi-icarə: siyasətçilərlə namespaces/tenant-labels; şifrələmə açarları izolyasiya.

10) Konfiqurasiya profilləri (fraqmentlər)

yaml global: { scrape_interval: 15s, evaluation_interval: 30s }
scrape_configs:
- job_name: 'app'
static_configs: [{ targets: ['app-1:8080','app-2:8080'] }]
rule_files: ['slo. rules. yaml']

yaml groups:
- name: http_slo rules:
- record: job:http_request_duration_seconds:p99 expr: histogram_quantile(0. 99, sum(rate(http_server_duration_seconds_bucket[5m])) by (le,route))
- alert: HighLatencyP99 expr: job:http_request_duration_seconds:p99{route="/pay"} > 1 for: 5m

python provider = TracerProvider(resource=Resource. create({"service. name":"checkout","service. version":"1. 8. 3"}))
provider. add_span_processor(BatchSpanProcessor(OTLPExporter(endpoint="otel-collector:4317")))
set_tracer_provider(provider)
with tracer. start_as_current_span("pay", attributes={"route":"/pay","tenant":"t-42"}):
business logic pass

python log. info("gw_timeout", extra={"route":"/pay","code":502,"trace_id":get_trace_id()})

11) Data/ETL və axın

Məlumatlar üçün SLI: təzəlik (max lag), tamlıq (rows vs expectation), «keyfiyyət» (validatorlar/duplicatlar).
Alertlər: pəncərə keçidi, konsumer gecikməsi, DLQ böyüməsi.
Korrelyasiya: 'run _ id', 'dataset _ urn', lineage hadisələri; payplayns üçün izlər (batch/partition üçün span).
Kafka/NATS: metrik prodüser/konsumer, lag/imtina; headers izləri (o cümlədən 'traceparent').

12) Profil və eBPF (əlavə siqnal)

Aşağı səviyyəli isti CPU/alloc/IO yolları; hadisə profilləri.
eBPF-telemetriya (şəbəkə gecikmələri, DNS, sistem zəngləri) 'trace _ id '/PID ilə əlaqələndirilir.

13) Müşahidə testləri

Siqnalların müqaviləsi: CI-yə metrik/etiket/histoqramların ixracının yoxlanılması.
Synthetic probes: RUM ssenariləri/xarici SLI üçün simulyasiya müştərilər.
Chaos/Fire drills: asılılığın söndürülməsi, deqradasiya - alertlərin və növbətçilərin necə reaksiya verdiyinə baxın.
Prod Smoke: Yeni end nöqtələrinin metrik və izləri olduğunu post-deploy yoxlama.

14) Dəyəri və həcminə nəzarət

Siqnal/əmr üzrə büdcələr; dashboard «cost per signal».
Büdcə altında kardinallıq (cardinality SLO), yeni etiketlərə limitlər.
Downsampling, məlumat sinifləri, «soyuq» arxivlər və audit üçün WORM.

15) Əməliyyat və SLO müşahidə platforma

SLO platformaları: 99. 9% uğurlu ingestlər; metrik indeksə qədər gecikmə ≤ 30 s, log ≤ 2 dəq, trek ≤ 1 dəq.
Platformanın alertləri: enjest laqası, damcıların böyüməsi, imza/şifrələmə xətası, buferlərin aşması.
DR/HA: multi-zonallıq, replikasiya, konfiqurasiya/qaydaların ehtiyat surətləri.

16) Çek vərəqləri

• Hər yerdə 'trace _ id '/' span _ id'; sxemi ilə JSON-log.
• Histoqramlarla RED/USE metrikası; exemplar → trass.
• Tail-sampling daxildir; 5xx/p99 = 100% qaydaları.
• Simptomlara görə alertlər + Runibuki; sakit saat/anti-flap.
• PII dezinfeksiyaedicilər; at rest/in transit şifrələmə; Audit üçün WORM.
• Həcm/kardinallıq üçün retensiyalar və büdcələr.

• Aylıq Alert Review (səs-küy/dəqiqlik), eşik sazlama.
• Error budget hesabatı və görülən tədbirlər (fichfries, hardening).
• Kritik yollar üçün dashboard/log/trass örtüklərinin yoxlanılması.
• Təlim hadisələr və runbook yeniləmə.

17) Runbook’и

RCA: p99/pay artımı

1. 'checkout' üçün RED dashboard açın.
2. exemplar → yavaş trek → «dar span» (məsələn, 'gateway. call`).
3. 'trace _ id' → vasitəsilə qeydləri açın.
4. RPS-in geri qaytarılması/limiti, asılılıq sahiblərini xəbərdar edin.
5. Sabitləşmədən sonra - RCA, optimallaşdırma biletləri, oynatma testi.

1. SLI «təravət» qırmızı → cob track → failing addım.

2. Broker lag/DLQ, bağlayıcı səhvləri yoxlayın.

3. status kanalı vasitəsilə istehlakçıları (BI/məhsul) xəbərdar reprocess başlayın.

18) Tez-tez səhvlər

Sxem olmadan və 'trace _ id' olmadan qeydlər. Araşdırmalar xeyli uzanır.
simptomlar əvəzinə infrastruktur alertlər. Paging «süd» gedir.
Metriklərin sonsuz kardinallığı. Xərclərin partlaması və qeyri-sabitlik.
Bütün marşrutlar 100% təşkil edir. Bahalı və lazım deyil; ağıllı sempleme daxil edin.
PII/log sirləri. Sanitizatorları və «qırmızı siyahıları» daxil edin.
«Dilsiz» fiçlər. Metrik/trass/log olmadan yeni kod.

19) FAQ

S: Xam log mətnini saxlamaq lazımdırmı?
A: Bəli, lakin retensiya və arxiv ilə; alert və SLO üçün kifayət qədər aqreqat var. Audit - WORM-də.

S: Yollar üçün nə seçmək lazımdır - head və ya tail sampling?
A: Kombinasiya: əsas örtük üçün head-probabilistic + səhvlər və anomaliyalar üçün tail-rules.

S: Xüsusi metrika və texniki əlaqə necə?
A: Ümumi 'trace _ id' və biznes etiketləri ('route', 'tenant', 'plan'), eləcə də məhsul hadisələri (dönüşümlər) ilə yollara korrelyasiya.

S: Alertlərdə boğulmamaq üçün necə?
A: Simptomlara görə döymək, səssiz saatlar, deduplikasiya, qruplaşma, SLO prioritetləşdirmə və hər bir alert üçün default sahibi.

• «Audit və dəyişməz jurnallar»
• «Transit/At Rest şifrələmə»
• «Sirlərin menecmenti»
• «Məlumatların mənşəyi (Lineage)»
• «Privacy by Design (GDPR)»
• «Webhook çatdırılma zəmanətləri»