اگر یک سرور لینوکس، VPS یا زیرساختی برای اجرای برنامه‌های خود دارید، بررسی مداوم وضعیت آن اهمیت زیادی دارد. پرشدن فضای دیسک، افزایش مصرف حافظه یا از دسترس خارج‌شدن یک سرویس می‌تواند باعث اختلال در وب‌سایت‌ها، APIها، پایگاه‌های داده و Workflowهای اتوماسیون شود.
یکی از روش‌های ساده برای آگاه‌شدن از این مشکلات، استفاده از n8n و ربات تلگرام است. با ترکیب این دو ابزار می‌توانید فرآیند بررسی وضعیت سرور را خودکار کنید و در صورت مشاهده شرایط غیرعادی، پیام هشدار دریافت کنید.
در این آموزش یک سیستم مانیتورینگ ساده می‌سازیم که در بازه‌های زمانی مشخص به سرور متصل می‌شود، مصرف حافظه و فضای دیسک را بررسی می‌کند و در صورت عبور از آستانه تعیین‌شده، گزارشی به تلگرام می‌فرستد.
مانیتورینگ سرور با n8n چه کاربردی دارد؟
مانیتورینگ یا پایش سرور به معنی بررسی وضعیت سیستم و شناسایی مشکلات احتمالی پیش از تبدیل‌شدن آن‌ها به اختلال جدی است.
برای مثال، فرض کنید چندین سرویس روی یک سرور اجرا می‌کنید. اگر فضای دیسک به ۹۰ درصد برسد، ممکن است ثبت لاگ‌ها، اجرای پردازش‌ها یا عملکرد پایگاه داده با مشکل مواجه شود. اگر این وضعیت زودتر شناسایی شود، فرصت دارید فایل‌های غیرضروری را بررسی کنید یا فضای ذخیره‌سازی را افزایش دهید.
با n8n می‌توانید چنین بررسی‌هایی را در یک Workflow قرار دهید و نتیجه را از طریق تلگرام دریافت کنید.
چند کاربرد مهم این روش عبارت‌اند از:
- بررسی مصرف RAM سرور
- بررسی درصد استفاده از فضای دیسک
- دریافت هشدار هنگام عبور منابع از آستانه تعیین‌شده
- بررسی دوره‌ای در دسترس‌بودن یک وب‌سایت یا API
- دریافت گزارش وضعیت سرور در ساعات مشخص
- ارسال هشدار به مدیر سیستم یا تیم پشتیبانی
در این مقاله، تمرکز اصلی بر بررسی منابع سیستم لینوکس از طریق SSH است. برای بررسی در دسترس‌بودن وب‌سایت‌ها نیز می‌توان یک مرحله HTTP Request به همین Workflow اضافه کرد.
پیش‌نیازهای آموزش
برای پیاده‌سازی مثال این مقاله به موارد زیر نیاز دارید:
- یک نمونه فعال از n8n
- یک ربات تلگرام متصل به n8n
- دسترسی SSH به سرور لینوکس موردنظر
- یک حساب کاربری محدود و مجاز برای اجرای فرمان‌های موردنیاز
- آشنایی مقدماتی با ساخت Workflow و استفاده از Nodeهای n8n
در این مثال، n8n می‌تواند روی همان سرور یا روی سرور دیگری اجرا شود. اگر روی سرور جداگانه قرار دارد، باید بتواند از طریق SSH به سرور مقصد متصل شود.
اگر هنوز ربات تلگرام را به n8n متصل نکرده‌اید، ابتدا مقاله «آموزش اتصال تلگرام به n8n؛ ساخت اولین اتوماسیون تلگرام» را مطالعه کنید.
مرحله اول: طراحی Workflow مانیتورینگ
ابتدا وارد پنل n8n شوید و یک Workflow جدید ایجاد کنید.
ساختار کلی Workflow ما به این صورت خواهد بود:
Schedule Trigger
|
v
SSH Node
|
v
پردازش اطلاعات
|
v
بررسی آستانه‌ها
|
v
آیا هشدار لازم است؟
|
+------ خیر ------> پایان
|
+------ بله ------> Telegram
هر بخش وظیفه مشخصی دارد:
- Schedule Trigger: اجرای دوره‌ای Workflow
- SSH: اتصال به سرور و اجرای فرمان‌های بررسی وضعیت
- Code یا Edit Fields: آماده‌سازی و پردازش داده‌ها
- IF: بررسی عبور منابع از حد تعیین‌شده
- Telegram: ارسال هشدار در صورت نیاز
در این ساختار، پیام تلگرام فقط زمانی ارسال می‌شود که شرایط هشدار برقرار باشد. بنابراین، لازم نیست هر بار که Workflow اجرا می‌شود، یک پیام جدید دریافت کنید.
مرحله دوم: تنظیم Schedule Trigger
یک Node از نوع Schedule Trigger به Workflow اضافه کنید.
این Node تعیین می‌کند Workflow با چه فاصله‌ای اجرا شود. برای مثال، می‌توانید آن را طوری تنظیم کنید که هر پنج دقیقه یک‌بار وضعیت سرور را بررسی کند.
برای شروع، فاصله ۵ یا ۱۰ دقیقه می‌تواند برای یک سناریوی آزمایشی مناسب باشد؛ اما فاصله مناسب به اهمیت سرویس، بار سرور و تعداد Workflowهای شما بستگی دارد.
نکات مهم:
- زمان‌بندی Workflow را متناسب با نیاز واقعی تنظیم کنید.
- پس از تکمیل تنظیمات، Workflow را ذخیره و فعال کنید.
- اگر چندین سرور دارید، تعداد اجراها و میزان بار ناشی از بررسی‌های مکرر را در نظر بگیرید.
- اگر زمان‌بندی بر اساس ساعت مشخصی است، منطقه زمانی تنظیم‌شده در n8n را بررسی کنید.
در محیط عملیاتی، بهتر است ابتدا Workflow را با اجرای دستی آزمایش کنید و پس از اطمینان از صحت نتیجه، زمان‌بندی را فعال کنید.
مرحله سوم: تنظیم اتصال SSH به سرور
برای خواندن اطلاعات منابع سرور، باید بتوانیم فرمان‌های لینوکس را اجرا کنیم.
یک Node از نوع SSH اضافه کنید و آن را بعد از Schedule Trigger قرار دهید.
در تنظیمات اتصال SSH، اطلاعات سرور مقصد را وارد کنید. این اطلاعات معمولاً شامل موارد زیر است:
- آدرس IP یا نام میزبان سرور
- پورت SSH، معمولاً 22 مگر اینکه تغییر کرده باشد
- نام کاربری
- روش احراز هویت، مانند کلید خصوصی SSH یا روش مورد پشتیبانی Node
در بخش عملیات، گزینه اجرای فرمان یا Execute Command را انتخاب کنید؛ نام دقیق گزینه ممکن است با نسخه n8n متفاوت باشد.
نکات امنیتی اتصال SSH
برای مانیتورینگ منابع، بهتر است از یک کاربر اختصاصی با حداقل دسترسی لازم استفاده کنید. در صورت امکان، ورود با کلید SSH را به‌کار ببرید و از استفاده غیرضروری از حساب root خودداری کنید.
همچنین:
- کلید خصوصی را در Credentials نگه دارید.
- دسترسی SSH را به مبدأهای مورد اعتماد محدود کنید.
- اعتبارسنجی کلید میزبان SSH را غیرفعال نکنید مگر اینکه خطرات آن را آگاهانه پذیرفته باشید.
- فرمان‌هایی که از ورودی کاربران ساخته می‌شوند را مستقیماً اجرا نکنید.
- در صورت اجرای n8n داخل Docker، مطمئن شوید مسیر شبکه و دسترسی لازم برای اتصال SSH برقرار است.
مرحله چهارم: دریافت اطلاعات RAM و فضای دیسک
اکنون باید فرمانی اجرا کنیم که وضعیت منابع را از سرور بخواند.
در فیلد فرمان SSH، کد زیر را قرار دهید:
disk=$(df -P / | awk 'NR==2 {gsub("%","",$5); print $5}')
memory=$(free | awk '/Mem:/ {printf "%.0f", $3/$2*100}')
printf '{"disk_percent":%s,"memory_percent":%s}\n' "$disk" "$memory"
این فرمان دو مقدار تولید می‌کند:
disk_percent: درصد استفاده از فضای دیسک مربوط به مسیر/memory_percent: درصد تقریبی حافظه مصرف‌شده بر اساس خروجی فرمانfree
خروجی نمونه می‌تواند چنین باشد:
{
"disk_percent": 72,
"memory_percent": 64
}
مقادیر بالا فرضی هستند و باید با اطلاعات واقعی سرور جایگزین شوند.
این فرمان چگونه کار می‌کند؟
فرمان df -P / وضعیت فضای دیسکی را که مسیر اصلی سیستم روی آن قرار دارد نمایش می‌دهد. بخش awk درصد استفاده را استخراج می‌کند و علامت درصد را حذف می‌کند.
فرمان free اطلاعات حافظه را نمایش می‌دهد. در این مثال، نسبت حافظه استفاده‌شده به کل حافظه محاسبه می‌شود. این عدد یک شاخص ساده برای هشدار است؛ اما برای تحلیل دقیق‌تر مصرف حافظه لینوکس، به‌ویژه با توجه به حافظه قابل‌بازیابی و Cache، باید معیارهای مناسب‌تری را نیز در نظر گرفت.
نکته: اگر مسیر / روی فضای ذخیره‌سازی جداگانه‌ای قرار ندارد یا می‌خواهید پارتیشن دیگری را پایش کنید، مسیر موردنظر را در فرمان df تغییر دهید. اگر خروجی فرمان خالی یا نامعتبر بود، پیش از ادامه بررسی کنید که ابزارهای df, awk و free روی سرور موجود باشند.
مرحله پنجم: بررسی خروجی SSH در n8n
پس از اجرای Workflow، خروجی SSH Node را باز کنید.
بسته به نسخه Node و تنظیمات آن، خروجی فرمان ممکن است در فیلدی مانند stdout قرار بگیرد. پیش از نوشتن Expressionها، ساختار واقعی خروجی را بررسی کنید.
برای مثال، اگر خروجی به شکل زیر باشد:
{
"stdout": "{\"disk_percent\":72,\"memory_percent\":64}"
}
باید متن داخل stdout را به JSON تبدیل کنیم تا بتوانیم مقادیر عددی را در IF بررسی کنیم.
یک Node از نوع Code بعد از SSH اضافه کنید و کد زیر را در حالت اجرای مناسب برای یک آیتم قرار دهید:
const output = $json.stdout;
const metrics = JSON.parse(output);
return [
{
json: {
disk_percent: Number(metrics.disk_percent),
memory_percent: Number(metrics.memory_percent),
},
},
];
این کد فرض می‌کند که خروجی فرمان در stdout قرار دارد و حاوی JSON معتبر است. اگر خروجی SSH در نسخه شما ساختار متفاوتی دارد، مسیر را مطابق داده واقعی تغییر دهید.
همچنین اگر فرمان اجرا نشده باشد یا خروجی معتبر تولید نکند، JSON.parse() خطا خواهد داد. در Workflow عملیاتی بهتر است خطاهای اجرای SSH و خروجی نامعتبر را نیز مدیریت کنید.
پس از اجرای Code Node، باید مقادیر عددی زیر را در خروجی مشاهده کنید:
{
"disk_percent": 72,
"memory_percent": 64
}
اکنون می‌توانیم از این مقادیر در شرط‌های Workflow استفاده کنیم.
مرحله ششم: تعیین آستانه هشدار
در این مرحله مشخص می‌کنیم چه زمانی لازم است هشدار ارسال شود.
برای مثال، می‌توانیم دو آستانه اولیه تعریف کنیم:
| شاخص | آستانه نمونه |
|---|---|
| استفاده از دیسک | 85 درصد |
| استفاده از حافظه | 90 درصد |
این اعداد صرفاً مقادیر نمونه هستند. آستانه مناسب به نوع سرور، ظرفیت منابع، الگوی مصرف و حساسیت سرویس بستگی دارد.
یک Node از نوع IF بعد از Code Node قرار دهید و شرطی تعریف کنید که اگر یکی از این وضعیت‌ها برقرار بود، مسیر هشدار اجرا شود.
Expression زیر نمونه‌ای برای بررسی هم‌زمان دو شرط است:
{{ $json.disk_percent >= 85 || $json.memory_percent >= 90 }}
اگر Expression مقدار true داشته باشد، Workflow به مسیر هشدار می‌رود. اگر مقدار false باشد، پیام هشدار ارسال نمی‌شود.
در این مثال، از عملگر || استفاده شده است؛ بنابراین عبور هرکدام از شاخص‌ها از آستانه برای فعال‌شدن هشدار کافی است.
اگر می‌خواهید پیام جداگانه‌ای برای دیسک و حافظه ارسال کنید، می‌توانید دو شرط یا یک Switch با مسیرهای مشخص ایجاد کنید.
مرحله هفتم: ارسال هشدار به تلگرام
اکنون یک Node از نوع Telegram به مسیر خروجی صحیح IF اضافه کنید.
عملیات ارسال پیام را انتخاب کنید، Credentials ربات را مشخص کنید و Chat ID مقصد را وارد کنید.
در فیلد متن پیام می‌توانید از Expression زیر استفاده کنید:
هشدار مانیتورینگ سرور
مصرف دیسک: {{ $json.disk_percent }}%
مصرف حافظه: {{ $json.memory_percent }}%
لطفاً وضعیت سرور را بررسی کنید.
وقتی شرط هشدار برقرار باشد، پیام با مقادیر واقعی دریافت‌شده از سرور به تلگرام ارسال می‌شود.
برای نمونه، اگر استفاده از دیسک به ۸۸ درصد برسد و حافظه ۷۶ درصد مصرف داشته باشد، پیام شامل این اطلاعات خواهد بود:
هشدار مانیتورینگ سرور
مصرف دیسک: 88%
مصرف حافظه: 76%
لطفاً وضعیت سرور را بررسی کنید.
این روش کمک می‌کند بدون ورود مداوم به سرور، از نزدیک‌شدن منابع به آستانه خطر مطلع شوید.
مرحله هشتم: اضافه‌کردن نام سرور به گزارش
اگر چند سرور دارید، لازم است بدانید هر هشدار مربوط به کدام سرور است.
برای این کار می‌توانید یک فیلد مانند server_name به داده‌ها اضافه کنید. برای مثال:
{
"server_name": "server-01",
"disk_percent": 88,
"memory_percent": 76
}
سپس نام سرور را در متن پیام قرار دهید:
هشدار مانیتورینگ
سرور: {{ $json.server_name }}
مصرف دیسک: {{ $json.disk_percent }}%
مصرف حافظه: {{ $json.memory_percent }}%
در این مثال، server_name یک مقدار نمونه است. اگر اطلاعات چند سرور را پردازش می‌کنید، مطمئن شوید نام هر سرور همراه با داده‌های همان سرور به مراحل بعدی منتقل می‌شود.
همچنین می‌توانید در گزارش، زمان بررسی، نام سرویس یا نوع هشدار را اضافه کنید؛ البته بهتر است اطلاعات محرمانه سرور در پیام درج نشود.
مرحله نهم: جلوگیری از ارسال هشدارهای تکراری
اگر Workflow هر پنج دقیقه اجرا شود و مصرف دیسک برای چند ساعت بالاتر از آستانه باقی بماند، ممکن است در هر اجرا یک پیام جدید ارسال شود.
برای جلوگیری از شلوغ‌شدن تلگرام، می‌توانید منطق هشدار را کمی پیشرفته‌تر کنید.
روش اول: ارسال هشدار فقط هنگام عبور از آستانه
به‌جای اینکه در هر اجرا پیام بفرستید، وضعیت قبلی و فعلی را مقایسه کنید.
برای مثال:
- اجرای قبلی: مصرف دیسک 82 درصد
- اجرای فعلی: مصرف دیسک 87 درصد
- آستانه هشدار: 85 درصد
در این شرایط، هشدار زمانی ارسال می‌شود که وضعیت از محدوده عادی به محدوده هشدار وارد شده باشد.
برای پیاده‌سازی این روش باید وضعیت قبلی را در یک محل پایدار، مانند پایگاه داده، ذخیره کنید و در اجرای بعدی آن را مقایسه کنید.
روش دوم: ارسال هشدار و سپس یادآوری دوره‌ای
می‌توانید اولین هشدار را فوراً ارسال کنید و در صورت ادامه مشکل، فقط در بازه‌های زمانی مشخص یادآوری بفرستید.
برای مثال، پس از اولین هشدار، تا ۳۰ دقیقه پیام جدیدی ارسال نشود؛ مگر اینکه وضعیت به شکل قابل توجهی تغییر کند.
این روش به ذخیره زمان آخرین هشدار و وضعیت آن نیاز دارد.
روش سوم: ارسال پیام بازیابی
هنگامی که مصرف منابع دوباره به محدوده عادی بازمی‌گردد، می‌توانید یک پیام بازیابی ارسال کنید.
برای مثال:
وضعیت سرور به حالت عادی بازگشت.
مصرف دیسک: 72%
مصرف حافظه: 61%
این پیام کمک می‌کند متوجه شوید مشکل فقط شناسایی نشده، بلکه وضعیت پایش‌شده نیز به محدوده عادی برگشته است.
مرحله دهم: بررسی در دسترس‌بودن وب‌سایت یا API
علاوه بر منابع سیستم، می‌توانید بررسی کنید که آیا یک وب‌سایت یا API پاسخ می‌دهد یا خیر.
برای این کار یک Node از نوع HTTP Request اضافه کنید و آدرس سرویس موردنظر را به آن بدهید.
در تنظیمات، می‌توانید روش درخواست و رفتار مربوط به خطاهای HTTP را مطابق نیاز خود مشخص کنید.
سپس نتیجه درخواست را بررسی کنید. برای مثال، می‌توانید در صورت دریافت پاسخ ناموفق یا بروز خطای اتصال، یک هشدار به تلگرام ارسال کنید.
ساختار کلی Workflow می‌تواند چنین باشد:
Schedule Trigger
|
v
HTTP Request
|
v
بررسی پاسخ سرویس
|
v
ارسال هشدار در صورت مشکل
برای بررسی دقیق‌تر، تنها به دریافت پاسخ HTTP اکتفا نکنید. بعضی سرویس‌ها حتی هنگام بروز مشکل در منطق برنامه، پاسخ HTTP موفق برمی‌گردانند. اگر API شما پاسخ ساختاریافته دارد، فیلدهای مهم آن را نیز بررسی کنید.
همچنین اگر خطای HTTP باعث توقف اجرای Node شود، باید تنظیمات مدیریت خطای همان Node یا Error Workflow را متناسب با هدف خود تنظیم کنید. یک IF در مسیر عادی همیشه قادر به دریافت خطایی نیست که اجرای قبلی را متوقف کرده است.
مرحله یازدهم: مدیریت خطای اتصال SSH
یکی از نکات مهم در مانیتورینگ این است که اگر خود اتصال SSH شکست بخورد، Workflow نباید به‌اشتباه تصور کند منابع سرور در وضعیت عادی هستند.
برای مثال، اگر سرور خاموش باشد یا اتصال شبکه برقرار نشود، ممکن است اصلاً اطلاعاتی از منابع دریافت نکنید.
بنابراین باید میان این دو وضعیت تفاوت قائل شوید:
- وضعیت منابع دریافت شده است: می‌توانید درصد مصرف دیسک و حافظه را بررسی کنید.
- اطلاعات دریافت نشده است: مشکل اتصال، احراز هویت یا اجرای فرمان باید جداگانه بررسی شود.
برای رسیدگی به خطاهای اجرایی، می‌توانید از قابلیت مدیریت خطا در n8n و Error Workflow استفاده کنید. اگر خطا باید در تلگرام گزارش شود، مسیر مدیریت خطا را طوری تنظیم کنید که علت کلی مشکل را اطلاع دهد.
به‌عنوان مثال، پیام می‌تواند چنین باشد:
هشدار مانیتورینگ
دریافت اطلاعات از سرور ناموفق بود.
وضعیت منابع در این اجرا مشخص نشده است.
لطفاً اتصال SSH و وضعیت سرور را بررسی کنید.
این پیام از ارسال اطلاعات ساختگی جلوگیری می‌کند. اگر دریافت داده شکست خورده باشد، نباید مقادیر خالی یا قدیمی را به‌عنوان وضعیت فعلی سرور نمایش دهید.
مرحله دوازدهم: نکات مهم برای مانیتورینگ سرورهای واقعی
Workflow این آموزش برای شروع و پیاده‌سازی یک سیستم ساده مناسب است؛ اما برای استفاده عملیاتی باید چند موضوع را در نظر بگیرید:
۱. محدودیت منابع
اجرای مکرر فرمان‌ها روی تعداد زیادی سرور می‌تواند بار اضافی ایجاد کند. فاصله بررسی را متناسب با نیاز انتخاب کنید.
۲. امنیت دسترسی
حساب SSH باید حداقل دسترسی لازم را داشته باشد. کلید خصوصی را در متن Workflow یا پیام تلگرام قرار ندهید.
۳. ذخیره وضعیت هشدارها
اگر نمی‌خواهید پیام تکراری ارسال شود، وضعیت قبلی هر سرور را در یک محل پایدار ذخیره کنید.
۴. بررسی مستقل کانال هشدار
اگر n8n روی همان سروری اجرا می‌شود که قرار است پایش شود، از کار افتادن کامل آن ممکن است مانع ارسال هشدار شود. برای پایش حیاتی، استفاده از یک سامانه مانیتورینگ مستقل یا اجرای بخش هشدار روی زیرساختی جداگانه را در نظر بگیرید.
۵. بررسی شاخص‌های مناسب
درصد مصرف RAM به‌تنهایی همیشه نشانه کمبود حافظه نیست. برای تشخیص دقیق‌تر مشکلات حافظه، شاخص‌هایی مانند حافظه در دسترس، Swap و وضعیت فرایندهای مهم نیز ممکن است لازم باشند.
۶. تعیین آستانه‌های متناسب با سرور
آستانه 85 درصد برای دیسک یا 90 درصد برای حافظه یک قانون عمومی نیست. آستانه‌ها باید بر اساس ظرفیت منابع، رفتار عادی سرور و اهمیت سرویس تعیین شوند.
جمع‌بندی
در این مقاله یاد گرفتیم چگونه با n8n و ربات تلگرام یک سیستم ساده مانیتورینگ سرور ایجاد کنیم.
با استفاده از Schedule Trigger، Workflow در بازه‌های مشخص اجرا می‌شود. سپس از طریق SSH اطلاعات مصرف دیسک و حافظه را دریافت می‌کنیم، مقادیر را پردازش می‌کنیم و با IF بررسی می‌کنیم که آیا شرایط هشدار برقرار است یا خیر. در صورت نیاز، Telegram Node پیام هشدار را ارسال می‌کند.
همچنین دیدیم که می‌توان بررسی در دسترس‌بودن وب‌سایت و API را به این سیستم اضافه کرد و با ذخیره وضعیت قبلی، تعداد هشدارهای تکراری را کاهش داد.
این روش نقطه شروع مناسبی برای ساخت اتوماسیون‌های مدیریتی است؛ اما برای سرورهای حیاتی بهتر است مانیتورینگ مستقل، ثبت تاریخچه، سیاست هشدار و مدیریت خطا نیز در نظر گرفته شود.
سوالات متداول
آیا برای مانیتورینگ سرور با n8n باید روی سرور مقصد n8n نصب شود؟
خیر. می‌توانید n8n را روی یک سرور جداگانه اجرا کنید و از طریق SSH به سرور مقصد متصل شوید. این روش امکان پایش چند سرور را از یک Workflow فراهم می‌کند.
آیا می‌توان مصرف RAM سرور را به تلگرام ارسال کرد؟
بله. با اجرای فرمان‌های لینوکس از طریق SSH می‌توانید اطلاعات حافظه را دریافت کنید، آن‌ها را در n8n پردازش کنید و با Telegram Node گزارش یا هشدار ارسال کنید.
آیا می‌توان مانیتورینگ را هر پنج دقیقه اجرا کرد؟
بله. با Schedule Trigger می‌توانید فاصله اجرای Workflow را تعیین کنید. فاصله مناسب به اهمیت سرویس، تعداد سرورها و میزان بار ایجادشده بستگی دارد.
چگونه از ارسال هشدارهای تکراری جلوگیری کنیم؟
می‌توانید وضعیت قبلی را ذخیره کنید و تنها هنگام عبور از آستانه یا تغییر وضعیت هشدار پیام ارسال کنید. برای این کار، ذخیره وضعیت در یک پایگاه داده یا محل پایدار گزینه مناسبی است.
اگر سرور کاملاً از دسترس خارج شود، آیا n8n می‌تواند هشدار بدهد؟
اگر n8n روی سرور جداگانه اجرا شود و بتواند از قطع اتصال مطلع شود، می‌تواند خطای اتصال را گزارش کند. اگر خود n8n روی همان سرور از دسترس خارج شود، ممکن است نتواند پیام هشدار ارسال کند؛ به همین دلیل برای سرویس‌های حیاتی، مانیتورینگ مستقل اهمیت دارد.
آیا این روش جایگزین ابزارهای تخصصی مانیتورینگ است؟
برای بررسی‌های ساده و ساخت هشدارهای سفارشی، n8n گزینه مناسبی است. اما برای زیرساخت‌های بزرگ، ثبت تاریخچه دقیق معیارها، نمودارهای بلندمدت، تشخیص ناهنجاری و پایش گسترده، ممکن است به ابزار تخصصی مانیتورینگ نیز نیاز داشته باشید.
