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

[exesition]

Какая задача: Есть самописная система с выводом алертов с 1с на отдельном экране. В качестве интерфейса обмена данных есть api.rest. Заказчик хочет узнать если возможность сделать вывод алертов из заббикса в эту систему 1c. От заббикса нужно имя очереди, описание ошибки и факт того, проблема есть или это ее устранение. Форма выше - это текущая структура данных одного уведомления. В идеале хотят чтобы сам zabbix при необходимости скидывал данные о появившейся проблеме, которую 1с бы забирала.

1. На текущий момент есть мысли подумать о curl с последующим парсингом данных
2. использовать api, но в таком случае не избежать многочисленных запросов.
3. скриптом выдрать данные напрямую из БД

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

[exesition]

Подумал на досуге и возник еще один вопрос
А реально ли инициировать по факту срабатывания тригера передачу именно последнего события, которое случилось с последующим восстановлением?
По идеи если просто делать запрос в API оно будет выдавать весь список событий

[sadman]

1) Создать новый способ оповещения (Media type) с типом Script: https://www.zabbix.com/documentation...ion/mediatypes
2) В требуемом Действии (Action) указать этот способ оповещения, в тело сообщения напихать что требуется 1С-ке.
3) Научить скрипт разбирать message body и пр. части алерта и готовить их к отсылке по REST.
4) ...
5) Profit!

[exesition]

1) Создать новый способ оповещения (Media type) с типом Script: https://www.zabbix.com/documentation...ion/mediatypes
2) В требуемом Действии (Action) указать этот способ оповещения, в тело сообщения напихать что требуется 1С-ке.
3) Научить скрипт разбирать message body и пр. части алерта и готовить их к отсылке по REST.
4) ...
5) Profit!

В целом, да - это вариант.
А случаем нет аналогичных скриптов? Нужен пример, чтобы было от чего отталкиваться т.к. особо потребности раньше не было что то похожее делать

[sadman]

У меня тоже нет потребности в этом. И скриптов тоже.

[exesition]

Так. Наковырял api запрос, который на выходе выдает

{
    "jsonrpc": "2.0",
    "result": [

        {
            "alertid": "610565",
            "actionid": "39",
            "eventid": "22361678",
            "userid": "68",
            "clock": "1575103358",
            "mediatypeid": "10",
            "sendto": "599",
            "subject": "Problem: *HOSTNAME* что то там случилось",
            "message": "[Problem *HOSTNAME*]: что то там случилось",
            "status": "1",
            "retries": "0",
            "error": "",
            "esc_step": "1",
            "alerttype": "0",
            "p_eventid": "22361657",
            "acknowledgeid": "0"
        }
    ],
    "id": 1
}

По сути дела из этой структуры нужны следующие сущности:
"clock": "1575103358",
"message": "[Problem *HOSTNAME*]: что то там случилось" и аналогичное, когда проблема уходит

"clock": "1575103358"
"message": "[OK *HOSTNAME*]: что то там случилось"


Основные проблемы в следующем:
- Нужно преобразовать время в unixtime подобный
- Данные на кириллицы приходят в формате \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u 044f
- Не могу пока понять как будут отправляться данные именно самого последнего срабатывания интересующего триггера


По второму пункту отбой. Можно просто распарсить данные. Остается последних 2 пункта

- Нужно преобразовать время в unixtime подобный
- Не могу пока понять как будут отправляться данные именно самого последнего срабатывания интересующего триггера

[oscar]

1. Так вроде это и есть unixtime
2. Если извлекаете из истории событий то, ИМХО, через модификаторы "sort" по времени и "limit 1"

[exesition]

1. Так вроде это и есть unixtime
2. Если извлекаете из истории событий то, ИМХО, через модификаторы "sort" по времени и "limit 1"

Там опечатка из Unixtime - конечно. Эта проблема в принципе тоже решается после парсинга.

Применил ваш фильтры к запросу. Стало как минимум удобней. Теперь осталось понять как в заббикс агенте прописать Userparametrs + как все это объединить в скрипт и как заставить отправлять заббикс отправлять информацию на api 1c

но, есть проблема. Отображается первая наименьшая запись (выделена жирным шрифтом), а не самая свежая (выделено курсивом). Как можно исправить ?
{
"jsonrpc": "2.0",
"method": "alert.get",
"params": {
"output": "extend",
"actionids" : "37",
"sortfield" : ["alertid", "clock"],
"limit" : "1"
},
"auth": "abcdef",
"id": 1
}

