سود:
- توانایی درک سه ستون مشاهده پذیری (متریک، لاگ، ردیابی) و چهار سیگنال طلایی و داشتن هوش مصنوعی پرس و جوهای PromQL، قوانین هشدار و داشبورد را ایجاد می کند.
- امکان جلوگیری از خستگی هشدار با عمل گرا نگه داشتن آلارم ها و در آستانه های اضطراری مناسب و آزمایش در برابر داده های تاریخی سیستم شما
- امکان جلوگیری از حریم خصوصی و نشت مخفی با پوشاندن مناطق حساس قبل از دادن لاگ به هوش مصنوعی
در حالی که به نظر می رسد یک سیستم در حال کار است، ممکن است در حال مرگ باشد: حافظه به آرامی پر می شود، زمان پاسخ افزایش می یابد، نرخ خطا افزایش می یابد. تنها راه برای مشاهده این موضوع نظارت مداوم بر سیستم است. یک مفهوم پیشرفته تر، مشاهده پذیری است: توانایی درک آنچه در داخل سیستم می گذرد با مشاهده علائم بیرونی آن. سه پایه قابل مشاهده وجود دارد و متخصصان DevOps از هر سه استفاده می کنند:
- متریک: مقادیر عددی اندازهگیری شده در طول زمان - استفاده از CPU، تعداد درخواستها، زمان پاسخدهی، میزان خطا. "چقدر؟" به سوال پاسخ می دهد
- ورود: سوابق رویداد متنی تولید شده توسط سیستم - "کاربر وارد شده است"، "اتصال پایگاه داده از دست رفته". "دقیقا چه اتفاقی افتاد؟" به سوال پاسخ می دهد
- Trace: مسیری که یک درخواست در حین انتقال از سرویسی به سرویس دیگر در سیستم و مدت زمان هر مرحله طی می کند. کندی کجاست؟ به سوال پاسخ می دهد
رایج ترین ابزارها: Prometheus برای معیارها، Grafana برای تجسم، Loki/ELK برای log، Jaeger/OpenTelemetry برای ردیابی. هوش مصنوعی در نوشتن زبان های پرس و جو (به خصوص PromQL Prometheus)، قوانین هشدار و تنظیمات داشبورد برای این ابزارها بسیار ماهر است. همچنین این جایی است که هوش مصنوعی در قویترین نقطه خود قرار دارد: خلاصه کردن بخشهای بزرگی از گزارشها و معیارها و پرچمگذاری ناهنجاریها.
بیایید تفاوت بین نظارت و مشاهده پذیری را در یک جمله روشن کنیم: نظارت پرسیدن سؤالاتی است که قبلاً می دانید ("آیا CPU از 90٪ گذشته است؟"). قابلیت مشاهده این است که بتوانید سؤالاتی بپرسید که قبلاً نمی دانستید ("چرا این کندی عجیب فقط برای یک مشتری خاص در زمان خاصی اتفاق می افتد؟"). سیستم های مدرن به قدری پیچیده هستند که نمی توانید همه حالت های شکست را پیش بینی کنید. بنابراین، توانایی جمعآوری معیارها، گزارشها و ردیابیهای غنی و سپس پرسوجو در عمق آنها - یعنی قابلیت مشاهده - حیاتی میشود. در اینجاست که هوش مصنوعی هنگام پاسخ به «سوال ناشناخته قبلی» وارد عمل می شود: به سرعت داده های خام شما را اسکن می کند، الگوها و ناهنجاری ها را پیشنهاد می کند و با تأیید این سرنخ ها به علت اصلی می رسید.
گام به گام: چه چیزی و چگونه نظارت کنیم؟
- معیارهای مناسب را انتخاب کنید. در صنعت، "چهار سیگنال طلایی" به عنوان پایه در نظر گرفته می شود: تأخیر، ترافیک، خطاها، اشباع - میزان پر بودن منبع. اینها سلامت اکثر خدمات را خلاصه می کنند.
- معیارها را جمع آوری کنید اجازه دهید برنامه یک نقطه پایانی ارائه دهد که Prometheus بتواند آن را بخواند.
- داشبوردها را تنظیم کنید این معیارها را در Grafana تجسم کنید.
- قوانین هشدار را بنویسید در صورت تجاوز از آستانه به چه کسی و چگونه هشدار داده می شود؟
- لاگ ها را متمرکز کنید همه گزارشهای خدمات را در یک مکان جستجو کنید.
- نویز را کاهش دهید. هشدار بیش از حد باعث ایجاد "خستگی هشدار" می شود. هشدار مهم ناپدید می شود.
نکته: یک زنگ هشدار خوب دو چیز را برآورده می کند: قابل اجرا و فوریت مناسب است. زنگ هشداری که فرد را در ساعت 3 صبح از خواب بیدار می کند باید چیزی باشد که در واقع نیاز به مداخله شبانه دارد. هیچ کس را برای چیزی که به خودی خود نیاز به اقدام ندارد، مانند "CPU 70%" از خواب بیدار نکنید. آن را روی تخته نمایش دهید.
چگونه یک قانون هشدار بنویسیم؟
یک هشدار از سه جزء تشکیل شده است: شرط (کدام متریک از چه آستانهای فراتر میرود و برای چه مدت)، مدت («برای 5 دقیقه» برای جلوگیری از ایجاد نوسانات لحظهای) و اهمیت/عمل (برای چه کسی، از طریق کدام کانال). هوش مصنوعی به طرز ماهرانه ای این سه را با زمینه مناسب ایجاد می کند. برای مثال، ترجمه قاعدهای مانند «زنگ هشدار بحرانی در صورتی که نرخ خطا به مدت 5 دقیقه از 5 درصد فراتر رفت» به PromQL یک کار چند ثانیهای برای هوش مصنوعی است – اما شما تصمیم میگیرید که آیا آستانه برای سیستم شما مناسب است یا خیر.
احتیاط: آستانه های هشدار پیشنهاد شده توسط هوش مصنوعی مفروضات کلی هستند. بار نرمال، تحمل و تاثیر کار سیستم شما متفاوت است. قبل از اینکه یک آستانه را مستقیماً در prod قرار دهید، به دادههای تاریخی خود نگاه میکنید و میپرسید "چند بار این آستانه در گذشته ایجاد شده است، چند مورد از آنها مشکلات واقعی بوده است؟" به سوال پاسخ دهید.
حریم خصوصی گزارش: هشدار حیاتی
سیاههها اغلب نادیده گرفته شده ترین منبع نشت هستند. یک خط گزارش ممکن است تصادفاً حاوی رمز عبور، شماره کارت اعتباری یا دادههای شخصی (تحت KVKK/GDPR) باشد. هنگام چسباندن لاگ ها به هوش مصنوعی برای تجزیه و تحلیل:
- نواحی حساس را بپوشانید. مقادیری مانند رمز، رمز عبور، ایمیل، شماره شناسه را با <REDACTED> جایگزین کنید.
- مثال بزنید نه همه. به جای یک میلیون خط، چند صد خط نماینده اغلب کافی است.
- وسیله نقلیه مورد تایید موسسه را انتخاب کنید. به خصوص برای لاگ های تولید، از ابزاری استفاده کنید که اطلاعات آن به آموزش نمی رود.
چهار سیگنال طلایی و میز زنگ هشدار
سیگنال
اندازه گیری شده توسط
مثال آستانه آلارم
فوریت
تاخیر
زمان پاسخگویی
p95 > 800 ms، 5 دقیقه
بالا
ترافیک
درخواست/ثانیه
افزایش/کاهش ناگهانی 300%
متوسط
خطا
نرخ درخواست ناموفق
> 5%، 5 دقیقه
انتقادی
اشباع
اشغال منابع
دیسک > 85٪
بالا
سه کیف کوچک
مورد 1 - 400 خط گزارش خلاصه شده در 30 ثانیه. یک سرویس کند شده بود. مهندس 400 خط گزارش نقابدار را به هوش مصنوعی داد و گفت: "الگوهای خطای تکرارشونده و شدت زمان را خلاصه کنید." هوش مصنوعی نشان داد که یک API خارجی خاص هر 30 ثانیه یکبار به پایان می رسد. علت اصلی در 30 ثانیه پیدا شد. اسکن لاگ ها به صورت دستی نیم ساعت طول می کشد.
مورد 2 - خستگی هشدار حل شده است. یک تیم روزانه 200 آلارم دریافت میکرد و همه آنها را نادیده میگرفت - تا زمانی که هشدار قطعی واقعی نادیده گرفته شد. تمام قوانین هشدار را به هوش مصنوعی بدهید و بپرسید "کدامیک قابل اجرا نیستند و کدام را می توان ترکیب کرد؟" آنها پرسیدند. تعداد آلارم ها به 12 در روز کاهش یافت. اکنون هر زنگ خطر جدی گرفته می شد.
مورد 3 - آستانه اشتباه زود تشخیص داده شد. YZ برای دیسک "Warn when 95% full" را پیشنهاد کرد. مهندس به داده های تاریخی نگاه کرد: هنگامی که دیسک به 95٪ رسید، زمان کمی برای مداخله وجود داشت. این آستانه را به 80 درصد کاهش داد و زنگ دوم را بر اساس "نرخ رشد" اضافه کرد. راستیآزمایی از قطعی واقعی نیمه شب جلوگیری کرد.
چهار قالب قابل کپی
1) خلاصه کردن گزارش (ماسک شده):
مثال گزارش زیر را تجزیه و تحلیل کنید (من مقادیر حساس را با <REDACTED> پنهان کردم). به من بدهید: (1) الگوهای خطای تکرار شونده، (2) تمرکز در طول زمان، (3) محتمل ترین علت اصلی، و (4) 3 معیاری که برای تأیید بررسی خواهم کرد. گزارش: [LINES]
2) تولید قانون هشدار:
یک قانون هشدار برای Prometheus/Alertmanager بنویسید: اگر [THRESHOLD] از [METRIC][DURATION] بیشتر شد، زنگ [SEVERITY] ایجاد کنید. این قانون باید عمل گرا باشد و شامل حاشیه نویسی و فیلد پیوند runbook باشد. PromQL را توضیح دهید و بنویسید که چرا این آستانه معقول است.
3) نوشتن/اعلام پرس و جو PromQL:
یک کوئری PromQL بنویسید که اندازهگیری میکند: [EX. 5xxe درصد نرخ خطا در 5 دقیقه گذشته]. مرحله به مرحله سوال را توضیح دهید. سپس به من بگویید که محدوده سالم برای این مقدار چقدر باید باشد.
4) طراحی داشبورد:
یک داشبورد Grafana برای [SERVICE] طراحی کنید: با کدام پانل ها باید چهار سیگنال طلایی (تأخیر، ترافیک، خطا، اشباع) را نمایش دهم؟ متریک، نوع تجسم و آستانه معقول را برای هر پانل پیشنهاد دهید. هدف: مشاهده وضعیت سلامت یک نگهبان در 10 ثانیه.
اعلان ضعیف / اعلان قوی
ضعیف: "در آن گزارش چه چیزی وجود دارد؟" (به دنبال آن 5000 خط لاگ خام، توکن ها در آن وجود دارد)
نتیجه: شما اسرار را فاش می کنید و هوش مصنوعی خلاصه ای غیر هدفمند و سطحی ارائه می دهد.
Strong: "الگوهای خطای تکرارشونده و شدت زمان را در مثال گزارش 300 خطی پوشانده شده در زیر بیابید؛ محتمل ترین علت اصلی و معیارهایی را که برای تأیید بررسی خواهم کرد به من بگویید. من نشانه ها را <REDACTED> ساختم."
تفاوت: اعلان دوم یک مثال پوشانده شده و متمرکز را ارائه می دهد که خروجی تحلیل واضحی را می خواهد. هم بی خطر است و هم مفید.
اشتباهات رایج
- چسباندن لاگ به هوش مصنوعی بدون ماسک کردن. رایج ترین نشت اطلاعات شخصی/محرمانه.
- تنظیم آلارم برای همه چیز خستگی زنگ هشدار واقعی را مدفون می کند.
- زنگ هشدار غیر قابل عمل این صدای هشدار است که هیچ کس نمی تواند کاری در مورد آن انجام دهد.
- پذیرش آستانه هوش مصنوعی بدون سوال. آستانه باید با توجه به سابقه سیستم شما تنظیم شود.
- فقط به متریک نگاه کنید. بدون ثبت و ردیابی، بیشتر اوقات نمی توان علت اصلی را پیدا کرد.
- تنظیم نکردن زمان زنگ هشدار (برای). نوسانات لحظه ای آلارم های کاذب تولید می کنند.
به طور خلاصه
قابلیت مشاهده این توانایی درک درون سیستم از بیرون با معیارها، گزارشها و ردیابی است. چهار سیگنال طلایی (تأخیر، ترافیک، خطا، اشباع) سلامت اکثر خدمات را خلاصه می کند. هوش مصنوعی در نوشتن پرس و جوهای PromQL، قوانین هشدار و داشبوردها، و در خلاصه کردن بخشهای بزرگ گزارشها و یافتن ناهنجاریها بسیار قدرتمند است. اما این مسئولیت شماست که آستانه های هشدار را در برابر تاریخچه سیستم خود تأیید کنید، هشدارها را در جهت عمل نگه دارید و هرگز گزارش ها را بدون پوشاندن آنها به اشتراک نگذارید.
وظیفه کاربردی
برای یک سرویس (یا یک سرویس نمونه) آن را با سوال تست کنید؛ (2) نمونه گزارشی را که دارید بپوشانید و آن را با الگوی "خلاصه گزارش" تجزیه و تحلیل کنید. (3) توجه داشته باشید که برای تأیید محتمل ترین علت اصلی به کدام معیار نگاه می کنید.
چک لیست
- [ ] من معیارهایی را برای ردیابی بر اساس چهار سیگنال طلایی انتخاب کردم.
- [ ] من تمام گزارش هایی را که به هوش مصنوعی دادم از نظر مناطق حساس پوشانده ام.
- [ ] من تأیید کردم که هر زنگ هشدار عمل محور و فوریت صحیحی دارد.
- [ ] من آستانه های هشدار را در برابر داده های تاریخی سیستمم آزمایش کردم.
- [ ] من نوسانات آنی را با اضافه کردن (مدت) به آلارم ها فیلتر کردم.
- [ ] من از متریک + log + trace با هم برای علت اصلی استفاده کردم.