Пример маленькой автоматизации zabbix-Mikrotik-ELK⁠⁠

Итак, в прошлом посте читатель узнал, что у меня завелось 55 микротиков. За прошедшее время, по заветам комментаторов, был развернут ELK Stack. Это такая штука для сбора логов со всего, что может эти логи слать. ELK = Elasticsearch + Logstash + Kibana.

Настраивала вот по этим двум статьям, в принципе там всё понятно. Раз и два.

Но помним, что микротиков сильно больше пары штук – это раз. Второе, если прописывать все их в фильтры сборщика логов, то появляется ещё одно место, куда надо что-то писать руками при вводе микротика в эксплуатацию, что не есть хорошо. Да и лень мне было прописывать их все. Короче, во мне стал зарождаться DevOps.

Задача - чтобы в заббиксе мы микротик завели – а логи с него автоматом бы полились и уже с меткой mikrotik.

Я слегка погружусь в теорию, чтобы было понятнее, что мы делаем. Итак, развернут ELK – изначально логи попадают в logstash, где с ними можно что-то сделать. Например, мы отбираем по некоторым критериям логи микротиков и вешаем на них метку «Mikrotik». Этим критерием у меня является IP – то есть «если ip из вот этого перечисления, то это микротик». Если бы у нас был ELK только для микротиков – мы бы просто вешали метку на весь трафик или обошлись без неё, но мы потом хотим добавлять еще логи всякого, например, виндовых серверов. После обработки логи попадают в elasticsearch, где мы их просматриваем с помощью Kibana (это типа веб-морда).

Для начала нам надо получить список микротиков из zabbix. Я использую для этого скриптик на питоне, который получает ip по группе и сразу генерирует кусок конфига, который будет в logstash filter.

Сперва надо установить модули zabix для питона:

apt install python3-pip

pip3 install pyzabbix

Теперь нам надо получить id группы в zabbix – его можно посмотреть в адресной строке браузера на странице группы – там в конце будет что-то типа groupid=65

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

Получается строка вида «if [host] in ["10.1.1.254", “10.2.2.254”]{»

Теперь её надо вставить в правильное место конфига logstash. Чтобы этого добиться, я ставлю метку #MIKMIKMIK туда, куда будет вставлена получившаяся строка.

Вставлять будем с помощью Ansible, один раз вставится, потом будет проверяться на соответствие. Собственно из-за этого и выбран Ansible – он сам будет проверять наш конфиг на соответствие и вносить изменения только, если они есть.

Вот так выглядит /etc/logstash/conf.d/filter.conf до первой работы анзибля

Теперь собираем котлету вместе. Делаем playbook в ansible, который запустит нам скрипт, потом получившийся конфиг вставит в конфиг logstash, и если зафиксированы изменения – перезапустит службу. Со службой я долго не могла понять – почему перезапуска не происходит и ansible отваливается по timeout – ему просто не хватало прав.

write_logstash.yml:

Ну и запихиваем скрипт в крон делаться каждый час.

15  *  *  *  * ansible-playbook /usr/scripts/write_logstash.yml

Опытный читатель спросит – и что же, нам теперь на 55 микротиках настраивать логирование? И мы возвращаемся к предыдущему моему посту (и понимаем, зачем нам это было надо). Вот пример настройки лог-сервера, при этом в команде к каждому микротику указывается его IP в качестве источника данных. Без этого у меня автоматом выбирался служебный ip с интерфейса ip-ip туннеля и это было неудобно.

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

В итоге мы получили что хотели – достаточно добавить микротик в заббикс и настроить на нем пересылку логов, а в ELK оно попадёт автоматом с нужной меткой.

Получился маленький кирпичик автоматизации, но путь в DevOps иногда начинается с одного шага..

Код текстом.