تمرکز سیاهههای مربوط

1) چرا متمرکز سیاهههای مربوط

• سرعت جستجو برای ریشه های حادثه (همبستگی با request-id/trace-id) ؛
• به شما امکان می دهد هشدارهای سیگنال را در مورد علائم (خطاها، ناهنجاری ها) ایجاد کنید.
• یک دنباله حسابرسی (چه کسی/چه زمانی/چه چیزی آن را انجام داد) ؛
• هزینه پایین تر به دلیل اتحاد نگهداری و ذخیره سازی.

2) اصول اساسی

1. فقط سیاهههای ساختاری (JSON/RFC5424) - بدون «متن آزاد» بدون کلید.
2. طرح یکنواخت کلید: 'ts، سطح، خدمات، ENV، منطقه، مستاجر، ، ، (ماسک)، MSG، KV...'.
3. همبستگی پیش فرض: تلنگر trace_id از دروازه به backends و سیاهههای مربوط.
4. به حداقل رساندن سر و صدا: سطوح صحیح، نمونه برداری، تکرار تکرار.
5. ایمنی توسط طراحی: ماسک PII، RBAC/ABAC، غیر قابل تغییر.
6. اقتصاد: گرم/گرم/سرد، فشرده سازی، تجمع، TTL و آبرسانی.

3) معماری معمولی

EFK/ELK: (بیت روان/Fluentd/Filebeat) → (کافکا - опц.) → (Elasticsearch/OpenSearch) → (داشبورد Kibana/OpenSearch). جستجو و جمع آوری جهانی.
Loki-like (فهرست بندی ورود توسط برچسب ها): بیت Promtail/Fluent → Loki → Grafana. ارزان تر برای حجم های بزرگ، فیلتر برچسب قدرتمند + مشاهده خطی.
ابر: CloudWatch/Cloud Logging/Log Analytics + صادرات به ذخیره سازی سرد (S3/GCS/ADLS) و/یا SIEM.
Data Lake approach: shippers → object storage (parquet/iceberg) → queries analysical cheap (Athena/BigQuery/Spark) + online layer (OpenSearch/Loki) for the last N days.

توصیه: برای حفظ لایه آنلاین (7-14 روز گرم) و بایگانی (ماه/سال) در دریاچه با توانایی آبرسانی.

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'، کلید در snake_case.

5) سطح ورود به سیستم و نمونه برداری

DEBUG - فقط در dev/مرحله ؛ با پرچم و TTL.
INFO - چرخه زندگی درخواست ها/رویدادها.
هشدار - شرایط مشکوک بدون تاثیر SLO.
ERROR/FATAL - تاثیر بر درخواست/کاربر.

• محدودیت نرخ برای خطاهای تکراری (به عنوان مثال، 1/sec/key).
• نمونه برداری دم از آثار (ترک سیاهههای مربوط کامل/آثار فقط برای درخواست «بد»).
• پویا: در صورت طوفان خطاها، جزئیات را کاهش دهید، خلاصه را ذخیره کنید.

6) تحویل سیاهههای مربوط (عوامل و حمل و نقل)

در گره: Fluent Bit/Filebeat/Promtail جمع آوری فایل های stdout/juntrals، تجزیه، ماسک کردن، بافر کردن.
صف های شبکه: Kafka/NATS برای صاف کردن پیک، بازپرداخت و سفارش.
قابلیت اطمینان: backpressure، بافر دیسک، تایید تحویل (حداقل یک بار)، شاخص های idempotent (کلید هش).
فیلتر کردن در لبه: دور انداختن «پچ پچ» و اسرار قبل از ضربه زدن به شبکه.

7) نمایه سازی و ذخیره سازی

پارتیشن بندی زمان (روزانه/هفتگی) + توسط 'ENV/منطقه/مستاجر' (از طریق قالب شاخص و یا برچسب).

• داغ (SSD، 3-14 روز): جستجو سریع و هشدار.
• گرم (HDD/فریزر، 30-90 روز): گاهی اوقات ما نگاه می کنیم.
• سرد/بایگانی (شی، ماه/سال): انطباق و تحقیقات نادر است.
• فشرده سازی و چرخش: ILM/ISM (سیاست های چرخه عمر)، gzip/zstd، downsampling (جداول جمع آوری).
• Rehydration: بارگیری موقت دسته های بایگانی شده در یک خوشه «داغ» برای تحقیق.

8) جستجو و تجزیه و تحلیل: پرس و جو نمونه

رخداد: فیلتر زمان × «سرویس =»... × «سطح> = خطا» × «ردیابی _ شناسه »/« درخواست _ شناسه».
ارائه دهندگان: «کد: PSP _' و» kv. ارائه دهنده: psp-a 'گروه بندی شده توسط منطقه.
ناهنجاری ها: افزایش فرکانس پیام ها یا تغییر در توزیع میدان (آشکارسازهای ML، مبتنی بر قانون).
حسابرسی: 'دسته: حسابرسی' + 'بازیگر '/' منابع' + نتیجه.

9) ارتباط با معیارها و ردیابی ها

