Conducte jurnal: ELK și Loki

1) De ce și când: obiective de exploatare forestieră

Observabilitate și RCA: accelerație Debag, post-mortem, control SLO/SLA.
Securitate și audit: urme de acces, anomalii, investigații.
Valori de afaceri: conversie, fluxul de plăți, erori PSP, comportamentul utilizatorului.
Conformitate: stocare, PII mascare, politici de retenție, Legal Hold.

Tipuri de jurnale: aplicație, infrastructură (kubelet, kube-proxy, CNI, ingress), rețea, audit, plată, evenimente web, Nginx/Envoy, bază de date.

2) Arhitecturi de nivel înalt

Opțiunea A: ELK

Producatori Logshipper (Filebeat/Fluent Bit/Vector) Logstash/Beats intrare Elasticsearch

Opțiunea B: Loki

Producători Promtail/Fluent Bit Loki distribuitor/ingester/querier

Hibrid

ELK pentru căutare full-text/fațetă, Loki pentru stocare scalabilă low-cost și interogări rapide asemănătoare graficului; corelație cu valorile/urmele din Grafana.

3) Fluxul de date și nivelurile de prelucrare

1. Colecție: fișiere coadă octet, jurnal, syslog, containere stdout, HTTP.
2. Îmbogățire: normalizare timestamp, gazdă/pod/namespace, env (prod/stage), eliberare, comite SHA, urme/span id.
3. Parsing: JSON → câmpuri plate; grok/regex; Formate Nginx/Envoy; scheme de plată (coduri de eroare PSP).
4. Filtrare/editare: taie PII (PAN, CVV, e-mail, adrese), secrete, jetoane.
5. Rutare: prin nivel chiriaș/serviciu/jurnal; cald/cald/rece; pentru a S3/object depozitarea.
6. Stocare și păstrare: politica TTL pe clase de date.
7. Access/Analytics/Alerte.

4) ELK: soluții cheie

4. 1 Logstash/Bătăi

Utilizați Beats/Fluent Bit pe noduri pentru alegere ușoară, Logstash ca ETL central (grok, disect, mutate, geoip, translate).
Piscine Logstash: ingera-ETL, securitate-ETL, plăți-ETL - pentru a izola încărcături.

4. 2 Căutare elastică

Sharding: se concentreze pe ~ 20-50 GB pe ciob; evita o „explozie de cioburi”.
Strategie index: 'logs- <chirias> - <service> -AAAA. MM. DD' sau fluxuri de date; rollover după mărime/timp.

• fierbinte: SSD, 1-7 zile; cald: HDD, 7-30 zile; rece: volumetrică; congelate: cost minim cu acces mai lent.
• Mappings - Câmpuri de tip greu, restricționați datele de teren și creați câmpuri dinamice.
• Cache și interogări: filtre după câmpuri de cuvinte cheie, agregate - frumos; pin-la-fierbinte pentru căutare de înaltă frecvență.

4. 3 Kibana

Spații pentru multi-chirie.
Căutări salvate, Lens/TSVB, valori prag/alertă.
RBAC după index-modele („busteni-tenant-”).

5) Loki: decizii cheie

5. 1 Model de etichetă

Etichetele sunt indexul lui Loki. "Utilizați cardinalitate scăzută: 'cluster', 'namespace', 'app', 'level', 'env', 'chiriaș'.
Câmpuri cu cardinalitate ridicată (uid, request_id) - la rând; recuperează '| =', '| json', '| regexp' atunci când este interogat prin LogQL.

5. 2 Componente

Promtail: сбор stdout, fișiere, jurnal; parsers (JSON, regex, cri).
Distribuitor/Ingester/Querier/Interogare frontend: scalare după rol; solicita caching.
Stocarea obiectelor (S3/GCS/MinIO) pentru stocarea pe termen lung a jurnalelor de bucăți.

5. 3 Tehnici LogQL

Fast grep: '{app = „plăți”, level =” eroare”} | = „refuzat”'

Парсинг JSON: ' {app =” api”} | json | code =” 5xx” | durata de despachetare | avg ()'

Corelație cu valorile: 'rate ({app = "nginx"} | = "200" [5m] "

