Полезные советы
- Если zabbix server — не один:
- В агенте прописать так:
... Server=192.168.0.1,192.168.0.2 ServerActive=192.168.0.1,192.168.0.2 ...
Проблема: Триггер с элементом vm.memory.size
Пытаюсь мониторить переполнение RAM (если меньше 10% свободной RAM в течении 5 минут) и создаю триггер:
{hostname:vm.memory.size.last(5m)}<10
Однако ничего не происходит.
Решение:
Вам для вашей задачи лучше использовать функцию max()
{hostname:vm.memory.size.max(5m)}<10
источник
Пример: {Zabbix server:vm.memory.size.max(5m)}<10
{Zabbix server:system.cpu.util.last(0)}>20
Получается, что ожидает операции ввода.вывода более 20 сек ?
Решение: Cоветую увеличить интервал и также путем увелечинеия памяти!
Проверьте и в случае необходимости, подправьте настройки правил обнаружения или увеличьте количество процессов которые занимаются обнаружением новых устройств (параметр StartDiscoverers в конфиг файле zabbix сервера). К пингу этот процесс и триггер отношения не имеют. Если не нужен, то и не запускайте обнаружения. Если нужен, то поставьте 2. Посмотрите на графике динамику изменения. Если всё равно нагрузка будет большая, поставьте 3. Ну и так далее.
- Проблема: zabbix win 7 cannot make counterpath for «\\»: Обязательный аргумент пропущен или указан неправильно.
- Решение:
cmd lodctr /r
взято тут
* Проблема: fping failed: /usr/bin/fping: can’t create socket (must run as root?) : Permission denied * Решение:
chown root:zabbix /usr/bin/fping chmod 710 /usr/bin/fping chmod ug+s /usr/bin/fping
взято тут
* Проблема: : Connection refused
* Решение: commented out the line #ServerActive=127.0.0.1 from the agent configuration file /etc/zabbix/zabbix_agentd.conf.
или закомментируйте строку активного сервера и укажите только просто ip сервера.
источник
Отложенное оповещение
Для настройки отложенного оповещения идем в web интерфейс zabbix сервера, в раздел Configuration -> Actions и выбираем правило оповещения, которое будем изменять. Я для примера возьму дефолтное правило Report problems to Zabbix administrators.
Идем во вкладку Operations и меняем Default operation step duration на 5m, если вы хотите отложить отправку оповещения на 5 минут. Далее редактируем шаг исполнения. В разделе Steps ставим значения 2 — 2. Изначально там стоит 1 — 1. То есть мы указываем, выполнить отправление со второго шага, а длину шага ранее установили в 5 минут.
Вот и все. Я показал на простом примере, как отложить отправку оповещения о событии в zabbix.
Оптимизация MySQL
Конфигурация MySQL достаточно сложная, но, к счастью, вам не нужно в нее сильно углубляться. Есть специальный скрипт под названием MySQLTunner, который анализирует работу MySQL и дает советы какие параметры нужно изменить и какие значения для них установить. Скрипт поддерживает большинство версий MariaDB, MySQL и Percona XtraDB. Нам понадобится загрузить три файла с помощью wget:
Первый из них — это сам скрипт, написанный на Perl, второй и третий — база данных простых паролей и уязвимостей. Они позволяют обнаружить проблемы с безопасностью. Дальше можно переходить к тестированию. Я использую сервер с настройками mysql по умолчанию, установленными панелью управления VestaCP.
Буквально за несколько минут скрипт выдаст полную статистику по работе MySQL. Количеству запросов, занимаемому объему памяти и эффективности работы буферов. Вы можете ознакомиться со всем этим, чтобы лучше понять в чем причина проблем. Проблемные места обозначены красными восклицательными знаками. Например, здесь мы видим, что размер буфера движка таблиц InnoDB (InnoDB buffer pool) намного меньше, чем должен быть для оптимальной работы:
Кроме того, в самом конце вывода утилита предоставит список рекомендаций как исправить ситуацию. Мы рассмотрим все сообщения утилиты из этого примера и почему нужно использовать именно их, а не другие.
Все параметры нужно добавлять в /etc/my.cnf. Еще раз замечу, что вы не копируете статью, а смотрите что вам выдала утилита. Начнем с query-cache.
Скрипт рекомендует отключить кэш запросов. Query Cache — это кэш вызовов SELECT. Когда базе данных отправляется запрос, она выполняет его и сохраняет сам запрос и результат в этом кэше. И все бы ничего, но при использовании его вместе с InnoDB при любом изменении совпадающих данных кэш будет перестраиваться, что влечет за собой потерю производительности. И чем больше объем кэша, тем больше потери. Кроме того при обновлении кэша могут возникать блокировки запросов. Таким образом, если данные часто пишутся в базу данных — его надежнее отключить.
Оба параметра устанавливают размер памяти, которая используется для внутренних временных таблиц MySQL. Утилита рекомендует использовать объем больше 16 мегабайт, просто установите это ваше значение для обоих переменных, если у вас достаточно памяти, то можно выделить 32 или даже 64
Но важно чтобы оба значения совпадали, иначе будет использоваться минимальное
Этот параметр отвечает за количество потоков, которые будут закэшированны. После того, как работа с подключением будет завершена, база данных не разорвет его, а закэширует, если количество кэшированных потоков не превышает ограничение. Утилита рекомендует больше четырех, например, 16.
Указывает, что не нужно пытаться определить доменное имя для подключений извне. Ускоряет работу, так как не тратится время на DNS запросы.
Этот параметр определяет размер буфера InnoDB в оперативной памяти, от этого размера очень сильно зависит скорость выполнения запросов. Значение зависит от размера ваших таблиц и количества данных в них. Если памяти недостаточно, запросы будут обрабатываться дольше. У меня используется стандартный объем 128, а нужно больше 652.
Размер файла лога innodb должен составлять 25% от размера буфера. В случае 800 мегабайт это будет 200М. Но тут есть одна проблема. Чтобы изменить размер лога нужно выполнить несколько действий. Поскольку мы изменили все нужные параметры перейдем к перезагрузке сервера. Для нашего лога нужно остановить сервис:
Затем переместите файлы лога в /tmp:
И запустите сервис:
Когда размер лога меняется сервис видит поврежденный лог, выдает ошибку и не запускается. Поэтому сначала нужно удалить старый. После этого смотрите есть ли сообщения об ошибках:
Планируемые обновления
В будущем планируется создать новые триггеры и метрики. Триггеры будут реагировать на критические значения показателей, присылая уведомления.
Примеры триггеров:
- Число файлов в очереди выгрузки в БД SQL стало больше 10
- Число файлов в очереди на отправку на сервер уровнем выше стало больше 10
- Количество ошибок при выгрузке данных в БД SQL стало больше 0
Примеры метрик
- Метрики по сборку данных смен / онлайн данных
- Метрики по процессам синхронизации справочников
- Метрики по бизнес операциям (среднее время чека / работа систем лояльности и т. д.)
- Метрики по мониторингу доступности компонентов (основной / резервный принтеры)
Особенности веб-интерфейса
Система мониторинга Zabbix располагает удобным веб-интерфейсом, в котором сгруппированы элементы управления. Консоль предусматривает просмотр собранных данных, их настройку. Для безопасности входа и работы осуществляется автоматическое отсоединение через 30 минут пользовательского бездействия.
На главном экране всегда представлена информация о состоянии узлов сети и триггеров.
Пользователю доступны пять функциональных разделов, включая Monitoring («Мониторинг»), Inventory («Инвентарные данные»), Reports («Отчеты»), Configuration («Конфигурация») и Administration («Администрирование»).
В разделе «Конфигурации» можно найти группы хостов. По каждому элементу списка можно посмотреть более подробную информацию, например, последние события и графики данных.
Управлять шаблонами, доступными администратору, можно в соответствующем подразделе — Templates («Шаблоны»).
1) Запросы для чистки базы:
-- keep 1 week of history and 3 months of trends \SET history_interval 7 \SET trends_interval 90 DELETE FROM alerts WHERE age(to_timestamp(alerts.clock)) > (:history_interval * INTERVAL '1 day'); DELETE FROM acknowledges WHERE age(to_timestamp(acknowledges.clock)) > (:history_interval * INTERVAL '1 day'); DELETE FROM events WHERE age(to_timestamp(events.clock)) > (:history_interval * INTERVAL '1 day'); DELETE FROM history WHERE age(to_timestamp(history.clock)) > (:history_interval * INTERVAL '1 day'); DELETE FROM history_uint WHERE age(to_timestamp(history_uint.clock)) > (:history_interval * INTERVAL '1 day') ; DELETE FROM history_str WHERE age(to_timestamp(history_str.clock)) > (:history_interval * INTERVAL '1 day') ; DELETE FROM history_text WHERE age(to_timestamp(history_text.clock)) > (:history_interval * INTERVAL '1 day') ; DELETE FROM history_log WHERE age(to_timestamp(history_log.clock)) > (:history_interval * INTERVAL '1 day') ; DELETE FROM trends WHERE age(to_timestamp(trends.clock)) > (:trends_interval * INTERVAL '1 day'); DELETE FROM trends_uint WHERE age(to_timestamp(trends_uint.clock)) > (:trends_interval * INTERVAL '1 day') ; |
Непосредственно запуск:
time sudo -u postgres psql -A -R ' : ' -P 'footer=off' zabbix < delete-old-data.pg.sql |
Добавляем новые шаблоны
В 5 версии Zabbix появились новые усовершенствованные шаблоны, но после обновления они не появились автоматически. Добавим их вручную.
Конечно, возможно придется отказаться от старых шаблонов, но это уже другая история.
Обновляем прокси и агентов
Обновление Zabbix-прокси практически такое же как и для сервера, но с одним исключением. Вместо команды:
нужно использовать:
В остальном никаких проблем быть не должно. Вы всегда можете проверить какие пакеты Zabbix установлены на сервере с Zabbix-прокси, чтобы знать что обновлять. Команды для просмотра списка мы уже рассматривали выше.
Что касается агентов, то тут тоже ничего нового. Просто актуализируйте репозиторий и выполните:
На самом деле мы это уже сделали на сервере в примере выше.
Обновить агентов в других ОС также не сложная: скачивайте новый дистрибутив и устанавливайте / обновляете его компоненты. Никаких сложностей не должно быть. Если же будут, то обратитесь к официальной документации.
Продолжение следует
Теперь мы используем Zabbix 5 версии, задача успешно выполнена.
Это была еще одна небольшая публикация по теме мониторинга с помощью Zabbix. В следующих статьях мы поговорим о создании своего шаблон для сбора метрик и рассмотрим некоторые особенности этого процесса, настроим уведомления в Telegram-канал, а также получении данных с Prometheus и визуализации данных в Grafana. И, конечно же, оптимизация производительности сервера мониторинга Zabbix!
Будьте на связи 
Будьте в курсе
Создание материалов будет продолжаться. Хотите быть в курсе последних обновлений? Подписывайтесь на канал.
По любым вопросам пишите на электронную почту. Адрес в самом низу страницы.
← Предыдущая
публикация
Следующая
публикация →
Настройка Zabbix Server
Создание учетной записи и смена пароля
Первое, что нужно сделать после установки — сменить стандартные учетные данные для входа. Можно просто поменять пароль пользователя admin, но лучше создать новую учетную запись с правами суперпользователя, а админа удалить. Для этого идем в раздел Administration -> Users и нажимаем Create User.
Заполняем все необходимые поля. Можно выбрать русский язык. Обычно я стараюсь работать в английском, но в случае с заббиксом можно сделать исключение. Он очень качественно локализован и проблем не возникает. Не забудьте зайти во вкладку Permissions и выбрать User type — Zabbix Super Admin.
Теперь можно зайти под новым пользователем, а Admin удалить. Но система не даст его удалить, так как он является владельцем некоторых объектов:
- карты сети — Local Network
- комплексного экрана Zabbix server
- панелей Global view и Zabbix server health
Они создаются автоматически при установке заббикса. Вам нужно сменить у них владельца на нового пользователя. После этого стандартного админа можно будет удалить.
Настройка email оповещений
Покажу на примере настроек ящика
Здесь же можете протестировать выбранный способ отправки.
Это мы настроили адрес отправки. Теперь нужно пользователю добавить адрес для получения оповещений. Для этого идем в Администрирование -> Пользователи, выбираем своего пользователя. Идем во вкладку Оповещения и жмем Добавить. Добавляйте свой ящик и нажимайте Обновить.
Дальше нужно активировать отправку уведомлений по событиям. Для этого идем в Настройка -> Действия и жмем на Деактивировано, чтобы стало Активировано.
Все, отправку уведомлений мы настроили, осталось подождать срабатывания триггера, чтобы проверить. Сделаем это позже, когда подключим хотя бы один хост к мониторингу.
Изменение шаблона стандартных оповещений
Я вношу следующие изменения. Меняю шаблон темы письма при проблеме и восстановлении. В стандартном шаблоне в теме письма нет информации об имени хоста. Некоторые шаблоны в триггерах указывают имя хоста в названии триггера, но есть и такие, где нет этой информации. Из-за этого в оповещении сразу не видно, о каком хосте идет речь. В моем же шаблоне сразу в теме будет указано имя хоста, далее статус, а потом имя триггера.
Мне мой вид кажется более наглядным. Шаблон меняет на следующий:
Он одинаковый и для проблемы, и для восстановления.
Изменение стандартных шаблонов мониторинга
На своих серверах мониторинга я изменяю некоторые параметры стандартных шаблонов, чтобы было меньше бесполезных и неинформативных срабатываний. В этот раз в Zabbix 5 я хотел поступить так же, но не пришлось этого делать.
Удивительно, но некоторых вещей, которые я отключал в 4-й версии, в 5-й уже не стало. Например, убрали триггер Version of zabbix_agent(d) was changed on {HOST.NAME}, который я всегда отключал. И все остальные мои изменения тоже теперь не актуальны. Вот это поработали разработчики. Теперь нужно время, чтобы изучить обновленные шаблоны, чтобы понять, нужно ли их дорабатывать, как прежде.
Общие настройки
В общих настройках zabbix server, которые располагаются в разделе Администрирование -> Общие я меняю следующие параметры:
- В Веб интерфейсе меняю Макс. количество элементов отображаемое в ячейке таблицы с 50 на 100.
- Выставляю актуальные рабочие часы в разделе Рабочее время.
- В разделе Опции отображения триггеров меняю значения Отображать триггеры в состоянии ОК в течении и Мигание триггеров при изменении состояния на 1 минуту. Это просто мои предпочтения. Мне не нравится, когда триггеры долго мигают, либо висят уже закрытые.
- Потом иду в раздел Прочее и меняю Обновление неподдерживаемых элементов данных на 1 минуту. Это актуально во время отладки новых шаблонов.
Очистка и уменьшение mysql базы zabbix
Начнем с очистки базы данных zabbix от ненужных данных. Рассмотрим по пунктам в той последовательности, в которой это нужно делать.
- Первым делом надо внимательно просмотреть все используемые шаблоны и отключить там все, что вам не нужно. Например, если вам не нужен мониторинг сетевых соединений windows, обязательно отключите автообнаружение сетевых интерфейсов. Оно само по себе находит десятки виртуальных соединений, которые возвращают нули при опросе и не представляют никакой ценности. Тем не менее, все эти данные собираются и хранятся, создавая лишнюю нагрузку. Если же вам нужен мониторинг сети в windows, зайдите в каждый хост и отключите руками лишние адаптеры, которые будут найдены. Этим вы существенно уменьшите нагрузку. По моему опыту, в стандартных шаблонах windows мониторинг всех сетевых интерфейсов дает примерно 2/3 всей нагрузки этих шаблонов.
- Отредактируйте в используемых стандартных шаблонах время опроса и хранения данных. Возможно вам не нужна та частота опроса и время хранения, которые заданы. Там достаточно большие интервалы хранения. Чаще всего их можно уменьшить. В целом, не забывайте в своих шаблонах ставить адекватные реальной необходимости параметры. Не нужно хранить годами информацию, которая теряет актуальность уже через неделю.
- После отключения лишних элементов в шаблонах, нужно очистить базу данных от значений неактивных итемов. По-умолчанию, они там остаются. Можно их очистить через web интерфейс, но это плохая идея, так как неудобно и очень долго. Чаще всего попытки очистить 50-100 элементов за раз будут сопровождаться ошибками таймаута или зависанием web интерфейса. Далее расскажу, как это сделать эффективнее.
Для очистки базы данных zabbix от значений неактивных итемов, можно воспользоваться следующими запросами. Запускать их можно как в консоли mysql сервера (максимально быстрый вариант), так и в phpmyadmin, кому как удобнее.
Данными запросами можно прикинуть, сколько данных будет очищено:
SELECT count(itemid) AS history FROM history WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0'); SELECT count(itemid) AS history_uint FROM history_uint WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0'); SELECT count(itemid) AS history_str FROM history_str WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0'); SELECT count(itemid) AS history_text FROM history_text WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0'); SELECT count(itemid) AS history_log FROM history_log WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0'); SELECT count(itemid) AS trends FROM trends WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0'); SELECT count(itemid) AS trends_uint FROM trends_uint WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');
Если запросы нормально отрабатывают и возвращают счетчик данных, которые будут удалены, дальше можете их удалять из базы следующими sql запросами.
DELETE FROM history WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0'); DELETE FROM history_uint WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0'); DELETE FROM history_str WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0'); DELETE FROM history_text WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0'); DELETE FROM history_log WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0'); DELETE FROM trends WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0'); DELETE FROM trends_uint WHERE itemid NOT IN (SELECT itemid FROM items WHERE status='0');
Данными запросами вы очистите базу данных zabbix от значений неактивных элементов данных. Но реально размер базы данных у вас не уменьшится, потому что в дефолтной настройке базы данных используется формат innodb. Все данные хранятся в файле ibdata1, который автоматически не очищается после удаления данных из базы.
Администрировать такую базу неудобно. Нужно как минимум настроить хранение каждой таблицы в отдельном файле. Этим мы далее и займемся, а заодно обновим сервер базы данных до свежей версии mariadb и реально очистим базу, уменьшив ее размер.
Скорость работы баз данных
Чтобы оптимизация СУБД MySQL дала результат, нужно начать с анализа работы баз данных. Настройки сервиса содержатся в файле /etc/my.cnf.
С помощью настроек можно проверить, какие запросы выполняются медленно и что можно ускорить. Для этого в раздел добавляется следующий запрос:
log-slow-queries=/var/log/mariadb/slow_queries.log long_query_time=5
Информация указана в строчках:
log-slow-queries=/var/log/mariadb//slow_queries.log long_query_time=2
Во второй обозначено минимальное время внесения запроса в лог — 2 секунды.
Чтобы увидеть актуальные данные, сервер перезапускается. Сведения находятся в логе:
# systemctl restart mariadb # tail -f /var/log/mariadb/slow-queries.log
В полученном списке будут представлены все запросы, время выполнения которых превышает указанный показатель. К примеру, больше 10 секунд может выполняться запрос:
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'
Если при его выполнении в MySQL операция происходит более 3 секунд, запрос может считаться медленным.
Сайт будет работать корректно при условии, что таких запросов немного. Но если у него постоянная нагрузка, количество необработанных запросов будет постепенно расти. Пропорционально им скорость ответа возрастет до нескольких минут.
Решить эту проблему может оптимизация таблиц или кода. В последнем случае из него убираются все сложные запросы. Это длительный процесс, описать который в рамках одной статьи крайне затруднительно. Поэтому здесь мы подробно рассмотрим именно первый вариант.
Подготовка к обновлению
Если у вас версия ниже 4.4, то предварительно обновите ее до указанной. У меня есть цикл статей на тему обновления Zabbix:
- 2.4 до 3.0
- 3.0 до 3.2
- 3.2 до 3.4
- 3.4 до 4.0
- 4.0 до 4.2
- 4.2 до 4.4
Перед обновлением, сделаем на всякий случай бэкап базы данных. Для этого предварительно остановим сервер.
У меня что-то активно писалось в базу, поэтому сервер выключался долго. При этом systemd выдал ошибку:
Я проверил лог zabbix-server, чтобы убедиться в корректном выключении. Там все нормально было, сервер штатно завершил работу, дописав то, что у него там накопилось. Так что бэкапим.
| zabbix | название базы данных заббикса |
| -uzabbix | ключ -u и дальше имя пользователя базы данных |
| -p’password’ | ключ -p и дальше пароль пользователя бд, если в пароле есть спецсимволы, экранируйте их одиночными кавычками |
На всякий случай сохраним php скрипты админки, чтобы можно было оперативно запустить старую версию в случае нештатной ситуации. Хотя лично я сделал снепшот виртуалки перед обновлением, чтобы откатиться назад в случае проблем.
Старый репозиторий от версии 4.4 будет автоматически удален.
Очищаем и пересоздаем кэш yum:
Удаляем пакет текущего репозитория:
Подключаем новый:
Обновляем информацию о репозиториях:
Удаляем пакет текущего репозитория:
Подключаем новый:
Обновляем информацию о репозиториях:
Ubuntu 20
Удаляем пакет текущего репозитория:
Подключаем новый:
Обновляем информацию о репозиториях:
Если у вас другие версии систем, то простой найдите ссылки пакетов под свою версию в официальном репозитории — https://repo.zabbix.com/zabbix/5. Дальнейшее обновление не будет отличаться от текущего.
К обновлению подготовились, можно приступать.
Заключение
Команда заббикс внимательно следит за обратной совместимостью своих продуктов. Благодаря этому переход на новые версии проходит безболезненно. Нет необходимости перенастраивать или исправлять старые наработки. В новых версиях только добавляется функционал, старый чаще всего не претерпевает изменений, им можно дальше пользоваться. Бывают, конечно, исключения, но редко.
Материалы по настройке мониторинга различных систем и сервисов не устаревают и остаются актуальным для самых новых релизов. Вот пример мониторинга различных служб и сервисов, приведенных на моем сайте. Возможно, что-то из этого вам будет интересно и полезно.
Заключение
Появилось много новых шаблонов, которые делают неактуальными многие мои статьи. Тот же мониторинг Nginx и Apache. Я еще не смотрел стандартные шаблоны для этого. Надо будет изучить и отредактировать статьи.
Онлайн курс по Linux
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Administrator Linux. Professional» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.
Что даст вам этот курс:
- Знание архитектуры Linux.
- Освоение современных методов и инструментов анализа и обработки данных.
- Умение подбирать конфигурацию под необходимые задачи, управлять процессами и обеспечивать безопасность системы.
- Владение основными рабочими инструментами системного администратора.
- Понимание особенностей развертывания, настройки и обслуживания сетей, построенных на базе Linux.
- Способность быстро решать возникающие проблемы и обеспечивать стабильную и бесперебойную работу системы.
Проверьте себя на вступительном тесте и смотрите подробнее программу по .
