А как вы смотрите логи 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
strangeman ★★★★
( 10.02.14 14:21:54 MSK )
Для вебсервера проблема отобразить текстовый файл? Или отображай напрямую или через cgi какой-нибудь — их море да и самому написать 5 мин. работы.
sdio ★★★★★
( 10.02.14 14:22:22 MSK )
Ответ на: комментарий от sdio 10.02.14 14:22:22 MSK
Для вебсервера проблема отобразить текстовый файл?
6 Мониторинг файлов журналов
Zabbix можно использовать для централизованного мониторинга и анализа файлов журналов с/без поддержки ротации журналов.
Можно использовать оповещения для предупреждения пользователей, когда файл журнала содержит конкретные строки или шаблоны строк.
Для наблюдения за файлом журнала у вас должно быть:
- Работающий Zabbix агент на узле сети
- Настроенный элемент данных для мониторинга журнала
Максимальный размер наблюдаемого файла журнала зависит от поддержки файлов большого объема.
Настройка
Проверка параметров агента
- Параметр ‘Hostname’ совпадает с именем узла сети в веб-интерфейсе
- Указаны сервера в параметре ‘ServerActive’ для обработки активных проверок
Настройка элемента данных
Настройте элемент данных для мониторинга журнала.
Все обязательные поля ввода отмечены красной звёздочкой.
Специально для элементов данных наблюдения за журналами вы должны указать:
| Тип | Здесь выберите Zabbix агент (активный). |
| Ключ | Укажите: log[/путь/к/файлу/имя_файла,,,,,,] или logrt[/путь/к/файлу/регулярное_выражение_описывающее_шаблон_имени_файла,,,,,,] Zabbix агент фильтрует записи из файла журнала по регулярному выражению, если оно указано. Если требуется только количество совпадающих строк укажите: log.count[/путь/к/файлу/имя_файла,,,,,< максзадержка >] или logrt.count[/путь/к/файлу/регулярное_выражение_описывающее_шаблон_имени_файла,,,,,< максзадержка >]. Убедитесь, что у файла имеются права на чтение для пользователя ‘zabbix’, в противном случае состояние элемента данных будет ‘unsupported’. Для получения более подробных сведений смотрите информацию о ключах log, log.count, logrt и logrt.count в разделе поддерживаемых ключей элементов данных Zabbix агентом. |
| Тип информации | Выберите здесь Журнал (лог) для элементов данных log и logrt или Числовой (целое положительное) для элементов данных log.count и logrt.count. Если используется опциональный параметр вывод , вы можете выбрать подходящий тип информации, отличный от «Журнал (лог)». Обратите внимание, что выбор не журнального типа информации приведет к потере локального штампа времени. |
| Интервал обновления (в сек) | Этот параметр задает как часто Zabbix агент будет проверять наличие любых изменений в файле журнала. Указав этот параметр равным 1 секунде, вы можете быть уверенными, что получите новые записи как можно скорее. |
| Формат времени журнала | В этом поле вы можете опционально задать шаблон для анализа штампа времени строки журнала. Если оставить пустым, штамп времени не будет анализироваться. Поддерживаемые значения: * y: Год (0001-9999) * M: Месяц (01-12) * d: День (01-31) * h: Час (00-23) * m: Минута (00-59) * s: Секунда (00-59) Например, рассмотрим следующую строку из файла журнала Zabbix агента: » 23480:20100328:154718.045 Zabbix agent started. Zabbix 1.8.2 (revision 11211).» Она начинается шестью символами обозначающими PID, далее следует дата, время, и остальная часть строки. Форматом времени журнала для этой строки является «pppppp:yyyyMMdd:hhmmss». Обратите внимание, что символы «p» и «:» являются лишь заменителями и могут быть чем угодно, за исключением «yMdhms». |
Важные замечания
- Сервер и агент следят за размером наблюдаемого журнала и временем последней модификации (для logrt) двумя счетчиками. Дополнительно:
- Также агент использует номера inode (на UNIX/GNU/Linux), индексы файлов (на Microsoft Windows) и MD5 суммы первых 512 байт файла журнала для улучшения выбора в случае когда файлы журнала усекаются и ротируются.
- На системах UNIX/GNU/Linux предполагается, что файловые системы где хранятся файлы журналов, сообщают числа inode, которые могут быть использованы для слежения за состоянием файлов.
- На системах Microsoft Windows Zabbix агент определяет тип файловой системе на которой находятся файлы журналов:
- На файловой системе NTFS 64-битные файловые индексы.
- На файловых системах ReFS (только Microsoft Windows Server 2012) 128-битные файловые ID.
- На файловых системах где файловые индексы меняются (т.е. FAT32, exFAT) используется запасной алгоритм для получения разумного подхода в неопределенных условиях, когда сжатие файла журнала приводит в результате к множеству файлов журналов с одинаковым временем изменения.
Извлечение совпадающей части регулярного выражения
Иногда мы можем захотеть извлечь только интересующие значения из требуемого файла вместо того, чтобы получать всю строку, в случае когда найдено совпадение с регулярным выражением.
Начиная с Zabbix 2.2.0, элементы данных файлов журналов расширены возможностью получения извлечения требуемых значений из строк файла. Добавился дополнительный параметр вывод у элементов данных log и logrt .
Использование параметра ‘вывод’ позволяет обозначить подгруппу совпадения в которой мы можем быть заинтересованы.
log[/path/to/the/file,"large result buffer allocation.*Entries: ([0-9]+)". \1]должно позволить получить количество записей со следующего содержания:
Fr Feb 07 2014 11:07:36.6690 */ Thread Id 1400 (GLEWF) large result buffer allocation - /Length: 437136/Entries: 5948/Client Ver: >=10/RPC ID: 41726453/User: AUser/Form: CFG:ServiceLevelAgreementПричина, почему Zabbix вернет только одно число, потому что параметр ‘вывод’ здесь определен как \1 ссылка только на первую интересующую подгруппу: ([0-9]+)
Вместе с возможностью извлечения и получения числа, значение можно использовать в определениях триггеров.
Использование параметра максзадержка
Параметр ‘максзадержка’ в элементах данных журналов позволяет игнорировать более старые строки с целью получения наиболее новых строк проанализированных в течении “максзадержка” секунд.
Параметр ‘maxdelay’ > 0, может привести к игнорированию важных записей в файлах журналов и пропуску оповещений. Используйте этот параметр осторожно и на свой страх и риск, только в случае необходимости.
По умолчанию элементы данных мониторинга журналов забирают все новые строки появляющиеся в файлах журналов. Однако, имеются приложения, которые в некоторых ситуациях начинают записывать огромное количество сообщений в свои файлы журналов. Например, если база данных или DNS сервер недоступны, то такие приложения могут флудить файлы журналов тысячами практически идентичных сообщений об ошибке до тех пор пока не восстановится нормальный режим работы. По умолчанию, все эти сообщения добросовестно анализируются и совпадающие строки оправляются на сервер, как настроено в элементах данных log и logrt .
Встроенная защита от перегрузов состоит из настраиваемого параметра ‘макс. кол-во строк’ (защищающий сервер от слишком большого количества приходящих совпадающих строк в журнале) и ограничения в 4*’макс. кол-во строк’ (защищает CPU и I/O хоста от перегрузки агентам одной проверкой). Тем не менее имеется 2 проблемы со встроенным механизмом защиты. Первая, на сервер будет отправлено большое количество потенциально не так информативных сообщений, которые займут место в базе данных. Вторая, по причине ограниченного количества строк анализируемых в секунду агент может отставать на часы от самых новых записей в журнале. Вполне вероятно, что вы захотите как можно быстрее быть информированным о текущей ситуации в файлах журналов вместо ковыряния часами старых записей.
Решение этих двух проблем является использование параметра ‘максзадержка’. Если параметр ‘maxdelay’ > 0, во время каждой проверки измеряются количество обработанных байт, количество оставшихся байт и время обработки. Отталкиваясь от этих значений, агент вычисляет оценочную задержку — как много секунд может потребоваться, чтобы проанализировать все оставшиеся записи в файле журнала.
Если задержка не превышает ‘максзадержка’, тогда агент поступает с анализом файла журнала как обычно.
Если задержка больше чем ‘максзадержка’, тогда агент игнорирует часть файла журнала, «перепрыгивая» эту часть к новой оценочной позиции таким образом, чтобы оставшиеся строки можно было проанализировать за ‘максзадержка’ секунд.
Обратите внимание, что агент даже не читает проигнорированные строки в буфер, но вычисляет приблизительную позицию для прыжка в файле.
Сам факт пропуска строк в файле журнала записывается в файл журнала агента, примерно следующим образом:
14287:20160602:174344.206 item:"logrt["/home/zabbix32/test[0-9].log",ERROR,,1000. 120.0]" logfile:"/home/zabbix32/test1.log" skipping 679858 bytes (from byte 75653115 to byte 76332973) to meet maxdelayКоличество «to byte» является оценочным, потому что после «прыжка» агент скорректирует позицию в файл к началу строки в журнале, которая может быть в файле чуть дальше или раньше.
В зависимости от того как скорость роста соотносится к скорости анализа файла журнала, вы можете не увидеть «прыжков», а можете увидеть редкие или частые «прыжки», большие или маленькие «прыжки», или даже маленькие «прыжки» каждую проверку. Колебания загрузки системы и сетевые задержки также влияют на вычисления задержки и, следовательно, «прыжки» вперед чтобы не отставать от параметра «максзадержка».
Заметки по обработке ротации ‘copytruncate’ файлов журналов
logrt с опцией copytruncate подразумевает, что разные файлы журналов имеют разные записи (по крайней мере штампы времени в них отличаются), поэтому MD5 суммы начальных блоков (до первых 512 байт) будут отличаться. Два файла с одинаковыми MD5 суммами начальных блоков означают, что один из них оригинал, а второй — копия.
logrt с опцией copytruncate делает попытку правильной обработки копий файлов журналов без дублирующих сообщений. Тем не менее, такие варианты как создание нескольких копий файлов журналов с одинаковыми штампами времени, ротация файлов журналов чаще чем интервал обновления logrt[] элемента данных, частый перезапуск агента не рекомендуются. Агент пытается справиться со всеми этими ситуациями, но хорошие результаты не гарантируются при всех обстоятельствах.
Действия, если произошла ошибка связи между агентом и сервером
Каждая совпадающая строка с элементов данных log[] и logrt[] и результат проверки каждого элемента данных log.count[] и logrt.count[] требует свободный слот в выделенной 50% области буфера отправки в агенте. Элементы буфера регулярно отправляются серверу (или прокси) и слоты буфера становятся снова пустыми.
Пока имеются свободные слоты в выделенной области для журналов в буфере отправки в агенте и связь между агентом и сервером (или прокси) нарушена, результаты мониторинга журналов накапливаются в буфере отправки. Такое поведение позволяет смягчить кратковременные нарушения связи.
Во время длительных нарушений свящи все слоты журналов становятся занятыми и выполняются следующие действия:
- Проверки элементов данных log[] и logrt[] останавливаются. Когда связь восстановится и появятся свободные слоты, проверки вернутся к предыдущей позиции. Не совпадающие строки потеряются. Совпадающие строки не будут потеряны, они просто отправятся позже.
- Проверки log.count[] и logrt.count[] останавливаются, если maxdelay = 0 (по умолчанию). Поведение похоже на элементы данных log[] и logrt[] , описанное выше. Обратите внимание, что потеря связи может повлиять на результаты log.count[] и logrt.count[] : например, одна проверка насчитает 100 совпадающих строк в файле журнала, но по причине отсутствия свободных слотом в буфере проверка будет остановлена. Когда связь восстановится агент насчитает те же 100 совпадающих строк, а также 70 новых совпадающих строк. После чего агент отправит количество = 170, так как они найдены за одну проверку.
- Проверки log.count[] и logrt.count[] при maxdelay > 0 : если не было «прыжка» во время проверки, тогда поведение аналогично описанному выше. Если всё же был «прыжок» через строки файла журнала, тогда позиция после «прыжка» сохранится и подсчитанный результат будет отброшен. Таким образом, агент пытается не отставать от увеличивающегося файла журнала, даже в случае проблем со связью.
Портал технической поддержки 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
Тип информации выберите Журнал (лог). Для применения изменений нажмите Обновить.
Была ли эта статья полезной? Да Нет
К сожалению, мы не смогли помочь вам в разрешении проблемы. Ваш отзыв позволит нам улучшить эту статью.
6 Мониторинг файлов журналов
Zabbix можно использовать для централизованного мониторинга и анализа файлов журналов с/без поддержки ротации журналов.
Можно использовать оповещения для предупреждения пользователей, когда файл журнала содержит конкретные строки или шаблоны строк.
Для наблюдения за файлом журнала у вас должно быть:
- Zabbix агент запущенный на узле сети
- Настроенный элемент данных для мониторинга журнала
Максимальный размер наблюдаемого файла журнала зависит от поддержки файлов большого объема.
Настройка
Проверка параметров агента
- Параметр ‘Hostname’ совпадает с именем узла сети в веб-интерфейсе
- Для обработки активных проверок указаны сервера в параметре ‘ServerActive’
Настройка элемента данных
Настройте элемент данных для мониторинга журнала:
Конкретно для элементов данных наблюдения за журналами вы должны ввести:
Тип Здесь выберите Zabbix агент (активный). Ключ Установите:
log[имя файла с размещением файла,,,,]
или
logrt[имя файла с размещением файла,,,,]
Например:
log[/var/log/syslog]
log[/var/log/syslog,error]
logrt[«/home/user/filelog_.*_[0-9]»,»совпадение_с_шаблоном»,»UTF-8″,100].
Последний пример будет собирать данные из таких файлов как «filelog_abc_1» или «filelog__001».
Для получения более подробных сведений смотрите информацию о log и logrt в разделе поддерживаемых ключей элементов данных.
Убедитесь, что у файла выставлены права на чтение для пользователя ‘zabbix’, в противном случае состояние элемента данных будет установлено равным ‘unsupported’. Zabbix агент будет фильтровать записи в файле журнала по регулярному выражению, если оно задано.Тип информации Здесь выберите Журнал (лог). Интервал обновления (в сек) Этот параметр задает как часто Zabbix агент будет проверять наличие любых изменений в файле журнала. Установив этот параметр равным 1 секунде вы сможете убедиться, что вы получите новые записи как можно скорее. Формат времени журнала Поддерживаемые значения:
* y: Год (0001-9999)
* M: Месяц (01-12)
* d: День (01-31)
* h: Час (00-23)
* m: Минута (00-59)
* s: Секунда (00-59)
Если оставить пустым, штамп времени не будет анализироваться.
Например, рассмотрим следующую строку из файла журнала Zabbix агента:
» 23480:20100328:154718.045 Zabbix agent started. Zabbix 1.8.2 (revision 11211).»
Она начинается шестью символами обозначающими PID, далее следует дата, время, и остальная строка.
Формат времени журнала для этой строки должен быть «pppppp:yyyyMMdd:hhmmss».
Обратите внимание, что символы «p» и «:» являются лишь заполнителями и могут быть чем угодно, за исключением «yMdhms».Важные заметки
- Сервер и агент следят за размером наблюдаемого журнала и временем последнего изменения (для logrt) двумя счетчиками.
- Агент начинает читать лог-файл с той позиции, в которой он остановился последний раз.
- Количество байт уже проанализированное (счетчик размера) и время последней модификации (счетчик времени) хранятся в базе данных Zabbix и отправляются агенту, для уверенности, что он начнет читать файл журнала с этой позиции.
- Всякий раз, когда лог-файл становится меньше, чем известное агенту значение счетчика размера, счетчик обнуляется и агент начинает читать лог-файл с самого начала, принимая во внимание счетчик времени.
- Все файлы, соответствующие формату имени файла в соответствующей папке, анализируются каждый цикл и агент пытается получить следующую строку из лог-файла (для logrt).
- Если в папке существует несколько соответствующих файлов с тем же временем последнего изменения, то агент будет лексикографически читать наименьший из этих файлов.
- Zabbix агент обрабатывает новые записи лог-файла один раз на Период обновления в секундах.
- Zabbix агент отправляет не более чем maxlines записей из лог-файла в секунду. Это ограничение предотвращает перегрузку сети и ресурсов процессора и переопределяет значение по умолчанию предусмотренное параметром MaxLinesPerSecond в файле конфигурации агента.
- Кроме того, данные из лог файлов всегда ограничены 50% от размера буфера отправки у агента, даже если в буфере нет значений не связанных с данными из лог файлов. Таким образом, значения maxlines будут отправлены за одно соединение (и не в нескольких соединений), параметр BufferSize агента должен быть по крайней мере равен maxlines x 2.
- При остутствии элементов данных журналов весь размер буфера используется для значений не связанных с данными из логов. Когда появляются значения от лог файлов они заменяют устаревшие данные не связанные с лог файлами, если требуется, до максимального уровня 50%.
- Специальное примечание для разделителей пути «\»: если формат файла представлен как «file\.log», тогда там не должно быть папки «file», поскольку невозможно однозначно определить, экранируется ли это символ «.» или это первый символ в имени файла.
- Регулярные выражения для logrt поддерживаются только в именах файлов, совпадение регулярного выражения с папкой не поддерживается.