Как посмотреть логи zabbix

А как вы смотрите логи Zabbix-сервера?

Есть Zabbix-сервер (уже отлично)
Есть Zabbix-frontend к этому серверу, всё настроено и работает (просто супер! ;))
Вопрос на 10000$: как из этого чудесого фронтенда увидеть такую в общем даром никому не нужную вещь, как лог zabbix-сервера? Я имею в виду то, что сервер пишет в /var/log/zabbix, а не абсолютно бесполезную информацию о том, что я в этом веб-интерфейсе делал и когда (спасибо фронтенду конечно, но я и сам в курсе).
На самом деле проблема должна была бы «всколыхнуть сообщество» уже давно, поскольку ситуации, когда банально просто нет доступа физически на сервер с zabbix_server, а есть только фронтенд, пусть даже и с правами Admin’а — это вряд ли такая уж редкость. Если бы zabbix писал в базу данных события логов, которые отображались бы записью в syslog — всё было бы замечательно, но zabbix просто тупо пишет в файл и не даёт никакой адекватной возможности прочитать этот файл иначе как посредством перенастройки syslog’а (заказчик машет ластами и крутит пальцем у виска) или прямого доступа по ssh на целевую машинку (заказчик нервно хохочет, догадываясь о том, что нелегально попасть по SSH на его машинку можно, поскольку данный им админский доступ к фронтенду позволяет делать подобные вещи, пусть и через Ж).
В общем, как увидеть логи сервера в морде веба, а не через удалённый доступ к консоли?
Сапсибо! 😉

DRVTiny ★★★★★
10.02.14 14:18:38 MSK

Портал технической поддержки Cloud24.kz

Zabbix можно использовать для централизованного мониторинга и анализа файлов журналов с/без поддержки ротации журналов. Можно использовать оповещения для предупреждения пользователей, когда файл журнала содержит конкретные строки или шаблоны строк. (подробнее Мониторинг файлов журналов)

Для наблюдения за файлом журнала у вас должно быть:

• Работающий Zabbix агент на узле сети (Установка Zabbix Agent 5.X на ОС CentOS/Debian/Ubuntu)
• Настроенный элемент данных для мониторинга журнала

В данном примере будет рассматриваться мониторинг логирования пользователей по SSH . Необходимо предоставить доступ для чтения пользователю zabbix к файлу логов, например для ОС Centos

chgrp zabbix /var/log/secure chmod 640 /var/log/secure

для ОС Debian/Ubuntu

chgrp zabbix /var/log/auth.log chmod 640 /var/log/auth.log

В случае есть имеются ошибки в файле логов zabbix-agent для ОС Centos типа

Cannot open file "/var/log/secure": [13] Permission denied

то необходимо предоставить разрешение SELinux для агента zabbix.

Проверьте текущие настройки SELinux для агента zabbix

getsebool -a | grep zabbix

если имеются троки типа

zabbix_can_network --> off

измените настройки на on командой

setsebool -P zabbix_can_network=1

Далее необходимо настроить Узел сети на стороне Zabbix сервера. Перейдите по адресу https://monitoring.cloud24.kz, введите логин и пароль

Перейдите в Настройка — Узлы сети и выберите необходимый узел сети. Перейдите во кладку Элементы данных и нажмите на кнопку Создать элемент данных. В появившемся окне в поле Имя впишите наименование для нового Элемента данных, поле Тип выберите из выпадающего списка Zabbix агент (активный), в поле ключ впишите значение

log[/var/log/secure,"^.*sshd.*(Accepted|closed).*". ]

*значение выше будет логировать удачные и не удачные попытки входа по shh

Тип информации выберите Журнал (лог). Для применения изменений нажмите Обновить.

Была ли эта статья полезной? Да Нет

К сожалению, мы не смогли помочь вам в разрешении проблемы. Ваш отзыв позволит нам улучшить эту статью.

Zabbix мониторинг логина на Linux server

Даже когда на сервер запрещено логиниться ото всюду, кроме разрешенных ip адресов — все равно может потребоваться мониторить удачные (да и неудачные вдруг) входы на сервер. В принципе даже в шаблоне по умолчанию для Linux серверов есть элемент количества залогиненых пользователей, и можно просто повесить триггер на изменение этого числа. Но мне нужно было получить ip адрес, с которого произошел вход. Вот как я это сделал.

Я настраивал все это на Ubuntu 18/20 , но думаю что на других системах всё примерно похоже. Итак, нас будет интересовать лог файл /var/log/auth.log а в нем строчка :

Dec 18 19:07:17 server sshd[4096267]: Accepted password for user from 168.0.1.42 port 51850 ssh2

Создаем в Zabbix новый элемент. Имя элементу на свой вкус, тип элемента — Zabbix agent (active), ключ элемента будет такой:

То есть мы проверяем файл /var/log/auth.log и ищем в нем момент строки, который совпадает с маской ‘from IPv4’. Не факт, что это самое правильно написание регулярного выражения и я буду рад, если меня поправят. Но оно работает. Тип информации элемента — log. Параметры обновления и хранения данных элемента — на свой вкус. Сохраняем элемент и добавляем его на нужный сервер.

Идем проверять. Latest data, выбираем нужный сервер, проверяем появились ли данные после логина на сервер. Можно даже посмотреть историю.

Теперь сделаем триггер. Триггер будет срабатывать при появлении новой строки в лог файле, и если в течение 10 минут новых данных не будет — триггер будет закрываться. Имя триггера — New login, выражение триггера такое:

Так как тут же проверяется на отсутствие данных в течение 10 минут — я не буду делать выражение для события статуса Ok и т.д. То есть в принципе триггер готов. Сохраняем, логинимся и проверяем.

