Zabbix - розширюємо макро кордони

Роблячи рішення для клієнта, виникло 2 завдання, які хотілося вирішити красиво та штатним функціоналом Zabbix.

Завдання 1. Відстежує актуальну версію прошивки на роутерах Mikrotik.

Завдання вирішується легко - додаванням до шаблону HTTP агента. Агент отримує актуальну версію з сайту Mikrotik, а тригер порівнює актуальну версію з поточної та у разі розбіжності видає алерт.

Коли у вас 10 роутерів, такий алгоритм не є критичним, а що робити з 3000 роутерів? Надіслати 3000 запитів на сервер? Працюватиме, звичайно, така схема буде, але сама ідея 3000 запитів мене не влаштовувала, хотілося знайти інше рішення. До того ж, недолік у подібному алгоритмі все-таки був: інша сторона може порахувати таку кількість запитів з одного IP за атаку DoS, можуть просто забанити.

Завдання 2. Використання сесії авторизації у різних HTTP агентах.

Коли через HTTP агент потрібно отримувати інформацію із «закритих» сторінок, потрібна кука авторизації. Для цього зазвичай існує стандартна форма авторизації з парою «логін/пароль» та встановленням ID сесії в куку.

Але є проблема, не можна з одного АЙТЕМ HTTP агента звернутися до даних іншого АЙТЕМ для підстановки цього значення в Header.

Існує ще "Веб сценарій", у нього інше обмеження, він не дає отримати контент для аналізу та подальшого збереження. Можна лише перевірити наявність необхідних змінних на сторінках або передавати отримані змінні між кроками веб сценарію.

Трохи подумавши над цими завданнями, вирішив використовувати макроси, які добре видно у будь-якій частині системи моніторингу: у шаблонах, хостах, тригерах чи айтемах. А оновлювати макроси можна через API веб-інтерфейсу.

Zabbix має хорошу і докладну документацію по API. Для обміну даними API використовується формат даних Json. Детально можна прочитати в офіційної документації.

Послідовність процесів отримання необхідних нам даних і запис їх у макрос представлена ​​на схемі нижче.

Крок 1

Перший крок може складатися з однієї дії або безлічі дій. У перші кроки закладається вся основна логіка, а головними є останні 3 кроки.

У моєму прикладі, на першому кроці виконувалося отримання куки авторизації на АТС для першого завдання. Для другого завдання я отримував номер поточної версії Mikrotik.

URL актуальних версій прошивок Mikrotik

• upgrade.mikrotik.com/routeros/LATEST.6 — URL-адреса актуальної Stable версії
• upgrade.mikrotik.com/routeros/LATEST.6fix — URL-адреса актуальної LTS версії

До цих адрес звертається саме обладнання Mikrotik, при отриманні останньої доступної версії прошивки.

Перший крок повністю індивідуальний кожному за випадку і логіка його може бути різною. Все залежить від вашого завдання.

При роботі з веб-сценаріями відстежуйте який спосіб отримання відповіді вам потрібен. Заголовки HTTP відповіді чи саме тіло відповіді без заголовків?
Якщо потрібні куки авторизації, метод відповіді ставте Заголовки як у випадку з Asterisk.

Якщо потрібні дані, як у відповідь сервера 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;

• method - метод, який викликається;
• params - параметри, що передаються методом;
• id - довільний ідентифікатор запиту;
• auth - ключ аутентифікації користувача; та як у нас його ще немає, вкажемо його рівним null.

Для роботи з API я створив окремий обліковий запис з обмеженими правами. По-перше, не потрібно давати доступ туди, куди не потрібно. А по-друге до версії 5.0, заданий через макрос пароль, можна було прочитати. Відповідно, якщо використовувати пароль адміністратора Zabbix, облік адміну легко вкрасти.

Це особливо буде актуально, коли працюєте з API через сторонні скрипти та зберігаєте облікові дані на стороні.

З версії 5.0 з'явилася опція приховати пароль, збережений у макросі.

Якщо ви створюєте окремий обліковий запис для оновлення даних через API, обов'язково перевіряйте, чи доступні через веб-інтерфейс потрібні вам дані, і чи можливо їх оновлення. Я не перевірив, а потім довго не міг зрозуміти, чому API не видно потрібний мені макрос.

Після того, як отримали авторизацію в API, переходимо до отримання списку макросів.

Крок 3

API інтерфейс не дозволяє оновлювати макрос хоста на ім'я, для цього потрібно спочатку отримати ID макросу. Більше того, щоб отримати список макросів конкретного хоста, потрібно дізнатися про ID цього хоста, а це зайвий запит. Використовувати штатний макрос {HOST.ID} у запиті не можна. Обмеження вирішив обійти так:

Я створив локальний макрос із ID цього хоста. Дізнатися ID хоста дуже легко з веб-інтерфейсу.

Відповідь зі списком всіх макросів даного хоста можна відфільтрувати за шаблоном:

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

Таким чином, ми отримуємо ID потрібного нам макросу, де 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
}

Мінлива {sid} отримана на другому кроці і використовуватиметься постійно, де потрібно працювати з API інтерфейсом.

Фінальний 4 КРОК - оновлення макросу

Тепер ми знаємо ID макросу, який потрібно оновити, куку авторизації або версію прошивки роутера. Можна оновлювати сам макрос.

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} - Значення набули в третьому кроці - id макросу, який оновлюємо.

Висновки

Підхід до вирішення завдання штатним функціоналом у рази складніший і довший. Особливо якщо знаєш програмування та можеш швидко накидати потрібну логіку у скрипті.

Очевидним плюсом цього підходу є «переносимість» рішення між різними серверами.

Особисто для мене є дивним відсутність можливості звертатися в HTTP агенті до даних іншого айтема і підстановка їх у тіло запиту або заголовки [ ZBXNEXT-5993].

Готовий шаблон можна скачати на GitHub.

Джерело: habr.com