Логтарды орталықтандыру

1) Логтарды орталықтандырудың қажеті

• инциденттердің түбірін іздеуді жеделдетеді (request-id/trace-id бойынша корреляция);
• белгілерге (қателер, ауытқулар) дабыл алертін құруға мүмкіндік береді;
• аудит-ізін береді (кім/қашан/не жасады);
• ретенцияны біріздендіру және сақтау есебінен құнын төмендетеді.

2) Базалық қағидаттар

1. Тек құрылымдалған логтар (JSON/RFC5424) - кілтсіз «free-text» жоқ.
2. Бірыңғай кілт схемасы: 'ts, level, service, env, region, tenant, , , (masked), msg, kv...'.
3. Әдепкі корреляция: trace_id gateway бағдарламасынан бэкендерге және логтарға тастаңыз.
4. Шудың минимумы: дұрыс деңгейлер, семплинг, қайталаулардың дедупликациясы.
5. Қауіпсіздік by design: PII-бүркемелеу, RBAC/ABAC, өзгермейтін.
6. Экономика: hot/warm/cold, сығу, агрегаттау, TTL және rehydration.

3) Үлгілік сәулеттер

EFK/ELK: (Fluent Bit/Fluentd/Filebeat) → (Kafka — опц.) → (Elasticsearch/OpenSearch) → (Kibana/OpenSearch Dashboards). Әмбебап іздеу және агрегаттау.
Loki-ұқсас (белгілер бойынша логиндекстеу): Promtail/Fluent Bit → Loki → Grafana. Үлкен көлемдер үшін арзан, қуатты label-сүзгі + сызықты қарау.
Бұлттар: CloudWatch/Cloud Logging/Log Analytics + суық қоймаға (S3/GCS/ADLS) және/немесе SIEM-ге экспорттау.
Data Lake тәсілі: шипперлер → объектілік сақтау (parquet/iceberg) → соңғы N күн үшін арзан аналитикалық сұрау (Athena/BigQuery/Spark) + онлайн қабаты (OpenSearch/Loki).

Ұсыным: прод-онколл үшін онлайн (7-14 күн hot) және мұрағаттық (айлар/жылдар) қабатын rehydrate мүмкіндігімен lake-де ұстау.

4) Логтардың схемасы мен форматы (ұсыным)

json
{
"ts":"2025-11-01T13:45:12.345Z",
"level":"ERROR",
"service":"payments-api",
"env":"prod",
"region":"eu-central",
"tenant":"tr",
"trace_id":"0af7651916cd43dd8448eb211c80319c",
"span_id":"b7ad6b7169203331",
"request_id":"r-7f2c",
"user_id":"",        // masked
"route":"/v1/payments/charge",
"code":"PSP_TIMEOUT",
"latency_ms":1200,
"msg":"upstream PSP timeout",
"kv":{"provider":"psp-a","attempt":2,"timeout_ms":800}
}

Стандарттар: уақыт үшін RFC3339, 'TRACE/DEBUG/INFO/WARN/ERROR/FATAL' жиынтығынан level, кілттер snake_case.

5) Логизация және семплинг деңгейлері

DEBUG - тек dev/stage; тудың бойымен және TTL-мен.
INFO - сұраулардың/оқиғалардың өмірлік циклі.
WARN - SLO-ға әсер етпейтін күмәнді жағдайлар.
ERROR/FATAL - сұрау салуға/пайдаланушыға әсер ету.

• қайталанатын қателер үшін rate-limit (мысалы, 1/сек/кілт).
• tail-семплинг трассалары («жаман» сұраулар үшін ғана толық логин/трейстерді қалдыру).
• динамикалық: қателер дауылы кезінде нақтылауды азайту, жиынтықты сақтау.

6) Логтарды жеткізу (агенттер мен шипперлер)

