بهترین روش‌های مانیتورینگ سرورها (Prometheus، Grafana و ...)

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

به همین دلیل، Server Monitoring فقط بررسی Up یا Down بودن سرور نیست. یک سیستم مانیتورینگ حرفه‌ای باید بتواند وضعیت منابع، عملکرد سرویس‌ها، ظرفیت زیرساخت، روند تغییرات و خطاهای مهم را جمع‌آوری کند و در زمان مناسب تیم فنی را از مشکل مطلع سازد.

در معماری‌های مدرن، ترکیب Prometheus، Node Exporter، Grafana و Alertmanager یکی از الگوهای رایج برای مانیتورینگ Metrics است. در کنار آن‌ها، بسته به نیاز سازمان می‌توان Logging و Tracing را نیز به معماری Observability اضافه کرد.

مانیتورینگ سرور دقیقاً چیست؟

مانیتورینگ سرور فرآیند جمع‌آوری، ذخیره‌سازی، تحلیل و نمایش اطلاعات مربوط به وضعیت و عملکرد یک Server یا Infrastructure است.

یک سیستم مانیتورینگ مناسب باید بتواند حداقل به این پرسش‌ها پاسخ دهد:

• آیا سرور در دسترس است؟
• CPU چه میزان مصرف دارد؟
• Memory و Swap در چه وضعیتی هستند؟
• کدام Disk یا Filesystem در حال پر شدن است؟
• میزان Read و Write دیسک چقدر است؟
• ترافیک ورودی و خروجی Network چقدر است؟
• آیا Packet Loss یا Network Error وجود دارد؟
• Load سیستم در چه وضعیتی است؟
• آیا سرویس‌های مهم در حال اجرا هستند؟
• آیا Latency سرویس افزایش پیدا کرده است؟
• آیا وضعیت فعلی با روند معمول سیستم متفاوت است؟
• اگر مشکلی رخ دهد، چه کسی و از چه طریقی باید مطلع شود؟

بنابراین مانیتورینگ خوب باید از مشاهده وضعیت به سمت تشخیص مشکل و واکنش به آن حرکت کند.

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

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

برای مثال، فرض کنید یک Filesystem به‌صورت میانگین هر روز ۲ درصد رشد می‌کند. بدون مانیتورینگ ممکن است تیم فنی زمانی متوجه مشکل شود که Disk به ۱۰۰ درصد رسیده و یک سرویس دیگر قادر به نوشتن اطلاعات نباشد.

اما با مانیتورینگ مناسب می‌توان افزایش مصرف Disk را از روزها یا هفته‌ها قبل مشاهده کرد و قبل از ایجاد Incident، ظرفیت را افزایش داد یا علت رشد غیرعادی را بررسی کرد.

تفاوت Monitoring با Observability چیست؟

Monitoring و Observability مفاهیم مرتبط اما یکسانی نیستند.

Monitoring معمولاً روی پاسخ دادن به پرسش‌هایی تمرکز دارد که از قبل می‌دانیم باید آن‌ها را بررسی کنیم؛ برای مثال:

• CPU بالای ۸۰ درصد است؟
• Disk کمتر از ۱۰ درصد فضای آزاد دارد؟
• سرور Down شده است؟
• HTTP Error Rate افزایش پیدا کرده است؟

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

معمولاً سه دسته اصلی داده در معماری Observability مطرح هستند:

در نتیجه، Prometheus و Grafana می‌توانند بخش مهمی از Monitoring را پوشش دهند، اما در معماری‌های پیچیده‌تر، Monitoring تنها بخشی از Observability است.

معماری استاندارد مانیتورینگ سرورها

یک معماری ساده و قابل توسعه برای مانیتورینگ Linux Server می‌تواند به شکل زیر باشد:

Linux Server
     │
     ▼
Node Exporter
     │
     │ Metrics
     ▼
Prometheus
     │
     ├──────────► Alertmanager
     │                 │
     │                 ├── Email
     │                 ├── Chat
     │                 └── On-Call
     │
     ▼
Grafana
     │
     ├── Dashboards
     ├── Explore
     └── Alerting

