مانیتورینگ ابری؛ راهنمای عملی پایش و هشدار در زیرساخت ابری

چرا مانیتورینگ ابری فراتر از یک داشبورد ساده است؟

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

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

شاخص‌های کلیدی: چه چیزی را باید پایش کرد؟

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

شاخص‌های سطح زیرساخت (Infrastructure Metrics)

این دسته شامل منابع پایه است که معمولاً از طریق ابزارهایی مانند Prometheus، Grafana یا سرویس‌های بومی هر ارائه‌دهنده ابری قابل جمع‌آوری است:

• CPU Usage: میانگین استفاده از پردازنده در بازه‌های ۵ و ۱۵ دقیقه‌ای. نرخ ۸۰٪ به‌مدت ۱۰ دقیقه، معمولاً زنگ خطر است.
• Memory Usage: درصد حافظه مصرفی و میزان swap. در لینوکس، دستور free -h را با اسکریپت‌های cron ترکیب کنید.
• Disk I/O و Disk Space: فضای خالی دیسک و تعداد عملیات خواندن/نوشتن در ثانیه (IOPS). پر شدن دیسک، یکی از دلایل اصلی از کار افتادن پایگاه‌داده است.
• Network Throughput: پهنای باند ورودی و خروجی. این شاخص در حملات DDoS یا ترافیک غیرعادی، اولین نشانه است.

شاخص‌های سطح برنامه (Application Metrics)

پایش زیرساخت به شما می‌گوید که ماشین زنده است؛ اما نمی‌گوید که برنامه شما درست کار می‌کند. برای این کار باید شاخص‌های سطح برنامه را نیز جمع‌آوری کنید:

• Latency (تأخیر): زمان پاسخ‌گویی به درخواست‌ها. صدک ۹۵ (p95) را پایش کنید، نه میانگین را؛ میانگین می‌تواند ناهنجاری‌ها را پنهان کند.
• Error Rate: درصد درخواست‌هایی که با کد خطای 5xx پاسخ داده می‌شوند. آستانه پیشنهادی: بیش از ۱٪ در بازه ۵ دقیقه‌ای.
• Throughput: تعداد درخواست‌های موفق در ثانیه (RPS). افت ناگهانی RPS می‌تواند نشانه قطعی سرویس یا مشکل در صف پیام باشد.
• Queue Depth: عمق صف‌های پیام (مانند RabbitMQ یا Kafka). اگر صف مدام پر می‌شود، مصرف‌کننده کندتر از تولیدکننده است.

شاخص‌های تجاری (Business Metrics)

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

تنظیم آستانه‌ها: از هشدارهای بی‌مورد تا هشدارهای دیرهنگام

آستانه (Threshold) قلب سیستم هشدار است. اگر آستانه را خیلی پایین بگذارید، تیم شما غرق اعلان می‌شود. اگر خیلی بالا بگذارید، مشکل را وقتی می‌فهمید که کاربران شکایت کرده‌اند. راه‌حل، استفاده از آستانه‌های پویا و چندسطحی است.

آستانه ثابت در برابر آستانه پویا

آستانه ثابت مانند «هشدار اگر CPU از ۸۰٪ بیشتر شد» برای محیط‌های کوچک کافی است. اما در محیط‌های بزرگ، الگوهای ترافیک متفاوت است. برای مثال، یک وب‌سایت خبری ممکن است در ساعات صبح CPU بالایی داشته باشد و در شب تقریباً بیکار باشد. در این حالت، آستانه پویا که بر اساس میانگین متحرک ۷ روزه محاسبه می‌شود، دقیق‌تر عمل می‌کند.

در Prometheus، می‌توانید با استفاده از record قوانین، آستانه پویا تعریف کنید. مثال زیر یک قانون برای هشدار بر اساس انحراف از میانگین است:

groups:
  - name: dynamic-thresholds
    rules:
      - record: job:cpu_usage:avg_7d
        expr: avg_over_time(instance:cpu_usage:rate5m[7d])
      - alert: HighCpuDynamic
        expr: |
          instance:cpu_usage:rate5m > job:cpu_usage:avg_7d * 1.5
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "CPU usage is 50% above 7-day average"

آستانه‌های چندسطحی (Multi-Level Thresholds)

به‌جای یک حالت هشدار، سه سطح تعریف کنید:

1. Info (اطلاع‌رسانی): برای مثال، استفاده از دیسک به ۷۰٪ رسیده است. این هشدار به کانال عمومی تیم می‌رود و نیاز به اقدام فوری ندارد.
2. Warning (هشدار): استفاده از دیسک به ۸۵٪ رسیده است. این هشدار به‌صورت پیامک یا اعلان به فرد مسئول ارسال می‌شود.
3. Critical (بحرانی): استفاده از دیسک به ۹۵٪ رسیده است. این هشدار از طریق تماس تلفنی یا ارسال به کانال اضطراری اطلاع‌رسانی می‌شود.

این رویکرد باعث می‌شود که تیم شما بتواند اولویت‌بندی کند و فقط در موارد بحرانی از خواب بیدار شود.

