[FATHER_FBI]

Народ бьюсь над проблемой массового добавления интерфейсов. Есть сеть и есть железки с которых снимается статистика трафика в vlan. Но иногда случаются такие ситуации, когда появляется пачка новых виланов которая проходит транзитом через всю сеть, а это порядка 20 железок. Вариант с шаблоном не катит, так как может быть такое что на какой нибудь железке этого вилана не будет. Создавать ручками элементы данных, это хуже онанизма левой рукой.

Прочитал статью на хабре что для этого используют zabbix api. Может есть у кого готовый интерфейс или ткните носом в какую нибудь статью с базовой информацией.

[s.lobanov]

Не нужно api для этого. Вам нужно смотреть в сторону discovery

[FATHER_FBI]

Не нужно api для этого. Вам нужно смотреть в сторону discovery

Есть у меня LLDP, свой функционал выполняет. Но как быть если например мне нужно добавить 10 интерфейсов с разными триггерами для каждого из них.

Edited March 5, 2016 by FATHER_FBI

[s.lobanov]

Для этого есть прототипы

[SergeiK]

Всякие задачи случаются.

Мы API активно используем для заведения хостов но не для управления параметрами.

Нам проще, при заведении, посадить хост в правильный шаблон, чем настраивать хост индивидуально.

 

Но, в целом, смогу подсказать что-то по работе с API, после праздников.

[Negator]

Вручную тоже ничего сложного на самом деле.

[Megas]

Вручную? да вы извращенец... не сочтите за грубость.

 

 

Пилите LLD, в 3ке еще не смотрел но вроде сделали вкусняшки от которых можно отталкиваться.

В обще я поднимал уже тему признаков, также вам никто не мешает передевать различные параметры для тригеров напрямую из LLD скрипта в качестве опций. К примеру, вы вешаете влан и пишите ему дескрипшин: U300M-D500M, дальше LLD скрипт это обнаруживает и там вшивается логика которая передает в тригер параметры что обрабатывать так и так...

 

Короче крутите по правильному в этом направлении и не надо пытаться микроскопом забить гвозди.

[FATHER_FBI]

Но, в целом, смогу подсказать что-то по работе с API, после праздников.

Спасибо, буду ждать.

Вручную тоже ничего сложного на самом деле.

А вы знаете толк в извращении)

Пилите LLD, в 3ке еще не смотрел но вроде сделали вкусняшки от которых можно отталкиваться.

В обще я поднимал уже тему признаков, также вам никто не мешает передевать различные параметры для тригеров напрямую из LLD скрипта в качестве опций. К примеру, вы вешаете влан и пишите ему дескрипшин: U300M-D500M, дальше LLD скрипт это обнаруживает и там вшивается логика которая передает в тригер параметры что обрабатывать так и так...

Согласен с вами lldp гибкая херня. Но все же сабж про API, лучше написать web морду, обвязать ее API что бы добавление специфических элементов данных занимало от силы секунд 30)

[Megas]

Вы застрелитесь когда у вас таких вот специфичных элементов будет пару тысяч, там забыли повестить, там забыли убрать.

Я прекрасно вас понимаю, накодить можно много чего, но исходите из процесса маштабирования, забикс позволяет больше чем вы видите, да есть уникальные периодами вещи, но на все это надо смотреть из призмы маштабируемости.

 

https://www.zabbix.com/documentation/3.0/manual/introduction/whatsnew300#linking_to_applications_based_on_discovery_values

Вот фича которую по идее можно сейчас перевязать с разными моментами, но скажу честно, в планах только через месяц расколупывать, к сожалению сильно застрял в Django.

 

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

Да, скрипт на LLD лучше писать свой, можно взять Jimsona за основу на перле, но там есть нюансы, с разными коммутаторами иногда бывают проблемы, я для себя переписывал под питон его весь, под разные железки и с разными параметрами, хотя вроде в теме кто-то тоже писал и выкладывал свои разработки. В общем в любом случае, все что имеет признаки маштабируемости требуется включать на динамические плюшки.

[FATHER_FBI]

Вы застрелитесь когда у вас таких вот специфичных элементов будет пару тысяч, там забыли повестить, там забыли убрать.

Я прекрасно вас понимаю, накодить можно много чего, но исходите из процесса маштабирования, забикс позволяет больше чем вы видите, да есть уникальные периодами вещи, но на все это надо смотреть из призмы маштабируемости.

 

https://www.zabbix.com/documentation/3.0/manual/introduction/whatsnew300#linking_to_applications_based_on_discovery_values