در این معماری، Node Exporter اطلاعات مربوط به Host را در اختیار Prometheus قرار می‌دهد. Prometheus این Metrics را به‌صورت Time Series جمع‌آوری و ذخیره می‌کند و Grafana برای Query و Visualization آن‌ها استفاده می‌شود. Alertmanager نیز مسئول مدیریت و مسیریابی Alertهای Prometheus است.

Prometheus به‌صورت رسمی Node Exporter را برای Export کردن طیف وسیعی از Hardware و Kernel Metrics در سیستم‌های Unix-like ارائه می‌کند. 

Prometheus چیست؟

Prometheus یک سیستم Open Source برای Monitoring و ذخیره‌سازی Time-Series Metrics است.

در مدل معمول Prometheus، خود Prometheus به‌صورت دوره‌ای Endpointهای مشخصی را اصطلاحاً Scrape می‌کند و Metrics را دریافت می‌کند.

برای مثال، Node Exporter می‌تواند Endpointی مانند زیر ارائه دهد:

/metrics

Prometheus در بازه‌های مشخص به این Endpoint درخواست می‌فرستد و Metrics را دریافت می‌کند.

این مدل باعث می‌شود Prometheus بتواند وضعیت تعداد زیادی Server و Service را در یک سیستم متمرکز جمع‌آوری کند.

Node Exporter چیست؟

Node Exporter یکی از مهم‌ترین اجزای Monitoring برای Linux Server است. این ابزار Metrics مربوط به سیستم‌عامل و منابع سخت‌افزاری را در قالبی قابل دریافت توسط Prometheus ارائه می‌کند.

برخی از Metrics مهم Node Exporter عبارت‌اند از:

• CPU Usage
• Memory Usage
• Swap
• Filesystem Usage
• Disk I/O
• Network Traffic
• Network Errors
• Load Average
• System Uptime
• File System Statistics
• Kernel و System Metrics

برای مثال، Metricsهایی مانند node_cpu_seconds_total و node_filesystem_avail_bytes می‌توانند برای تحلیل وضعیت CPU و فضای دیسک استفاده شوند. 

چه Metricsهایی را باید روی سرور مانیتور کنیم؟

یکی از اشتباهات رایج این است که Monitoring را به CPU و RAM محدود کنیم. یک سیستم Production باید مجموعه‌ای از Metrics را در چند لایه بررسی کند.

۱. CPU

مصرف CPU یکی از مهم‌ترین شاخص‌های عملکرد سرور است، اما صرفاً درصد CPU Usage همیشه معیار مناسبی نیست.

بهتر است مواردی مانند موارد زیر نیز بررسی شوند:

• User CPU
• System CPU
• IO Wait
• Steal Time در محیط‌های Virtualized
• Load Average
• CPU Saturation

برای مثال، CPU Usage پایین در کنار IO Wait بالا می‌تواند نشان دهد که مشکل اصلی CPU نیست و سیستم بیشتر منتظر Storage است.

۲. Memory

Memory Monitoring نیز فقط بررسی درصد RAM مصرف‌شده نیست.

شاخص‌های مهم شامل موارد زیر هستند:

• Used Memory
• Available Memory
• Cached Memory
• Swap Usage
• Swap I/O
• Memory Pressure

استفاده از Swap به‌تنهایی الزاماً به معنی خرابی نیست، اما افزایش مداوم Swap Activity می‌تواند نشانه فشار Memory باشد.

۳. Disk و Filesystem

برای Disk Monitoring باید حداقل دو موضوع متفاوت را بررسی کرد: Capacity و Performance.

از نظر Capacity، موارد زیر مهم هستند:

• Filesystem Usage
• Free Space
• Inode Usage
• Growth Rate

از نظر Performance نیز باید شاخص‌هایی مانند IOPS، Throughput، Latency و Queue را در صورت در دسترس بودن بررسی کرد.

۴. Network

در Network Monitoring باید فقط Traffic را اندازه‌گیری نکرد. Error و Saturation نیز اهمیت زیادی دارند.

• Inbound Traffic
• Outbound Traffic
• Packets per Second
• Packet Errors
• Dropped Packets
• Connection Count
• Network Throughput

۵. Availability

یک سرور ممکن است از دید سیستم‌عامل Up باشد اما سرویس اصلی آن قابل استفاده نباشد.

به همین دلیل بهتر است Availability در چند سطح بررسی شود:

• Host Availability
• Port Availability
• Process Availability
• Service Availability
• HTTP Availability
• Application Health

