Обмен данных 1С<>Zabbix

[exesition]

Ещё раз: вам не нужен API в сторону Zabbix-а, чтобы оттуда что-то выдёргивать.
Вам нужен скрипт, который вы настраиваете в качестве в Action-е, чтобы он срабатывал при возникновении проблемы, а затем - при восстановлении.
Такой скрипт можно оформить либо просто как внешнюю команду, либо как один из каналов доставки уведомлений (это дело вкуса); а с версии 4.4 ещё добавилась возможность использования веб-хуков. В любом случае все перечисленные вами параметры можно передавать этому скрипту во входных данных, используя соответствующие Zabbix-овские макросы.

Честно говоря пытался разобраться и сделал уже скрипт, который мне выдает результат какой то, но осознание пришло того что это все не совсем правильно.
Выходные данные в сторону 1 с
4 поля в формате json
При проблеме

"subject": "dbur.data", "event.id": "371", "status": "problem", "message": bla bla

При восстановление

"subject": "dbur.data", "event recovery.id": "372", "event recovery status": "OK", "message": bla bla

Пошел вашим методом. Создал Medya type с необходимыми макросами (картинка 1). По сути в них есть вся необходимая информация, как вы и говорили.

Дальше в Action создал текст уведомление из макросов, что мы ранее выставляли в medya type.
Только пока все равно не доходит как сделать передачу данных в сервис 1с да и скрипта как такого нет, только представление. Либо нужно делать скрипт в выполнение удаленной команды? Авторизация на сервере 1С проходит по логину\паролю. Отсутствие практики сказывается (


Напрямую через сторонние программы POST передаем данные в 1с и все прекрасно (картинка 3). Со стороны 1с сервер ждет информацию в виде json файла.

Точно знаю что в итоге у нас должно быть преобразование данных в Json формат данных а дальше команда на отправку этих данных средствами POST. В общем нужна какая то аналогия или подсказка. Запутался...

Вероятно по конструкции будет что то такое в плане передачи данных:

/usr/bin/curl -H "Content-type: application/json" \
-H "Authorization: user : pass" \
-X POST \
-d "{
"subject": "true",
"event_id": "$MESSAGE_COLOR",
"status": "status",
"message": "$MESSAGE"}" \

https://1.1.1.1//hs/ds/diagnosticmessage

[Kos]

Я писал:

Такой скрипт можно оформить либо просто как внешнюю команду, либо как один из каналов доставки уведомлений (это дело вкуса);

Т.е. это альтернатива: либо делаете одно, либо - другое. Возможны оба варианта, у каждого есть свои плюсы и минусы.
Например:

• для внешних команд может быть любое количество агрументов, в качестве которых можно указывать макросы; в то время как для скрипта, используемого в качестве канала доставки уведомлений, доступны только три макроса: {ALERT.*};
• это, однако, не сильно большая проблема, т.к. практически все нужные макросы доступны на шаге формирования сообщения для уведомления (в шаблоне уведомления для Action-а), а скрипту доставки передаётся уже соответствующим образом сформированное сообщение (доступное через макрос {ALERT.MESSAGE}) и тема сообщения (доступная через макрос {ALERT.SUBJECT}), и потом эти данные можно при необходимости распарсить уже внутри скрипта;
• в отличие от вызова внешней команды, скрипт доставки уведомлений может отрабатывать также и для событий восстановления; при этом в сообщении корректно раскрываются макросы EVENT.RECOVERY.* (раскрываются в данные, относящиеся к событию восстановления) и макросы EVENT.* (раскрываются в данные, относящиеся к исходному событию).
• при работе скрипта в качестве канала доставки уведомлений макрос {ALERT.SENDTO} раскрывается в адрес, который был указан для данного пользователя в качестве адреса именно для данного канала доставки.

Например, мы у себя решили для интеграции с другой системой (Jira) использовать скрипт, оформленный как канал доставки - для этого был заведён отдельный пользователь, которому был прописан свой "адрес" (набор ключевых слов, используемых в скрипте - тип issue, имя проекта и т.п.) для данного канала доставки. А выбрали именно такой тип скрипта потому что для нас было важно иметь возможность использовать его и для обработки событий восстановления, и при такой обработке важно было "видеть" ID исходного события (по которому находим нужный issue в Jira-е, чтобы его обновить).
Но ваша ситуация может отличаться.

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

• на экране настроек media type можно оставить только три поля, в которые передавать значения макросов {ALERT.*} (остальные макросы в этом месте всё равно не работают);
• все остальные нужные макросы засунуть в настройки Action-а (шаблон темы и самого уведомления). Так, если содержимое остальных макросов имеет заранее известный формат (без кавычек/апострофов/бэкслэшей/etc.), то можно нужный Вам JSON сформировать прямо в качестве текста уведомления. В противном случае задача будет сложнее - нужно будет принимать меры к тому, чтобы на выходе получился корректный JSON (окружая кавычками строковые значения, экранируя "подозрительные" символы и т.п.).
• при необходимости какие-то данные можно прописать в качестве адреса доставки по этому каналу уведомлений для выбранного пользователя. Например, в Вашем случае - URL сервера 1С либо используемые там имя и пароль. Этот адрес будет доступен скрипту доставки через макрос {ALERT.SENDTO}, что удобно, т.к. при необходимости изменений не потребуется переписывать скрипт.
• вкладка "Operations" в настройках Action-а сводится к отсылке сообщения нужному (служебному) пользователю через настроенный канал доставки; никаких дополнительных шагов (скрипт -> удалённая команда) там не нужно.
• собственно, логика дествий самого скрипта доставки будет сводиться к тому, чтобы принять и распарсить (при необходимости) входные параметры, сформировать выходной JSON и вызвать, например, тот же curl, работать с которым Вы уже умеете.

Да, и ещё несколько замечаний из опыта:

• тема уведомления (содержимое {ALERT.SUBJECT}) может состоять только из одной строки, в то время как текст уведомления (содержимое {ALERT.MESSAGE}) - при необходимости, из нескольких.
• для триггера с включенной опцией "Multiple PROBLEM events generation" для события восстановления значения макросов {EVENT.RECOVERY.*} подставляются понятно и ожидаемо, а вот в качестве значений макросов {EVENT.*} подставляются данные не о первом проблемном событии, а о лишь о самом последнем.

[exesition]

Более правильно будет пойти по пути большей автоматизации поэтому логичнее использовать скрипт.
Что было сделано:
создан пользователь в системе заббикс. В поле "Оповещение", "Отправлять на:" http:сервис.1с
создан medya type: (см вложение 1-2 картинка) В целом учитывая что данные отправляются в text\plain формате это должно походить на json формат


далее скрипт. может есть какой то шаблон? Пытался найти что то похожее есть какие то крупицы, но все не то.

скорее всего в теле должен быть такой формат или около такой. буду проверять

"{
"subject": {EVENT.NAME}, \ n
"id": {EVENT.ID}, \ n
"status": {EVENT.STATUS}, \ n
"message": {TRIGGER.NAME} \n
"}