خطوط لوله ورود به سیستم: ELK و Loki

1) چرا و چه زمانی: اهداف ورود به سیستم

قابلیت مشاهده و RCA: شتاب دباگ، پس از مرگ، کنترل SLO/SLA.
امنیت و حسابرسی: ردیابی دسترسی، ناهنجاری ها، تحقیقات.
معیارهای کسب و کار: تبدیل، جریان پرداخت، خطاهای PSP، رفتار کاربر.
انطباق: ذخیره سازی، ماسک PII، سیاست های نگهداری، نگهداری قانونی.

انواع سیاهههای مربوط: برنامه، زیرساخت (kubelet، kube-proxy، CNI، ingress)، شبکه، حسابرسی، پرداخت، رویدادهای وب، Nginx/Envoy، پایگاه داده.

2) معماری سطح بالا

گزینه A: ELK

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

گزینه B: لوکی

تولید کنندگان → Promtail/Fluent Bit → توزیع کننده Loki/ingester/querier → Grafana/Алертинг

ترکیبی

ELK برای جستجوی کامل متن/چهره، Loki برای ذخیره سازی مقیاس پذیر کم هزینه و پرس و جوهای سریع مانند نمودار ؛ ارتباط با معیارها/ردیابی در Grafana.

3) جریان داده ها و سطوح پردازش

1. مجموعه: فایل های بایت دم، مجله، syslog، ظروف stdout، HTTP.
2. غنی سازی: نرمال سازی زمان، میزبان/غلاف/فضای نام، env (prod/stage)، انتشار، مرتکب SHA، شناسه ردیابی/span.
3. تجزیه: JSON → زمینه های مسطح ؛ grok/regex ؛ قالب های Nginx/Envoy طرح های پرداخت (کدهای خطای PSP).
4. فیلتر کردن/ویرایش: برش PII (PAN، CVV، ایمیل، آدرس)، اسرار، نشانه ها.

5. مسیریابی: توسط مستاجر/خدمات/سطح ورود به سیستم ؛ گرم/گرم/سرد ؛ برای S3/object انبار

6. ذخیره سازی و نگهداری: سیاست TTL توسط کلاس داده.
7. دسترسی/تجزیه و تحلیل/هشدارها.

4) ELK: راه حل های کلیدی

4. 1 ذخیره سازی/ضربه

استفاده از بیت بیت بیت/Fluent در گره ها برای جمع آوری آسان، Logstash به عنوان ETL مرکزی (grok، dissect، mutate، geoip، translate).
استخرهای ذخیره سازی: مصرف-ETL، امنیت-ETL، پرداخت-ETL - برای جداسازی بارها.

4. 2 الستیک سرچ

شاردینگ: تمرکز بر ~ 20-50 گیگابایت در هر شارد ؛ جلوگیری از «انفجار»

استراتژی شاخص: 'logs- - -YYYY. MM. DD 'یا جریان داده ؛ رول اور بر اساس اندازه/زمان.

• داغ: SSD، 1-7 روز ؛ گرم: HDD، 7-30 روز ؛ سرد: حجمی ؛ منجمد: حداقل هزینه با دسترسی کندتر.
• Mappings - فیلدهای نوع سخت، محدود کردن داده های میدانی و ایجاد زمینه های پویا.
• کش و نمایش داده شد: فیلتر های زمینه های کلمه کلیدی, aggregates - منظمی; پین به گرم برای جستجوی فرکانس بالا.

4. 3 کیبانا

فضا برای چند اجاره.
جستجوهای ذخیره شده، Lens/TSVB، معیارهای آستانه/هشدار.
RBAC توسط الگوهای شاخص («logs-tenant-»).

5) لوکی: تصمیمات کلیدی

5. 1 مدل برچسب

برچسب ها: شاخص «لوکی» "استفاده از کاردینالیتی کم:" خوشه "،" فضای نام "،" برنامه "،" سطح "،" env "،" مستاجر ".
زمینه های با کاردینالیتی بالا (UID، request_id) - در یک ردیف ؛ «| =»، «json»، «regexp» را هنگام درخواست از طریق LogQL بازیابی کنید.

5. 2 قطعات