Grafana چه نقشی در مانیتورینگ دارد؟

Grafana معمولاً لایه Visualization و تحلیل Monitoring است.

Grafana می‌تواند به Prometheus متصل شود و داده‌های Time Series را در قالب Dashboard، Graph، Table، Stat Panel و Visualizationهای مختلف نمایش دهد.

در مستندات Grafana، Prometheus به‌عنوان یک Data Source داخلی پشتیبانی می‌شود و می‌توان از PromQL برای Query کردن Metrics استفاده کرد. Grafana همچنین امکان Explore، Visualization و Alerting روی داده‌های Prometheus را فراهم می‌کند. 

یک Dashboard مناسب Server Monitoring می‌تواند شامل بخش‌های زیر باشد:

• Server Availability
• CPU
• Memory
• Disk
• Network
• Load Average
• Filesystem
• Top Processes
• Alerts

Dashboard خوب چه ویژگی‌هایی دارد؟

داشتن صدها نمودار لزوماً به معنی داشتن Dashboard بهتر نیست.

یک Dashboard عملیاتی باید در چند ثانیه وضعیت کلی سیستم را مشخص کند.

بهتر است Dashboard در چند سطح طراحی شود:

سطح اول: Overview

• تعداد Serverهای سالم و ناسالم
• Active Alerts
• CPU و Memory کلی
• Diskهای بحرانی
• Availability

سطح دوم: Server Detail

• CPU
• Memory
• Disk I/O
• Filesystem
• Network
• Load
• Processes

سطح سوم: Troubleshooting

• Time Series دقیق‌تر
• Correlation بین Metrics
• Logs
• Events
• Application Metrics

این ساختار باعث می‌شود Grafana فقط یک صفحه پر از Graph نباشد و واقعاً به ابزار Operations تبدیل شود.

PromQL چیست و چرا اهمیت دارد؟

PromQL زبان Query کردن Metrics در Prometheus است.

برای مثال، یک Metric خام ممکن است میزان CPU Time را نشان دهد. اما برای تبدیل آن به نرخ مصرف CPU باید روی Time Series عملیات مناسب انجام شود.

یکی از الگوهای رایج:

rate(node_cpu_seconds_total[5m])

سپس می‌توان با استفاده از Labelها، Aggregation و سایر قابلیت‌های PromQL اطلاعات دقیق‌تری استخراج کرد.

در عمل، کیفیت Dashboard تا حد زیادی به کیفیت Queryهای PromQL وابسته است. Dashboardهای پیچیده با Queryهای غیرضروری می‌توانند فشار زیادی به Monitoring Backend وارد کنند.

Alerting؛ مهم‌تر از Dashboard

داشتن Dashboard به این معنی نیست که Monitoring کامل شده است.

اگر ساعت سه صبح یک سرور Disk پر کند، احتمالاً کسی قرار نیست دائماً Grafana را نگاه کند.

اینجاست که Alerting اهمیت پیدا می‌کند.

Prometheus می‌تواند Alert Ruleهایی را بر اساس Expressions تعریف کند. این Ruleها می‌توانند پس از برقرار بودن یک شرط برای مدت مشخص، Alert را فعال کنند. 

برای مثال، به‌جای اینکه صرفاً بگوییم:

Disk Usage > 80%

می‌توان Rule را طوری طراحی کرد که فقط زمانی Alert ایجاد شود که وضعیت برای چند دقیقه پایدار باشد. این کار از ایجاد Alertهای ناشی از Spikeهای کوتاه‌مدت جلوگیری می‌کند.

Alertmanager چیست؟

Alertmanager بخشی از اکوسیستم Prometheus است که وظیفه مدیریت Alertها و ارسال Notification را بر عهده دارد.

Prometheus تشخیص می‌دهد که یک شرط Alert برقرار شده است؛ سپس Alertmanager می‌تواند Alertها را Group، Deduplicate، Route، Silence و Inhibit کند و آن‌ها را به Receiver مناسب ارسال کند. 

این تفکیک معماری اهمیت زیادی دارد:

Metrics
   │
   ▼
Prometheus
   │
   │ Alert Rules
   ▼
Alertmanager
   │
   ├── Email
   ├── Chat
   ├── On-Call
   └── Other Notification Channels

