دستورات از راهدور در زیبکس

مقدمه
در این مقاله به شرح نحوه استفاده از قابلیت دستورات از راهدور در زیبکس و اینکه چه مواردی را باید در نظر داشته باشید، پرداخته شده است. سناریوی حقیقی نظارت فعالانه خدمات ویندوز، برای شروع خودکار خدماتی که به هر دلیلی متوقف شدهاند و سپس استفاده از پشتیبانی برای اطلاع رسانی به کاربران، در صورتی که فرمان از راهدور کمکی نکند.
توجه داشته باشید: در نسخه مورد استفاده در اینجا، دقیقاً مانند فایلهای نوشتار Docker، نسخه 4.2.1 استفاده میشود. اما نگران نباشید، این یک ویژگی جدید نیست و حتی در نسخهی 3.0 نیز موجود است. بنابراین شما حتی اگر آخرین نسخه زبیکس را نداشته باشید، هنوز هم قادر به استفاده از آن هستید.
آنچه در اینجا داریم به شرح زیر میباشد:
- یک هاست پیش فرض از سرور زبیکس که البته در این مقاله چندان مهم نیست.
- یک agent بر روی هاست ویندوز نصب کردهایم
- علاوه بر این، یک هاست به نام localhost نیز وجود دارد، که یکagent زبیکس در حامل Docker است، دقیقاً مانند سرور front و موارد دیگر.

دستورات از راهدور در زیبکس: ایده پشت آن و آنچه میتوانیم با آن به دست بیاوریم
پارامترهای کاربر
همانطور که میدانید، مواردی بر روی agent ها وجود دارد که مسئول جمعآوری نوعی از معیارها هستند. اما معمولاً آنها کلیدهای ثابتی هستند که وظیفه دریافت بار CPU سیستم، فضای دیسک رایگان، وضعیت برخی خدمات یا مواردی از این دست را بر عهده دارند.
در مقالات قبلی در مورد گسترش قابلیت عملکرد agent زبیکس و استفاده از پارامترهای کاربر صحبت کردهایم.
برای این کار باید به فایل پیکربندی بروید، پارامتر جدید کاربر را اضافه کنید، سرویس agent زیبکس یا باینری را مجدداً راهاندازی کنید، سپس کلید جدید ایجاد میشود. بسته به آنچه در فایل پیکربندی مشخص کردهایم میتواند هر کاری را که میخواهیم انجام دهد.
سپس پارامتر موجود در agent config file در این مقاله، این موضوع را در localhost خود zabbix_agentd.conf نشان میدهیم.

دو پارامتر وجود دارد:
- اول از همه EnableRemoteCommands برابر با ‘0’
# Mandatory: no
# Default:
# EnableRemoteCommands=0
EnableRemoteCommands=
این مقدار پیش فرض است و به طور پیش فرض هنگام نصب agent زبیکس دستورات از راهدور مجاز نیستند. بنابراین حتی اگر شما سعی کنید از front end استفاده کنید، کار نخواهد کرد، پیام خطا دقیقاً با این مضمون یکسان خواهد بود. ‘Remote commands are not allowed on that host‘
- پارامتر بعدی LogRemoteCommands است که به صورت پیش فرض ‘0‘–turned off میباشد.
# Mandatory: no
# Default:
# LogRemoteCommands=0
LogRemoteCommands
اگر آن را فعال کنید، تمام دستورات از راهدور در زیبکس اجرا شده از این agent نیز به فایل log agent نوشته خواهد شد. بنابراین بعداً به نوعی یک audit log خواهید داشت و میتوانید بفهمید که چه دستوری چه اقدامی را اجرا کرده است.
system.run
اول از همه، یک مورد در agent زبیکس وجود دارد که system.run نامیده میشود. من میتوانم آن را از CLI استفاده کنم، این دستور #zabbix_get -s local host -k system.run[]. میباشد. در پارامترها، در براکتها [] امکان نوشتن هر دستور مورد نظر وجود دارد.
[root@localhost-]#zabbix_get -s 127.0.0.1 -k system
شما باید همچین تصویری بر روی صفحه مشاهده کنید:

پاسخ این دستور ‘123’ میباشد، بنابراین اساساً ما از دستور از راهدور runtime استفاده میکنیم. اگرconfig file agent خود را ویرایش کنید
[root@localhost~]# vim
EnableRemoteCommands را از حالت کامنت خارج کنید
# Mandatory: no
# Default:
# EnableRemoteCommands=0
# EnableRemoteCommands=1
wq
و سعی کنید بار دیگر این دستور را اجرا کنید.
[root@localhost~]# systemctl restart zabbix-agent
[root@localhost~]# zabbix_get -s 127
شما یک پیام خطا دریافت خواهید کرد.

