رفع مشکل ارسال نشدن هشدار در Zabbix 7.4؛ از رویداد تا اعلان

داده‌ها در Latest data به‌روز می‌شوند و حتی ممکن است یک Problem هم در داشبورد دیده شود، اما ایمیل مورد انتظار به دست شما نمی‌رسد. از کجا باید بررسی را شروع کرد: ارتباط Agent، تنظیمات SMTP یا شرایط Action؟

برای پیدا کردن علت، باید مشخص کنیم زنجیرهٔ ارسال اعلان در کدام مرحله متوقف شده است. در این مقاله، ابتدا مسیر بررسی را مرور می‌کنیم و سپس یک خطای مشخص را در قالب سناریوی آموزشی بازسازی می‌کنیم: رویداد Warning ایجاد می‌شود، اما Action برای High و بالاتر تنظیم شده است.

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

پاسخ کوتاه: چرا داده ثبت می‌شود اما اعلان نمی‌رسد؟

مسیر معمول اعلان مبتنی بر Trigger چنین است:

دریافت مقدار Item ← ارزیابی Trigger و ایجاد رویداد ← تطبیق شرایط Action ← اجرای Operation ← ارسال از Media type به مقصد کاربر

وجود مقدار در Latest data فقط دریافت داده را نشان می‌دهد. برای اعلان، باید رویداد مناسب ایجاد شود، شرایط Action برقرار باشد و عملیات ارسال با گیرنده و کانال درست تعریف شده باشد.

پیش از تغییر تنظیمات، این سه سؤال را پاسخ دهید:

1. آیا برای همین مشکل، رویداد PROBLEM ایجاد شده است؟
2. آیا Action مربوط به همین رویداد اجازهٔ اجرا داشته است؟
3. آیا تلاش ارسال ثبت شده و نتیجهٔ آن چیست؟

قدم اول: وجود رویداد را بررسی کنید

به Monitoring → Latest data بروید و زمان آخرین مقدار Item را ببینید. سپس در Monitoring → Problems، مشکل مرتبط با همان Host و Trigger را پیدا کنید؛ فیلتر زمان و نمایش رویدادهای حل‌شده یا سرکوب‌شده را نیز متناسب با مورد بررسی تنظیم کنید.

نام Host، زمان وقوع و Severity رویداد را یادداشت کنید.

اگر Problem مرتبطی وجود ندارد، بررسی را روی وضعیت و عبارت Trigger ادامه دهید. دریافت داده به این معنی نیست که شرط Trigger برقرار شده است. Trigger داده را ارزیابی می‌کند و بر اساس عبارت خود تغییر وضعیت می‌دهد.

در این مرحله، تغییر SMTP کمکی به توضیح نبودن یک رویداد نمی‌کند؛ ابتدا باید تولید رویداد روشن شود.

قدم دوم: آیا رویداد با Action تطبیق دارد؟

مسیر Alerts → Actions → Trigger actions را باز کنید و Action مورد نظر را بررسی کنید:

• فعال بودن Action؛
• انتخاب Host یا Host group درست؛
• شرط Severity و سایر فیلترها؛
• منطق ترکیب شرایط، مانند And یا Or.

برای مثال، یک رویداد با Severity برابر Warning، شرط «High و بالاتر» را برآورده نمی‌کند. همچنین در حالت And، درست بودن یکی از شرط‌ها کافی نیست؛ همهٔ شرایط باید برقرار باشند.

در صورت مشاهدهٔ این ناهماهنگی، ابتدا سیاست مورد انتظار اعلان را مشخص کنید:

• اگر قرار است Warning اطلاع‌رسانی شود، شرط Action باید آن را بپذیرد.
• اگر سیاست فقط اعلان مشکلات High است، نرسیدن پیام Warning می‌تواند رفتار صحیح تنظیمات باشد.

قدم سوم: عملیات ارسال و گیرنده را بررسی کنید

در تب Operations همان Action، وجود عملیات Send message را بررسی کنید. گیرنده، Media type و مراحل Escalation را ببینید.

ممکن است ارسال برای مرحله‌ای بعدی برنامه‌ریزی شده باشد؛ مقدار Start in در فهرست عملیات به تشخیص زمان مورد انتظار کمک می‌کند.

گیرنده باید حداقل دسترسی Read به Host مرتبط داشته باشد. برای دریافت اعلان، صرفاً وجود نام کاربر در تنظیمات Operation کافی نیست.

عملیات اعلان مشکل را در بخش Operations بررسی کنید. Recovery operations و Update operations برای موقعیت‌های متفاوتی هستند و جای عملیات اعلان اولیهٔ مشکل را نمی‌گیرند.

قدم چهارم: Media type و مقصد کاربر را جدا بررسی کنید

دو قسمت را از هم تفکیک کنید:

Media type: کانال ارسال، مانند Email یا Webhook.

