Архив рубрики: Monitoring

Zabbix. An unknown option was passed in to libcurl.

Однажды надо было настроить целый Zabbix для мониторинга парочки web-страниц. Сервер с FreeBSD на борту уже был, осталось только поставить заббикс и настроить. Процесс установки не сложный, описывать нет смысла.

После установки сразу добавил хост, на котором, собственно и добавил таски для мониторинга web-страниц. И стал ждать. Первая же проверка показала, что «An unknown option was passed in to libcurl». WTF? Раньше такое проделывалось неоднократно и никаких проблем не возникало.

Понятно, что разница скорее всего в параметрах сборки curl. Сравнение этих параметров на одном из действующих серверов и на новом показало, что разница всего-то в том, что на новом сервере была отключена поддержка Proxy. Кроме этой опции включены следующие:

  • CA_BUNDLE
  • COOKIES
  • IDN
  • IPV6

После пересборки curl и пересборки (на всякий) заббикса с его последующим перезапуском, проверка web-страницы успешно отрапортовала кодом 200.

Мониторинг логов в Zabbix и возврат триггера в OK

Zabbix может многое. Главное — суметь это настроить :) Одна из полезных возможностей — мониторинг лог-файлов на наличие определенных записей. Если вы хотите держать руку на пульсе событий при мониторинге серверов, то без мониторинга логов никак не обойтись: почти все серьезные ошибки пишутся в логи и во многих случаях гораздо эффективнее мониторить один-два лога, чем настраивать отслеживания статуса 50 сервисов, работоспособность которых не всегда легко проверить.

Мониторинг логов возможен только при установке агента на хост

Собственно, в самой настройке мониторинга логов нет ничего сложного: добавляем соответствующий Item, пишем регулярное выражение для триггера и начинаем получать уведомления! Например, мы хотим отслеживать все ошибки из System лога на серверах под управлением OS Windows. Для этого, создаем следующий Item:

eventlog[System,,"Error",,@eventlog,,skip]

Параметры следующие: System — лог, который отслеживаем; второй параметр — регулярное выражение, которое ищем (пропущен, берем все записи); третий — «Error» — важность, согласно классификации ОС; четвертый — любой источник; пятый — @eventlog — макрос, который исключает события с идентификаторами ^(1111|36888|36887|36874)$;  шестой — максимальное кол-во строк, которое мы отправляем серверу в секунду (неограниченное);  последний параметр — skip — заставляет сервер читать только новые записи лога, а не перечитывать его весь.

В качестве триггера мы используем следующую строку:

{host:eventlog[System,,"Error",,@eventlog,,skip].regexp(^.*$)}<>0

Т.е. мы берем любую строку, которая попала в Item и высылаем уведомление.

После такой настройки мы получим первую ошибку из лога и триггер будет висеть в состоянии PROBLEM до скончания веков, т.к. нет события, которое его переводит в состояние OK. Для решения этой проблемы необходимо добавить к триггеру еще одно условие: наличие новых данных в течение промежутка времени, меньшего, чем время опроса Item. Т.е. если мы проверяем лог на ошибки раз в минуту, то нам надо поставить любой промежуток времени, меньший, чем минута. Итоговый триггер будет выглядеть как-то так:

{host:eventlog[System,,"Error",,@eventlog,,skip].regexp(^.*$)}<>0 and {host:eventlog[System,,"Error",,@eventlog,,skip].nodata(10)}<>1

Выглядеть это будет как «нашли что-то в Item» И «за последние 10 секунд были получены новые данные». При следующей проверке триггер перейдет в состояние OK, т.к. за последние 10 секунд новых данных получено не было. Других способов возврата триггера для лога в нормальное состояние в заббиксе версии 2 не предусмотрено.

Очень медленно грузится web-интерфейс Zabbix

Утро началось как обычно: с проверки всех систем, отчетов и просмотра графиков заббикса. Вот только с последним возникла непонятная проблема. Он установлен на сервере, который является по совместительству веб-сервером для различных проектов. При попытке открыть страницу, браузер висел в ожидании каждого графика, да и страницы в целом секунд по 20-25. Просмотр вывода top не показал никакой нагрузки, ну т.е. совсем никакой — la около 0,3, загрузка процессора около 5%. Количество процессов вменяемое, никаких лимитов не превышено.

После сбора расширенных логов с nginx (именно он стоит в качестве фронтенда) с временем генерации страниц, становится понятно, что затык не в нем, а ниже, т.е. либо в апаче, либо в mysql. Лог медленных запросов mysql тоже не сказал ничего насчет таблиц заббикса. Сервер «боевой», поэтому включать дебаг и смотреть чем же занят все это время httpd и почему же загрузка процессора им равна 0 никак нельзя. Процессы httpd висят в состоянии kqread и не грузят процессор совсем.

Что удивительнее, другие сайты/приложения работали без задержек. Пришлось судорожно вспоминать все изменения, которые вносились в конфигурацию сервера в последнее время. Из всего, что было сделано, на ум приходила только настройка форвардинга в DNS-сервере bind. С целью уменьшения задержек и объема внешнего трафика, был настроен форвардинг запросов DNS на сервер провайдера. Казалось бы, причем тут DNS? Но после отключения форвардинга и перезапуска dns-сервера, заббикс загрузился быстро, как ни в чем не бывало. Подробный анализ всех логов выявил таймауты при обращении к DNS провайдера… Но как? Как это могло повлиять на загрузку веб-интерфейса заббикса?..

Zabbix и счетчики производительности (perf counters)

Понадобилось недавно мониторить некоторые параметры виндовых серверов. Т.к. система мониторинга, а именно Zabbix, уже была установлена и активно использовалась, решено было не изобретать велосипед и попользовать ее с этой целью. Благо, по заверениям разработчиков, она это легко умеет. Все было бы легко, если бы документация по этому вопросу была полноценной.

Стоит начать с того, что имя счетчика пишется в двойных кавычках, начиная с бэкслэша (\). В точности так, как выводит его команда typeperf -qx. Т.е. правильный вид для мониторинга загрузки всех ядер CPU будет выглядеть примерно так:

perf_counter["\Processor(_Total)\% Processor Time"]

Все бы ничего, но при вводе такого счетчика и довольных мыслях («ща всё замониторю с красивыми графиками») мы получаем ответ от заббикса в виде Not supported. Начинаем долго и нудно гуглить по этому вопросу и никак не натыкаемся на ответ. В качестве одной из предполагаемых причин такого поведения может быть запуск 32-битного агента на 64-битном хосте. Но даже при запуске правильного, 64-битного клиента, мы не получаем удовлетворения и видим Not supported.

А все потому, что по умолчанию, у вновь создаваемых элементов (item) мониторинга выставлен тип информации (type of information) — numeric(unsigned). Казалось бы, ничего в этом страшного нет. Загрузка процессора не может быть отрицательной. Так и есть. Но почему-то, разработчики заббикса посчитали, что под понятие numeric(unsigned) попадают ТОЛЬКО целые числа. О чем, в принципе, они честно сообщают в докахNumeric (unsigned) — 64bit unsigned integer. Выставляем numeric(float) и тихо радуемся работающему мониторингу.