برای مثال اگر ۲۰ سرور به دلیل یک Network Failure هم‌زمان دچار مشکل شوند، بهتر است تیم فنی ۲۰ Notification مستقل و غیرقابل استفاده دریافت نکند. Grouping و Routing می‌تواند این Alertها را به شکل قابل مدیریت‌تری ارائه کند.

چه Alertهایی برای سرور ضروری هستند؟

هیچ Threshold واحدی برای تمام سازمان‌ها وجود ندارد؛ اما یک Baseline مناسب می‌تواند شامل Alertهای زیر باشد:

یکی از بزرگ‌ترین اشتباهات: Alert زیاد

Monitoring ضعیف معمولاً یا هیچ Alertی ندارد یا برعکس، تعداد زیادی Alert غیرضروری تولید می‌کند.

اگر تیم Operations روزانه صدها Alert دریافت کند، به‌مرور دچار Alert Fatigue می‌شود و احتمال نادیده گرفتن Alertهای واقعی افزایش پیدا می‌کند.

هر Alert بهتر است یک Action مشخص داشته باشد:

• آیا نیاز به اقدام فوری دارد؟
• چه کسی باید آن را بررسی کند؟
• Severity آن چیست؟
• Runbook مربوط به آن کجاست؟
• اگر رفع نشود چه اتفاقی رخ می‌دهد؟

اگر برای یک Alert هیچ Action مشخصی وجود ندارد، باید بررسی کرد که آیا اصلاً لازم است Alert باشد یا بهتر است فقط در Dashboard نمایش داده شود.

Monitoring سرویس‌ها؛ فقط مانیتور کردن سرور کافی نیست

ممکن است Server کاملاً سالم باشد اما Application روی آن خراب شده باشد.

برای همین Monitoring باید از سطح Host به سطح Service و Application نیز گسترش پیدا کند.

برای مثال در یک Server که PostgreSQL روی آن اجرا می‌شود، فقط CPU و RAM کافی نیست. بهتر است Metrics مربوط به مواردی مانند Connectionها، Query Performance، Replication و Storage نیز در صورت نیاز بررسی شوند.

همین موضوع برای Redis، MySQL، Nginx، HAProxy، RabbitMQ، Kafka و سایر سرویس‌های Infrastructure نیز صدق می‌کند.

این Metrics معمولاً از طریق Exporterهای تخصصی یا Integrationهای مربوط به همان سرویس وارد سیستم Monitoring می‌شوند.

Blackbox Monitoring چیست؟

در کنار Whitebox Monitoring که وضعیت داخلی سیستم را بررسی می‌کند، Blackbox Monitoring نیز اهمیت زیادی دارد.

در Blackbox Monitoring از بیرون به سرویس نگاه می‌کنیم و می‌پرسیم:

• آیا DNS پاسخ می‌دهد؟
• آیا Port باز است؟
• آیا HTTP Endpoint پاسخ می‌دهد؟
• Latency چقدر است؟
• آیا TLS Certificate معتبر است؟

این نوع Monitoring برای بررسی واقعی Availability از دید Client بسیار مفید است.

به‌خصوص در معماری‌هایی که چندین Load Balancer، Reverse Proxy، Firewall یا Network Segment وجود دارد، ممکن است Host از دید داخلی سالم باشد اما از دید کاربر قابل دسترسی نباشد.

Monitoring سرورها در Kubernetes

در محیط‌های Kubernetes، Monitoring پیچیده‌تر می‌شود؛ زیرا دیگر فقط چند Server مستقل نداریم و باید وضعیت Cluster، Node، Pod، Container، Workload و Application را نیز بررسی کنیم.

در چنین محیطی معمولاً Monitoring شامل چند لایه است:

در معماری‌های Kubernetes، ترکیب Prometheus و Grafana می‌تواند پایه مناسبی برای Monitoring باشد و در کنار آن باید Logging، Tracing و Application Metrics نیز در صورت نیاز اضافه شوند.

اگر با Kubernetes کار می‌کنید، پیشنهاد می‌کنیم راهنمای کوبرنتیس چیست؟ و همچنین مقاله مقدمه‌ای بر کوبرنتیس را نیز مطالعه کنید.

Monitoring و Logging چه تفاوتی دارند؟

Metrics و Logs اطلاعات متفاوتی ارائه می‌کنند.