User media: مقصد دریافت پیام برای کاربر، مانند آدرس ایمیل و شرایط استفاده از آن.

در Alerts → Media types، کانال مورد نظر را بررسی و با گزینهٔ Test یک پیام آزمایشی ارسال کنید. برای ایمیل، علاوه بر پیام موفقیت تست، دریافت واقعی پیام در صندوق مقصد را هم بررسی کنید.

این تست به‌تنهایی نشان نمی‌دهد که یک رویداد واقعی از شرایط Action عبور می‌کند.

سپس در Users → Users → کاربر مورد نظر → Media این موارد را ببینید:

• Status فعال باشد.
• مقدار Send to درست باشد.
• Severity مورد نظر در Use if severity انتخاب شده باشد.
• زمان ارسال در محدودهٔ When active قرار بگیرد.

بازهٔ زمانی User media بر اساس منطقهٔ زمانی همان کاربر محاسبه می‌شود. بنابراین تنظیمات ظاهراً درستِ ساعت کاری، با منطقهٔ زمانی نامناسب می‌تواند باعث ازدست‌رفتن اعلان مورد انتظار شود.

اگر تست کانال موفق است اما اعلان رویداد نمی‌رسد، بررسی Action، گیرنده، مجوز و شرایط User media را ادامه دهید.

قدم پنجم: Action log چه چیزی نشان می‌دهد؟

به Reports → Action log بروید و بازهٔ زمانی، Action، گیرنده و Media type مرتبط را انتخاب کنید.

نبود رکورد به‌تنهایی علت را ثابت نمی‌کند. برای ایمیلِ Sent که در صندوق دیده نمی‌شود، بررسی Spam، قرنطینه و لاگ سرویس ایمیل، قدم بعدی مناسبی است.

سناریوی آموزشی: Warning ساخته می‌شود، اما Action فقط High را می‌پذیرد

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

آماده‌سازی محیط

پیش از شروع:

• یک Zabbix Server 7.4 و ابزار zabbix_sender در دسترس داشته باشید.
• از Host و گیرندهٔ مخصوص آزمایش استفاده کنید.
• کانال Email را طوری تنظیم کنید که تست آن واقعاً به مقصد برسد.
• گیرنده به Host آزمایشگاهی دسترسی Read داشته باشد و User media او Warning را بپذیرد.
• برای ساده ماندن آزمایش، Host در Maintenance نباشد.

برای ساخت اشیای آزمایشگاهی از تنظیمات زیر استفاده کنید:

در Data collection → Hosts، Host را در یک گروه آزمایشگاهی بسازید، فعال نگه دارید و Item را اضافه کنید.

این Item از نوع Trapper است و مقدار را از فرستنده می‌پذیرد. پس از ذخیره، ممکن است برای به‌روزرسانی کش تنظیمات Server تا حدود ۶۰ ثانیه زمان لازم باشد.

عبارت Trigger را چنین قرار دهید:

last(/LAB-NOTIFY-01/lab.notify.test)=1

در این مثال، آخرین مقدار ۱ وضعیت مشکل را فعال می‌کند و مقدار ۰ امکان بازگشت به وضعیت عادی را فراهم می‌کند.

ساخت Action با ناهماهنگی عمدی

یک Trigger action آزمایشگاهی به نام LAB notification test بسازید:

برای مستقل بودن متن پیام آزمایش از الگوها، در Operation گزینهٔ Custom message را فعال کنید و یک Subject و Message ساده مخصوص لابراتوار بنویسید. Action را فعال و ذخیره کنید.

در این تنظیم، Host درست انتخاب شده، اما شرط Severity عمداً Warning را شامل نمی‌شود.

ایجاد رویداد کنترل‌شده

فرمان‌های زیر برای اجرای مستقیم zabbix_sender روی همان ماشین Zabbix Server، با پورت پیش‌فرض و ارتباط مجاز در لابراتوار نوشته شده‌اند.

در Docker، مسیر Proxy یا ارتباط TLS، آدرس مقصد و پارامترهای لازم را با همان محیط تطبیق دهید. مقدار -s باید نام فنی Host باشد.

ابتدا مقدار عادی را ارسال کنید:

zabbix_sender -z 127.0.0.1 -p 10051 -s "LAB-NOTIFY-01" -k lab.notify.test -o 0

ثبت مقدار ۰ و وضعیت عادی Trigger را بررسی کنید. سپس مقدار مشکل را بفرستید:

zabbix_sender -z 127.0.0.1 -p 10051 -s "LAB-NOTIFY-01" -k lab.notify.test -o 1

معیار بررسی، دریافت موفق مقدار توسط Server، مشاهدهٔ مقدار ۱ در Latest data و ایجاد Problem با Severity برابر Warning است.

خروجی ناموفق sender را ابتدا از نظر مقصد، نام فنی Host، کلید، Allowed hosts و کش تنظیمات بررسی کنید.

