Не смог найти нормальную актуальную инструкцию по мониторингу линуксовых логов забиксом - сделал свою, под 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 адресс машины с агентом.
Готово!