3 Низькорівневе виявлення [Zabbix Documentation 3.0]

1. 3 Низькорівневе виявлення огляд
2. Обмеження даних для значень, що повертаються
3. 3.1 Виявлення файлових систем
4. 3.2 Виявлення мережевих інтерфейсів
5. 3.3 Виявлення CPU і ядер CPU
6. 3.4 Виявлення SNMP OID'ов
7. 3.5 Виявлення з використанням SQL запитів ODBC
8. 3.6 Виявлення служб Windows
9. 3.7 Створення призначених для користувача LLD правил
10. 3.8 Використання макросів LLD в контекстах користувальницьких макросів

3 Низькорівневе виявлення

огляд

Наша взаимовыгодная связь https://banwar.org/

Низькорівневе виявлення (LLD) дає можливість автоматичного створення елементів даних, тригерів і графіків для різних об'єктів на комп'ютері. Наприклад, Zabbix може автоматично почати моніторити файлові системи або мережеві інтерфейси з вашого пристрою, без необхідності створення вручну елементів даних для кожної файлової системи або мережевого інтерфейсу. Крім того, в Zabbix є можливість налаштувати видалення непотрібних об'єктів, грунтуючись на фактичних результатах періодично виконуваного виявлення.

У Zabbix підтримуються три вбудованих типу елементів даних для виявлення:

• виявлення файлових систем;

• виявлення мережевих інтерфейсів;

• виявлення CPU і ядер CPU;

• виявлення SNMP OID'ов;

• виявлення з використанням SQL запитів ODBC;

• виявлення Windows служб.

Користувач має можливість визначити свої власні типи виявлення, забезпечивши їх функціонування згідно специфікації JSON протоколу.

Загальна архітектура процесів виявлення полягає в наступному.

Перш за все, користувач створює правило виявлення в "Налаштування" → "Шаблони" → колонка "Виявлення". Правило виявлення складається з (1) елемента даних, який здійснює виявлення необхідних об'єктів (наприклад, файлові системи або мережеві інтерфейси) і (2) прототипів елементів даних, тригерів і графіків, які повинні бути створені на підставі отриманих значень цього елемента даних.

Елемент даних, який здійснює виявлення необхідних об'єктів, подібний до звичайних елементів даних, які видно в інших місцях: Zabbix сервер запитує у Zabbix агента (або будь-який інший вказаний тип елемента даних) значення цього елемента даних, і агент відповідає текстовим значенням. Різниця в тому, що значення, яке повертає агент, має містити список виявлених об'єктів в спеціальному JSON форматі. Хоча деталі цього формату важливі тільки для творців власних перевірок виявлення, все ж усім необхідно знати, що повертається значення містить список з пар: макрос → значення. Наприклад, елемент даних "net.if.discovery" може повернути дві пари: "{#IFNAME}" → "lo" і "{#IFNAME}" → "eth0".

Елементи даних низкоуровневого виявлення - vfs.fs.discovery, net.if.discovery підтримуються Zabbix агентом починаючи з версії 2.0.
Елемент даних низкоуровневого виявлення "system.cpu.discovery" підтримується Zabbix агентом починаючи з версії 2.4.
Виявлення SNMP OID'ов підтримується Zabbix сервером і проксі починаючи з версії 2.0.
Виявлення з використанням SQL запитів ODBC підтримується Zabbix сервером і проксі починаючи з версії 3.0.

Ці макроси потім використовуються в іменах, ключах і в інших полях прототипів, які є основою для створення реальних елементів даних, тригерів і графіків кожному виявленому об'єкту. Дивіться повний список опцій по використанню макросів в низкоуровневом виявленні.

Коли сервер отримує значення елемента даних виявлення, він дивиться на пару макрос → значення і для кожної пари створює реальні елементи даних, тригерів і графіків, заснованих на їх прототипах. У наведеному вище прикладі з "net.if.discovery", сервер буде створювати один набір елементів даних, тригерів і графіків для локального інтерфейсу "lo" і інший набір для інтерфейсу "eth0".

Наступний розділ ілюструє весь процес, описаний вище, в деталях і служить керівництвом, як здійснювати всі згадані вище типи виявлень. Останній розділ описує формат JSON елементів даних виявлення і дає приклад того, як реалізувати ваш власний скрипт для виявлення файлових систем, використовуючи Perl скрипт.

Обмеження даних для значень, що повертаються