شناسه های یکسان: 'trace _ id/span _ id' در هر سه سیگنال (معیارها، سیاهههای مربوط، ردیابی).
پیوندها از نمودارها: انتقال قابل کلیک از پانل p99 به سیاهههای مربوط توسط 'trace _ id'.
حاشیه نویسی انتشار: نسخه/canaries در متریک و سیاهههای مربوط برای اتصال سریع.

10) ایمنی، PII و انطباق

طبقه بندی زمینه: PII/اسرار/امور مالی - ماسک یا حذف در ورودی (فیلترهای Fluent Bit/Lua، Re2).
RBAC/ABAC: دسترسی به شاخص/برچسب توسط نقش، سطح امنیت/سطح میدان.
تغییر ناپذیری (WORM/append-only) برای حسابرسی و الزامات قانونی.
حفظ و «حق فراموش کردن»: TTL/حذف توسط کلید، tokenization 'user _ id'.
امضاها/هش ها: یکپارچگی مجلات انتقادی (اقدامات مدیریتی، پرداخت).

11) معیارهای ورود به سیستم SLO و خط لوله

تحویل: 99. 9٪ از حوادث در لایه داغ ≤ 30-60 ثانیه.
تلفات: <0 01٪ در 24 ساعت (به عنوان علامت مرجع).

قابلیت جستجو: ≥ 99 9 درصد در 28 روز

تاخیر درخواست: p95 ≤ 2-5 ثانیه در فیلترهای معمولی.
هزینه: $/1M رویدادها و $/ذخیره سازی/GB در لایه.

12) داشبورد (حداقل)

سلامت خط لوله: ورود/خروج از حمل و نقل، retrays، پر کردن بافر، تاخیر کافکا.
خطاها توسط خدمات/کدها: بالا N، روند، درصد 'latency _ ms'.
فعالیت حسابرسی: اقدامات مدیریت، خطاهای ارائه دهنده، دسترسی.
اقتصاد: حجم/روز، شاخص رشد، ارزش توسط لایه، «گران» نمایش داده شد.

13) عملیات و playbooks

طوفان ورود: فعال کردن نمونه برداری تهاجمی/نرخ محدود در عامل، افزایش بافر، به طور موقت انتقال بخشی از جریان به گرم است.
رانش طرح: هشدار برای ظاهر کلید های جدید/انواع، شروع مذاکره طرح کاتالوگ.
جستجوی آهسته: بازسازی شاخص ها، افزایش کپی ها، تجزیه و تحلیل نمایش داده های «سنگین»، آرشیو دسته های قدیمی.
حادثه امنیتی: تغییر ناپذیری فوری را فعال کنید، مصنوعات خالی، دسترسی محدود شده توسط نقش، RCA.

14) FinOps: چگونه به شکست در سیاهههای مربوط

حذف غرور: چند خط stacktrace را به یک میدان «پشته» و تکرار نمونه تبدیل کنید.
فعال کردن TTL: متفاوت برای 'env '/' level '/' category'.
برای دسترسی نادر از Loki/archive + on-demand rehydrate استفاده کنید.
احزاب و فشرده سازی: احزاب بزرگتر ارزان تر هستند، اما مراقب SLA های جستجو باشید.
ارزیابی های مکرر (جمع های روزانه) را تحقق بخشید.

15) مثال های ابزاری

بیت روان (نقاب زدن و ارسال به جستجوی باز)

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 в 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 (داغ → گرم → حذف)

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/Cloud) و آرشیو (S3/GCS + پارکت) انتخاب شده است.
• ILM/ISM + سیاست های نگهداری گرم/گرم/سرد، فرایند rehydrate.
• RBAC/ABAC، غیر قابل تغییر حسابرسی، ورود به سیستم دسترسی.
• داشبورد خط لوله، هشدار از دست دادن/تاخیر/بافر دیسک.
• Playbooks: طوفان ورود به سیستم، رانش طرح، جستجوی آهسته، حادثه امنیتی.
• محدودیت های مالی: رویدادهای $/1M، سهمیه برای درخواست های «گران».

17) ضد الگوهای

سیاهههای مربوط به متن بدون ساختار → عدم توانایی فیلتر کردن و جمع آوری.
stacktrace غول پیکر در انفجار INFO → حجم.
عدم همبستگی → «fluttering» برای همه خدمات.
ذخیره «همه چیز برای همیشه» → لایحه ابر مانند یک هواپیما.
اسرار/PII در سیاهههای مربوط → خطرات انطباق.
شاخص دستی ویرایش در فروش → رانش و خرابی جستجو طولانی است.

18) خط پایین

Log Centralization یک سیستم است، نه فقط یک پشته. طرح استاندارد، همبستگی، حمل و نقل امن، ذخیره سازی لایه ای و سیاست های دسترسی دقیق، سیاهههای مربوط را به یک ابزار قدرتمند برای SRE، امنیت و محصول تبدیل می کند. بازخورد صحیح و FinOps بودجه را حفظ می کند و SLO ها و playbooks خط لوله تحقیقات را سریع و قابل تکرار می کنند.