اشتباه رایج: نادیده گرفتن «مدت زمان» (For Duration)

یکی از رایج‌ترین اشتباهات در مانیتورینگ ابری، هشدار دادن بر اساس یک نمونه (sample) واحد است. اگر CPU برای ۳۰ ثانیه به ۹۰٪ برسد، ممکن است فقط یک spike کوتاه باشد که به‌خودی‌خود برطرف می‌شود. همیشه از پارامتر for استفاده کنید تا هشدار فقط پس از تداوم مشکل در یک بازه مشخص (مثلاً ۱۰ دقیقه) فعال شود. در مثال بالا، for: 15m یعنی مشکل باید ۱۵ دقیقه ادامه یابد تا هشدار صادر شود.

کانال‌های اطلاع‌رسانی: پیام درست، در کانال درست

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

ماتریس کانال‌ها و سطوح هشدار

• ایمیل: مناسب برای هشدارهای سطح Info و گزارش‌های دوره‌ای. ایمیل را برای موارد بحرانی استفاده نکنید؛ ممکن است ساعت‌ها دیده نشود.
• پیامک (SMS): مناسب برای سطح Warning. اگر تیم شما شیفتی است، پیامک را به فرد مسئول شیفت ارسال کنید.
• پیام‌رسان‌های تیمی (Slack, Telegram, Rocket.Chat): بهترین گزینه برای هشدارهای سطح Warning و Critical. با استفاده از Webhook می‌توانید هشدارها را به کانال‌های خاص ارسال کنید.
• تماس تلفنی (Phone Call): فقط برای سطح Critical. سرویس‌هایی مانند PagerDuty یا Opsgenie این امکان را فراهم می‌کنند.

مثال عملی: ارسال هشدار به تلگرام با Webhook

فرض کنید از Alertmanager استفاده می‌کنید و می‌خواهید هشدارهای Critical را به یک ربات تلگرام ارسال کنید. ابتدا یک ربات بسازید و توکن آن را دریافت کنید. سپس در فایل پیکربندی Alertmanager، یک receiver تعریف کنید:

receivers:
  - name: 'telegram-critical'
    webhook_configs:
      - url: 'https://api.telegram.org/bot<YOUR_BOT_TOKEN>/sendMessage'
        send_resolved: true
        http_config:
          headers:
            Content-Type: application/json
        body: |
          {
            "chat_id": "<YOUR_CHAT_ID>",
            "text": "{{ range .Alerts }}{{ .Annotations.summary }}\n{{ .Annotations.description }}{{ end }}",
            "parse_mode": "HTML"
          }

نکته مهم: در Webhook تلگرام، باید متد sendMessage را به‌صورت مستقیم در URL قرار دهید و بدنه درخواست را به‌صورت JSON ارسال کنید. همچنین مقدار chat_id را می‌توانید از طریق ربات @userinfobot در تلگرام دریافت کنید.

اشتباه رایج: ارسال همه هشدارها به یک کانال

اگر همه هشدارها (از Info تا Critical) به یک کانال تلگرام ارسال شود، اعضای تیم به‌سرعت اعلان‌ها را بی‌صدا (Mute) می‌کنند. حتماً کانال‌ها را تفکیک کنید: یک کانال عمومی برای هشدارهای Info و Warning، و یک کانال محدود (یا حتی یک گروه جداگانه) برای هشدارهای Critical که فقط افراد مسئول عضو آن هستند.

جمع‌بندی: مانیتورینگ ابری یک فرایند است، نه یک ابزار

مانیتورینگ ابری مؤثر، ترکیبی از انتخاب شاخص‌های درست، تنظیم آستانه‌های هوشمند و ارسال هشدار به کانال‌های مناسب است. با پیاده‌سازی چرخه‌ای که در این مقاله توضیح داده شد، می‌توانید از حالت واکنشی خارج شوید و به‌صورت پیشگیرانه مشکلات را قبل از تأثیر بر کاربران شناسایی کنید.

اگر تیم شما تازه شروع به کار با زیرساخت ابری کرده است، پیشنهاد می‌کنم ابتدا با یک ابزار ساده مانند Prometheus و Grafana شروع کنید و به‌تدریج پیچیدگی‌ها را اضافه کنید. به یاد داشته باشید که هدف نهایی، داشتن یک داشبورد زیبا نیست؛ هدف، کاهش زمان تشخیص و بازیابی (MTTD و MTTR) است. سرویس‌های میزبانی ابری مانند آنچه ServerNet ارائه می‌دهد، معمولاً ابزارهای پایش پایه را در اختیار شما می‌گذارند؛ اما تنظیم دقیق هشدارها و شاخص‌ها، همیشه مسئولیت تیم فنی شماست.

در نهایت، یک توصیه عملی: هر ماه یک «بازبینی هشدار» انجام دهید. هشدارهایی که در یک ماه گذشته هیچ اقدام عملی به دنبال نداشته‌اند را حذف یا اصلاح کنید. این کار باعث می‌شود سیستم هشدار شما همیشه مرتب، کارآمد و قابل‌اعتماد بماند.