برای مثال:

Metric:
CPU Usage = 94%

Log:
2026-09-26 12:41:23
database connection timeout

Metric می‌تواند نشان دهد که مشکلی رخ داده است؛ Log ممکن است اطلاعات بیشتری درباره علت آن ارائه کند.

به همین دلیل، در زیرساخت‌های Production بهتر است Metrics و Logs در کنار یکدیگر قرار بگیرند.

برای مانیتورینگ Log می‌توانید مقاله مانیتورینگ لاگ‌ها با Loki و Grafana را مطالعه کنید.

OpenTelemetry چه نقشی دارد؟

OpenTelemetry یک چارچوب مهم برای جمع‌آوری Telemetry در معماری‌های مدرن است و می‌تواند در کنار Prometheus و Grafana قرار گیرد.

در معماری‌های پیچیده‌تر، ممکن است بخشی از Metrics، Logs و Traces از طریق OpenTelemetry Collector جمع‌آوری و سپس به Backend مناسب ارسال شوند.

برای مثال می‌توان معماری را به شکل زیر توسعه داد:

Servers / Applications
        │
        ├── Metrics ───────► Prometheus
        │
        ├── Logs ──────────► Loki
        │
        └── Traces ────────► Tempo / Jaeger
                                  │
                                  ▼
                               Grafana

OpenTelemetry Collector نیز دارای Host Metrics Receiver برای جمع‌آوری Host-level Metrics است و در معماری‌های Agent-based می‌تواند مورد استفاده قرار گیرد. 

Prometheus یا ابزارهای دیگر؟

Prometheus انتخاب مناسبی برای بسیاری از محیط‌های مدرن است، اما تنها راه‌حل موجود نیست.

انتخاب ابزار باید بر اساس Architecture، تعداد Serverها، نوع Application، نیاز به Retention، مدل Alerting، تیم Operations و نیازهای Observability انجام شود؛ نه صرفاً محبوبیت یک ابزار.

مانیتورینگ متمرکز یا مانیتورینگ روی هر سرور؟

در محیط‌های کوچک ممکن است نصب یک Monitoring Stack روی یک Server جداگانه کافی باشد:

Server 1 ─┐
Server 2 ─┤
Server 3 ─┼──► Prometheus ──► Grafana
Server 4 ─┘

اما در محیط‌های بزرگ‌تر، Monitoring خودش تبدیل به یک سرویس حیاتی می‌شود و باید برای آن Availability، Backup، Security و Capacity Planning در نظر گرفت.

اگر Prometheus تنها محل نگهداری Metrics باشد و خودش از دسترس خارج شود، ممکن است Visibility زیرساخت نیز از بین برود.

در محیط‌های Enterprise می‌توان از معماری‌هایی مانند Prometheus Federation یا Backendهای سازگار با Prometheus برای نگهداری و Query کردن Metrics در مقیاس بزرگ‌تر استفاده کرد.

Retention و Storage را فراموش نکنید

Metrics نیز مانند Logs فضای Storage مصرف می‌کنند.

هرچه تعداد Serverها، Metricsها، Labelها و مدت Retention بیشتر شود، حجم داده افزایش پیدا می‌کند.

بنابراین باید از ابتدا درباره موارد زیر تصمیم‌گیری شود:

• چند Server مانیتور می‌شود؟
• Scrape Interval چقدر است؟
• چند Metric جمع‌آوری می‌شود؟
• Cardinality چقدر است؟
• Metrics برای چند روز یا ماه نگهداری می‌شوند؟
• آیا Long-Term Storage نیاز است؟
• آیا Metrics باید به یک Backend دیگر ارسال شوند؟

Cardinality چیست و چرا اهمیت دارد؟

یکی از موضوعات مهم در Prometheus، Cardinality است.

هر ترکیب متفاوت از Metric Name و Labelها یک Time Series ایجاد می‌کند. اگر Labelهایی با تعداد مقادیر بسیار زیاد یا تقریباً نامحدود استفاده شوند، تعداد Seriesها می‌تواند به‌شدت افزایش پیدا کند.

برای مثال استفاده از User ID، Request ID یا بعضی مقادیر Unique به‌عنوان Label می‌تواند طراحی نامناسبی باشد.