بنابراین برای استفاده از کلید system.run بر روی agent ها باید فایل پیکربندی agent را باز کرده و دستورهای از راهدور را فعال کنید.
LogRemoteCommands درخواست شما است: اگر میخواهید آنها را در فایل log وارد کنید، در غیر این صورت انجام این کار اجباری نیست.

چرا میخواهیم به جای پارامترهای کاربر از system.run استفاده کنیم؟
زیرا برای اضافه کردن یک پارامتر کاربر، باید آن هاست را باز کنیم، اصلاحات را انجام دهیم و agent زبیکس را مجدداً راهاندازی کنیم. برای استفاده از system.run کافی است یک مورد را در front end اضافه کنید، بنابراین این یک ابزار CLI نیست.
مانند هر مورد دیگر: به Host Items بروید، بر روی Create a new one کلیک کنید، نوع آن agent زبیکس و یک کلید: system.run خواهد بود و در براکتها باید دستور را وارد کنید.
استفاده از دستورات از راهدور در زیبکس برای حل مشکلات
این در اصل فقط کوچکترین قسمت در مورد دستورات از راهدور در زیبکس است. نکته دوم در ارتباط با دستورات از راهدور موارد زیر میباشد: در اینجا در موارد agent زبیکس، ما دوباره از دستور از راهدور برای گرفتن metric استفاده میکنیم.
اما میتوانید از دستورات از راهدور در زیبکس استفاده کنید تا برخی از مشکلات را بعد از وقوع برطرف نمایید. بنابراین از این دستورات به همراه اقداماتی استفاده میکنیم و به جای ارسال تنها یک ایمیل، در واقع دستورات از راهدور خود را برای رفع مشکل اجرا میکنیم.
به منظور نمایش، مثالی در هاست ویندوز خود پیکربندی کردهایم. ما یک هاست ویندوز داریم و کامپیوتر شخصی خود را نظارت میکنیم. یک الگوی پیش فرض سیستم عامل ویندوز اضافه کردیم که دارای یک کشف سرویس ویندوز نیز میباشد.
کشف هاست ویندوز Windows Host Discovery


بنابراین ما در حال کشف تمام خدمات در دستگاه ویندوز خود هستیم که دارای نوعی تأخیر خودکار یا اتوماتیک با تأخیر است. این موارد را برای مانیتور کردن بر وضعیت سرویس ایجاد میکند، مانند این موارد: Windows service discovery, state of service، وضعیت سرویس، سپس Service name و Service Discription در براکتها

این موارد همچنین دارای trigger نیز هستند. صفحه را به سمت بالا بکشید تا Triggers را ببینید.
Discovery > Triggers
و triggerها هنگامی که حالت سیستم هر چیزی به غیر از شروع شده باشد، مانند: متوقف شده است، شروع نشده است و یا درگیر نوعی خطا است، فعال خواهد شد.
اگر سه چک آخر به صورت عدم اجرای سرویس ظاهر شود، به طور پیش فرض در front end مشکلی ایجاد خواهد کرد.

ما میتوانیم عملی را ایجاد کنیم که سعی میکند با هر بار متوقف شدن سرویس ویندوز، آن را شروع کند. دلیل این اقدام این است که این triggerها میتوانند نویز زیادی ایجاد کنند و همیشه لازم نیست شخصی را از یک تیم پشتیبانی درگیر کنید تا آن را چک کند، وارد دستگاهی شود و شاید یک سرویس را شروع کند.
در عوض وقتی سرویس در حال اجرا نیست میتوانیم زبیکس را آموزش دهیم تا بطور خودکار سعی کند آن را راهاندازی کند. اگر بعد از به طور مثال 10 دقیقه سرویس هنوز اجرا نشده است، میتوانیم تعدادی ایمیل برای تیم پشتیبانی خود ارسال کنیم.
چطور این کار را انجام دهیم؟ در اقدامات پیکربندی باید عملی را ایجاد کنیم که مسئول خدمات ویندوز ما باشد. اما باید اطمینان حاصل کنیم که این عمل فقط روی سرویسهای ویندوز کار خواهد کرد زیرا بدیهی است که اگر مشکل با نوع فضای رایگان دیسک باشد، تلاش برای شروع یا راهاندازی مجدد برخی از سرویسها بر روی آن مشکل، راه حل بدی خواهد بود.
Configuration > Actions > Windows restart service > Operations

