نظارت بر زیرساخت ها
نظارت بر زیرساخت
1) اهداف و قاب
نظارت بر زیرساخت یک سیستم سیگنال در مورد سلامت، عملکرد و در دسترس بودن یک پلت فرم است. او باید:- اخطار قبل از خرابی کاربر) آشکارسازی زودهنگام (.
- تشخیص علت ریشه ای (از علامت تا علت).
- پشتیبانی SLO از انتشار و بازگشت خودکار.
- تجزیه و تحلیل پس از حادثه (شواهد به عنوان داده ها).
اصول پشتیبانی: قابل مشاهده توسط طراحی، سر و صدای کمتر - سیگنال های بیشتر، اتوماسیون واکنش ها، یک پانل حقیقت است.
2) سه گانه قابل مشاهده
Timeseries - نرخ/تقاضا/خطا/اشباع (استفاده/قرمز)
سیاهههای مربوط: جزئیات رویداد با زمینه ؛ هیچ رازی وجود ندارد/PII
آثار: موارد توزیع شده با روابط علی.
به علاوه:- پروفایل (CPU/heap/lock/io)، eBPF برای سطح سیستم.
- رویدادها/ممیزی (رویدادهای K8s، تغییرات در پیکربندی/اسرار).
3) SLI/SLO/SLA - زبان با کیفیت
SLI: «در دسترس بودن»، «error _ rate»، «p95 _ latency»، «queue _ lag».
SLO (هدف): "درخواست های موفق ≥ 99. 9 درصد در 30 روز
بودجه خطا: تحمل ؛ برای انتشار خودکار توقف استفاده می شود.
مثال SLO (YAML):yaml service: "api-gateway"
slis:
- name: success_rate query_good: sum(rate(http_requests_total{status!~"5.."}[5m]))
query_total: sum(rate(http_requests_total[5m]))
slo: 99. 9 window: 30d
4) نقشه لایه های نظارت
1. میزبان/VM/گره ها: CPU/Load/Steal، RAM/Swap، دیسک IOPS/Latency، فایل سیستم.
2. Network/LB/DNS: RTT، packets/drop، backlog، SYN/Timeout، health-probes.
3. Kubernetes/Orchestrator: سرور API, ETCD, کنترل, برنامه ریز; pods/nodes, در انتظار/اخراج, throttling, kube-events.
4. خدمات/ظروف: RED (نرخ/خطاها/مدت زمان)، آمادگی/زنده بودن.
5. پایگاه داده ها/کش ها: QPS، انتظار قفل، تاخیر تکرار، ضربه بافر، پرس و جو آهسته.
6. صف/اتوبوس: تاخیر مصرف کننده، درخواست/نامه مرده، توان.
7. ذخیره سازی/ابر: خطاهای S3/Blob و تاخیر، 429/503 از ارائه دهندگان.
8. مرزهای محیطی: WAF/محدودیت نرخ، 4xx/5xx توسط مسیر، CDN.
9. Synthetics: چک اسکریپت HTTP (سپرده/خروجی)، TLS/گواهی.
10. اقتصاد/ظرفیت: هزینه هر سرویس، استفاده، سر و صدا.
5) جعبه سفید и جعبه سیاه
Whitebox: صادر کنندگان/SDK ها در خدمات (Prometheus، OpenTelemetry).
Blackbox: نمونه های خارجی از مناطق مختلف (در دسترس بودن، تأخیر، انقضا TLS).
ترکیب: «نشانه خارج» + «تشخیص در داخل».
yaml modules:
https_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"
6) Kubernetes: سیگنال های کلیدی
Кластер: 'apiserver _ request _ total', 'etcd _ server _ has _ leader', etcd fsync.
Узлы: 'container _ cpu _ cfs _ throttled _ seconds _ total', 'node _ pressure'.
پد: در انتظار/CrashLoopBackOff، OOMKilled، راه اندازی مجدد.
برنامه ها/محدودیت ها: درخواست ها در مقابل محدودیت ها، PodDisruptionBudget، HPA/VPA.
شبکه: NetworkPolicy قطره، خستگی اتصال.
Дашборды: «سلامت خوشه»، «اشباع بار کاری»، «خدمات خطای بالا».
7) DB و صف
PostgreSQL/MySQL: تاخیر تکرار، بن بست، پرس و جو آهسته٪، بازرسی I/O.
Redis/Memcached: نسبت ضربه، اخراج، اتصالات رد شده.
Kafka/RabbitMQ: تاخیر مصرف کننده، بازپرداخت، بازپرداخت، کارگزار ISR، استفاده از دیسک.
8) معیارهای RED/USE و ارتباطات تجاری
قرمز: «نرخ» (RPS)، «خطاها» (4xx/5xx)، «مدت زمان» (p95/p99).
استفاده (برای منابع): استفاده، اشباع، خطاها.
مرتبط با محصول: سپرده/پرداخت موفقیت، پرچم تقلب، تبدیل - این «نگهبانان» برای آزادی قناری هستند.
9) هشدار ساختار
Tier-1 (صفحه): حوادثی که بر SLO تأثیر می گذارد (در دسترس بودن، 5xx، تأخیر، خرابی اجزای مهم خوشه).
Tier-2 (بلیط): تخریب ظرفیت، رشد خطا بدون تاثیر SLO.
Tier-3 (اطلاع رسانی): روند، ظرفیت پیش بینی، گواهینامه های منقضی شده.
قوانین تشدید: زمان سکوت/فشرده سازی تکراری، چرخش در تماس، پیگیری خورشید.
نمونه ای از مسیرهای Alertmanager:yaml route:
group_by: ["service","severity"]
receiver: "pager"
routes:
- match: { severity: "critical" }
receiver: "pager"
- match: { severity: "warning" }
receiver: "tickets"
10) مثال قانون پرومتئوس
10. 1 خطاهای 5xx با آستانه SLO
yaml groups:
- name: api rules:
- alert: HighErrorRate expr:
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m])) > 0. 005 for: 10m labels: { severity: "critical", service: "api-gateway" }
annotations:
summary: "5xx > 0. 5% 10m"
runbook: "https://runbooks/api-gateway/5xx"
10. 2 خطای سوزاندن بودجه (سوزاندن چند پنجره)
yaml
- alert: ErrorBudgetBurn expr:
(1 - (
sum(rate(http_requests_total{status!~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
)) > (1 - 0. 999) 14 for: 5m labels: { severity: "critical", slo: "99. 9" }
annotations: { summary: "Fast burn >14x for 5m" }
10. 3 اشباع سیستم (CPU Throttling)
yaml
- alert: CPUThrottlingHigh expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1 for: 10m labels: { severity: "warning" }
annotations: { summary: "CPU throttling >10%" }
11) سیاهههای مربوط: جمع آوری، عادی سازی، نگهداری
استاندارد سازی: JSON سیاهههای مربوط: 'ts'، 'سطح'، 'خدمات'، 'ردیابی _ id'، 'کاربر/مستاجر'.
خط لوله: عامل (Fluent Bit/Vector) → بافر → شاخص/ذخیره سازی.
تجدید نظر: PII/اسرار پنهان در لبه.
نگهداری: کلاس ذخیره سازی سریع (7-14 روز)، آرشیو سرد (30-180 روز).
معناشناسی: خطا بودجه/مستهلک - کانال های جداگانه.
12) مسیرهای پیاده روی و OpenTelemetry
نقاط ورودی ابزار (دروازه), kliyent → servis calls, DB/caches/queues.
معیارهای Bind برای ردیابی ویژگی ها (Exemplars) برای ناوبری سریع.
OTel Collector به عنوان یک دروازه مرکزی: فیلتر کردن، نمونه برداری، صادرات به backend انتخاب شده است.
yaml receivers: { otlp: { protocols: { http: {}, grpc: {} } } }
processors: { batch: {}, tail_sampling: { policies: [ { name: errors, type: status_code, status_codes: [ERROR] } ] } }
exporters: { prometheus: {}, otlp: { endpoint: "traces. sink:4317" } }
service:
pipelines:
metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }
traces: { receivers: [otlp], processors: [tail_sampling,batch], exporters: [otlp] }
13) مصنوعی و چک های خارجی
HTTP سناریوهای کسب و کار را اجرا می کند (ورود، واریز، برداشت، خرید).
TLS/Domain: سلامت گواهی/CAA/DNS.
منطقه ای بودن: نمونه هایی از کشورها/ارائه دهندگان کلیدی (لیست های مسیریابی/بلوک).
Synthetics باید هشدار اگر به کاربر در دسترس نیست، حتی با تله متری داخلی سبز.
14) پروفایل و eBPF
پروفایل مداوم: شناسایی توابع داغ، قفل.
eBPF: رویدادهای سیستم (syscalls، TCP retransmitts)، بر روی محصول با حداقل سربار.
هشدار مشخصات بدون زور زدن (بلیط)، و برای رگرسیون پس از آزادی - به عنوان یک سیگنال از عقبگرد.
15) داشبورد و «پانل حقیقت»
حداقل مجموعه:1. بررسی اجمالی پلت فرم: SLI/SLO توسط خدمات کلیدی، بودجه خطا، هشدارها.
2. API RED: RPS/ERRORS/DURATION توسط مسیر.
3. خوشه K8s: کنترل هواپیما، узлы، صندلی ظرفیت.
4. DB/کش: تاخیر/قفل/پرس و جو آهسته٪، نسبت ضربه.
5. صف ها: backlog/lag, fail/retry.
6. Per-release: مقایسه معیارهای قبل/بعد (پنجره های قناری).
7. FinOps: هزینه هر فضای نام/سرویس، ресурсы بیکار/بزرگ.
16) حوادث، سر و صدای هشدار و تشدید
تقسیم بندی - گروه بندی خدمات/علت، سرکوب آبشار
سکوت/نگهداری: انتشار/مهاجرت نباید همه چیز را قرمز کند.
Runbooks: هر هشدار بحرانی با مراحل تشخیصی و یک «دکمه» برگشت.
Postmortem: جدول زمانی، آنچه آنها آموخته اند، چه سیگنال هایی اضافه شده/تمیز شده است.
17) ایمنی در نظارت
RBAC برای خواندن/ویرایش قوانین/منابع داده.
اسرار: صادر کننده/عامل نشانه - از طریق مدیر مخفی.
جداسازی: معیارهای مشتری/مستاجر - به فضاهای جداگانه/زبانه ها.
یکپارچگی: امضای عوامل/ساخت، پیکربندی از طریق GitOps (بررسی ادغام).
18) امور مالی و ظرفیت (FinOps)
سهمیه ها و بودجه ها ؛ هشدار برای رشد غیر طبیعی
اندازه گیری درست: تجزیه و تحلیل درخواست ها/محدودیت ها، استفاده از CPU/RAM، نمونه های نقطه ای برای وظایف غیر مهم.
«هزینه هر درخواست/مستاجر» به عنوان KPI های عملکرد.
19) ضد الگوهای
معیارهای زیرساخت تنها بدون SLI های سفارشی.
100 + هشدار «در مورد همه چیز» → کوری در تماس.
Logs به عنوان تنها منبع (بدون متریک و ردیابی).
داشبورد قابل تغییر بدون نسخه/بررسی.
فقدان مصنوعی: «همه چیز سبز است»، اما جلو در دسترس نیست.
هیچ ارتباطی با نسخه ها وجود ندارد: غیرممکن است که پاسخ دهیم «چه چیزی در حال حاضر تغییر کرده است».
20) چک لیست پیاده سازی (0-60 روز)
0-15 روز
SLI/SLO را برای 3-5 سرویس کلیدی تعریف کنید.
صادرکنندگان/نمایندگان اصلی را فعال کنید، سیاهههای مربوط به JSON را استاندارد کنید.
پیکربندی هشدار Tier-1 (در دسترس بودن، 5xx، p95).
16-30 روز
اضافه کردن مصنوعی برای سناریوهای بحرانی.
OTel را در خدمات ورودی/بحرانی فعال کنید.
داشبوردهای «Per-release» و قوانین سوزاندن بودجه خطا.
31-60 روز
پوشش DB/صف/کش با سیگنال های پیشرفته.
پیاده سازی eBPF/پروفایل برای خدمات CPU بالا.
GitOps برای قوانین/داشبورد/هشدار، تمیز کردن سر و صدا به طور منظم.
21) معیارهای بلوغ
پوشش SLO خدمات کلیدی ≥ 95٪.
MTTA/MTTR (هدف: دقیقه/ده دقیقه).
نسبت هشدارهای Tier-1 بسته شده توسط عمل خودکار یا برگشت سریع.
نسبت هشدارهای «مفید «/» پر سر و صدا «> 3:1 است.
پوشش مصنوعی تمام مسیرهای «پول» = 100٪.
22) برنامه های کاربردی: مینی قالب
Prometheus - در دسترس بودن توسط کلاس وضعیت
yaml
- record: job:http:availability:ratio_rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
Grafana - نکته برای قناری ها
expr: histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket{version=~"stable canary"}[5m])) by (le,version))
Alertmanager - وظیفه و سکوت
yaml receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true inhibit_rules:
- source_match: { severity: "critical" }
target_match: { severity: "warning" }
equal: ["service"]
23) نتیجه گیری
نظارت مجموعه ای از نمودار نیست، اما سیستم عامل SRE: SLI/SLO به عنوان یک قرارداد کیفیت، معیارها/مسیرهای پیاده روی/سیاهههای مربوط به عنوان منابع حقیقت، هشدارها به عنوان یک سیگنال کنترل شده، synthetics به عنوان «صدای کاربر»، GitOps به عنوان یک رشته تغییر. یک حلقه واحد را از میزبان به API بسازید، آن را به نسخه ها و رول ها متصل کنید - و این پلت فرم قابل پیش بینی، سریع و مقرون به صرفه است.