Zabbix - گسترش مرزهای کلان

هنگام ساخت یک راه حل برای یک مشتری، 2 کار ایجاد شد که می خواستم آنها را به زیبایی و با عملکرد معمولی Zabbix حل کنم.

وظیفه 1 ردیابی نسخه سیستم عامل فعلی در روترهای میکروتیک.

این کار به راحتی حل می شود - با افزودن یک عامل به الگوی HTTP. نماینده نسخه فعلی را از سایت میکروتیک دریافت می کند و ماشه نسخه فعلی را با نسخه فعلی مقایسه می کند و در صورت مغایرت هشدار می دهد.

وقتی 10 روتر دارید، چنین الگوریتمی حیاتی نیست، اما با 3000 روتر چه باید کرد؟ ارسال 3000 درخواست به سرور؟ البته، چنین طرحی کار خواهد کرد، اما ایده 3000 درخواست برای من مناسب نبود، می خواستم راه حل دیگری پیدا کنم. علاوه بر این، در چنین الگوریتمی هنوز یک اشکال وجود داشت: طرف مقابل می تواند چنین تعداد درخواست از یک IP را برای حمله DoS شمارش کند، آنها به سادگی می توانند آن را ممنوع کنند.

وظیفه 2 استفاده از یک جلسه مجوز در عوامل مختلف HTTP.

هنگامی که یک نماینده نیاز به دریافت اطلاعات از صفحات "بسته" از طریق HTTP دارد، یک کوکی مجوز لازم است. برای انجام این کار، معمولاً یک فرم مجوز استاندارد با جفت "ورود / رمز عبور" و تنظیم شناسه جلسه در کوکی وجود دارد.

اما مشکلی وجود دارد، دسترسی به داده های یک آیتم دیگر از یک آیتم عامل HTTP برای جایگزینی این مقدار در هدر غیرممکن است.

همچنین یک "اسکریپت وب" وجود دارد، محدودیت دیگری نیز دارد، به شما اجازه نمی دهد محتوا را برای تجزیه و تحلیل و ذخیره بیشتر دریافت کنید. شما فقط می توانید وجود متغیرهای لازم را در صفحات بررسی کنید یا متغیرهای دریافتی قبلی را بین مراحل وب اسکریپت ارسال کنید.

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

Zabbix مستندات API خوب و دقیقی دارد. برای تبادل داده از طریق api از فرمت داده Json استفاده می شود. جزئیات را می توان در یافت اسناد رسمی.

توالی اقدامات برای به دست آوردن داده های مورد نیاز و ثبت آنها در یک ماکرو در نمودار زیر نشان داده شده است.

مرحله 1

اولین مرحله می تواند شامل یک عمل واحد یا چند عمل باشد. تمام منطق اصلی در مراحل اول گذاشته شده است و 3 مرحله آخر مراحل اصلی هستند.

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

URL نسخه های فعلی سیستم عامل Mikrotik

• upgrade.mikrotik.com/routeros/LATEST.6 - آدرس URL نسخه پایدار فعلی
• upgrade.mikrotik.com/routeros/LATEST.6رفع - آدرس URL نسخه LTS فعلی

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

مرحله اول برای هر مورد کاملاً فردی است و ممکن است منطق کار آن متفاوت باشد. همه چیز به وظیفه شما بستگی دارد.

هنگام کار با وب اسکریپت، روش پاسخگویی را که نیاز دارید پیگیری کنید. عناوین پاسخ HTTP یا خود тело پاسخ بدون هدر؟
اگر به کوکی‌های مجوز نیاز است، روش پاسخ را تنظیم کنید عناوین همانطور که در مورد ستاره.

اگر به داده نیاز دارید، مانند پاسخ سرور mikrotik، قرار دهید بدن پاسخ بدون هدر

مرحله 2

بیایید به مرحله دوم برویم. دریافت یک جلسه مجوز:

POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc

{
    "jsonrpc": "2.0",
    "method": "user.login",
    "params": {
        "user": "Admin"
        "password": "zabbix"
    },
    "id": 1,
    "auth": null
}

