ლოგოს კონვეიერები: ELK და Loki

1) რატომ და როდის: ლანდშაფტის მიზნები

დაკვირვება და RCA: დაჩქარება დაჩქარებული, პოსტ-mortem, SLO/SLA კონტროლი.
უსაფრთხოება და აუდიტი: წვდომის კვალი, ანომალიები, გამოძიება.
ბიზნეს მეტრიკა: კონვერტაცია, გადახდის ფლეშ, PSP შეცდომები, მომხმარებლის ქცევა.
შესაბამისობა: PII- ის შენახვა, შენიღბვა, ჭრის პოლიტიკა, ლეგალური ჰოლდი.

ლოგოების ტიპები: დანართი, ინფრასტრუქტურული (kubelet, kube-proxy, CNI, ingress), ქსელი, აუდიტი, გადახდა, ვებ-მოვლენები, Nginx/Envoy, BD.

2) მაღალი დონის არქიტექტურები

ვარიანტი A: ELK

Producers → Logshipper (Filebeat/Fluent Bit/Vector) → Logstash/Beats input → Elasticsearch → Kibana/Алертинг

ვარიანტი B: Loki

Producers → Promtail/Fluent Bit → Loki distributor/ingester/querier → Grafana/Алертинг

ჰიბრიდი

ELK სრულ ტექსტში/ფასებში მოსაძებნად, ლოკი იაფი მასშტაბური შენახვისთვის და სწრაფი მსუქანი მსგავსი მოთხოვნებისთვის; კორელაცია მეტრიკებით/ბილიკებით გრაფანაში.

3) მონაცემთა ნაკადი და დამუშავების დონე

1. კოლექცია: ორმაგი tail ფაილები, journald, syslog, stdout კონტეინერები, HTTP.
2. გამდიდრება: timestamp- ის ნორმალიზაცია, host/pod/namespace, env (wish/stage), release, commit SHA, trace/spank id.
3. პარსინგი: JSON - flat fields; grok/regex; Nginx/Envoy ფორმატები; გადახდის სქემები (PSP შეცდომების კოდი).
4. ფილტრაცია/გამოცემა: მოჭრა PII (PAN, CVV, ელ.ფოსტა, მისამართები), საიდუმლოებები, ნიშნები.
5. Routing: tenant/service/log დონის მიხედვით; hot/warm/cold; S3/ობიექტში.
6. შენახვა და ჭრა: TTL პოლიტიკა მონაცემთა კლასებში.
7. წვდომა/ანალიტიკა/ალერტა.

4) ELK: ძირითადი გადაწყვეტილებები

4. 1 Logstash/Beats

გამოიყენეთ Beats/Fluent Bit მსუბუქი კოლექციონერის კოდებზე, Logstash - როგორც ცენტრალური ETL (grok, dissect, mutate, geoip, translate).
Pulls Logstash: ingest-ETL, უსაფრთხოების-ETL, payments-ETL - დატვირთვის იზოლირებისთვის.

4. 2 Elasticsearch

შარდვა: ფოკუსირება 20-50 GB ჰარდზე; მოერიდეთ შარდის აფეთქებას.
ინდექსების სტრატეგია: 'logs- <tenant> - <სერვისი> - YYYY. MM. DD 'ან მონაცემთა ნაკადები; როლოვერის ზომა/დრო.

• ცხელი: SSD, 1-7 დღე; warm: HDD, 7-30 დღე; ცივი: მოცულობითი; frozen: მინიმალური ღირებულება უფრო ნელი დაშვებით.
• Mappings: მკაცრად ასახეთ ველები, შეზღუდეთ 'fielddata' და შექმნათ დინამიური ველები.
• ქეში და მოთხოვნები: ფილტრები keyword მინდვრებში, აგრეგატები - სისუფთავე; მაღალი სიხშირის ძებნისთვის pin-hot.

4. 3 Kibana

სივრცეები (Spaces) მულტფილმისთვის.
Saved searches, Lens/TSVB, threshold/metric alerts.
RBAC ინდექსის ნიმუშებზე ('logs-tenant-').

5) ლოკი: ძირითადი გადაწყვეტილებები

5. 1 ეტიკეტის მოდელი

ეტიკეტები ლოკის „ინდექსია“. გამოიყენეთ დაბალი კარდინალი: 'cluster', 'namespace', 'app', 'level', 'env', 'tenant'.
მაღალი კარდინალური ველები (uid, request _ id) - სტრიქონში; ამოიღეთ LogQL '| =', 'json', '| regexp'.

5. 2 კომპონენტები