Логи из Linux в Zabbix. Подробнейшая инструкция

Не смог найти нормальную актуальную инструкцию по мониторингу линуксовых логов забиксом — сделал свою, под 6.4.

И отвлекусь на установку агента — не зря же писал скрипт.

Установка и настройка агента

Открываем консоль на машине которую собираемся мониторить, локально или подключившись по SSH. Ставим zabbix-agent, рекомендуют использовать вторую версию. Я ставлю из RPM пакета, ссылку на версию под свою ОС берём на https://www.zabbix.com/ru/download

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

hostnamectl

В моём случае это восьмая версия «Operating System: Rocky Linux 8.7 (Green Obsidian)»
Однако бывают подлости, например fedora 37 отсутствует в списке дистрибутивов и это не проблема — достаточно спросить у гугла на чём она основана, либо спросить через консоль и посмотреть результат (вторая строка)

cat /proc/version Linux version 6.2.15-200.fc37.x86_64 (mockbuild@bkernel02.iad2.fedoraproject.org) (gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4), GNU ld version 2.38-27.fc37) #1 SMP. 

Соответственно выбираем Red Hat. А вот универсального решения для определения версии ос у меня нет, хотя чтение страницы редхата на википедии намекает на девятую версию.

Проверяем что в данный момент агент не установлен(вывод должен быть пустым):

systemctl list-units --type service | grep -E "*zabbix*"

Непосредственно инсталляцию можно провести так как рекомендует заббикс во втором пункте, но использование rpm не самый удобный способ поэтому я заменил вызов на dnf с ключём автоподтверждения

dnf install https://repo.zabbix.com/zabbix/6.4/rhel/8/x86_64/zabbix-release-6.4-1.el8.noarch.rpm -y dnf install zabbix-agent2 zabbix-agent2-plugin-* -y

Для получения данных из файла необходимо запускать агент в активном режиме поэтому прописываем в конфиг ip сервера и стираем хостнэйм чтоб он брался из имени компьютера. И запускаем сервис.

sed -i 's/^Server=127.0.0.1/Server=192.168.6.22/' /etc/zabbix/zabbix_agent2.conf sed -i 's/^ServerActive=127.0.0.1/ServerActive=192.168.6.22/' /etc/zabbix/zabbix_agent2.conf sed -i 's/^Hostname=Zabbix server/ /' /etc/zabbix/zabbix_agent2.conf systemctl enable zabbix-agent2 --now

Осталось выдать заббикс агенту правана чтение интересующего файла:

chown root:zabbix /var/log/messages chmod 640 /var/log/messages*

Настройки на Zabbix сервере

Идём в Сбор данных>Шаблоны>Создать шаблон. Указываем произвольное имя шаблона на английском и группу, добавляем и ищем его в общем списке. Переключаемся на вторую вкладку «Элементы данных» и создаём новый.

Произвольное имя и обязательно тип «Zabbix агент (активный)».
Ключ log[/var/log/messages,kernel] включает в себя:
Log позволяет читать дополняемые файлы, используйте logrt для файлов с ротацией. Не смотря на то messages архивирует старые данные ротацией — нас интересует только свежак, да и заббикс будет хранить в себе копию лога
/var/log/messages — путь к файлу, с этим всё понятно. А вот дальше интереснее — kernel это подстрока при наличии которой данные будут пересылаться на сервер. Нам нужны только важные события поэтому мы и выбираем kernel, разумеется для своих целей смотрим в файл и решаем что интересно именно вам.

Тип информации Журнал (лог). Интервал обновления я поставил в секунду — это не вызывает проблем с производительностью

Но и в кернелах хватает мусора! Переключаем на вкладку Предобработка в столбце Имя (очевидный косяк перевода) выставляем Замена, в параметрах какое значение нам необходимо фильтровать. Обратите внимание что параметры регистрозависимы.

Осталось заставить заббикса выводить оставшуюся информацию на главную панель.
На вкладке Тригер создаём новый Имя произвольное а вот в Имя события можно выводить полезную информацию. Мне удобно выводить имя устройства и всю строку переданную с заббикс агента. К слову ITEM.LASTVALUE2 выведет предпоследнюю строку и т. д.

Выражение — при появлении элемента данных найти в нём то что мы добавили в предобработке и проигнорировать, а остальные строки показать. Если поставим =1 покажет только строку добавленную в предобработку. Формируется этот запрос разумеется через кнопку Добавить — выбираем Элемент данных, Функцию find и всё!

Режим генерации событий ПРОБЛЕМА Множественная позволяет обрабатывать каждую строку по отдельности, хоть и не гарантирует оригинальный порядок строк.

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

Генерация ОК события я отключаю, так как выводятся только важные события на которые стоит обратить пристальное внимание, но часто используют выражения вида nodata(/log_messages_kernel/log[/var/log/messages,kernel],15m)=0 — отсутствие событий за последние 15 минут. Вот только это не работает с Множественным режимом генерации проблем и вам придётся городить скрипты или зависимые события.

Ну и разрешить ручное закрытие разумеется.

Последний этап добавить узел сети Сбор данных, Узлы сети, Создать узел сети.

Имя узла сети для активного агента обязательно указывать таким же как в агенте. Если на агенте оно явно не прописано в строке Hostname файла /etc/zabbix/zabbix_agent2.conf, то берётся название из строки Static hostname: вывода команды hostnamectl что удобно для автоматизации процесса развёртывания.

Добавляем в Шаблоны только что созданный и Linux by Zabbix agent active для мониторинга стандартных метрик. Разумеется можно было добавить тригеры и элементы данных в стандартный шаблон, но очевидно это плохая практика.

Так же задаём удобную Группу узлов сети, Интерфейс с типом Агент и IP адресс машины с агентом.