jsonrpc نسخه پروتکل JSON-RPC است که در حال استفاده است.
Zabbix JSON-RPC نسخه 2.0 را پیاده سازی می کند.

• روش - روشی که نامیده می شود؛
• پارامترها - پارامترهایی که توسط روش ارسال می شوند.
• id یک شناسه درخواست دلخواه است.
• auth - کلید احراز هویت کاربر؛ از آنجایی که هنوز آن را نداریم، بیایید آن را روی null قرار دهیم.

برای کار با API، یک حساب کاربری جداگانه با حقوق محدود ایجاد کردم. اولاً، لازم نیست به جایی که نیازی ندارید دسترسی بدهید. و در مرحله دوم، قبل از نسخه 5.0، رمز عبور تنظیم شده از طریق ماکرو قابل خواندن بود. بر این اساس، اگر از رمز عبور مدیر Zabbix استفاده کنید، حساب کاربری مدیریت به راحتی قابل سرقت است.

این امر به ویژه هنگام کار با API از طریق اسکریپت های شخص ثالث و ذخیره اعتبار در کنار آن صادق خواهد بود.

از نسخه 5.0 گزینه ای برای پنهان کردن رمز عبور ذخیره شده در ماکرو وجود دارد.

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

پس از دریافت مجوز در API، به دریافت لیستی از ماکروها اقدام می کنیم.

مرحله 3

API به شما اجازه به روز رسانی ماکرو میزبان را با نام نمی دهد، ابتدا باید شناسه ماکرو را دریافت کنید. علاوه بر این، برای دریافت لیستی از ماکروها برای یک هاست خاص، باید شناسه این هاست را بدانید و این یک درخواست اضافی است. از ماکرو پیش فرض استفاده کنید {شناسه میزبان} در درخواست مجاز نیست. من تصمیم گرفتم محدودیت را به این صورت دور بزنم:

من یک ماکرو محلی با شناسه این میزبان ایجاد کردم. پیدا کردن شناسه میزبان از رابط وب بسیار آسان است.

یک پاسخ با لیستی از همه ماکروها در یک میزبان معین را می توان با یک الگو فیلتر کرد:

regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"

بنابراین، ما شناسه ماکرو مورد نیاز خود را در کجا دریافت می کنیم MIKROTIK_VERSION نام کلان مورد نظر ما است. در مورد من، ماکرو جستجو شده است MIKROTIK_VERSIONکه به میزبان اختصاص داده شد.

خود درخواست به این شکل است:

POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc

{
    "jsonrpc":"2.0",
    "method":"usermacro.get",
    "params":{
        "output":"extend",
        "hostids":"{$HOST_ID}"
    },
    "auth":"{sid}",
    "id":1
}

متغیر {سید} در مرحله دوم به دست آمده و به طور مداوم مورد استفاده قرار می گیرد، جایی که باید با رابط API کار کنید.

مرحله 4 نهایی - به روز رسانی ماکرو

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

POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc

{
    "jsonrpc":"2.0",
    "method":"usermacro.update",
    "params":{
        "hostmacroid":"{hostmacroid}",
        "value":"{mikrotik_version}"
    },
    "auth":"{sid}",
    "id":1
}

{mikrotik_version} مقدار به دست آمده در مرحله اول است. در مثال من، نسخه سیستم عامل میکروتیک فعلی است
{hostmacroid} - مقدار در مرحله سوم به دست آمد - شناسه ماکرو که در حال به روز رسانی هستیم.

یافته ها

رویکرد حل مشکل با عملکرد استاندارد بسیار پیچیده تر و طولانی تر است. به خصوص اگر برنامه نویسی بلد باشید و بتوانید به سرعت منطق لازم را در اسکریپت اضافه کنید.

مزیت آشکار این رویکرد «قابل حمل بودن» راه حل بین سرورهای مختلف است.

برای من شخصاً عجیب است که عامل HTTP نمی تواند به داده های مورد دیگری دسترسی داشته باشد و آنها را در بدنه درخواست یا هدرها جایگزین کند. ZBXNEXT-5993].

قالب تمام شده می تواند در GitHub دانلود کنید.

منبع: www.habr.com