Promtail: сбор stdout، فایل ها، journald ؛ تجزیه کننده ها (JSON، regex، cri).

توزیع کننده/Ingester/Querier/Query-frontend: مقیاس بندی توسط نقش ؛ درخواست ذخیره سازی

ذخیره سازی شی (S3/GCS/MinIO) برای ذخیره سازی طولانی مدت از سیاهههای مربوط تکه.

5. 3 تکنیک های LogQL

grep سریع: {برنامه = «پرداخت»، سطح =» خطا»} | = «کاهش یافته» '

Парсинг JSON: «{app =» api «} | json | code =» 5xx «| مدت زمان باز کردن برنامه | avg ()»

ارتباط با معیارها: «نرخ ({app =» nginx «} | =» 200 «[5m])»

6) مقایسه ELK در مقابل Loki (به طور خلاصه)

جستجو/تجمع: ELK برای پرس و جوهای پیچیده تمام متن و چهره قوی تر است. Loki - grep مانند، سریع و ارزان است.
هزینه: Loki اغلب در حجم های بزرگتر ارزان تر است (ذخیره سازی شی + شاخص کوچکتر).
پیچیدگی عملیاتی: ELK نیاز به نظم و انضباط در شاخص ها/ILM، Javu-hips ؛ لوکی - رشته های برچسب.
ارتباط با معیارها/ردیابی: Loki به طور طبیعی با پشته Grafana/OTel ادغام می شود ؛ ELK همچنین می داند که چگونه، اما اغلب از طریق ادغام.

7) ایمنی و انطباق

نسخه PII در لبه (فرستنده): ماسک PAN، ایمیل، تلفن، آدرس، نشانه.
TLS در حال حمل و نقل، mTLS بین عوامل و اتوبوس ها.
RBAC: شاخص ها/برچسب های هر مستاجر ؛ جداسازی neimspaces/فضاها.

بهداشت اسرار: متغیرهای محیطی بدون اسرار، مدیران مخفی فردی

برگزاری حقوقی: مکانیسم انجماد بخش/شاخص ؛ نوشتن یک بار برای دوره های مورد بحث.
حذف/نگهداری: سیاست های TTL توسط کلاس داده (prod/stateful/payments/audit).
ورود به سیستم دنباله حسابرسی.

8) قابلیت اطمینان و توان

بافر و فشار پشتی: فایل های محلی/دیسک برای عوامل ؛ عقب نشینی با عقب نشینی نمایی.
Idempotency: 'ingest _ id '/' log _ id' fields برای جلوگیری از تکراری در طول تکراری.

HA: حداقل 3 گره برای استادان Loki ES/ingesters ؛ ضد وابستگی по AZ

سهمیه ها و محدودیت های نرخ توسط مستاجر/خدمات ؛ حفاظت در برابر «طوفان» ورود به سیستم.
طرح سطح ورود: 'ERROR' محدود، 'DEBUG' تنها به طور موقت از طریق پرچم های پویا.

9) عملکرد و تنظیم

• JVM پشته 50٪ RAM (اما ≤ ~ 30-32 گیگابایت در هر گره)، حافظه پنهان صفحه مهم است.
• رول اور هوشمند (20-50 GB/shard)، ↑ 'refresh _ interval' برای شاخص های مصرف.
• در Logstash، اجتناب از «سنگین» grok ؛ در صورت امکان، ورود به سیستم JSON در منبع.

• برچسب مناسب کلید سرعت است.
• قطعات بزرگ → ذخیره سازی ارزان تر، اما حافظه گران تر در ingester ؛ تعادل.
• Query-frontend + cache (meme/Redis) برای درخواست های مکرر.

10) FinOps برای سیاهههای مربوط (هزینه)

کاهش کاردینالیتی فیلدها/برچسبها.
نمونه برداری DEBUG و «سوئیچ ورود به سیستم» پویا.
چرخش: کوتاه گرم، طولانی سرد به شی.
Deduplication و پیام های تلفیقی (دسته ای).
بایگانی به ندرت از سیاهههای مربوط به کلاس های ذخیره سازی ارزان استفاده می شود.
داشبورد ارزش: حجم/جریان داده/برچسب/شاخص/مستاجران.

