Оповещения в telegram со ссылками на график и триггер
Расскажу про еще один интересный скрипт для отправки красивых и функциональных оповещений в telegram, в котором помимо всего прочего сразу же публикуются ссылки на триггер, график и некоторые другие полезности. Вот он на гитхабе — https://github.com/xxsokolov/Zabbix-Notification-Telegram. Инструкция от автора в некоторых местах не очень понятная, так что я немного повозился, прежде чем все получилось. В основном c xml были проблемы, но обо всем по порядку.
Клонируем к себе репозиторий.
# cd ~ # git clone https://github.com/xxsokolov/Zabbix-Notification-Telegram
Копируем в /usr/lib/zabbix/alertscripts папку zbxTelegram_files и файлы _config.yml, zbxTelegram.py, .requirements и zbxTelegram_config.example.py. Последний переименовываем в zbxTelegram_config.py.
Делаем пользователя zabbix владельцем этих файлов и разрешаем исполнение скрипта.
# chown -R zabbix. /usr/lib/zabbix/alertscripts # chmod +x zbxTelegram.py
Автор скрипта предлагает запускать его в виртуальном окружении, поэтому поставим пакет virtualenv.
# dnf install virtualenv
Переходим в /usr/lib/zabbix/alertscripts, создаем виртуальное окружение и активируем его.
# cd /usr/lib/zabbix/alertscripts # virtualenv venv --python=python3 # source venv/bin/activate
Ставим зависимости и деактивируем окружение.
# pip install -r .requirements # deactivate
Редактируем конфигурационный файл zbxTelegram_config.py. Список параметров, которые нужно поменять.
tg_proxy = False tg_token = '1393668911:AFGHTRDVdfJ28R-wxKfvH1RTR6-vdNw' zabbix_api_url = 'http://10.20.1.23/zabbix/' zabbix_api_login = 'Admin' zabbix_api_pass = 'zabbix'
В url на конце должен обязательно быть слеш. Дальше делаем все то же самое, что и ранее. Идем в Способы оповещений и добавляем новый тип, где в качестве скрипта указываем zbxTelegram.py.
Шаблоны тем сообщений можете настроить как вам больше нравится. Автор предлагает такие:
{Problem} {TRIGGER.SEVERITY} `TRIGGER`.`SEVERITY`: {EVENT.NAME} {Resolved} {TRIGGER.SEVERITY} `TRIGGER`.`SEVERITY` {EVENT.NAME} {Update} {TRIGGER.SEVERITY} `TRIGGER`.`SEVERITY` {EVENT.NAME}
- {Problem} — мапинг значений Problem\Resolved\Update в emoji (config: zabbix_status_emoji_map)
- `TRIGGER`.`SEVERITY` — мапинг значений Severity в emoji (config: zabbix_status_emoji_map)
В поле Сообщение копируется xml конфиг полностью, который приведен в файле actions.example. Копируйте его 1 в 1.
Во все шаблоны можете его вставить без изменений. Я немного попытался его править, но каждый раз потом получал ошибку парсинга xml. В итоге бросил. Автор перечисляет значение каждого парметра, так что можете попытаться настроишь шаблоны на свой вкус.
- <graphs></graphs> — прикреплять график (True\False)
- <graphlinks>True</graphlinks> — прикрепить ссылку url на History (True\False)
- <triggerlinks>True</triggerlinks> — прикрепить ссылку url из триггера (True\False)
- <tag>True</tag> — прикрепить теги (True\False)
- <graphs_period></graphs_period> — период графика в секундах
- <itemid></itemid> — передача itemid {ITEM.ID1}
- <triggerid></triggerid> — передача triggerid {TRIGGER.ID}
- <eventid></eventid>- передача eventid {EVENT.ID}
- <title></title> — заголовок графика {HOST.HOST} — {EVENT.NAME}
- <triggerurl></triggerurl> — передача url из триггера {TRIGGER.URL}
- <tags></tags> — передача списка тэгов из триггера {EVENT.TAGS}
Проверим работу уведомлений. Сначала через консоль.
# ./zbxTelegram.py @serveradmin_zabbix_group test test
В данном случае слова test менять нельзя. Именно они инициируют отправку тестового сообщения. Вот как оно выглядит.
То же самое можно сделать через web интерфейс.
Если все в порядке, подключайте данный тип уведомлений к пользователю, указывайте его в действиях и проверяйте. Уже не буду это подробоно описывать, так как устал. Материал и так очень объемный получился. В итоге уведомления в телеграме от этого скрипта будут выглядеть вот так:
Текст более информативен по дефолту и выглядит приятнее, графики в одном сообщении с текстом. В последней строке есть готовые ссылки на триггер, историю по итему. Только имейте ввиду, что url для ссылок берется из конфига и если у вас там указан localhost, то только с него и можно будет их посмотреть. Так что указывайте внешний, а не локальный url. Из минусов отмечу тоненькие графики без заливки. В скрипте от ableev они более наглядные.
JavaScript и Duktape
Почему были выбраны именно JavaScript и Duktape? Рассматривались различные варианты языков и движков:
- Lua – Lua 5.1
- Lua – LuaJIT
- Javascript – Duktape
- Javascript – JerryScript
- Embedded Python
- Embedded Perl
Основными критериями выбора были распространенность, простота интеграции движка в продукт, низкое потребление ресурсов и общая производительность движка, и безопасность внедрения кода на этом языке в мониторинг. По совокупности показателей победил JavaScript на движке Duktape.
Критерии выбора и performance testing
Особенности Duktape:
— Стандарт ECMAScript E5/E5.1
— Модули Zabbix для Duktape:
- Zabbix.log() — позволяет вписать непосредственно в лог Zabbix Server сообщения с различным уровень детализации, что обеспечивает возможность сопоставлять ошибки, например, в Webhook с состоянием сервера.
- CurlHttpRequest() — позволяет делать HTTP-запросы в сеть, на чем основано применение Webhook.
- atob() и btoa() — позволяет кодировать и декодировать строки в формат Base64.
ПРИМЕЧАНИЕ. Duktape соответствует стандартам ACME. В Zabbix используется версия скрипта 2015 года. Последующие изменения незначительны, поэтому их можно игнорировать.
Обновление «в лоб»
Ничего особо сложного в обновлении заббикса сейчас нет. Закажи сервер, проведи его настройку, слей копию базы. Поставь пакеты мониторинга и укажи им базу, запусти заббикс — и он тебе сам всё обновит, накатит все миграции. Ну да, наверное, вы знаете, каким лёгким стал апгрейд заббикса.
В сумме миграции БД заняли около 15-ти минут и даже без особой ругани. И вроде бы всё хорошо. Да? Как бы не так! Несмотря на то, что IP нового сервера не прописан в белых листах агентов, и он собирает данные лишь с нескольких тестовых хостов, на нём по прежнему стабильно происходит Невозможное.
К чести разработчиков заббикса надо сказать, они своё слово держат — версия 4.2 на тот момент поддерживается. После общения в трекере проекта мы выясняем, что причина невозможного в том что не совпадает с ожидаемой структура одной из таблиц БД.
Закрадываются смутные сомнения. Тут нелишне будет напомнить, что исторически самые «толстые» таблицы БД заббикса у нас секционированы. Прежде всего, из соображений производительности, чтобы хоть как-то прикрыть любимую мозоль заббикса — удаление исторических данных в РСУБД. Сравниваем структуры всех подряд таблиц в свежеобновлённой базе и контрольной — созданной самим сервером с нуля. Опасения подтвердились. Кроме отсутствия некоторых констрейнтов в БД, во множестве таблиц многие цифровые колонки имеют неправильный тип.
То есть, по факту, мы имеем не поддерживаемую разработчиками схему базы, а свой собственный «форк». Другой тип данных колонок это, потенциально:
- другая стоимость хранения метрик
- другая точность цифр
- другая скорость выборки/записи метрик
Думаете, в лучшую сторону? Сомнительно. По прошлому опыту работы с техподдержкой и разработчиками заббикса, тюнить СУБД они умеют.
И этот тип данных колонок можно, но сложно и долго менять. И невозможно без долгого простоя мониторинга. Без гарантий успеха, без поддержки со стороны разработчика в будущем. Нужен другой путь.
И его есть у заббикса. Потому что в апреле 2019-го выходит zabbix-4.2
Разные оповещения о разных событиях
Далее показываю на примере, как можно слать уведомления в личку и в группу, одновременно и по отдельности, в зависимости от настроенных условий. По каким-то действиям пишем в личку, по каким-то в группу. Достаточно просто сделать 2 отдельных пользователя для этого. Одному настроить в качестве способа оповещений личные сообщения, а второму указать группу. Затем в действиях, указывая, какому пользователю отправлять сообщение, выбирать способы уведомлений.
Перед созданием пользователя надо добавить новую группу и дать ей необходимые права. Вы можете очень гибко этим управлять.
Если учетка техническая, только для оповещений, то доступ к веб интерфейсу можно не делать. Даем ей права доступа на чтение только к группе Zabbix servers, так как будем слать уведомления только по триггерам этого хоста.
Теперь добавляем пользователя и помещаем его в эту группу.
Добавляем ему telegram группу в способы оповещения. Добавлять можно не по id, а по имени группы, так удобнее.
Так же добавим персональные уведомления telegram пользователю admin. Здесь уже указываем id учетной записи .
Настраиваем действия. В данном примере я делаю отправку всех уведомлений пользователю Admin, у которого в способах оповещений указана личка telegram. А сообщения по конкретному триггеру Zabbix server: Zabbix agent is not available (for 3m) пользователю tg-group, у которого указана группа telegram.
Думаю, идею вы поняли. Можно очень гибко настроить уведомления в Zabbix и это очень круто и удобно. И работает из коробки. Проверим теперь, как будут выглядеть оповещения в telegram. Останавливаем на сервере zabbix-agent и ждем работы триггера с оповещениями.
Проверяем телеграм и видим там одинаковые уведомления и в группе, и в личке.
После обновления проблемы или закрытия, придут свои оповещения.
При этом, если сработает любой другой триггер, уведомление придет только в личку. В группу ничего не будет отправлено.
Шаблоны и графики в уведомлениях можете настраивать по своему вкусу
Обращаю внимание на графики. Они приходят в отдельных сообщениях
Далее я покажу еще один скрипт для уведомлений в telegram. Он немного по-другому работает — прикрепляет сразу ссылки на историю и триггер, а так же вкладывает графики в то же сообщение, что и текст.
Обращаю внимание. Для того, чтобы отправлялся график в telegram, он должен существовать в системе мониторинга
Если его нет, то вы будете получать ошибку, вместо графика. Но текстовое оповещение будет приходить нормально.
Если у вас возникают ошибки с отправкой графиков, то проверить их работу можно в консоли. Вот пример запроса.
# sudo -u zabbix ./zbxtg.py zeroxzed test "$(echo -e 'zbxtg;graphs: \nzbxtg;graphs_period=3600\nzbxtg;itemid:23301\nzbxtg;title:ololo')" zbxtg.py: Bad Request: PHOTO_INVALID_DIMENSIONS zbxtg.py: Zabbix user couldn't get graph (probably has no rights to get data from host), check script manually, see https://github.com/ableev/Zabbix-in-Telegram/wiki/Graphs
Это нормальный вывод ошибки, которая указывает на то, что выбран itemid 23301, которого либо не существует, либо к нему нет доступа, либо для него нет графика. Если выбрать правильный itemid, то после выполнения скрипта никакого вывода не будет, а в телеграм будет отправлен выбранный график.
JavaScript для Zabbix
В апреле 2019 года был представлен Zabbix 4.2 с функцией предобработки на JavaScript. Многие загорелись идеей отказаться от написания скриптов, которые где-то забирают данные, переваривают их и предоставляют уже в понятном для Zabbix формате, а выполнять простые проверки, которые будут получать неготовые для хранения и обработки Zabbix данные, а потом обрабатывать этот поток данных с использованием средств Zabbix и JavaScript. В связке с низкоуровневым обнаружением и зависимыми элементами данных, которые появились в Zabbix 3.4, получилось достаточно гибкая концепция для сортировки и управления полученными данными.
В Zabbix 4.4, как логическое продолжение предобработки на JavaScript, появился новый способ оповещения — Webhook, который можно использовать для простой интеграции оповещений Zabbix со сторонними приложениями.
Настройка мониторинга принтеров по snmp
На самом сервере мониторинга настраивать особо нечего. Вам достаточно будет взять мои готовые шаблоны, убедиться что MIB и OID совпадают с вашими принтерами и добавить сами принтеры в мониторинг, не забыв указать у них snmp интерфейс.
Printer_HP.xml Printer_Kyocera.xml Printer_Brother.xml
Все шаблоны экспортированы с версии сервера Zabbix 3.4. На других версиях я не проверял, но думаю, что работать будет, так как никаких специфичных вещей в шаблонах нет. Обычные snmp проверки.
Вот пример одного элемента для шаблона принтеров HP.
А вот пример вычисляемого значения уровня тонера для шаблона Kyocera.
Пример триггера, который присутствует во всех шаблонах.
Всю информацию о принтерах можно вывести на Dashboard примерно в таком виде:
Интервалы опроса итемов в шаблонах:
- Всего напечатано страниц – 1 час
- Напечатано на текущем тонере – 10 мин
- Объем тонера – 10 мин
- Уровень тонера – 10 мин
- Название картриджа – 1 день
- Серийный номер – 1 день
На момент отладки рекомендую поставить эти значения 1 минута.
Для элемента данных «Уровень тонера» указан тип данных «Числовой», чтобы работал триггер и сравнивал значение. Если у вас какие-то ошибки с тонером, например из-за того, что не новый использовали, а заправляли старый, то значение будет приходить -2 или -3 с типом «Строка». Итем станет неактивным с ошибкой:
Value "-2" of type "string" is not suitable for value type "Numeric (unsigned)"
С этим уже ничего не поделать. Можете сделать для таких принтеров отдельный шаблон и изменить тип итема с числового на строковый. Так вы хотя бы будете получать значение -2, а не ошибку итема.
На этом у меня все по данной теме. Добавляйте шаблоны, проверяйте и пользуйтесь.
Отправка уведомлений в telegram через webhook
Начиная с 5-й версии, в Zabbix из коробки работают уведомления в telegram через механизм webhook. Чтобы настроить его, переходите в Администрирование -> Способы оповещений и выбирайте там Telegram.
Внутри увидите некоторые параметры. Можно так же посмотреть текст скрипта, который используется для отправки оповещений. В целом, тут сейчас не обязательно что-то менять. Дефолтные настройки полностью рабочие. Надо только указать токен бота.
Тут же можете шаблоны поправить так, как вам нравится. Это нововведение 5-й версии Zabbix — правка шаблонов оповещений в настройках самих оповещений. Это позволяет создавать для каждого типа свои шаблоны. Очень удобно.
Давайте теперь проверим отправку уведомлений через этот способ. Нажимайте Тест.
Я указал текст сообщения, заголовок, свой id и token бота. В итоге мне в личку пришло сообщение от бота.
Если хотите отправить оповещение в группу, то сначала создайте ее, а потом добавьте туда бота. Не потеряйте минус в id группы. Его тоже нужно указывать. Я сначала не понял этого и копировал id группы без минуса. В итоге, оповещения в группу не отправлялись.
Итак, убедились, что сообщения в telegram нормально отправляются. С технической стороны проблем нет. Теперь настроим отправку уведомлений по событиям. Я обычно для этого использую тестовый триггер. В стандартном шаблоне zabbix для OS Linux есть элемент данных Number of logged in users, который считает количество залогиненных пользователей. Я для него делаю триггер, чтобы он срабатывал, когда пользователей 2 и более. И с его помощью тестирую уведомления, просто подключаясь на сервер по ssh двумя подключениями одновременно.
Теперь идем в настройки пользователя и добавляем ему способ оповещений через telegram.
Если у вас ранее не работали никакие уведомления, то не забудьте активировать Действия.
У нас все настроено для отправки оповещений в telegram. Добейтесь срабатывания триггера и проверяйте телеграм канал, в который настроили отправку сообщений.
Все работает. Если вам достаточно такого функционала, то можно оставлять и пользоваться. Но как по мне, так бледновато эти уведомления выглядят. Можно немного шаблоны изменить, чтобы было более читаемо. Так же есть возможность все настроить более красиво и наглядно, да еще и с графиками. Дальше я расскажу еще 2 разных способа отправки уведомлений из zabbix в telegram с графиками и готовыми ссылками на события.
Практические задачи
Задача 1
Заменить вычисляемый элемент данных предобработкой.
Условие: получаем с датчика температуру в градусах по Фаренгейту для хранения в градусах по Цельсию.
Раньше мы создали бы элемент данных, который собирает температуру в градусах по Фаренгейту. После этого — еще один элемент данных (вычисляемый), который по формуле преобразовывал бы градусы по Фаренгейту в градусы по Цельсию.
Проблемы:
- Необходимо дублировать элементы данных и хранить все значения в базе.
- Необходимо согласовать интервалы для «родительского» элемента данных, который вычисляется и используется в формуле, и для вычисляемого элемента данных. В противном случае вычисляемый элемент данных может перейти в неподдерживаемое состояние или посчитать предыдущее значение, что скажется на надежности результатов мониторинга.
Одним из решений был отказ от гибких интервалов проверок в пользу фиксированных интервалов, чтобы гарантированно вычислять вычисляемый элемент данных после элемента данных, получающего данные (в нашем случае — температура в градусах по Фаренгейту).
Но если, например, шаблон мы используем для проверки большого количества устройств, и проверка выполняется раз в 30 секунд, 29 секунд Zabbix «халтурит», а в последнюю секунду начинает проверки и вычисления. Это приводит к созданию очереди и влияет на производительность. Поэтому рекомендуется использовать фиксированные интервалы, только если это действительно необходимо.
В данной задаче оптимальное решение — предобработка из одной строки на JavaScript, которая конвертирует градусы по Фаренгейту в градусы по Цельсию:
Это быстро и просто, не нужно создавать лишних элементов данных и хранить по ним историю, а также можно использовать для проверок гибкие интервалы.
Но, если в гипотетической ситуации необходимо полученный элемент данных сложить, например, с какой-либо константой, определенной в макросе, необходимо учитывать, что параметр value раскрывается в строку. При операции сложения строк, две строки просто объединяются в одну.
Для получения результата математического действия, необходимо привести типы полученных значений в числовой формат. Для этого можно использовать функцию parseInt(), которая выдает целое число, функцию parseFloat(), которая выдает десятичную дробь, или функцию number, которая выдает целое число или десятичную дробь.
Задача 2
Получить время в секундах до окончания сертификата.
Условие: некий сервис выдает дату окончания сертификата в формате «Feb 12 12:33:56 2022 GMT».
В ECMAScript5 Date.parse() принимает дату в формате ISO 8601 (YYYY-MM-DDTHH:mm:ss.sssZ). Необходимо привести к нему строку в формате MMM DD YYYY HH:mm:ss ZZ
Проблема: значение месяца выражено текстом, а не числом. Данные в таком формате не принимаются Duktape.
Пример решения:
-
В первую очередь объявляется переменная, которая принимает значение (весь скрипт — объявление переменных, которые перечислены через запятую).
-
В первой строке мы получаем дату в параметре value и разделяем ее пробелами методом split. Таким образом, мы получаем массив, где каждому элементу массива, начиная с индекса 0, соответствует один элемент даты до и после пробела. split(0) — месяц, split(1) — число, split(2) — строка с временем и т. д. После этого к каждому элементу даты можно обращаться по индексу в массиве.
Данные в полученном формате — количество секунд с 1970 года до какого-то момента в будущем. Использовать данные в полученном формате в триггерах практически невозможно, потому что Zabbix позволяет оперировать только макросами {Date} и {Time}, которые возвращают дату и время в понятном для пользователя формате.
В триггере можно указать выражение ‘last<‘ и набор цифр, который соответствует количеству секунд в периоде, на которое необходимо отреагировать, например, в неделях. Таким образом, триггер будет оповещать о том, что срок действия сертификата заканчивается через неделю.
ПРИМЕЧАНИЕ
Обратите внимание на использование parseInt() в функции return, чтобы сконвертировать дробное число, полученное в результате деления миллисекунд, в целое число. Также можно использовать parseFloat() и хранить дробные данные
Поиск необходимых OID
Для начала возьмем какой-нибудь принтер и посмотрим, что он нам будет отдавать по snmp. Я для примера возьму принтер HP LaserJet Pro MFP M426fdn (ip адрес 192.168.88.20). По-умолчанию у принтеров HP разрешен просмотр параметров по snmp.
Идем в консоль linux и посмотрим с помощью snmpwalk метрики принтера по snmp. Для этого установим необходимый пакет.
# yum install net-snmp-utils
Теперь посмотрим метрики принтера:
# snmpwalk -v 2c -c public 192.168.88.20
В консоль вылетит целая куча строк, которые неудобно просматривать. Направим вывод в текстовый файл и внимательно посмотрим на него.
# snmpwalk -v 2c -c public 192.168.88.20 > ~/snmp.txt
Я вас томить не буду, а сразу укажу на строки, которые нас интересуют:
SNMPv2-SMI::mib-2.43.10.2.1.4.1.1 = Counter32: 8909 | Всего напечатано страниц |
SNMPv2-SMI::mib-2.43.11.1.1.6.1.1 = STRING: «Black Cartridge HP CF226X» | Название картриджа |
SNMPv2-SMI::mib-2.43.5.1.1.17.1 = STRING: «PHB8K3H0P1» | Серийный номер |
SNMPv2-SMI::mib-2.43.11.1.1.9.1.1 = INTEGER: 85 | Уровень тонера |
Возможно, вас еще заинтересует параметр mib-2.43.5.1.1.16.1 — название принтера. Мне лично это не нужно, но если все выводить в сводную таблицу, то может пригодиться
Так же обращаю внимание на параметр mib-2.43.11.1.1.8.1.1. Обычно он показывает максимальное число страниц, которые можно напечатать с текущего картриджа
Мне приходилось сталкиваться с двумя различными ситуациями в показаниях уровня тонера:
- Уровень тонера выводится сразу в % в 2.43.11.1.1.9.1.1. Параметр максимального числа страниц с текущего картриджа указан как 100% в 2.43.11.1.1.8.1.1.
- Уровень тонера в 2.43.11.1.1.9.1.1 показывает количество напечатанных страниц с текущего картриджа. Второй параметр 2.43.11.1.1.8.1.1 показывает максимальное количество страниц, которое может быть напечатано текущим картриджем. Тогда уровень тонера в % нужно считать по формуле 100-100*(mib-2.43.11.1.1.9.1.1)/(mib-2.43.11.1.1.8.1.1).
Первая ситуация мне попалась в принтерах HP, вторая в Kyocera и Brother. Из-за этого пришлось сделать 3 разных шаблона под каждого производителя принтеров. Все остальные параметры у них совпали.
В принтерах Brother mib об уровне тонера были немного другие, такие же как у HP и Kyocera, но отличались на последнюю цифру — 2.43.11.1.1.8.1.2 и 2.43.11.1.1.9.1.2 соответственно. Я не знаю, с чем это связано, но видел подобную ситуацию у других людей. Кто-то из-за этого создавал правила автообнаружения, чтобы точно вычислить последнюю цифру. Мне не пришлось этого делать. Достаточно было создать разные шаблоны для каждого производителя. Все принтеры попали в эти шаблоны на 100%.
Отдельная история с цветными принтерами. Там несколько картриджей и надо внимательно смотреть на их номера. Но тоже не сложно, просто смещение будет на одну единицу, все картриджи будут идти по порядку.
Алексей Владышев ( alexvl )
Zabbix
- это уровень железа – что-то произошло с какой-то железякой, мы тут же об этом узнаем,
- уровень операционной системы,
- сеть, в основном это мониторинг через SNMP,
- виртуальный уровень, т.е. «из коробки» мы предлагаем, например, мониторинг WMware инфраструктуры, vCenter и vSphere,
- дальше идет middleware,
- бизнес-приложения.
это работает быстро, по крайней мере, быстрее, т.к
сервер не должен заниматься постоянным опрашиванием устройств, сами устройства отправляют информацию,
более безопасно с точки зрения агента, потому что агент не должен слушать никакие TCP-соединения или сетевые соединения.
небольшое преимущество, то, что нам сегодня важно – в активном режиме есть буферизация. Если Zabbix-сервер недоступен по каким-то причинам, допустим, мы делаем апгрейд Zabbix-сервера, у нас downtime несколько минут, то данные будут накапливаться на стороне агента
Как только мы сервер запускаем, данные тут же отправятся на сторону сервера, и мы их сможем обрабатывать.
История. Мы основываем свое решение не только на real-time мониторинге, на оперативной информации, которую мы только-только получили, но и смотрим в историю. В историю нужно обязательно смотреть
Это важно.
Отсутствие проблемы – не есть ее решение. Я привел несколько примеров, но на самом деле, вы многие используете Zabbix, посмотрите критическим взглядом на те триггеры, которые у вас сейчас есть
Комбинация анализа истории с гистерезисом, с разными условиями для проблемы и для выхода из проблемы – она на самом деле творит чудеса. Получается такое очень-очень умное обнаружение проблем. Нужно обязательно использовать эту функциональность.
С аномалиями, опять же, мне трудно сказать, принесет ли это какую-то практическую пользу, но, по крайней мере, стоит попробовать. Что касается аномалии, в Zabbix 3.0, возможно, мы реализуем baseline monitoring. Что это означает? Baseline – это некая норма, т.е. этот baseline будет высчитываться из трендов. Если сейчас все триггеры работают с историей, то для baseline мониторинга мы будем брать информацию из трендов, из тенденций, и будет возможность, например, сравнивать поведение системы в рабочее время на прошлой неделе с поведением системы на этой неделе или сегодня. Т.е. мы что-то будем брать за основу, за нормальную ситуацию и сравнивать с тем, что есть сейчас. Это такой статистический анализ, основанный на тенденциях, на трендах.
Автоматическое решение проблем. Наверное, у каждого из вас, если вы используете систему мониторинга, есть такой класс проблем, про который вы знаете, что эта проблема произойдет рано или поздно, и с этим ничего нельзя сделать. Я привел примеры каких-то случайных падений операционной системы – мы знаем, что такая проблема есть, она может произойти в любое время, соответственно, автоматическое решение проблем – это хорошее решение.
И эскалируем проблемы. Отличный стимул для администраторов, если мы делаем эскалирование. Эскалирование не означает, что вот есть администратор, начальник, начальник начальника, начальник начальника начальника… Эскалирование – это означает, что мы сможем среагировать на проблему сразу одним способом, дальше попытаться, может быть, автоматически решить ее другим способом, и дальше, может быть, через 5 минут, если проблема все еще существует, попытаться решить ее следующим способом. Сначала мы перезапускаем сервис, проблема все еще существует, скажем, exchange не завелся с первого раза, что мы тогда можем сделать? Мы можем перезапустить сервер на физическом уровне и тогда уже смотреть, что произойдет.
Заключение
Я показал общий принцип работы с google api в Zabbix. Сам еще подробно не разбирался и дашборды не составлял. Остановился ровно на том, на чем закончил статью. Дальше буду все это разрабатывать и настраивать под конкретные задачи и нужды. Потом все это уедет вместе с остальными метриками в grafana для удобного дашборда. Возможно покажу все это уже в готовом виде.
Для более сложных и разнообразных запросов надо сделать один скрипт с передачей параметров даты, чтобы не плодить скрипты под каждый айтем. Хотелось бы получить какую-то обратную связь от тех, кто всем этим уже занимался. Тема вообще не гуглится, разбирался во всем сам. Думаю, что в основном для работы с api используются готовые библиотеки под различные языки программирования. Прямые запрос через curl больше на экзотику тянет.
И еще у меня есть некоторые подозрения, что я пошел по сложному пути, и есть способ доступа к api попроще, без протухающих токенов. Но я не понял, как сделать по-другому.
Онлайн курс Infrastructure as a code
Если у вас есть желание научиться автоматизировать свою работу, избавить себя и команду от рутины, рекомендую пройти онлайн курс Infrastructure as a code. в OTUS. Обучение длится 4 месяца.
Что даст вам этот курс:
- Познакомитесь с Terraform.
- Изучите систему управления конфигурацией Ansible.
- Познакомитесь с другими системами управления конфигурацией — Chef, Puppet, SaltStack.
- Узнаете, чем отличается изменяемая инфраструктура от неизменяемой, а также научитесь выбирать и управлять ей.
- В заключительном модуле изучите инструменты CI/CD: это GitLab и Jenkins
Смотрите подробнее программу по .