Promtail: сбор stdout, files, journald; პარსერები (JSON, regex, cri).
Distributor/Ingester/Querier/Query-frontend: როლების მასშტაბები; მოთხოვნის ქირა.
Object Storage (S3/GCS/MinIO) ჩანკის ლოგების გრძელვადიანი შენახვისთვის.

5. 3 LogQL ხრიკები

სწრაფი გრიპი: '{app = "payments", level = "error" | = "declined" "

Парсинг JSON: `{app="api"} | json | code="5xx" | unwrap duration | avg()`

კორელაცია მეტრიკებთან: 'rate ({app = "nginx" | = "200" [5 მ]) "

6) შედარება ELK vs Loki (მოკლედ)

ძებნა/აგრეგაცია: ELK უფრო ძლიერია რთული ტექსტისა და ფასადის მოთხოვნებისთვის; Loki - grep-like, სწრაფი და იაფი.
ღირებულება: ლოკი ხშირად იაფია დიდი მოცულობით (ობიექტის საცავი + მცირე ინდექსი).
ოპერაციის სირთულე: ELK მოითხოვს დისციპლინებს ინდექსებში/ILM, Javu-hipam; ლოკი - დისციპლინები ეტიკეტებში.
კორელაცია მეტრიკებთან/ტრასებთან: ლოკი ბუნებრივად ინტეგრირდება Grafana/OTel დასტთან; ELK- ს ასევე შეუძლია, მაგრამ უფრო ხშირად ინტეგრაციის გზით.

7) უსაფრთხოება და შესაბამისობა

PII გამოცემა ზღვარზე: შენიღბეთ PAN, ელ.ფოსტა, ტელეფონი, მისამართები, ნიშნები.
TLS in transit, mTLS აგენტებსა და საბურავებს შორის.
RBAC: per-tenant ინდექსები/ეტიკეტები; ნეიმსპეისების/სივრცეების იზოლაცია.
Secrets hygiene: გარემოს ცვლადი საიდუმლოებების გარეშე, ცალკეული საიდუმლო მენეჯერები.
Legal Hold: სეგმენტების/ინდექსების გაყინვის მექანიზმი; სადავო პერიოდებისთვის write-once.
მოცილება/რეცენზია: TTL პოლიტიკოსები მონაცემთა კლასებში (stateful/გადახდა/აუდიტი).
ლოგებზე წვდომის აუდიტის ბილიკები.

8) საიმედოობა და გამტარუნარიანობა

ბუფერიზაცია და დაბალანსება: ადგილობრივი ფაილები/დისკები აგენტებისთვის; retrais ექსპონენციალური backoff- ით.
Idempotence: ველები 'ingest _ id '/' log _ id' გამეორების დროს დუბლების თავიდან ასაცილებლად.
HA: მინიმუმ 3 ნოდა ES ოსტატებისთვის/Loki ingesters; antiaffinity по AZ.
კვოტები და საბადოები/მომსახურება; დაცვა „ქარიშხლისგან“.
ლოგოების დონის სქემა: 'ERROR' შეზღუდულია, 'DEBUG' მხოლოდ დროებით დინამიური დროშების საშუალებით.

9) პროდუქტიულობა და ტიუნინგი

• JVM heap 50% RAM (მაგრამ ~ 30-32 GB თითო Noda), page cache მნიშვნელოვანია.
• ჭკვიანი rollover (20-50 GB/shard), 'refresh _ interval' - ingest ინდექსებისთვის.
• Logstash- ში თავიდან აიცილეთ „მძიმე“ ჯგუფი; თუ ეს შესაძლებელია, JSON ლოგიკა წყაროზე.

• სწორი ეტიკეტის ნაკრები სიჩქარის გასაღებია.
• დიდი მონეტები იაფია, ვიდრე შენახვა, მაგრამ მეხსიერება უფრო ძვირია, ვიდრე ingester; დაბალანსება.
• Query-frontend + ქეში (mem/Redis) განმეორებითი მოთხოვნებისთვის.

10) FinOps ლოგებისთვის (ღირებულება)

ველების/ეტიკეტების კარდინალურობის შემცირება.
Sampling DEBUG და დინამიური „ლოგის სანთლები“.
როტაცია: მოკლე ცხელი, გრძელი ცივი ობიექტში.
დედუპლიკაცია და კონსოლიდირებული შეტყობინებები.
იშვიათად გამოყენებული ლოგების არქივირება შენახვის იაფი კლასებში.
დაშბორდის ღირებულება: მოცულობა/მონაცემთა ნაკადი/ეტიკეტი/ინდექსები/ტენანტები.

11) კორელაცია მეტრიკებით და ბილიკებით (Observability 3-in-1)