====Общий Вывод====
{
"jsonrpc": "2.0",
"result": [
{
"alertid": "609137",
"actionid": "37",
"eventid": "22343468",
"userid": "68",
"clock": "1575013629",
"mediatypeid": "10",
"sendto": "599",
"subject": "Problem: no data",
"message": "[PROBLEM HOSTNAME]: "очереди"",
"status": "1",
"retries": "0",
"error": "",
"esc_step": "1",
"alerttype": "0",
"p_eventid": "0",
"acknowledgeid": "0"
},
{
"alertid": "609138",
"actionid": "37",
"eventid": "22343477",
"userid": "68",
"clock": "1575013689",
"mediatypeid": "10",
"sendto": "599",
"subject": "6",
"message": "[OK HOSTNAME] : "нет данных в очереди"",
"status": "1",
"retries": "0",
"error": "",
"esc_step": "1",
"alerttype": "0",
"p_eventid": "22343468",
"acknowledgeid": "0"
},
{
"alertid": "614028",
"actionid": "37",
"eventid": "22427260",
"userid": "68",
"clock": "1575447191",
"mediatypeid": "10",
"sendto": "599",
"subject": "4",
"message": "[PROBLEM]: нет новых сообщений",
"status": "1",
"retries": "0",
"error": "",
"esc_step": "1",
"alerttype": "0",
"p_eventid": "0",
"acknowledgeid": "0"
},
{
"alertid": "614036",
"actionid": "37",
"eventid": "22428228",
"userid": "68",
"clock": "1575449198",
"mediatypeid": "10",
"sendto": "599",
"subject": "6",
"message": "[OK]: нет новых сообщений",
"status": "1",
"retries": "0",
"error": "",
"esc_step": "1",
"alerttype": "0",
"p_eventid": "22427260",
"acknowledgeid": "0"
}
],
"id": 1
}

[oscar]

Исправляется элементарно порядком сортировки "sortorder: DESC".
А если серьезно, зачем вам вообще API? Чуть выше вам правильно подсказали, что проще черед систему оповещений кастомным скриптом загонять все что нужно 1С. Просто ссылка не совсем удачная, тут, ИМХО, более понятный пример приведен -> https://www.zabbix.com/documentation...s/media/script

[exesition]

Исправляется элементарно порядком сортировки "sortorder: DESC".

Да уже нашел.

{
    "jsonrpc": "2.0",
    "method": "alert.get",
    "params": {
        "output": "extend",
        "actionids" : "34",
        "sortfield" : ["alertid"],
        "sortorder": "DESC",
        "limit" : "1"
    },
    "auth": "qwetry",
    "id": 1
}

В таком виде выводит как нужно.

А если серьезно, зачем вам вообще API? Чуть выше вам правильно подсказали, что проще черед систему оповещений кастомным скриптом загонять все что нужно 1С. Просто ссылка не совсем удачная, тут, ИМХО, более понятный пример приведен -> https://www.zabbix.com/documentation...s/media/script

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

[oscar]

По мне, так оба варианта не очень... Дело в том что API запрос дергает последний алерт и если вы его запускаете по расписанию, то при наступлении двух событий между запусками одно из них вы обязательно пропустите. Если же скрипт запускается как действие при событии (например, оповещение с типом "скрипт"), то тем более нет необходимости в API, т.к. все необходимые данные можно передать сразу в скрипт в качестве параметров... Если вопрос именно в скрипте, то поговорите с !Сниками/сделайте сами скрипт который будет принимать параметры из командной строки, а дальше как в ссылке выше...

[Kos]

Я так понял, что во втором случае речь идёт об API со стороны 1С.
По мне, так это единственный правильный вариант.

[exesition]

Я так понял, что во втором случае речь идёт об API со стороны 1С.
По мне, так это единственный правильный вариант.

Да, верно. Жду от них информацию. Думаю на следующей недели буду делать эту затею.

[exesition]

В общем новая вводная.
Наконец то есть понимание что хотят видеть 1с-ники

им необходимо чтобы со стороны заббикса прилетало 4 поля

1. Имя очереди RMQ
2. EventID - идентификатор триггера заббикса
3. Статус проблемы - problem/ok
4. Текст сообщения об ошибке

При опросе по api.alert.get и небольшом парсинге имеем следующее
"eventid": "1232214"
"subject": " db.data ", #имя очереди RMQ
"message": "[OK]: db9tokungur.data (приоритет: Critical) - за 20 минут нет новых сообщений", #Текст сообщения об ошибке

проблема в том что нет параметра отвечающего отдельно за статус триггера. Да мы видим, что в теле письма будет информации ОК -все хорошо, Problem все плохо.
Вопрос: Есть какая то возможность сделать внутри доп запрос через который бы можно было вычленять состояние ОК\Problem? или реален только вариант делать какой то отбор на основе полученных данных в файлик ?

[Kos]

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