همچنین شما نیاز به نوشتن یک دستور دارید. از آنجا که مثال در محیط ویندوز است، دستور بسیار ساده است. مانند تصویر بالا بر روی Edit کلیک کنید و بعد از رفرش صفحه، به پایین بروید تا Commands را در سمت چپ ببینید. در Commands بنویسید : net start و سپس {اسم خدمات در ویندوز}.
{net start {TRIGGER.DESCRIPTION
شما باید همچین تصویری بر روی صفحه مشاهده کنید:

دستور از راهدور Remote command
البته که نام سرویس پویا است، بنابراین ما نمیدانیم که نام این سرویس چه خواهد بود، زیرا بستگی به این دارد که با چه triggerی به حالت مشکل بر میخوریم.
اما میتوانیم همه این مشکلات را در الگوی کشف سرویس ویندوز حل کنیم. به Configuration → Hosts → Windows Host Discovery → Windows Service discovery. بروید.
در هاست ویندوز خود بر روی کشف سیستم ویندوز میتوانید کمی تغییرات ایجاد کنید. اول از همه نمونههای اولیه trigger. بر روی Windows Service discovery Triggers prototypes کلیک کنید.

در Trigger prototype یک قسمت توضیحات با ماکرو کشف سطح پایین service.name که اسم سرویس کشف شده را بازگردانی میکند، اضافه کنید.
Trigger prototypes > Template OS Windows: Service “{#SERVICE.DISPLAYNAME}) is not running (startup type {#SERVICE.STARTUPNAME})
به پایین صفحه بروید و {SERVICE.NAME} را در قسمت Description تایپ کنید.

سپس در Actions در remote command ‘net start’ خود، از ماکرو اینترنت trigger.description که با یک اسم سرویس واقعی ظاهر میشود، استفاده کنید.
{net start {TRIGGER.DESCRIPTION
سپس برای اطمینان از اینکه این مشکل تنها مربوط به سرویس ویندوز میباشد (و تنها برای سرویس ویندوز باید این دستور از راهدور را اجرا کرد) tag اضافه خواهید کرد. صفحه را به سمت بالا بکشید تا Tags را ببینید و بر روی آن کلیک کنید.

به نمونه trigger با اسم ‘type‘ و ارزش ‘WinService‘ تگ اضافه کنید.

اکنون تمامی اطلاعات مورد نیاز در قوانین کشف سطح پایین پیکربندی شده را دارید و میتوانید مراحل Actions را انجام دهید. بیایید به ‘Actions‘بازگردیم.
Configuration > Actions > Windows restart service.
در شرایطی که دارید: Tag type equals WinService

بنابراین براساس منطق ما، این شرط Condition A فقط بر روی triggerهایی که دارای ارزش برچسب WinService هستند تاثیر میگذارد، این به معنی خدمات ویندوز است. فقط برای اضافه کردن میتوانید شرط اضافی را اضافه کنید.
تصویر شرایط
این شرایط گروه هاست را بررسی میکند و تنها در صورت برابر بودن با ویندوز با آن کار خواهد کرد زیرا بدیهی است که چنین دستوراتی روی دستگاههای لینوکس کار نمیکند.
حال بیایید به بخش عملیات برویم. Configuration > Actions > Windows restart service > Operations > Edit >. به پایین صفحه بیایید تا Commands را ببینید. در Commands عبارت زیر را خواهید دید.
net start {TRIGGER.DESCRIPTION}
در هر کدام از triggerهای ایجاد شده به طور خودکار از نمونههای trigger، توضیح trigger در واقع نام سرویس واقعی را خواهد داشت.
آزمایش کردن دستورات از راهدور در زیبکس
حالا میتوانید این مورد را آزمایش کنید. بیایید به داشبورد برویم.
مطمئناً در برخی از سرویسهایی که در حال اجرا نیستند مشکلاتی وجود دارد. اما میتوانید منوی نمایش خدمات در ویندوز خود را Background Intelligent Transfer service، که BITS است، باز کنید و باید آن را متوقف کنید.

حالا بیایید به Monitoring > latest data برویم.
بیایید به ‘Windows host‘برویم و سرویس BITS را جستجو کنیم. Apply را کلیک کنید.

خواهید دید که آخرین چک “متوقف شده” است (چند ثانیه قبل آن را متوقف کردید). احتمالاً باید بار دیگر منتظر بمانید تا trigger فعال شود و ببینید که آیا این عمل اجرا و آیا این سرویس واقعاً آغاز شده است یا خیر.
در مدتی که منتظر هستید، بیایید در مورد کلید system.run صحبت کنیم. به Configurations > Hosts > Local host Items > بروید، به پایین صفحه بروید و آیتمی با نام ‘System run-agent version‘ را جستجو کنید (در صورت لزوم صفحه را تغییر دهید).

پس از کلیک بر روی آن، خواهید دید که نام ‘system.run agent‘ نسخه agent است، نوع ‘Zabbix agent‘ است و کلید ‘ system.run ‘است، بنابراین این بدان معنی است که ما یک دستور از راهدور را اجرا میکنیم. بیایید دستور را کپی کنیم.
[root@localhost ~]# /usr/sbin/zabbix_agentd -V

این دستور را کپی میکنیم تا نسخهای از agent زبیکس خود دریافت کنیم. پاسخ این دستور همان پاسخ CLI خواهد بود.

حالا برگردیم به داشبورد زبیکس. در این مثال میتوانید یک مشکل جدید به صورت چشمک زن
(Flashing Problem) جدید را ببینید که آخرین 15:04 است.

این مشکل جدید مربوط به سرویسهای دیگر متوقف شده است، نه BITS، بنابراین توسط ما اجباری نشده است، این اتفاق به خودی خود در ویندوز رخ داده است. میتوانیم ببینیم که مدت زمان آن 5 ثانیه است، اجرا نمیشود و ما یک عمل را اجرا میکنیم. این عمل ‘Remote Command-Executed‘ بوده است.

شواهدی وجود دارد که نشان میدهد زبیکس با موفقیت این سرویس بیومتریک ویندوز را آغاز کرده است. همچنین یک Tag – Type: WinService را مشاهده خواهیم کرد.
یک بار که صفحه را رفرش کنید، یک مشکل جدید برای BITS مشاهده خواهید کرد.

این مشکل میگوید که سرویس “BITS” (سرویس انتقال هوشمند پس زمینه) در حال اجرا نیست (نوع راهاندازی خودکار یا با تاخیر)، مدت زمان این مشکل 2 ثانیه است، نوع و مقدار برچسب WinService است.
یک بار که صفحه را refresh کنید، خواهید دید که این عمل در واقع انجام شده است.

این مشکل از یک عمل اجرا شده خبر خواهد داد، این عمل یک فرمان از راهدور، وضعیت ‘executed‘ با رنگ سبز خواهد بود. پس از این میتوانید در Services > Background Intelligent Transfer Service تأیید کنید، خواهید دید که وضعیت سرویس ‘Running‘است.

بنابراین زبیکس میتواند بطور خودکار سرویسی را که اجرا نشده است شروع کند و ما میتوانیم زمانی را برای تیم پشتیبانی خود ذخیره کنیم.
اگر هنوز میخواهید در مورد یک مشکل که نمیتوانید به طور خودکار آن را برطرف کنید، به کسی اطلاع دهید، میتوانید یک مرحله دیگر اضافه کنید.
Configurations > Actions > Windows Restart service > Operations
بنابراین اولین مرحله (که بلافاصله اجرا میشود) یک دستور از راهدور برای شروع یک سرویس است.

سپس اگر میخواهید یک مرحله دیگر ایجاد کنید، روی New کلیک کنید و به این ترتیب یک مرحله دیگر میتواند بعد از 10 دقیقه به برخی از گروههای کاربران پیام ارسال کند.

بنابراین این دستور به این معنی است: فوراً سعی کنید سرویس را شروع کنید، البته به مانیتور کردن ادامه دهید، اگر مشکل بعد از 10 دقیقه هنوز فعال است؛ سپس به تیم پشتیبانی ما اطلاع دهید.
توجه داشته باشید: از نظر این دستورات از راهدور باید یک اتصال passive به هاست برقرار شود. اگر اتصال فقط active باشد؛ بنابراین اتصالات ورودی به agent بر اساس مشخصات فایروال مجاز نیستند. سرور زبیکس قادر به اجرای دستور از راهدور بر روی agent نخواهد بود.
در مقالات پیشین، در مورد حالتهای فعال (active) و غیر فعال (passive) agent صحبت کردهایم. شما میتوانید حالت مورد نظر را انتخاب کنید: که میتواند یکی، دیگری و یا هر دو مورد باشد. اما اگر مشخصات محیط شما (به عنوان مثال محیط سرور ابری) اجازه اتصال به ورودی را نمیدهد، پس نمیتوانید از این قابلیتها استفاده کنید.
نتیجهگیری
سرویسهای ویندوز عنوان شده در اینجا تنها به عنوان مثال ذکر شدهاند. شما میتوانید در همه مسائل دیگر و triggerها و موارد نظارتی بر روی سرورها و در زیر ساختهای خود از این امر استفاده کنید.
امیدواریم این مقاله مطالب جدیدی به شما آموزش داده باشد. با استفاده از مطالب گفته شده، پیش بروید و حضور زبیکس را در محیط خود فعالتر کنید.