رفتار مورد انتظار: این رویداد با Action آزمایشگاهی تطبیق نمی‌کند؛ بنابراین نباید از همین Action پیام مشکل دریافت کنید. سایر Actionهای محیط ممکن است مستقل از این تمرین پیام بفرستند.

اصلاح شرط و آزمون دوباره

اگر سیاست لابراتوار ارسال پیام Warning است، شرط B را به این مقدار تغییر دهید:

Trigger severity is greater than or equals Warning

شرط Host را نگه دارید تا دامنهٔ Action به همان Host آزمایشگاهی محدود بماند. تغییر را ذخیره کنید و برای اعمال تنظیمات فرصت بدهید.

برای آزمونی قابل مقایسه، یک رویداد تازه ایجاد کنید:

1. مقدار ۰ را بفرستید.
2. بازگشت Trigger به OK را تأیید کنید.
3. مقدار ۱ را دوباره ارسال کنید.

این بار این سه معیار را بررسی کنید:

• Problem جدید با Severity برابر Warning ایجاد شده باشد.
• تلاش ارسال مربوط به Action آزمایشگاهی در Action log دیده شود.
• پیام در صندوق گیرندهٔ آزمایشگاهی دریافت شده باشد.

اگر معیار سوم برقرار نیست، از وضعیت و Info رکورد ارسال برای ادامهٔ تشخیص استفاده کنید. رسیدن به مرحلهٔ ارسال، بررسی کامل مقصد را حذف نمی‌کند.

پس از پایان تمرین، مقدار را به ۰ برگردانید و Action آزمایشگاهی را در صورت عدم نیاز غیرفعال کنید.

چه احتمال‌هایی را با چه شواهدی محدود می‌کنیم؟

هر شاهد فقط محدودهٔ خودش را تأیید می‌کند. دریافت یک پیام Test، سلامت تمام Actionها یا تحویل همهٔ اعلان‌های آینده را ثابت نمی‌کند.

اگر پیام ارسال می‌شود، اما با تأخیر می‌رسد

برای تأخیر، زمان ثبت رویداد را با زمان Operation و دریافت پیام مقایسه کنید. زمان‌بندی Escalation، تلاش‌های مجدد Media type و وضعیت مقصد ارسال را بررسی کنید.

در Maintenance، گزینهٔ Pause operations for suppressed problems می‌تواند اجرای عملیات مشکل را به تأخیر بیندازد. قبل از تغییر این گزینه، سیاست اطلاع‌رسانی زمان نگهداری را مشخص کنید.

چک‌لیست نهایی

• زمان آخرین دادهٔ مرتبط بررسی شده است.
• Problem مربوط به همان Host و Trigger مشخص است.
• Action فعال و شرایط آن منطبق با رویداد است.
• عملیات Send message، گیرنده و Media type درست تعریف شده‌اند.
• گیرنده حداقل دسترسی Read دارد.
• مقصد، Severity و بازهٔ زمانی User media بررسی شده‌اند.
• پیام Test در مقصد دریافت شده است.
• Action log و جزئیات خطا بررسی شده‌اند.
• پس از اصلاح، با یک رویداد جدید آزمون انجام شده است.

پرسش‌های متداول

چرا Test ایمیل موفق است، اما هشدار مشکل نمی‌رسد؟

Test کانال ارسال را با پارامترهای آزمایشی بررسی می‌کند. برای اعلان مشکل، Action، عملیات، مجوز گیرنده و شرایط User media نیز باید مناسب باشند.

آیا برای حل مشکل باید Severity را High کنیم؟

Severity باید بازتاب اهمیت واقعی مشکل باشد. اگر سیاست شما اعلان Warning است، شرایط ارسال را مطابق آن تنظیم کنید؛ شدت مشکل را صرفاً برای عبور از یک فیلتر تغییر ندهید.

چرا بعد از اصلاح، رویداد تازه می‌سازیم؟

این کار مقایسهٔ قبل و بعد را روشن‌تر می‌کند. تأیید بازگشت به OK و ایجاد PROBLEM جدید، وابستگی آزمون به وضعیت رویداد و Escalation قبلی را کمتر می‌کند.

نتیجهٔ این پرونده

در سناریوی طراحی‌شده، علت هدف ناهماهنگی Severity رویداد با شرط Action است. این فقط یکی از علت‌های ممکن ارسال‌نشدن اعلان است؛ در شبکهٔ خودتان، علت را با شواهد همان محیط تعیین کنید.

روش قابل تکرار این است: دریافت داده، ایجاد رویداد، تطبیق Action، عملیات ارسال و دریافت در مقصد را جداگانه بررسی کنید. سپس تغییر لازم را با یک رویداد جدید بسنجید.

ادامهٔ یادگیری

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

منابع رسمی

• اعلان‌ها در Zabbix 7.4
• شرایط Action
• عملیات Action
• Media types و تنظیمات مقصد کاربر
• Action log
• Zabbix trapper