6) ELK vs Loki comparație (pe scurt)

Căutare/agregare: ELK este mai puternic pentru interogări complete complexe și fațete; Loki - grep-like, rapid și ieftin.
Cost: Loki este adesea mai ieftin pe volume mai mari (stocare obiect + index mai mic).
Complexitatea operațională: ELK necesită disciplină în indici/ILM, Javu-șolduri; Loki - discipline de etichetare.
Corelație cu valorile/urmele: Loki se integrează în mod natural cu stiva Grafana/OTel; ELK știe, de asemenea, cum, dar mai des prin integrare.

7) Siguranță și conformitate

Ediție PII pe margine (expeditor): mască PAN, e-mail, telefon, adrese, jetoane.
TLS în tranzit, mTLS între agenți și autobuze.
RBAC: indici/etichete per chiriaș; izolarea spațiilor/spațiilor neimspaces.
Secretele igienei: variabile de mediu fără secrete, manageri secreți individuali.
Legal Hold: segment/index mecanism de congelare; scrie-o dată pentru perioade disputate.
Ștergere/păstrare: politici TTL pe clase de date (prod/statful/payments/audit).
Log trasee de audit de acces.

8) Fiabilitate și debit

Tamponare și backpressure: fișiere/discuri locale pentru agenți; se retrage cu backoff exponențial.
Idempotency: 'ingest _ id'/' log _ id' fields pentru a evita duplicatele în timpul duplicatelor.
HA: minim 3 noduri pentru Loki ES masters/ingesters; antiafinitate по AZ.
Cote și limite de rată de către chiriaș/serviciu; protecție împotriva exploatării forestiere „furtuni”.
Log level scheme: „EROARE” limitat, „DEPANARE” numai temporar prin steaguri dinamice.

9) Performanță și tuning

• JVM heap 50% RAM (dar ≤ ~ 30-32 GB pe nod), cache-ul paginii este important.
• Rollover inteligent (20-50 GB/shard), „refresh _ interval” ↑ pentru indici de ingerare.
• În Logstash, evitați grokul „greu”; dacă este posibil, JSON logare la sursa.

• Setul corect de etichete este cheia vitezei.
• Bucăți mari → stocare mai ieftină, dar memorie mai scumpă la ingestie; echilibru.
• Interogare-frontend + cache (meme/Redis) pentru cereri repetate.

10) FinOps pentru busteni (cost)

Scăderea cardinalității câmpurilor/etichetelor.
DEPANARE eșantionare și dinamică „comutatoare jurnal”.
Rotație: scurt cald, lung la rece pentru a obiecta.
Eliminarea duplicatelor și a mesajelor consolidate (lot).
Arhivarea jurnalelor rar utilizate la clase de stocare ieftine.
Tablou de bord valoare: volum/fluxuri de date/etichete/indici/chiriași.

11) Observabilitate 3-în-1

Trace-ID/Span-ID la fiecare jurnal (middleware pe gateway-uri și servicii API).
OpenTelemetry: context unic; exportatori către Tempo/Jaeger, valori către Prometheus/Mimir, jurnale către Loki/ELK.
Scenarii rapide: „alertă prin → metrice sari în jurnalele corespunzătoare → sari în pistă”.

12) Multi-chirie și izolare

Izolarea bazată pe namespace (etichete K8s), modele/etichete de index separate „chiriaș”.
Separarea alertelor/tablourilor de bord/retenschna de către chiriaș.
Facturarea consumului: volumul de ingerare, depozitare, cereri.

13) Monitorizarea și SLO pentru transportorul în sine

SLO ingera: "99. 9% busteni livrate

Căutare SLO: „p95 interogări <Y sec”.
Măsurători tehnice: adâncimea cozii, jurnalele scăzute, rata de reprocesare, rata de eroare a parserului, eșecul nodului ingester/ES.

14) Scheme tipice de implementare

Gestionat: Elasticsearch Service/Opensearch, Grafana Cloud Loki.
K8s auto-găzduit: StatefulSets pentru ES/Loki, anti-afinitate pentru AZ, PersistentVolumes, stocarea obiectelor.
Agenți de margine (aplicații în regiuni): tampon local + canal TLS la ingerarea centrală.