Вот фича которую по идее можно сейчас перевязать с разными моментами, но скажу честно, в планах только через месяц расколупывать, к сожалению сильно застрял в Django.

 

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

Да, скрипт на LLD лучше писать свой, можно взять Jimsona за основу на перле, но там есть нюансы, с разными коммутаторами иногда бывают проблемы, я для себя переписывал под питон его весь, под разные железки и с разными параметрами, хотя вроде в теме кто-то тоже писал и выкладывал свои разработки. В общем в любом случае, все что имеет признаки маштабируемости требуется включать на динамические плюшки.

Если реализовать lld через скрипт, будет возможность редактировать найденные эелементы данных, навешивать на них свои тригеры?

[Megas]

Уточните а зачем вам редактировать найденные элементы?

 

Вы создаете прототипы тригеров. или у вас каждый тригер сугубо индивидуальный? Мне кажется что не нет, все тригеры попадают под шаблоны. Сделайте пачку шаблонных тригеров и передавайте в них нужные параметры и состояния уже из LLD скрипта.

Сам LLD скрипт вы уже можете перевязать с БД если уж руки чешутся и передавать в забикс значения прямо из этой БД через LLD.

Мне кажется вы не можете для себя понять как сгрупировать однотипные элементы данных, поймите одно Zabbix это не Cacti, где все надо вручную делать, здесь почти полный автомат на все, но все зависит от того как вы используете его.

[OKyHb]

Когдо-то была сложность с LLD - не было простых способов задать разные severity для прототипа триггера. К примеру, важность триггера "к-во ошибок на порту" в зависимости от того, аплинковый порт или порт в сторону клиента. Или вообще, создавать такой триггер только для аплинковых портов.

 

Сейчас такие задачи уже как-то решаются стандартными средствами LLD? Или какие есть workarounds?

[Megas]

Такие задачи и раньше решались, с помощью разделения правил обнаружения через regexp фильтры. Вам никто не запрещает писать регулярку чтобы там где WAN шло в по одним правилам прототипов, по всем остальным по другим правилам. Опять же, смотрите что изменили в 3й версии, по идее стало проще.

[SergeiK]

Так как, актуальна еще борьба с API или уже нет?

 

По фильтрам в LLD,

Да, можно отдавать в LLD сложную таблицу, вешать несколько правил на одно и тоже, фильтрами определять нужные сущности и снимать разные параметры.

 

Например, самое простое - интерфейсы. В таблице интерфейсов цеплять поле (из БД или по дескрипшину), которое сообщает, что именно этот порт - uplink, сделать два правила lld, в одной группе будут рядовые интерфейсы, в другой - uplink-и. И вешать разные параметры, триггеры и прочее, в разных правил. Однако, если у вас меняется Uplink, из одного lld интерфейс потеряется, в другом появится, с новой статистикой.

Если это устраивает - можно играть так, но если нет - метод не годиться.

 

Можно городить и более сложные вещи, но не факт, что этот вариант лучше управления через API.

[SergeiK]

Но, в целом, смогу подсказать что-то по работе с API, после праздников.

Спасибо, буду ждать.

В целом, подробно по API написано в документации.

Примерно так это может выглядеть:

#!/usr/bin/php -e
<?php

$ch = curl_init();
curl_setopt($ch, CURLOPT_HTTPHEADER,["Content-Type: application/json-rpc"]);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLINFO_HEADER_OUT, true);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_URL, $argv[1]);

$api_auth_json='{ "jsonrpc": "2.0", "method": "user.login", "params": { "user": "'.$argv[2].'", "password": "'.$argv[3].'"}, "id": 1 }';
curl_setopt($ch, CURLOPT_POSTFIELDS, $api_auth_json);
$z_res = curl_exec($ch);
$z_json=json_decode($z_res);
$auth_id=$z_json->{'result'};

$api_host_get='{ "jsonrpc": "2.0", "method": "host.get", "params": '.
   '{ "output": ["hostid", "name" ] }, "auth": "'.$auth_id.'", "id": 1 }';
curl_setopt($ch, CURLOPT_POSTFIELDS, $api_host_get);
$z_res = curl_exec($ch);
$z_json=json_decode($z_res);
var_dump($z_json);
?>

Использование:

./zabbix_api_test "http://<IP>/<zabbix_folder>/api_jsonrpc.php" "<api_user>" "<api_pass>"

[FATHER_FBI]

Идея изначально заключается в том что бы написать php морду по работе с API и приблизить ее по юзабили к PRTG.

[Heggi]

Чтобы с curl не извращаться, лучше юзать готовую библиотечку https://github.com/confirm/PhpZabbixApi

Либа не моя, но успешно используется в продакшене.