بنابراین باید Labelها را با دقت انتخاب کرد و از ایجاد High Cardinality غیرضروری جلوگیری کرد.

Monitoring امن چگونه باید باشد؟

Endpointهای Monitoring حاوی اطلاعات داخلی زیرساخت هستند و نباید بدون کنترل در Internet قرار بگیرند.

حداقل اقدامات امنیتی شامل موارد زیر است:

• قرار ندادن Prometheus در معرض Public Internet بدون نیاز
• محافظت از Grafana با Authentication مناسب
• استفاده از HTTPS/TLS
• محدود کردن دسترسی Network به Monitoring Endpoints
• استفاده از Firewall و Network Segmentation
• مدیریت صحیح Credentials
• محدود کردن دسترسی کاربران Grafana بر اساس Role
• مانیتور کردن خود Monitoring Stack

به‌خصوص Endpointهایی مانند /metrics ممکن است اطلاعاتی درباره نام Hostها، Interfaceها، سرویس‌ها و وضعیت داخلی سیستم ارائه دهند؛ بنابراین باید سطح دسترسی آن‌ها کنترل شود.

Monitoring خود Monitoring Stack

یکی از اشتباهات رایج این است که همه‌چیز را مانیتور می‌کنیم به‌جز خود سیستم مانیتورینگ.

باید حداقل موارد زیر برای Monitoring Stack نیز بررسی شوند:

• Prometheus Availability
• Prometheus Storage
• Scrape Failures
• Target Down
• Query Performance
• Grafana Availability
• Alertmanager Availability
• Monitoring Server CPU و Memory
• Storage Growth

به بیان ساده، اگر Prometheus یا Alertmanager از کار بیفتد، نباید تنها زمانی متوجه آن شوید که یک سرویس دیگر نیز خراب شده است.

بهترین روش طراحی Alertها

یک Alert خوب باید چهار ویژگی داشته باشد:

1. Actionable باشد؛ یعنی دریافت آن منجر به یک اقدام مشخص شود.
2. Meaningful باشد؛ یعنی مشکل واقعی را نشان دهد.
3. Stable باشد؛ یعنی با هر Spike کوتاه‌مدت فعال نشود.
4. Context-rich باشد؛ یعنی اطلاعات کافی برای شروع Troubleshooting داشته باشد.

استفاده از Severity نیز بسیار مفید است:

همچنین بهتر است Alertها دارای Annotationهایی مانند Summary، Description، Instance و لینک Dashboard یا Runbook باشند.

از Thresholdهای ثابت فراتر بروید

Threshold ثابت همیشه بهترین روش نیست.

برای مثال CPU برابر ۸۰ درصد ممکن است برای یک Server کاملاً طبیعی باشد، اما برای Server دیگری نشانه مشکل باشد.

بهتر است Thresholdها با توجه به رفتار واقعی Workload و Business Impact تعیین شوند.

در سیستم‌های بالغ‌تر می‌توان از روند تاریخی، Baseline، Percentile و SLO استفاده کرد تا Alertها بیشتر بر Impact تمرکز کنند تا صرفاً یک عدد ثابت.

مانیتورینگ و SRE

در رویکردهای SRE، Metrics فقط برای نمایش وضعیت Server نیستند؛ بلکه بخشی از تصمیم‌گیری درباره Reliability سیستم هستند.

برای مثال می‌توان روی شاخص‌هایی مانند موارد زیر تمرکز کرد:

• Availability
• Latency
• Error Rate
• Throughput
• Resource Saturation

این نگاه باعث می‌شود Monitoring از یک ابزار Operations به بخشی از مدیریت Reliability تبدیل شود.

برای آشنایی بیشتر با این رویکرد، مقاله اصول SRE و نقش آن در DevOps را نیز مطالعه کنید.

Monitoring در معماری High Availability

در معماری‌های High Availability، مانیتورینگ اهمیت بیشتری پیدا می‌کند؛ زیرا باید علاوه بر سلامت هر Node، وضعیت کل سرویس نیز بررسی شود.

برای مثال در یک Cluster ممکن است یک Node Down شود اما Service همچنان در دسترس باقی بماند. در این حالت Host-level Alert ممکن است به‌تنهایی Severity بالایی نداشته باشد، در حالی که از دست رفتن چند Node می‌تواند به یک Incident جدی تبدیل شود.