Trace-ID/Span-ID თითოეულ ლოგში (middleware API კარიბჭეებზე და მომსახურებებში).
OpenTelemetry: ერთი კონტექსტი; ექსპორტიორები Tempo/Jaeger- ში, მეტრიკები Prometheus/Mimir- ში, Loki/ELK- ში.
სწრაფი სცენარები: „მეტრიანი ალერტი - გადახტომა შესაბამის ლოგოებში - ტრასაზე გადახტომა“.

12) მულტფილმები და იზოლაცია

Namespace-based იზოლაცია (K8s labels), ინდივიდუალური ინდექსის ნიმუშები/ეტიკეტები 'tenant'.
ალერტების/დაშბორდების/რეტენსების დაყოფა ტენანტში.
ბილინგი მოხმარებისთვის: ინვესტიციის მოცულობა, სცენა, მოთხოვნები.

13) მონიტორინგი და SLO თავად კონვეიერისთვის

SLO ingest: «99. ლოგოების 9% მიეწოდება

SLO ძებნა: „p95 მოთხოვნა <Y წამი“.
ტექნიკური მეტრიკა: queue depth, dropped logs, reprocess rate, error rate parsers, ingester/ES nod- ის უარყოფა.

14) ტიპიური განლაგების სქემები

Managed: Elasticsearch Service/Opensearch, Grafana Cloud Loki.
Self-hosted K8s: StatefulSets ES/Loki- სთვის, AZ anti-affinity, PersistentVolumes, ობიექტის საცავი.
Edge აგენტები (პროგრამები რეგიონებში): ადგილობრივი ბუფერი + TLS არხი ცენტრალური ინსტანციისთვის.

15) კონფიგურაციის მაგალითები

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 (ingest და შენიღბვა)

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) ალერტინგი და დაშბორდი (შაბლონები)

Ошибки API: `rate({app="api",level="error"}[5m]) > threshold` → PagerDuty/Telegram.
5xx სიჩქარე Nginx/Envoy- ში; ინჯესტი აგენტებში; მზარდი ძებნა.

• ლოგოების მოცულობა სერვისებში/ტენანტებში.
• შეცდომების ტოპ ნიმუშები (კოდი/გამონაკლისი/endpoint).
• ჭრის/საცავის კლასების ღირებულება.

17) ხარისხის შემოწმება (log-QA)

ლანდშაფტის ხელშეკრულებები: JSON ფორმატი, სავალდებულო ველები ('ts', 'level', 'service', 'env', 'trace _ id', 'msg').
Linter Logs in CI: ახალი ველების აკრძალვა მაღალი კარდინალობით, კოორდინაციის გარეშე.
კანარის მომსახურება: საცნობარო ლოგოების წარმოება რეგრესიების ადრეული გამოვლენისთვის.

18) ხშირი შეცდომები და საწინააღმდეგო ნიმუშები

Loki ეტიკეტები მაღალი კარდინალურობით ('user _ id', 'request _ id') - მეხსიერების აფეთქება.
დინამიური ველები ES- ში მპინგების გარეშე არის „ინდექსების აფეთქება“.
DEBUG გაყიდვაში „სამუდამოდ“. ჩართეთ დროშები და TTL.
PII გამოცემის არარსებობა.
ყველაფრისთვის ერთი ზოგადი „მონოლითური“ კონვეიერი უკეთესია, ვიდრე დომენების სეგმენტები.

19) განხორციელების გეგმა (გამეორება)

1. MVP: აგენტები + ერთი დალუქვა (პროგრამები), ძირითადი დაშბორდები, PII გამოცემა.
2. გაფართოება: ქსელის/ინფრა-ლოგები, SLO ალერტები, კორელაცია ბილიკებით.
3. FinOps: retenshn მატრიცა, ღირებულების ანგარიში, ეტიკეტის/ინდექსების ოპტიმიზაცია.
4. მრავალ ჩრდილში: სივრცეები, RBAC, მოხმარების ბილინგი.
5. საიმედოობა: HA, disaster-drills, Legal Hold.

20) გაშვების ჩეკის სია პროდ

• JSON ფორმატი და სავალდებულო ველები ყველა სერვისში.
• PII ნიღაბი აგენტზე/ინგესტზე.
• ჭრის პოლიტიკოსები/ILM ან bucket-lifecycle.
• RBAC/სივრცეები/ტენანტები.
• SLO ingest/ძებნა და ალერტები.
• კანარის ლოგები და სატესტო ჭრილობა დატვირთვით.
• დაშბორდები ღირებულება და ანგარიში მომსახურების მფლობელების შესახებ.
• Runbooks: „რა უნდა გავაკეთოთ, თუ ingest დაეცა/ძებნა ნელი/საშინელებათა წითელი“.

21) მინი-FAQ

რა უნდა აირჩიოს - ELK ან Loki?