Торапта: Fluent Bit/Filebeat/Promtail stdout файлдарын/журналдарын жинайды, парсинг, бүркемелеу, буферизация жасайды.
Желілік кезектер: Пиктерді, ретраларды тегістеуге және реттеуге арналған Kafka/NATS.
Сенімділігі: backpressure, дискілік буферлер, жеткізуді растау (at-least-once), идемпотенттік индекстер (кілт-хеш).
Шетінде сүзу: желіге түскенге дейін «сөйлесуді» және құпияларды тастау.

7) Индекстеу және сақтау

Уақыт бойынша партиялану (daily/weekly) + бойынша 'env/region/tenant' (индекс-шаблондар немесе лейблдер арқылы).

• Hot (SSD, 3-14 күн): жылдам іздеу және тәуекелдер.
• Warm (HDD/мұздатқыш, 30-90 күн): кейде іздейміз.
• Cold/Archive (объектілік, айлар/жылдар): комплаенс және сирек тергеулер.
• Қысу және ротациялау: ILM/ISM (өмірлік цикл саясаты), gzip/zstd, downsampling (агрегациялық кестелер).
• Rehydration: мұрағаттық партияларды тергеу үшін «ыстық» кластерге уақытша жүктеу.

8) Іздеу және талдау: типтік сұраулар

Оқыс оқиға: × 'service =...' × 'level> = ERROR' × 'trace _ id '/' request _ id'.
Провайдерлер: 'code: PSP _' және 'kv. provider: psp-a 'аймағы бойынша топтастырылған.
Аномалиялар: хабарламалар жиілігінің өсуі немесе өрістерді бөлудің ауысуы (ML-детекторлар, rule-based).
Аудит: 'category: audit' + 'actor '/' resource' + нәтижесі.

9) Метрикалармен және трассалармен корреляция

Бірдей идентификаторлар: 'trace _ id/span _ id' барлық үш сигналдарда (метриктер, логтар, трестер).
Сызбадан сілтемелер: p99 панелінен 'trace _ id' бойынша логтарға өту.
Релиздер аңдатпалары: жылдам байланыстыру үшін метриктер мен логтардағы нұсқалар/канареялар.

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

Өрістердің жіктелуі: PII/құпиялар/қаржы - кіре берісте жасыру немесе жою (Fluent Bit/Lua-сүзгілер, Re2).
RBAC/ABAC: рөлдер бойынша индекстерге/лейблдерге қолжетімділік, row-/field-level-security.
Аудит және реттеуіштер талаптары үшін өзгермейтін (WORM/append-only).
Ретенция және «ұмытылу құқығы»: TTL/кілттер бойынша жою, 'user _ id' токенизациясы.
Қолдар/хэштер: сындарлы журналдардың тұтастығы (әкімшілік іс-әрекеттер, төлемдер).

11) SLO және логтардың пайплайн метрикасы

Жеткізу: 99. Hot-қабаттағы оқиғалардың 9% ≤ 30-60 сек.
Шығындар: <0. 24 сағат бөлігінде 01% (бақылау белгілері бойынша).
Іздеу қолжетімділігі: ≥ 99. 28 күнде 9%.
Сұрау жасырындылығы: типтік сүзгілерде p95 ≤ 2-5 сек.
Құны: $/1M оқиғалар және $/сақтау/GB қабаттар бөлінісінде.

12) Дашбордтар (минимум)

Пайплайн денсаулығы: шипперлердің кіруі/шығуы, ретра, буферлерді толтыру, лаг Kafka.
Сервистер/кодтар бойынша қателер: топ-N, трендтер, перцентили 'latency _ ms'.
Аудит-белсенділік: әкімшілік-әрекеттер, провайдерлік қателер, қолжетімділік.
Экономика: көлем/күн, индекс-өсім, қабаттар бойынша құны, «қымбат» сұранымдар.

13) Операциялар және плейбуктер

Логтардың дауылы: агентте агрессивті семплинг/rate-limit қосу, буферлерді көтеру, ағынның бір бөлігін уақытша warm-ке ауыстыру.
Схеманың дрейфі: жаңа кілттердің/типтердің пайда болуына алерт, схемаларды келісуді іске қосу (schema-catalog).
Баяу іздеу: индекстерді қайта жинау, репликаларды ұлғайту, «ауыр» сұрауларды талдау, ескі партияларды мұрағаттау.
Қауіпсіздік инциденті: өзгермеушілікті дереу қосу, артефактілерді түсіру, рөлдер бойынша қолжетімділікті шектеу, RCA.