15) Exemple de configurare

15. 1 Promtail (K8s, CRI JSON)

yaml scrape_configs:
- job_name: kubernetes-pods kubernetes_sd_configs:
- role: pod pipeline_stages:
- cri: {}
- json:
expressions:
level: level msg: message trace: trace_id
- labels:
level:
app:
namespace:
- match:
selector: '{namespace="prod"}'
stages:
- regex:
expression: '(?P<pan>\b[0-9]{12,19}\b)'
- replace:
expression: '(?P<pan>\b[0-9]{12,19}\b)'
replace: '[REDACTED_PAN]'
relabel_configs:
- action: replace source_labels: [__meta_kubernetes_pod_label_app]
target_label: app
- action: replace source_labels: [__meta_kubernetes_namespace]
target_label: namespace
- action: replace source_labels: [__meta_kubernetes_pod_node_name]
target_label: node

15. 2 Logstash (ingerare și mascare)

ruby input {
beats { port => 5044 }
}
filter {
json { source => "message" skip_on_invalid_json => true }
mutate { add_field => { "env" => "%{[kubernetes][labels][env]}" } }
PII mutate {
gsub => [
"message", "\b[0-9]{12,19}\b", "[REDACTED_PAN]",
"message", "(?i)(authorization: Bearer)([A-Za-z0-9\.\-_]+)", "\1[REDACTED_TOKEN]"
]
}
}
output {
elasticsearch {
hosts => ["https://es-hot-1:9200","https://es-hot-2:9200"]
index => "logs-%{[fields][tenant]}-%{[app]}-%{+YYYY. MM. dd}"
ilm_enabled => true ssl => true cacert => "/etc/ssl/certs/ca. crt"
user => "${ES_USER}"
password => "${ES_PASS}"
}
}

16) Alertare și tablouri de bord (șabloane)

Ошибки API: 'rate ({app = „api „, level =” error”} [5m])> prag '→ PagerDuty/Telegram.
5xx splash în Nginx/Trimisul; picătură ingera în agenți; creșterea căutării latenței.

• Volumul de busteni de servicii/chiriasi.
• Modele de eroare de top (cod/excepție/punct final).
• Costul prin clase de retenție/stocare.

17) Controale de calitate (log-QA)

Contracte de logare: format JSON, câmpuri obligatorii ('ts',' level ',' service ',' env ',' trace _ id', 'msg').
Linter înregistrează în CI: interzicerea unor noi câmpuri cu cardinalitate ridicată fără acord.
Servicii canare: generarea de jurnale de referință pentru detectarea precoce a regresiilor.

18) Erori frecvente și anti-modele

Etichetele Loki cu cardinalitate ridicată ('user _ id',' request _ id') → o explozie de memorie.
Câmpuri dinamice în ES fără cartografiere → „explozie index”.
DEPANARE în vânzare "pentru totdeauna. "Porniți de steaguri și cu TTL.
Absența revizuirii PII.
O conductă comună „monolit” pentru tot - segmente mai bune de domeniu.

19) Planul de implementare (iterații)

1. MVP: agenți + o conductă (aplicații), tablouri de bord de bază, ediție PII.
2. Extensie: rețea/infra-jurnale, alerte SLO, corelație cu piese.
3. FinOps: matrice de retenție, raport cost, etichetă/optimizare index.
4. Multi-chiriaș: spații, RBAC, facturare consum.
5. Fiabilitate: HA, exerciții de dezastre, Legal Hold.

20) Lista de verificare a lansării în producție

Formatul JSON și câmpurile necesare în toate serviciile.

• PII mascare pe/ingera agent.
• Politici de retenție/ILM sau ciclul de viață al găleții.
• RBAC/spații/chiriași.
• SLO ingera/căutare și alerte.
• Jurnalele canare și testul de sarcină.
• Tablouri de bord de valoare și raport privind proprietarii de servicii.
• Runbooks: „ce să faci dacă ingera scăzut/căutare lent/cioburi roșii”.

21) Mini-Întrebări frecvente

Ce să alegeți - ELK sau Loki?