11) قابلیت مشاهده 3 در 1

ردیابی ID/Span-ID به هر ورود (میان افزار در دروازه API و خدمات).
OpenTelemetry: تک زمینه ؛ صادر کنندگان به Tempo/Jaeger، معیارهای Prometheus/Mimir، سیاهههای مربوط به Loki/ELK.
سناریوهای سریع: «هشدار توسط متریک → پرش به سیاهههای مربوط به → پرش به مسیر».

12) چند اجاره و انزوا

جداسازی مبتنی بر فضای نام (برچسب های K8s)، الگوهای شاخص جداگانه/برچسب «مستاجر».
جداسازی هشدارها/داشبورد/retenschna توسط مستاجر.
صورتحساب مصرف: حجم مصرف، ذخیره سازی، درخواست.

13) نظارت و SLO برای نوار نقاله خود

SLO مصرف: "99. 9٪ سیاهههای مربوط تحویل

جستجو در SLO: «نمایش داده شد p95 <Y ثانیه».
معیارهای فنی: عمق صف، سیاهههای مربوط کاهش یافته است، نرخ پردازش مجدد، تجزیه کننده نرخ خطا، ingester/ES شکست گره.

14) طرح های استقرار معمولی

مدیریت: خدمات Elasticsearch/Opensearch، Grafana Cloud Loki.
K8s خود میزبانی: StatefulSets برای ES/Loki، anti-affinity برای AZ، PersistentVolumes، ذخیره سازی شی.
عوامل لبه (برنامه های کاربردی در مناطق): بافر محلی + کانال 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 (مصرف و پوشش)

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/نماینده ؛ قطره مصرف در عوامل ؛ رشد جستجوی تاخیر.

• حجم سیاهههای مربوط توسط خدمات/مستاجران.
• الگوهای خطای بالا (کد/استثنا/نقطه پایانی).
• هزینه توسط کلاس های نگهداری/ذخیره سازی.

17) بررسی کیفیت (ورود به سیستم QA)

قراردادهای ورود به سیستم: فرمت JSON، فیلدهای مورد نیاز ('ts'، 'level'، 'service'، 'env'، 'trace _ id'، 'msg').
سیاهههای مربوط Linter در CI: ممنوعیت زمینه های جدید با کاردینالیتی بالا بدون توافق.
خدمات قناری: تولید سیاهههای مربوط به مرجع برای تشخیص زود هنگام رگرسیون.

18) خطاهای مکرر و ضد الگوهای

برچسبهای لوکی با کاردینالیتی بالا ('user _ id', 'request _ id') → انفجار حافظه.
زمینه های پویا در ES بدون نقشه برداری → «انفجار شاخص».
DEBUG در فروش «برای همیشه». با پرچم ها و با TTL روشن شوید.

عدم وجود بازنگری PII

یک خط لوله «یکپارچه» مشترک برای همه چیز - بخش های بهتر توسط دامنه.

19) برنامه پیاده سازی (تکرار)

1. MVP: عوامل + یک خط لوله (برنامه های کاربردی)، داشبورد پایه، نسخه PII.
2. فرمت: شبکه/infra-logs، هشدار SLO، ارتباط با آهنگ.
3. FinOps: ماتریس نگهداری، گزارش هزینه، بهینه سازی برچسب/شاخص.
4. چند مستاجر: فضاها، RBAC، صورتحساب مصرف.
5. قابلیت اطمینان: HA، تمرین های فاجعه، نگهداری قانونی.

20) چک لیست راه اندازی به تولید

• فرمت JSON و زمینه های مورد نیاز در تمام خدمات.
• PII پوشش/مصرف عامل.
• سیاست های نگهداری/ILM یا چرخه سطل.
• RBAC/فضاها/مستاجران.
• SLO مصرف/جستجو و هشدارها.
• سیاهههای مربوط به قناری و اجرای تست بار.
• داشبورد ارزش و گزارش در مورد صاحبان خدمات.
• Runbooks: «چه کاری باید انجام دهید اگر مصرف کاهش یافته/جستجو آهسته/تکه های قرمز».

21) مینی سوالات متداول

چه چیزی را انتخاب کنید - ELK یا Loki ؟