14) FinOps: ойықтарда қалай бұзылмау керек

Ауызша сөздерді алып тастаңыз: көп жолды stacktrace 'stack' өрісіне айналдырып, қайталауларды бөлектеңіз.
TTL қосыңыз: 'env '/' level '/' category' үшін әр түрлі.
Сирек қатынасу үшін Loki/Archives + on-demand rehydrate бағдарламасын пайдаланыңыз.
Партия және қысу: үлкен партия арзан, бірақ SLA іздеуді қадағалаңыз.
Жиі талдамалық есептерді (күнделікті агрегаттар) материалдандырыңыз.

15) Аспаптық мысалдар

Fluent Bit (бүркемелеу және OpenSearch қызметіне жіберу)

ini
[INPUT]
Name       tail
Path       /var/log/app/.log
Parser      json
Mem_Buf_Limit   256MB

[FILTER]
Name       modify
Match
Remove_key    credit_card, password

[OUTPUT]
Name       es
Host       opensearch.svc
Port       9200
Index       logs-${tag}-${date}
Logstash_Format  On
Suppress_Type_Name On

Nginx access log в JSON с trace_id

nginx log_format json escape=json '{ "ts":"$time_iso8601","remote":"$remote_addr",'
'"method":"$request_method","path":"$uri","status":$status,'
'"bytes":$body_bytes_sent,"ua":"$http_user_agent","trace_id":"$http_trace_id"}';
access_log /var/log/nginx/access.json json;

OpenSearch ILM саясаты (hot → warm → delete)

json
{
"policy": {
"phases": {
"hot":  { "actions": { "rollover": { "max_age": "7d", "max_size": "50gb" } } },
"warm": { "min_age": "7d", "actions": { "forcemerge": { "max_num_segments": 1 } } },
"delete":{ "min_age": "90d", "actions": { "delete": {} } }
}
}
}

16) Енгізу чек-парағы

• Өрістер схемасы мен логтардың деңгейлері қабылданды; trace/request-id корреляциясы қосылған.
• Бүркемелеу және буферлері бар агенттер (Fluent Bit/Promtail) теңшелді.
• Онлайндық қабат (OpenSearch/Loki/бұлт) және мұрағат (S3/GCS + parquet) таңдалды.
• ILM/ISM + hot/warm/cold ретенция саясаты, rehydrate-процесс.
• RBAC/ABAC, аудит үшін өзгермейтін, қол жеткізу журналы.
• Пайплайн дашбордтары, жоғалту/лаг/дискілік буферлер.
• Плейбуктар: дауыл, сызба дрейфі, баяу іздеу, security-инцидент.
• Қаржылық лимиттер: $/1М оқиғалар, «қымбат» сұраныстарға квоталар.

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

Құрылымы жоқ мәтіндік логтар → сүзу және біріктіру мүмкін емес.
INFO → көлеміндегі үлкен stacktrace.
Корреляцияның жоқтығы → Барлық сервистер бойынша «дірілдеу».
Сақтау «бәрібір» → ұшақ сияқты бұлт үшін есеп.
Құпиялар/PII логтарда → комплаенс-тәуекелдер.
Өнімдегі индекстерді қолмен түзету → дрейф және ұзақ іздеу кідірістері.

18) Қорытынды

Логтарды орталықтандыру - жай стек емес, жүйе. Стандартты схема, корреляция, қауіпсіз шпилькалар, қабатты сақтау және қатаң қолжетімділік саясаты логтарды SRE, қауіпсіздік және өнім үшін қуатты құралға айналдырады. Дұрыс ретенциялар мен FinOps бюджетті сақтайды, ал SLO пайплайндар мен плейбуктер тергеуді жылдам және ойнатылатын етеді.