Обмеження для JSON даних низкоуровневого правила виявлення відсутні, якщо ці дані отримані безпосередньо Zabbix сервером, так як отримані значення обробляються без збереження в базу даних. Також обмеження відсутні і для призначених для користувача правил низкоуровневого виявлення, однак, якщо передбачається отримання призначених для користувача LLD даних за допомогою призначеного для користувача параметра, тоді накладається обмеження за розміром значення (512 КБ) на сам користувальницький параметр.

Якщо дані надходять від Zabbix проксі, цей проксі змушений спочатку записати їх в базу даних. В такому випадку накладаються обмеження до бази даних , Наприклад, 2048 байт для Zabbix проксі, який працює з IBM DB2 базою даних.

3.1 Виявлення файлових систем

Для настройки виявлення файлових систем, зробіть наступне:

• Перейдіть в: Установки → Шаблони

• Натисніть на Виявлення в рядку відповідного шаблону

• Натисніть на Створити правило виявлення в верхньому правому куті екрану

• Заповніть діалог наступними деталями

Вкладка Правило виявлення містить загальні атрибути правила виявлення:

Параметр Опис Ім'я Ім'я правила виявлення. Тип Тип перевірки виконуваного виявлення; повинен бути Zabbix агент або Zabbix агент (активний) при виявленні файлових систем. Ключ Елемент даних "vfs.fs.discovery" вже вбудований в Zabbix агент на багатьох платформах (для отримання більш детальних відомостей дивіться список підтримуваних ключів елементів даних ), Який повертає список файлових систем, присутніх в комп'ютері, і їх типи в форматі JSON. Частота оновлення (в сек) Цей фільтр задає як часто Zabbix виконує виявлення. На початку, коли ви тільки налаштовуєте виявлення файлових систем, ви можете вказати маленький інтервал, але як тільки ви переконаєтеся що все працює, ви можете встановити його в 30 хвилин або більше, тому що зазвичай файлові системи не змінюються дуже часто.
Зверніть увагу: Якщо вкажіть значення рівне "0", елемент даних не буде оброблятися. Однак, якщо також існує змінний інтервал з ненульовим значенням, елемент даних буде оброблятися протягом дії змінного інтервалу. Призначені для користувача інтервали Ви можете створювати користувацькі правила перевірки елемента даних:
Гнучкий - створення виключень з Інтервалу поновлення (інтервал з іншою частотою оновлення)
За розкладом - створення призначеного для користувача розкладу перевірки.
Для отримання більш детальної інформації дивіться призначені для користувача інтервали . Перевірка за розкладом підтримується починаючи з Zabix 3.0.0. Період збереження втрачених ресурсів (днів) Це поле дозволяє вам вказати як багато днів виявлений об'єкт буде зберігатися (не буде видалений), як тільки його стан виявлення стане "Чи не виявляється більш" (макс 3650 дней).
Зверніть увагу: Якщо значення дорівнює "0", об'єкти будуть вилучені відразу. Використання значення "0" не рекомендується, так як просте помилкове зміна фільтра може закінчиться тим, що об'єкт буде видалено разом з усіма даними історії. Опис Введіть опис. Стан Якщо відзначене, правило буде оброблятися.

Вкладка Фільтри містить визначення фільтрації правила виявлення:

Параметр Опис Тип обчислення В наявності є таке опції розрахунку фільтрів:
І - повинні виконатися всі фільтри;
Або - досить виконання одного фільтра;
І / Або - використовується І для різних імен макросів і Або з однаковим ім'ям макросу;
Користувача вираз - з'являється можливість вказати для користувача обчислення фільтрів. Формула повинна включати в себе всі фільтри зі списку.
Обмежено 255 символами. Фільтри Фільтр можна використовувати тільки для генерування реальних елементів даних, тригерів і графіків конкретних файлових систем. очікується використання Розширені регулярні вирази POSIX . Наприклад, якщо ви зацікавлені тільки в файлових системах C :, D: і E :, ви можете помістити {#FSNAME} в полі "Макрос" і регулярний вираз "^ C | ^ D | ^ E" в текстові поля "Регулярний вираз" . Фільтрація також можлива за типами файлових систем, при використанні макросу {#FSTYPE} (наприклад, "^ ext | ^ reiserfs") і по типу диска (підтримується тільки Windows агентів), використовуючи макрос {#FSDRIVETYPE} (наприклад, "fixed") .
Ви можете ввести в поле "Регулярний вираз" регулярний вираз або посилання на глобальне регулярний вираз .
Для перевірки регулярного виразу ви можете використовувати "grep -E", наприклад: for f in ext2 nfs reiserfs smbfs; do echo $ f | grep -E '^ ext | ^ reiserfs' || echo "SKIP: $ f"; done Макрос {#FSDRIVETYPE} на Windows підтримується починаючи з Zabbix 3.0.0.
Визначення декількох фільтрів підтримується починаючи з 2.4.0.
Зверніть увагу, що якщо якийсь макрос з фільтра пропущений у відповіді, знайдений об'єкт буде ігноруватися.

База даних Zabbix в MySQL повинна бути створена чутливої ​​до регістру, якщо імена файлових систем розрізняються тільки по регістру, щоб виявлення спрацювало коректно.

Помилка або помилка в регулярному виразі, яке використовується в LLD правилі, може привести до видалення тисяч елементів конфігурації, даних історії і подій на великій кількості вузлів мережі. Наприклад, некоректне регулярний вираз "File systems for discovery" може привести до видалення тисяч елементів даних, тригерів, даних історії і подій.

Історія правил виявлення не зберігається.

Як тільки правило буде створено, перейдемо до елементів даних цього правила і натиснемо "Створити прототип", щоб створити прототип елементів даних. Зверніть увагу на те, як використовується макрос {#FSNAME}, де потрібно вказати ім'я файлової системи. Коли правило буде оброблятися, цей макрос буде замінений виявленої файлової системою.

Якщо прототип елемента даних створений зі станом деактивовано, то він буде доданий як виявлений об'єкт, але в деактивовано стані.

Прототип групи елементів даних є опцією, яка вказується у властивостях прототипів елементів даних. У властивостях групи елементів даних ви можете використовувати макроси низкоуровневого виявлення, які, після виконання виявлення, їх буде замінено фактичними значеннями при створенні груп елементів даних, які специфічні для виявленого об'єкта. Дивіться також замітки по виявленню груп елементів даних для отримання більш докладної інформації.

Ми можемо створити кілька прототипів елементів даних для кожної цікавить нас характеристики файлової системи:

Тепер схожим способом ми створимо прототипи тригерів:

Коли реальні тригера створюються з прототипів, можливо буде потрібно якась гнучкість щодо того яка константа ( '20' в нашому прикладі) у натуральному вираженні використовується для порівняння. дивіться як призначені для користувача макроси з контекстом можуть бути корисні для отримання подібної гнучкості.

Також ви можете задати залежно між прототипами тригерів (підтримується починаючи з Zabbix 3.0). Щоб це зробити, перейдіть на вкладку Залежності. Прототип тригерів може залежати від іншого прототипу тригерів з цього ж правила низкоуровневого виявлення (LLD) або від звичайного тригера. Прототип тригерів не може залежати від прототипу тригерів з іншого правила LLD і від тригера створеного іншим прототипом тригерів. Прототип тригерів вузла мережі не може залежати від тригера з шаблону.

І також прототипи графіків:

Зрештою, ми створили правило виявлення, яке виглядає як видно нижче. Воно має п'ять прототипів елементів даних, два прототипи тригерів і один прототип графіка.

Зверніть увагу: Для отримання інформації про налаштування прототипів вузлів мережі, дивіться в розділі моніторингу віртуальних машин про налаштування прототипів вузлів мережі .

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

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

Елементи даних (а також, тригери і графіки) створені за допомогою низкоуровневого правила виявлення неможливо видалити вручну. Тим не менш, вони будуть видалені автоматично, якщо виявлений об'єкт (файлова система, інтерфейс і т.д.) більш не виявляється (чи більше не потрапляє під фільтр). У цьому випадку вони будуть видалені через кілька днів вказане в полі Період збереження втрачених ресурсів.

Коли виявлений об'єкт стає 'Більш не виявляється', в списку елементів даних буде відображатися помаранчевий індикатор часу життя. Перемістіть курсор миші на цей індикатор і ви побачите повідомлення з кількістю днів до моменту видалення елемента даних.

Якщо об'єкти відзначені на видалення, але не були видалені в призначений час (деактивовано правило виявлення або елемент даних вузла мережі), вони втечуть при наступному виконанні правила виявлення.

Об'єкти містять інші об'єкти, які відзначені до видалення, що не будуть оновлюватися при змінах на рівні правила виявлення. Наприклад, тригери виявлені за допомогою низкоуровневого виявлення не будуть оновлюватися, якщо вони містять елементи даних, які позначені для видалення.

3.2 Виявлення мережевих інтерфейсів

Виявлення мережевих інтерфейсів здійснюється таким же чином, як і виявлення файлових систем, за винятком того, що ми використовуємо ключ правила виявлення "net.if.discovery" замість "vfs.fs.discovery" і макрос {#IFNAME} замість {#FSNAME} в фільтрі і в прототипах елементів даних / тригерів / графіків.

Приклади прототипів елементів даних, які ви можете захотіти створити грунтуються на "net.if.discovery": "net.if.in [{# IFNAME}, bytes]", "net.if.out [{# IFNAME}, bytes] ".

дивіться вище для отримання інформації з приводу фільтра.

3.3 Виявлення CPU і ядер CPU

Виявлення CPU і ядер CPU виконується аналогічно виявлення мережевих інтерфейсів за винятком того, що ключем правила виявлення є "system.cpu.discovery". Цей ключ виявлення возвращаетс два макроси - {# CPU.NUMBER} і {# CPU.STATUS}, що ідентифікують порядковий номер CPU і стан відповідно. Відзначимо, можна зробити чіткого відмінності між дійсними, фізичними процесорами, ядрами і hyperthread. {# CPU.STATUS} на Linux, UNIX і BSD системах повертають стан процесора, яке може бути як "online", так і "offline". На Windows системах, цей же макрос може являти собою третє значення - "unknown" - яке вказує на те, що процесор був виявлений, але інформація по ньому ще не зібрана.

Виявлення CPU засноване на процесі колектора агента, щоб підтримувати відповідність з даними, які поставляються колектором і зберегти ресурси на отримання даних. Така поведінка дає ефект, що цей ключ елемента даних не працює з прапором командою рядка тестування (-t) бінарного файлу, який повертає стан NOT_SUPPORTED і супутнє повідомлення про те, що процес колектора не запущено.

Прототипи елементів даних, які можна створити на основі виявлення CPU включають в себе, наприклад, "system.cpu.util [{# CPU.NUMBER}, <тип>, <режим>]" і "system.hw.cpu [{# CPU.NUMBER}, <інформація>] ".

3.4 Виявлення SNMP OID'ов

У цьому прикладі ми здійснимо виявлення SNMP на комутаторі. Спочатку перейдемо в "Налаштування" → "Шаблони".

Для зміни правил виявлення шаблону, натисніть на посилання в колонці "Виявлення".

Потім натисніть "Створити правило" і заповніть форму, як відображено на знімку екрана нижче.

На відміну від виявлення файлових систем і мережних інтерфейсів - цей елемент даних не вимагає наявності ключа "snmp.discovery", досить вказати, що типом елемента даних є SNMP агент.

OID'и для виявлення додаються в поле SNMP OID в наступному форматі: discovery [{# Макрос1}, oid1, {# МАКРОС2}, oid2, ...,]

де {# Макрос1}, {# МАКРОС2} ... допустимі імена низькорівневих макросів і oid1, oid2 ... є OID'амі здатними згенерувати осмислені значення для цих макросів. Вбудований макрос {#SNMPINDEX} містить індекс виявленого OID, який застосовується до виявлених об'єктів. Виявлені об'єкти групуються за значенням макросу {#SNMPINDEX}.

Для розуміння того, що ми маємо на увазі, давайте виконаємо кілька разів snmpwalk на нашому комутаторі:

$ Snmpwalk -v 2c -c public 192.168.1.1 IF-MIB :: ifDescr IF-MIB :: ifDescr.1 = STRING: WAN IF-MIB :: ifDescr.2 = STRING: LAN1 IF-MIB :: ifDescr.3 = STRING: LAN2 $ snmpwalk -v 2c -c public 192.168.1.1 IF-MIB :: ifPhysAddress IF-MIB :: ifPhysAddress.1 = STRING: 8: 0: 27: 90: 7a: 75 IF-MIB :: ifPhysAddress.2 = STRING: 8: 0: 27: 90: 7a: 76 IF-MIB :: ifPhysAddress.3 = STRING: 8: 0: 27: 2b: af: 9e

І поставимо SNMP OID рівним: discovery [{# IFDESCR}, ifDescr, {#IFPHYSADDRESS}, ifPhysAddress]

Тепер це правило буде виявляти об'єкти з макросом {#IFDESCR} рівним WAN, LAN1 і LAN2, макросом {#IFPHYSADDRESS} рівним 8: 0: 27: 90: 7a: 75, 8: 0: 27: 90: 7a: 76, і 8: 0: 27: 2b: af: 9e, макросом {#SNMPINDEX} рівним індексам виявлених OID 1, 2 і 3:

{ "Data": [{ "{#SNMPINDEX}": "1", "{#IFDESCR}": "WAN", "{#IFPHYSADDRESS}": "8: 0: 27: 90: 7a: 75"} , { "{#SNMPINDEX}": "2", "{#IFDESCR}": "LAN1", "{#IFPHYSADDRESS}": "8: 0: 27: 90: 7a: 76"}, { "{# SNMPINDEX} ":" 3 "," {#IFDESCR} ":" LAN2 "," {#IFPHYSADDRESS} ":" 8: 0: 27: 2b: af: 9e "}]}

Якщо виявлений об'єкт не має вказаний OID, тоді по цьому об'єкту відпо макрос пропускається. Наприклад, якщо у нас є такі дані:

ifDescr.1 "Interface # 1" ifDescr.2 "Interface # 2" ifDescr.4 "Interface # 4" ifAlias.1 "eth0" ifAlias.2 "eth1" ifAlias.3 "eth2" ifAlias.5 "eth4"

Тоді, в разі SNMP виявлення discovery [{# IFDESCR}, ifDescr, {#IFALIAS}, ifAlias] повернеться наступна структура:

{ "Data": [{ "{#SNMPINDEX}": 1, "{#IFDESCR}": "Interface # 1", "{#IFALIAS}": "eth0"}, { "{#SNMPINDEX}": 2 , "{#IFDESCR}": "Interface # 2", "{#IFALIAS}": "eth1"}, { "{#SNMPINDEX}": 3, "{#IFALIAS}": "eth2"}, { " {#SNMPINDEX} ": 4," {#IFDESCR} ":" Interface # 4 "}, {" {#SNMPINDEX} ": 5," {#IFALIAS} ":" eth4 "}]}

Представлений знімок екрана ілюструє як ми можемо використовувати ці макроси в прототипах елементів даних:

Знову ж, створимо стільки прототипів елементів даних, скільки необхідно:

Також як і прототипи тригерів:

І прототипи графіків:

Результат нашого правила виявлення:

Коли сервер працює, він створить реальні елементи даних, тригери і графіки на основі значень, отриманих від SNMP правила виявлення. В налаштуваннях вузлів мережі вони матимуть префікс посилання оранжевого кольору, яка веде до правила виявлення, що їх створив.

3.5 Виявлення з використанням SQL запитів ODBC

Цей тип виявлення здійснюється з використанням SQL запитів, отримані результати яких автоматично перетворюються в об'єкт JSON, придатний для низькорівневого виявлення. SQL запити виконуються за допомогою елементів даних типу "Монітор баз даних". Так що, більша частина вказівок зі сторінки ODBC моніторингу застосовна до отримання працюючого "Монітор баз даних" правила виявлення, єдина різниця лише в тому, що необхідно використовувати ключ "db.odbc.discovery [<опис>, <dsn>]" замість "db.odbc.select [<опис>, <dsn>] ".

В якості практичного прикладу, що ілюструє як SQL запит трансформується в JSON, розглянемо низкоуровневое виявлення Zabbix проксі, виконавши ODBC запит в Zabbix базу даних. Він може бути корисний для автоматичного створення внутрішніх елементів даних "Zabbix [proxy, <ім'я>, lastaccess]", щоб спостерігати які проксі живі.

Давайте почнемо з налаштування правила виявлення:

Тут використовується наступний прямий запит до бази даних Zabbix для вибірки всіх Zabbix проксі разом з кількістю вузлів мережі, за якими ці проксі спостерігають. Кількість вузлів мережі можна використовувати, наприклад, для фільтрації порожніх проксі:

mysql> SELECT h1.host, COUNT (h2.host) AS count FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxy_hostid WHERE h1.status IN (5, 6) GROUP BY h1.host; + --------- + ------- + | host | count | + --------- + ------- + | Japan 1 | 5 | | Japan 2 | 12 | | Latvia | 3 | + --------- + ------- + 3 rows in set (0.01 sec)

Завдяки внутрішньому механізму обробки елемента даних "db.odbc.discovery []", результат цього запиту автоматично перетвориться в наступний JSON:

{ "Data": [{ "{#HOST}": "Japan 1", "{#COUNT}": "5"}, { "{#HOST}": "Japan 2", "{#COUNT}" : "12"}, { "{#HOST}": "Latvia", "{#COUNT}": "3"}]}

Видно, що імена колонок стають іменами макросів і вибрані рядки стають значеннями цих макросів.

Якщо результат перетворення імені колонки в ім'я макросу неочевидний, пропонується використовувати аліаси до імен колонок, так само як "COUNT (h2.host) AS count" в прикладі вище.

У разі, якщо ім'я колонки не вдається конвертувати в припустиме ім'я макросу, правило виявлення стає непідтримуваних з детальним повідомленням про помилку який номер колонки не вдалося перетворити. Якщо бажана додаткова допомога, отримані імена колонки відображаються при DebugLevel = 4 в файлі журналу Zabbix сервера:

$ Grep db.odbc.discovery /tmp/zabbix_server.log ... 23876: 20150114: 153410.856 In db_odbc_discovery () query: 'SELECT h1.host, COUNT (h2.host) FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxy_hostid WHERE h1.status IN (5, 6) GROUP BY h1.host; ' 23876: 20150114: 153410.860 db_odbc_discovery () column [1]: 'host' 23876: 20150114: 153410.860 db_odbc_discovery () column [2]: 'COUNT (h2.host)' 23876: 20150114: 153410.860 End of db_odbc_discovery (): NOTSUPPORTED 23876 : 20150114: 153410.860 Item [Zabbix server: db.odbc.discovery [proxies, {$ DSN}]] error: Can not convert column # 2 name to macro.

Тепер, коли ми розуміємо як SQL запит трансформується в JSON об'єкт, ми можемо використовувати макрос {#HOST} в прототипах елементів даних:

Як тільки виявлення буде виконано, елемент даних буде створений по кожному проксі:

3.6 Виявлення служб Windows

Виявлення служб Windows здійснюється тим же самим способом, що і виявлення файлових систем. Використовуваним ключем в правилі виявлення є "service.discovery" і підтримуються наступні макроси для застосування їх в фільтрі і прототипах елементів даних / триггерах / графіків:

{# SERVICE.NAME} {# SERVICE.DISPLAYNAME} {# SERVICE.DESCRIPTION} {# SERVICE.STATE} {# SERVICE.STATENAME} {# SERVICE.PATH} {# SERVICE.USER} {# SERVICE.STARTUP} {# SERVICE.STARTUPNAME}

На основі виявлення служб Windows ви можете створити прототип елементів даних на зразок "service.info [{# SERVICE.NAME}, <парам>]", де парам набуває таких значень: state, displayname, path, user, startup або description. Наприклад, щоб отримати власний псевдонім служби вам необхідно використовувати елемент даних "service.info [{# SERVICE.NAME}, displayname]". Якщо значення парам не вказано ( "service.info [{# SERVICE.NAME}]"), буде використовуватися параметр state за замовчуванням.

Макроси {# SERVICE.STATE} і {# SERVICE.STATENAME} повертають однаковий вміст, однак, {# SERVICE.STATE} повертає числове значення (0-7), тоді як {# SERVICE.STATENAME} повертає текст (running, paused, start pending, pause pending, continue pending, stop pending, stopped або unknown). Те ж саме відноситься і до {# SERVICE.STARTUP} і {# SERVICE.STARTUPNAME}, де перший повертає числове значення (0-4), тоді як другий - текст (automatic, automatic delayed, manual, disabled, unknown).

3.7 Створення призначених для користувача LLD правил

Також є можливість створити повністю призначене для користувача правило низкоуровневого виявлення, для виявлення будь-якого типу об'єктів - наприклад, баз даних на сервері баз даних.

Щоб це зробити, необхідно створити окремий елемент даних, який буде повертати JSON, який визначає знайдені об'єкти і опціонально - деякі властивості цих об'єктів. Кількість макросів на об'єкт не обмежена - в той час як вбудовані правила виявлення повертають або один, або два макроси (нппрімер, два в разі виявлення файлових систем), є можливість повертати більше.

Необхідний JSON формат найкраще ілюструється в прикладі. Припустимо, що ми залишимо старий Zabbix агент версії 1.8 (який не підтримує "vfs.fs.discovery"), але нам також потрібно виявляти файлові системи. Ось простий Perl скрипт для Linux, який виявляє примонтировать файлові системи і видає на виході дані JSON, в яких включено і ім'я, і ​​тип файлової системи. Одним із способів його використання є UserParameter з ключем "vfs.fs.discovery_perl":

#! / Usr / bin / perl $ first = 1; print "{\ N"; print "\ T \" data \ ": [\ n \ n"; for ( `cat / proc / mounts`) {($ fsname, $ fstype) = m / \ S + (\ S +) (\ S +) /; print "\ T, \ n" if not $ first; $ First = 0; print "\ T {\ n"; print "\ T \ t \" {#FSNAME} \ ": \" $ fsname \ ", \ n"; print "\ T \ t \" {#FSTYPE} \ ": \" $ fstype \ "\ n"; print "\ T} \ n"; } print "\ N \ t] \ n"; print "} \ N";

Допустимими символами в іменах макросів низькорівневих правил виявлення є 0-9, AZ, _,.
Букви в нижньому регістрі в іменах не підтримуються.

Приклад його виведення (переформатований для наочності) представлений нижче. JSON дані від користувача перевірки виявлення слідують такому ж формату.

{ "Data": [{ "{#FSNAME}": "/", "{#FSTYPE}": "rootfs"}, { "{#FSNAME}": "/ sys", "{#FSTYPE}": "sysfs"}, { "{#FSNAME}": "/ proc", "{#FSTYPE}": "proc"}, { "{#FSNAME}": "/ dev", "{#FSTYPE}": "devtmpfs"}, { "{#FSNAME}": "/ dev / pts", "{#FSTYPE}": "devpts"}, { "{#FSNAME}": "/ lib / init / rw", " {#FSTYPE} ":" tmpfs "}, {" {#FSNAME} ":" / dev / shm "," {#FSTYPE} ":" tmpfs "}, {" {#FSNAME} ":" / home " , "{#FSTYPE}": "ext3"}, { "{#FSNAME}": "/ tmp", "{#FSTYPE}": "ext3"}, { "{#FSNAME}": "/ usr" , "{#FSTYPE}": "ext3"}, { "{#FSNAME}": "/ var", "{#FSTYPE}": "ext3"}, { "{#FSNAME}": "/ sys / fs / fuse / connections "," {#FSTYPE} ":" fusectl "}]}

Тоді, в правилах виявлення в поле "Фільтр" ми можемо вказати "{#FSTYPE}", як макрос, і "rootfs | ext3", як регулярний вираз.

Ви не зобов'язані використовувати імена макросів FSNAME / FSTYPE в призначених для користувача правилах низкоуровневого виявлення, ви можете використовувати будь-які інші імена, які вам подобаються.

Зверніть увагу на те, що при використанні для користувача параметра, що повертаються дані обмежені 512 КБ. Для отримання більш детальної інформації дивіться обмеження даних для значень, що повертаються LLD .

3.8 Використання макросів LLD в контекстах користувальницьких макросів

призначені для користувача макроси з контекстом можна використовувати для отримання більш гнучких порогів у виразах тригерів. Можна задати різні пороги на рівні користувача макросу і потім використовувати в константах тригерів в залежності від виявленого контексту. Виявлений контекст з'являється тоді, коли макрос низкоуровневого виявлення , Який використовується в макросах, розкривається в реальні значення.

Для ілюстрації ми модем взяти дані з прикладу вище і припустити, що будуть виявлені наступні файлові системи: /, / home, / tmp, / usr, / var.

Ми можемо додати прототип тригера, який перевіряє вільне місце на диску, на вузол мережі, де поріг задається за допомогою призначеного для користувача макросу з контекстом:

{host: vfs.fs.size [{# FSNAME}, pfree] .last ()} <{$ LOW_SPACE_LIMIT: "{# FSNAME}"}

Потім додамо призначені для користувача макроси:

Тепер, коли файлові системи будуть виявлені, події будуть згенеровані, якщо файлові системи /, / usr і / var мають менше 10% вільного місця на диску, файлова система / home - менше 20% вільного місця на диску або файлова система / tmp - менш 50% вільного місця на диску.