خدمات مانیتورینگ زیرساخت و Observability

راهنمای خدمات مانیتورینگ زیرساخت و Observability

خدمات مانیتورینگ زیرساخت برای تیمی است که چند سرور، تجهیزات شبکه و سرویس‌های کانتینری دارد و هنگام مشکل مجبور است به تک‌تک سرورها وصل شود و لاگ بخواند. مانیتورینگ وضعیت‌هایی را که از قبل تعریف شده‌اند می‌سنجد، مثل پر شدن دیسک یا توقف یک سرویس. Observability داده کافی جمع می‌کند تا علت مشکلی را هم پیدا کنید که کسی از قبل برایش هشدار نگذاشته است. بخش‌های زیر نشان می‌دهند هر نوع داده به چه کاری می‌آید، ابزار را چطور انتخاب کنید و چه چیزی زمان و هزینه راه‌اندازی را تعیین می‌کند.

متریک، لاگ و trace به چه پرسشی جواب می‌دهند؟

متریک عددی است که در فاصله‌های منظم ثبت می‌شود، مثل مصرف CPU، تعداد درخواست در ثانیه یا زمان پاسخ. متریک‌ها فضای کمی می‌گیرند و برای رسم روند و هشدار مناسب‌اند، ولی نمی‌گویند یک درخواست مشخص چرا خطا داده است. لاگ همین جزئیات را ثبت می‌کند: پیام خطا، آدرس درخواست و زمان دقیق. trace مسیر یک درخواست را بین چند سرویس دنبال می‌کند و نشان می‌دهد تأخیر در کدام مرحله بوده است.

برای بیشتر سازمان‌ها شروع با متریک و لاگ متمرکز کافی است. برای هر سرویس نرخ درخواست، نرخ خطا و زمان پاسخ ثبت می‌شود و blackbox exporter در دسترس بودن وب‌سایت و API را از بیرون می‌سنجد. وقتی متریک و لاگ با برچسب‌های یکسان، مثل نام سرویس و سرور، ذخیره شوند، از نمودار افزایش خطا در Grafana می‌توان مستقیم به لاگ‌های همان بازه رسید. راه‌اندازی این دو ابزار را در نصب و کانفیگ Prometheus و Grafana نوشته‌ایم.

Zabbix، Prometheus یا هر دو؟

Zabbix برای تجهیزات شبکه، سرورهای ویندوز و محیط‌هایی که ماشین‌هایش ثابت و طولانی‌مدت‌اند انتخاب راحت‌تری است. SNMP سوییچ‌ها و فایروال‌ها را پوشش می‌دهد، agent روی ویندوز و لینوکس نصب می‌شود و قالب‌ها و رابط مدیریتی آماده دارد. Prometheus داده را از exporterها می‌کشد و با برچسب کار می‌کند، به همین دلیل با کانتینرها و سرویس‌هایی که زیاد عوض می‌شوند بهتر کنار می‌آید. در بسیاری از زیرساخت‌ها هر دو کنار هم کار می‌کنند و Grafana داده هر دو را در یک داشبورد نشان می‌دهد.

برای لاگ، انتخاب بین ELK و Loki به نوع جست‌وجو برمی‌گردد. Elasticsearch کل متن لاگ را ایندکس می‌کند و جست‌وجوی متنی پیشرفته می‌دهد، ولی حافظه و دیسک بیشتری می‌خواهد. Loki فقط برچسب‌ها را ایندکس می‌کند و کم‌هزینه‌تر است، اما جست‌وجوی آزاد در متن لاگ‌های حجیم در آن محدودتر است. مدت نگهداری داده هم باید پیش از نصب تعیین شود، چون لاگ چندماهه به‌سرعت دیسک سرور مانیتورینگ را پر می‌کند. راه‌اندازی ELK را در راه‌اندازی Elastic Stack توضیح داده‌ایم.

هشدارهایی که تیم نادیده نمی‌گیرد

CPU بالای لحظه‌ای معمولاً کاری از کسی نمی‌خواهد، ولی افزایش نرخ خطای یک سرویس، کند شدن پاسخ یا دیسکی که با روند فعلی تا چند ساعت دیگر پر می‌شود، اقدام لازم دارد. در Alertmanager هشدارهای مرتبط گروه‌بندی می‌شوند تا قطع یک سوییچ ده‌ها پیام جداگانه نفرستد، و در زمان نگهداری برنامه‌ریزی‌شده بی‌صدا می‌شوند. هر هشدار به تلگرام، ایمیل یا کانال تیم می‌رسد و در متن آن نوشته می‌شود چه چیزی و روی کدام سرور خراب است.

چند هفته بعد از راه‌اندازی، هشدارهای پرتکرار بازبینی می‌شوند. هشداری که هر روز می‌آید و کسی برایش کاری نمی‌کند، یا آستانه اشتباهی دارد یا اصلاً نباید هشدار باشد. اگر هشدارها مشکل مشخصی مثل کندی دیتابیس یا کمبود منابع را نشان دهند، رفع آن در خدمات بهینه‌سازی سرور و دیتابیس انجام می‌شود.

سیستم مانیتورینگ را کجا نصب و چطور نگهداری کنیم؟

سرور مانیتورینگ باید جدا از سرورهایی باشد که پایش می‌کند، وگرنه با از کار افتادن همان سرور هشدار قطعی هم ارسال نمی‌شود. خود سیستم مانیتورینگ هم پایش می‌خواهد، چون اگر Prometheus از کار بیفتد یا دیسک Elasticsearch پر شود، نبودن هشدار ممکن است سالم بودن همه‌چیز به نظر برسد. داشبوردهای Grafana و Kibana را پشت رمز و VPN نگه دارید، چون نام سرورها، آدرس‌ها و گاهی داده حساس در لاگ‌ها دیده می‌شود. در سرورهای داخل ایران، دریافت ایمیج و بسته از بعضی مخزن‌های خارجی ممکن است محدود باشد، پس منبع نصب exporterها و ایمیج‌ها پیش از شروع مشخص می‌شود.

کانتینرها عمر کوتاهی دارند و با هر استقرار جدید نام و آدرسشان عوض می‌شود. متریک و لاگ آن‌ها با برچسب نام سرویس ذخیره می‌شود تا داده نسخه قبلی و جدید یک سرویس کنار هم دیده شود. راه‌اندازی خود کانتینرها در خدمات Docker انجام می‌شود.

زمان و هزینه راه‌اندازی مانیتورینگ به چه بستگی دارد؟

تعداد سرورها و تجهیزات شبکه، تعداد سرویس‌هایی که متریک اختصاصی می‌خواهند و حجم و مدت نگهداری لاگ پایه برآورد هستند. حجم لاگ روی منابع سرور مانیتورینگ اثر مستقیم دارد، پس فاصله جمع‌آوری متریک‌ها و فیلتر لاگ‌های کم‌ارزش در طراحی تنظیم می‌شوند. اگر Zabbix یا Prometheus از قبل نصب است، کار از بازبینی قالب‌ها و هشدارهای فعلی شروع می‌شود. نگهداری مستمر، یعنی افزودن سرویس‌های جدید و بازبینی هشدارها، جداگانه در برآورد می‌آید. اگر فقط تصویر یک‌باره‌ای از سلامت یک سرور می‌خواهید، بررسی رایگان سلامت سرور را درخواست کنید.