به همین دلیل Alerting باید تا حد امکان با Architecture واقعی سرویس و Business Impact هماهنگ شود.

برای اطلاعات بیشتر درباره معماری‌های High Availability می‌توانید به خدمات High Availability آلتیمیت کلاد مراجعه کنید.

یک معماری پیشنهادی برای سازمان‌های متوسط و Enterprise

برای یک زیرساخت متوسط یا Enterprise می‌توان معماری زیر را در نظر گرفت:

                    ┌───────────────┐
                    │    Grafana    │
                    └───────┬───────┘
                            │
                            ▼
                     ┌─────────────┐
                     │  Prometheus │
                     └──────┬──────┘
                            │
              ┌─────────────┼─────────────┐
              │             │             │
              ▼             ▼             ▼
       Node Exporter   App Metrics   Service Exporters
              │             │             │
       ┌──────┴──────┐      │      ┌──────┴──────┐
       ▼             ▼      ▼      ▼             ▼
    Server 1      Server 2  ...  Redis        Database

                     Prometheus
                          │
                          ▼
                    Alertmanager
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
           Email         Chat        On-Call

در صورت نیاز می‌توان Logging و Tracing را نیز به این Architecture اضافه کرد:

Metrics ──► Prometheus ──┐
                         │
Logs ─────► Loki ────────┼──► Grafana
                         │
Traces ───► Tempo ───────┘

این مدل یک پایه مناسب برای حرکت از Monitoring به سمت Observability ایجاد می‌کند.

بهترین روش مانیتورینگ سرور چیست؟

یک نسخه واحد برای تمام سازمان‌ها وجود ندارد، اما برای بسیاری از زیرساخت‌های Linux و Cloud Native، معماری زیر نقطه شروع مناسبی است:

چک‌لیست پیاده‌سازی Server Monitoring

اگر قصد دارید یک سیستم مانیتورینگ استاندارد برای زیرساخت خود ایجاد کنید، این چک‌لیست می‌تواند نقطه شروع مناسبی باشد:

• ☐ مشخص کردن Serverها و سرویس‌های حیاتی
• ☐ تعیین Metrics مورد نیاز
• ☐ نصب Node Exporter روی Linux Serverها
• ☐ راه‌اندازی Prometheus
• ☐ تعریف Targetها و Scrape Interval
• ☐ راه‌اندازی Grafana
• ☐ ساخت Dashboardهای Overview و Detail
• ☐ تعریف Alertهای Critical و Warning
• ☐ راه‌اندازی Alertmanager
• ☐ تعریف Notification Channelها
• ☐ اضافه کردن Service Monitoring
• ☐ اضافه کردن Blackbox Monitoring برای سرویس‌های حیاتی
• ☐ بررسی Disk و Retention
• ☐ کنترل امنیت Monitoring Stack
• ☐ مانیتور کردن خود Monitoring Stack
• ☐ اتصال Metrics به Logs و Traces در صورت نیاز
• ☐ مستندسازی Runbookهای Incident
• ☐ بازبینی دوره‌ای Alertها و حذف Alertهای غیرضروری

اشتباهات رایج در مانیتورینگ سرورها

۱. فقط نصب کردن Grafana

Grafana به‌تنهایی Monitoring Backend نیست. باید Data Source مناسب و داده قابل اتکا داشته باشد.

۲. مانیتور کردن فقط CPU و RAM

مشکلات واقعی ممکن است از Disk، Network، Application، Database یا Dependencyهای خارجی ناشی شوند.

۳. Alertهای بیش از حد

Alert زیاد باعث Alert Fatigue می‌شود و ارزش Notificationها را کاهش می‌دهد.

۴. نادیده گرفتن Storage

Monitoring خودش داده تولید می‌کند و باید برای Storage و Retention آن Capacity Planning انجام شود.

۵. قرار دادن Monitoring روی همان نقطه Failure

اگر Monitoring و تمام زیرساخت Production روی یک Failure Domain قرار داشته باشند، هنگام Incident ممکن است خود Monitoring نیز از دسترس خارج شود.

۶. بدون Runbook بودن Alertها

Alert بدون توضیح و مسیر Troubleshooting در Incidentهای جدی ارزش محدودی دارد.

۷. عدم تست Alerting

ممکن است Dashboard کاملاً سالم باشد اما Notification Channel یا Routing اشتباه پیکربندی شده باشد. Alertها باید به‌صورت دوره‌ای تست شوند.

Monitoring به‌عنوان بخشی از خدمات DevOps

مانیتورینگ حرفه‌ای معمولاً یک پروژه مستقل و جدا از سایر اجزای زیرساخت نیست. در یک مدل DevOps بالغ، Monitoring با CI/CD، Infrastructure as Code، Security، Logging، Incident Management و SRE ارتباط مستقیم دارد.

به همین دلیل، طراحی یک Monitoring Stack مناسب باید هم‌زمان با معماری Application و Infrastructure انجام شود.

آلتیمیت کلاد در قالب خدمات دواپس و خدمات DevOps می‌تواند طراحی و پیاده‌سازی Monitoring، Metrics، Logging، Alerting و Observability را متناسب با معماری سازمان انجام دهد.

برای پروژه‌هایی که نیاز به یک راهکار کامل‌تر دارند، می‌توانید خدمات مانیتورینگ، خدمات مدیریت لاگ و خدمات High Availability آلتیمیت کلاد را نیز بررسی کنید.

سؤالات متداول

آیا Prometheus برای مانیتورینگ سرورهای Linux مناسب است؟

بله. Prometheus به همراه Node Exporter یکی از معماری‌های رایج برای جمع‌آوری Metrics سرورهای Linux است و می‌تواند CPU، Memory، Filesystem، Disk و Network را پایش کند.

آیا برای استفاده از Prometheus حتماً به Grafana نیاز داریم؟

خیر. Prometheus رابط و ابزارهای Query داخلی خود را دارد، اما Grafana امکانات بسیار گسترده‌تری برای Dashboard، Visualization، Explore و Alerting در اختیار تیم‌های فنی قرار می‌دهد.

آیا Grafana خودش Metrics را ذخیره می‌کند؟

Grafana عمدتاً نقش Visualization و Query Layer را دارد و می‌تواند به Data Sourceهایی مانند Prometheus، Loki و بسیاری Backendهای دیگر متصل شود.

Node Exporter چه کاری انجام می‌دهد؟

Node Exporter Metrics مربوط به سیستم‌عامل و منابع Host را در اختیار Prometheus قرار می‌دهد. این Metrics شامل اطلاعاتی درباره CPU، Memory، Filesystem، Disk و Network است.

آیا Monitoring سرور برای Kubernetes هم لازم است؟

بله، اما در Kubernetes باید علاوه بر Nodeها، وضعیت Cluster، Podها، Workloadها و Application Metrics نیز بررسی شود.

آیا Monitoring همان Observability است؟

خیر. Monitoring بخشی از Observability است. Observability معمولاً Metrics، Logs و Traces را در کنار یکدیگر قرار می‌دهد تا تیم بتواند هم وضعیت سیستم را مشاهده کند و هم علت مشکلات پیچیده را بهتر پیدا کند.

جمع‌بندی

مانیتورینگ حرفه‌ای سرورها فقط نصب یک Dashboard و مشاهده CPU و RAM نیست. یک سیستم Monitoring مناسب باید بتواند وضعیت زیرساخت را اندازه‌گیری کند، تغییرات را نشان دهد، مشکلات را به‌موقع تشخیص دهد و Alert قابل اقدام ایجاد کند.

برای بسیاری از زیرساخت‌های مدرن، ترکیب Prometheus + Node Exporter + Grafana + Alertmanager نقطه شروع بسیار مناسبی است. در ادامه، با افزایش پیچیدگی معماری، می‌توان Application Metrics، Blackbox Monitoring، Logging و Distributed Tracing را نیز اضافه کرد.

مهم‌تر از انتخاب یک ابزار خاص، طراحی درست Architecture، انتخاب Metrics مناسب، کنترل Cardinality، تعریف Alertهای Actionable، تأمین Security و مانیتور کردن خود Monitoring Stack است.

در نهایت، هدف Monitoring این نیست که تعداد بیشتری نمودار داشته باشیم؛ هدف این است که قبل از تبدیل شدن یک مشکل زیرساختی به یک Incident جدی، از آن باخبر شویم و اطلاعات کافی برای تصمیم‌گیری و رفع مشکل در اختیار داشته باشیم.

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