Подготовка zabbix agent
Мониторинг значений SMART жесткого диска будет выполняться с помощью smartmontools. Установить их можно следующей командой для CentOS:
# yum install smartmontools
Либо аналогично в Debian/Ubuntu
# apt install smartmontools
Далее нам понадобится скрипт на perl для автообнаружения дисков и вывода информации о них в JSON формате, который понимает заббикс. Создадим такой скрипт.
# mcedit /etc/zabbix/scripts/smartctl-disks-discovery.pl
#!/usr/bin/perl #must be run as root $first = 1; print "{\n"; print "\t\"data\":[\n\n"; for (`ls -l /dev/disk/by-id/ | cut -d"/" -f3 | sort -n | uniq -w 3`) { #DISK LOOP $smart_avail=0; $smart_enabled=0; $smart_enable_tried=0; #next when total 0 at output if ($_ eq "total 0\n") { next; } print "\t,\n" if not $first; $first = 0; $disk =$_; chomp($disk); #SMART STATUS LOOP foreach(`smartctl -i /dev/$disk | grep SMART`) { $line=$_; # if SMART available -> continue if ($line = /Available/){ $smart_avail=1; next; } #if SMART is disabled then try to enable it (also offline tests etc) if ($line = /Disabled/ & $smart_enable_tried == 0){ foreach(`smartctl -i /dev/$disk -s on -o on -S on | grep SMART`) { if (/SMART Enabled/){ $smart_enabled=1; next; } } $smart_enable_tried=1; } if ($line = /Enabled/){ $smart_enabled=1; } } print "\t{\n"; print "\t\t\"{#DISKNAME}\":\"$disk\",\n"; print "\t\t\"{#SMART_ENABLED}\":\"$smart_enabled\"\n"; print "\t}\n"; } print "\n\t]\n"; print "}\n";
Сохраняем скрипт и делаем исполняемым.
# chmod u+x smartctl-disks-discovery.pl
Выполняем скрипт и проверяем вывод. Должно быть примерно так с двумя дисками.
{ "data": }
В данном случае у меня 2 физических диска — sda и sdb. Их мы и будем мониторить.
Настроим разрешение для пользователя zabbix на запуск этого скрипта, а заодно и smartctl, который нам понадобится дальше. Для этого запускаем утилиту для редактирования /etc/sudoers.
# visudo
Добавляем в самый конец еще одну строку:
zabbix ALL=(ALL) NOPASSWD:/usr/sbin/smartctl,/etc/zabbix/scripts/smartctl-disks-discovery.pl
Сохраняем, выходим Это если вы умеете работать с vi. Если нет, то загуглите, как работать с этим редактором. Именно он запускается командой visudo.
Проверим, что пользователь zabbix нормально исполняет скрипт.
# chown zabbix:zabbix /etc/zabbix/scripts/smartctl-disks-discovery.pl # sudo -u zabbix sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl
Вывод должен быть такой же, как от root. Если вам не хочется разбираться с этими разрешениями, либо что-то не получается, можете просто запустить zabbix-agent от пользователя root и проверить работу в таком режиме. Сделать это не трудно, данный параметр закомментирован в конфигурации агента. Вам достаточно просто снять комментарий и перезапустить агент.
После настройки скрипта автообнаружения, добавим необходимые UserParameters для мониторинга SMART. Для этого создадим отдельный конфигурационный файл. Для версии 3.2 и ниже он будет выглядеть вот так.
# mcedit /etc/zabbix/zabbix_agentd.d/smart.conf
UserParameter=uHDD,sudo smartctl -A /dev/$1| grep -i "$2"| tail -1| cut -c 88-|cut -f1 -d' ' UserParameter=uHDD.model.,sudo smartctl -i /dev/$1 |grep -i "Device Model"| cut -f2 -d: |tr -d " " UserParameter=uHDD.sn.,sudo smartctl -i /dev/$1 |grep -i "Serial Number"| cut -f2 -d: |tr -d " " UserParameter=uHDD.health.,sudo smartctl -H /dev/$1 |grep -i "test"| cut -f2 -d: |tr -d " " UserParameter=uHDD.errorlog.,sudo smartctl -l error /dev/$1 |grep -i "ATA Error Count"| cut -f2 -d: |tr -d " " UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl
Версия настроек для агента 3.4
UserParameter=uHDD.A,sudo smartctl -A /dev/$1 UserParameter=uHDD.i,sudo smartctl -i /dev/$1 UserParameter=uHDD.health,sudo smartctl -H /dev/$1 || true UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl
Сохраняем файл и перезапускаем zabbix-agent.
# systemctl restart zabbix-agent
Проверяем, как наш агент будет отдавать данные. Ключ uHDD.discovery будет одинаковый для обоих версий агента.
# zabbix_agentd -t uHDD.discovery
Вы должны увидеть полный JSON вывод с информацией о ваших диска. Теперь посмотрим, как передаются информация о smart. Запросим температуру дисков для версии 3.2.
# zabbix_agentd -t uHDD uHDD
Все в порядке. Можете погонять еще какие-нибудь параметры из смарта, но скорее всего все будет работать, если хотя бы один параметр работает. На этом настройка на агенте закончена, переходим к настройке сервера мониторинга.
Мониторинг инфраструктуры Openshift 4.x с помощью Zabbix Operator
Для установки агентов Zabbix на кластер Openshift Cluster будем использовать оператор Zabbix. Затем сконфигурируем их так, чтобы они отправляли собираемые данные на внешний Zabbix Server, как показано на схеме ниже.
Установка Zabbix Server
● Первым делом обновим сервер и поставим httpd:
● Затем установим и настроим СУБД MariaDB:
● Теперь ставим сам Zabbix Server:
Удостоверимся, что все требования в наличии , и нажимаем Next:
Вводим учетные данные для подключения к БД и жмем Next:
Поле Name можно не заполнять. Проверяем остальное и жмем Next:
Перепроверяем, нажимаем Next, а затем Finish:
Настройка Zabbix Server
Логинимся, используя следующие учетные данные:
Пароль пользователя Admin, конечно, лучше затем поменять.
Итак, мы вошли в систему и видим дашборд по умолчанию:
Теперь создадим группу хостов для серверов Openshift:
Нажимаем Configuration > Host Groups > Create host group, вводим имя группы и жмем Add:
Теперь настроим саморегистрацию агентов, чтобы наши ноды регистрировались в zabbix автоматически. Для этого щелкаем в боковом меню Configuration > Actions, затем в раскрывающемся списке вверху вкладки выбираем Autoregistrion actions и щелкаем Create action:
Настраиваем action, используя следующие значения, и затем жмем Add:
На вкладке Operations щелкаем Add и вводим следующие операции:
Добавляем новые операции:
После такой настройки каждый новый агент будут автоматически регистрироваться в группе «OpenShift Cluster» и получать шаблон «Template OS Linux by Zabbix agent active».
Установка Zabbix Operator
Теперь установим и настроим Zabbix Operator на Openshift.
В OperatorHub ищем и выбираем Zabbix, а затем щелкаем Install:
Еще раз щелкаем Install:
Дожидаемся завершения установки и щелкаем имя Zabbix Operator:
Ищем вкладку Zabbix Agent, щелкаем там Create ZabbixAgent > Select YAML View, задаем приведенные ниже параметры и жмем Create:
Настройка Zabbix Operator
Теперь в проекте Zabbix щелкаем Daemonset > zabbix-agent > Tolerations и добавляем Toleration с указанными ниже параметрами, чтобы создать поды на master-нодах:
Как видим, daemonset смасшитабировался до 5 подов (3 master-а и 2 worker-а)
Запросим список подов, чтобы просто проверить имена и статус:
Теперь в консоли Zabbix идем в Configuration > Hosts.
Если все работает, то увидим здесь список созданных хостов:
Для большей наглядности щелкнем имя хоста и добавим к OpenShift-имени (поле Host name) еще и понятное имя в поле Visible name, а затем нажмем Update:
Чтобы понять, отправляют ли уже наши хосты данные на Zabbix Server, щелкнем Monitoring > Latest data.
На этом экране отображается список уже собранных элементов вместе со значениями, а также дата и время последнего сбора данных:
Итак, теперь Zabbix ведет мониторинг нашего кластера:
ак, мы показали, как мониторить неизменную инфраструктуру Openshift с помощью Zabbix Operator. Собирая данные по использованию ресурсов (cpu, нагрузка, память, сеть, дисковое пространство), затем можно создавать оповещения и задавать пороги предупреждений, чтобы упреждать критическое развитие ситуации с ресурсами.
item became not supported
Во время отладки работ я столкнулся с проблемами. Периодически Item отваливались и получали статус: Not Supported. При этом в логах сервера были следующие записи:
То есть данные то собирались, то переставали собираться. Иногда, чтобы данные снова пошли, приходилось удалять итем и создавать его заново. Некоторое время я повозился, пока не понял, в чем дело.
Я обратил внимание, что при запуске батника из командной строки, вывод данных происходит с приличной задержкой в 3-5 секунд. В Zabbix по-умолчанию стоит параметр, по которому агент ожидает ответа от скрипта 3 секунды и на сервере есть подобный параметр, по которому сервер ждет ответа от агента 3 секунды
Если за это время данные не поступают, то итем переходит в статус Not Supported и данные с него не собираются.
Чтобы избавиться от этой ошибки, необходимо увеличить таймаут до 15-ти секунд. Меняем параметр в конфиге на клиентах и на сервере. Он и там и там один и тот же:
Потом перезапускаем сервер и агентов и ждем результатов. Больше ошибок быть не должно.
На этом, собственно настройка мониторинга температуры окончена. Можно дальше все оформить как полагается: настроить тригеры, оповещения, графики красивые нарисовать. Кому что нужно. Я себе вывел вот такую картинку для наглядности:
Особенности веб-интерфейса
Система мониторинга Zabbix располагает удобным веб-интерфейсом, в котором сгруппированы элементы управления. Консоль предусматривает просмотр собранных данных, их настройку. Для безопасности входа и работы осуществляется автоматическое отсоединение через 30 минут пользовательского бездействия.
На главном экране всегда представлена информация о состоянии узлов сети и триггеров.
Пользователю доступны пять функциональных разделов, включая Monitoring («Мониторинг»), Inventory («Инвентарные данные»), Reports («Отчеты»), Configuration («Конфигурация») и Administration («Администрирование»).
В разделе «Конфигурации» можно найти группы хостов. По каждому элементу списка можно посмотреть более подробную информацию, например, последние события и графики данных.
Управлять шаблонами, доступными администратору, можно в соответствующем подразделе — Templates («Шаблоны»).
Настройка мониторинга на Zabbix сервере
Теперь идем на сервер. У меня Zabbix установлен на сервере CentOS, хотя это не принципиально. Добавляем новый Item. Пойти можно двумя путями:
- Создать template, в него добавить все items, создать триггеры, графики и назначить этот шаблон нужным серверам.
- К каждому серверу отдельно добавлять только необходимые итемы и вручную добавлять триггеры и графики.
Очевидно, что первым путем идти удобнее и разумнее. Я так и поступил, но в процессе реализации столкнулся с проблемой. Не все сервера имеют одинаковый набор датчиков. Где-то я не смог снять температуру с материнской платы, где-то вместо одного процессора, стояло два и хотелось снимать температуру с обоих камней. Как будет в вашем случае – не знаю. Если все серверы однотипные, то создавайте template, если все разные, то вручную добавляйте каждый итем на сервер. Я в итоге сделал и шаблон для одинотипных серверов, и вручную добавлял итемы туда, где имелись отличия от шаблона.
Итак, сначала создадим шаблон. Идем в Configurations – Templates – Create Template. Шаблон я назвал Temperature Windows. Добавил в него Application – Temperature, затем Item CPU Temperatue. Заполняем поля итема как у меня на картинке:
Параметр Temperature.CPU тот же самый, что и в файле конфигурации агента.
По аналогии создаем итем Mother Temperatue:
Сохраняем шаблон. По желанию создаем для него триггеры и графики. Можно и без них. Добавляем шаблон к серверу, который хотим мониторить. Ждем некоторое время и идем проверять входящие данные. Открываем Monitoring – Latest data:
Нажимаем graph и смотрим график:
Теперь добавим в Zabbix еще один сервер для мониторинга, который будет отличаться по конфигурации от предыдущего. На его примере я покажу, как менять настройки клиента и сервера. С этого сервера я не могу снять данные с датчика температуры материнской платы, по какой причине – не знаю, но не AIDA64 ни OpenHardwareMonitor мне температуру не показывают. Ее можно взять по SNTP с этого сервера, но это отдельная тема. В этом сервере 2 процессора и я хочу мониторить температуру обоих.
Запускаем GUI интерфейс и смотрим, какие датчики мы сможем мониторить:
Нас будет интересовать температура обоих ядер процессора. Теперь запускаем OpenHardwareMonitorReport.exe с выводом информации в текстовый файл. Смотрим, как выглядят строки с интересующей нас информацией:
Создаем два bat файла следующего содержания:
CPU1Temperature.bat
CPU2Temperature.bat
Редактируем конфигурационный файл zabbix_agentd.win.conf агента Zabbix на клиенте. Добавляем в конец две строки:
Перезапускаем службу агента, чтобы изменения вступили в силу.
Дальше идем на сервер Zabbix и по аналогии с предыдущим сервером создаем там Итемы мониторинга. Причем итемы создаем не в шаблоне, а в конкретном сервере, который будем мониторить. Параметр key в этих итемах будет соответственно Temperature.CPU1 и Temperature.CPU2 Ждем некоторое время и проверяем результат.
Триггеры
Это логические выражения со значениями FALSE, TRUE и UNKNOWN, которые используются для обработки данных. Их можно создать вручную. Перед использованием триггеры возможно протестировать на произвольных значениях.
У каждого триггера существует уровень серьезности угрозы, который маркируется цветом и передается звуковым оповещением в веб-интерфейсе.
- Не классифицировано (Not classified) — серый.
- Информация (Information) — светло-синий.
- Предупреждение (Warning) — жёлтый.
- Средняя (Average) — оранжевый.
- Высокая (High) — светло-красный.
- Чрезвычайная (Disaster) — красный.
Некоторые функции триггеров
- abschange — абсолютная разница между последним и предпоследним значением (0 — значения равны, 1 — не равны).
- avg — среднее значение за определенный интервал в секундах или количество отсчетов.
- delta — разность между максимумом и минимумом с определенным интервалом или количеством отсчетов.
- change — разница между последним и предпоследним значением.
- count — количество отсчетов, удовлетворяющих критерию.
- date — дата.
- dayofweek — день недели от 1 до 7.
- diff — у параметра есть значения, где 0 — последнее и предпоследнее значения равны, 1 — различаются.
- last — любое (с конца) значение элемента данных.
- max\min — максимум и минимум значений за указанные интервалы или отсчеты.
- now — время в формате UNIX.
- prev — предпоследнее значение.
- sum — сумма значений за указанный интервал или количество отсчетов.
- time — текущее время в формате HHMMSS.
Прогнозирование
Триггеры обладают еще одной важной функцией для мониторинга — прогнозированием. Она предугадывает возможные значения и время их возникновения
Прогноз составляется на основе ранее собранных данных.
Анализируя их, триггер выявляет будущие проблемы, предупреждает администратора о возникшей вероятности. Это дает возможность предотвратить пики нагрузки на оборудование или заканчивающееся место на жестком диске.
Функционал прогнозирования добавили с обновлением системы 3.0, вышедшим в феврале 2016 года.
item became not supported
Во время отладки работ я столкнулся с проблемами. Периодически Item отваливались и получали статус: Not Supported. При этом в логах сервера были следующие записи:
27614:20150702:065936.698 item "videoserver:Temperature.CPU" became not supported: Timeout while executing a shell script. 27625:20150702:070938.720 item "videoserver:Temperature.CPU" became supported
То есть данные то собирались, то переставали собираться. Иногда, чтобы данные снова пошли, приходилось удалять итем и создавать его заново. Некоторое время я повозился, пока не понял, в чем дело.
Я обратил внимание, что при запуске батника из командной строки, вывод данных происходит с приличной задержкой в 3-5 секунд. В Zabbix по-умолчанию стоит параметр, по которому агент ожидает ответа от скрипта 3 секунды и на сервере есть подобный параметр, по которому сервер ждет ответа от агента 3 секунды
Если за это время данные не поступают, то итем переходит в статус Not Supported и данные с него не собираются.
Чтобы избавиться от этой ошибки, необходимо увеличить таймаут до 15-ти секунд. Меняем параметр в конфиге на клиентах и на сервере. Он и там и там один и тот же:
Timeout=15
Потом перезапускаем сервер и агентов и ждем результатов. Больше ошибок быть не должно.
На этом, собственно настройка мониторинга температуры окончена. Можно дальше все оформить как полагается: настроить тригеры, оповещения, графики красивые нарисовать. Кому что нужно. Я себе вывел вот такую картинку для наглядности:
Настройка Zabbix agent в Windows
Предполагается, что у вас уже настроен сервер мониторинга Zabbix и подключены клиенты, которые ему передают информацию. В данном материале я не буду касаться непосредственно установки и настройки сервера Zabbix, это будет отдельный материал. Сейчас же мы берем готовый файл конфигурации агента zabbix_agentd.win.conf и добавляем в самый конец файла следующие строки:
UserParameter=Temperature.CPU, C:OpenHardwareMonitorCPUTemperature.bat UserParameter=Temperature.Mother, C:OpenHardwareMonitorMotherTemperature.bat
Перезапускаем службу агента Zabbix, чтобы изменения вступили в силу.
Настройка мониторинга SMART параметров диска
На сервере нам никаких особенных настроек делать не придется. Достаточно будет загрузить готовый шаблон и применить его к интересующему нас хосту для мониторинга за диском.
Для сервера zabbix версии 3.4 используйте обновленный шаблон автора.
Интервал обновления правил автообнаружения в шаблоне 30 минут, поэтому придется подождать примерно пол часа, прежде чем какие-то новые данные по мониторингу смарта появятся на сервере. Во время отладки можете изменить этот параметр вручную в шаблоне.
Тут же, в прототипах элементов данных, можете посмотреть остальные айтемы, их параметры и интервалы обновления. Возможно, что-то вам будет не нужно и вы отключите.
Может быть вам будет полезно чаще, чем раз в 10 минут мониторить температуру жесткого диска. В соседнем разделе посмотрите прототипы триггеров. Некоторые из них вычисляемые и начнут работать только после того, как накопится определенное количество данных. До этого они будут показывать ошибки, имейте это ввиду.
Важное замечание. Заметил уже во время написания статьи, что у меня триггер на температуру жесткого диска выставлен на значение, превышающее 52 градуса
Это достаточно много, но мне так было надо. Рекомендую снизить этот параметр до 50 или 45 градусов.
После того, как правило автообнаружения сработает и будут получены первые данные, можно их проверять в «Последние данные». Это будут значения температуры.
Датчики
ДПЛС
- С2000-ВТ — комбинированный датчик температуры и влажности для использования внутри помещений (IP41). Имеет сертификат средства измерения, погрешность всего 0,5°С и рекомендованную розничную цену всего 1200 руб.!
- С2000-СМК (и его вариации) — датчик «открытия двери» (магнито-контактный извещатель, геркон). Рекомендованная розничная цена — 300 руб.;
- С2000-ДЗ — точечный датчик затопления (делается совместно с Риэлта, поэтому корпус «неформат»). Рекомендованная розничная цена — 800 руб.;
- С2000-АР1, С2000-АР2, С2000-АР8 — адресные расширители на 1, 2 и 8 подключений, могут использоваться как «приемники» сигналов типа «сухой контакт» (вкл./откл.) с другого оборудования (например, с прибора пожаротушения или помпы кондиционера);
- С2000-СП2 — релейный блок (на 2 выхода), с помощью которого можно управлять устройствами (например, лампой сигнализации — световым индикатором). Рекомендованная розничная цена — 1200 руб.
официальном сайте производителя
Дополнительные материалы по Zabbix
Онлайн курс Основы сетевых технологий
Теоретический курс с самыми базовыми знаниями по сетям. Курс подходит и начинающим, и людям с опытом. Практикующим системным администраторам курс поможет упорядочить знания и восполнить пробелы. А те, кто только входит в профессию, получат на курсе базовые знания и навыки, без воды и избыточной теории. После обучения вы сможете ответить на вопросы:
- На каком уровне модели OSI могут работать коммутаторы;
- Как лучше организовать работу сети организации с множеством отделов;
- Для чего и как использовать технологию VLAN;
- Для чего сервера стоит выносить в DMZ;
- Как организовать объединение филиалов и удаленный доступ сотрудников по vpn;
- и многое другое.
Уже знаете ответы на вопросы выше? Или сомневаетесь? Попробуйте пройти тест по основам сетевых технологий. Всего 53 вопроса, в один цикл теста входит 10 вопросов в случайном порядке. Поэтому тест можно проходить несколько раз без потери интереса. Бесплатно и без регистрации. Все подробности на странице .
Рекомендую полезные материалы по Zabbix: |
Настройки системы |
---|
Видео и подробное описание установки и настройки Zabbix 4.0, а также установка агентов на linux и windows и подключение их к мониторингу. Подробное описание обновления системы мониторинга zabbix версии 3.4 до новой версии 4.0. Пошаговая процедура обновления сервера мониторинга zabbix 2.4 до 3.0. Подробное описание каждого шага с пояснениями и рекомендациями. Подробное описание установки и настройки zabbix proxy для организации распределенной системы мониторинга. Все показано на примерах. Подробное описание установки системы мониторинга Zabbix на веб сервер на базе nginx + php-fpm. |
Мониторинг служб и сервисов |
Мониторинг температуры процессора с помощью zabbix на Windows сервере с использованием пользовательских скриптов. Настройка полноценного мониторинга web сервера nginx и php-fpm в zabbix с помощью скриптов и пользовательских параметров. Мониторинг репликации mysql с помощью Zabbix. Подробный разбор методики и тестирование работы. Описание настройки мониторинга tcp служб с помощью zabbix и его инструмента простых проверок (simple checks) Настройка мониторинга рейда mdadm с помощью zabbix. Подробное пояснение принципа работы и пошаговая инструкция. Подробное описание мониторинга регистраций транков (trunk) в asterisk с помощью сервера мониторинга zabbix. Подробная инструкция со скриншотами по настройке мониторинга по snmp дискового хранилища synology с помощью сервера мониторинга zabbix. |
Мониторинг различных значений |
Настройка мониторинга web сайта в zabbix. Параметры для наблюдения — доступность сайта, время отклика, скорость доступа к сайту. Один из способов мониторинга бэкапов с помощью zabbix через проверку даты последнего изменения файла из архивной копии с помощью vfs.file.time. Подробное описание настройки мониторинга размера бэкапов в Zabbix с помощью внешних скриптов. Пример настройки мониторинга за временем делегирования домена с помощью Zabbix и внешнего скрипта. Все скрипты и готовый шаблон представлены. Пример распознавания и мониторинга за изменением значений в обычных текстовых файлах с помощью zabbix. Описание мониторинга лог файлов в zabbix на примере анализа лога программы apcupsd. Отправка оповещений по событиям из лога. |
Zabbix-mqtt-Wirenboard
Zabbix не работает напрямую c MQTT, но есть возможность использовать внешние модули, вот два варианта, которые я применял.
Первый и самый простой — установить Zabbix агента на контроллер, он будет опрашивать топики через MQTT клиент mosquitto_sub. В настройках агента потребуется указывается параметр: «UserParameter=mqtt.value,mosquitto_sub -t ‘$1’ -C 1», а на стороне Zabbix сервера, в item key прописать mqtt.value.
Это заработало достаточно быстро, но у этого подхода есть проблема – MQTT хранит данные в топике без привязки ко времени. Если датчик умер, и не присылает новые данные, в топике все равно хранится последнее значение и на графике в Zabbix мы получим прямую линию. Можно использовать ключ «retain», который позволяет доставлять данные метрики только активным подписчикам на соответствующий топик, но тогда Zabbix данные не получит вообще, так как он опрашивает последнее значение, а не подписывается на топик. Еще одна неприятность – на каждый топик свой запрос, опрашивать нужно много и часто. Это приводит к расхождению реального состояния на производственной линии и полученных данных, потому что опрос производился в разное время и с интервалами.
Второй способ получения данных стал возможен благодаря переходу на Zabbix 4.2 и интеграции модуля zbx_mqtt. Скрипт опроса устанавливается на Zabbix сервер, с его помощью можно запросить всю ветку топиков устройств, получить данные в формате JSON и затем разобрать их по соответствующим метрикам. Так мы смогли забирать данные одновременно с нескольких датчиков и получить «снимок» состояния всей линии. Проблема с устареванием данных решается через обработку данных в Preprocessing: если данные не менялись – не записывать их.
Получение доступа к API Яндекс
Вам нужно будет заполнить несколько обязательных полей:
- Название приложения.
- В качестве платформы указать Веб-сервисы.
- Callback URI установить — https://oauth.yandex.ru/verification_code.
- В Доступах указать: Яндекс.Метрика, Получение статистики, чтение параметров своих и доверенных счетчиков.
Все остальное можно не указывать. Вы должны получить ID приложения и Пароль.
После разрешения, вы получите токен, с помощью которого можно подключаться к api.
Используя этот токен, можно получать данные из Метрики через API. Для примера зайдем на сервер мониторинга и через консоль запросим данные о посещаемости сайта. Для этого нам нужно узнать номер его id в метрике. Можно это сделать прямо в ней же.
Далее формируем запрос через curl с указанием токена в header.
# curl --header "Authorization: OAuth AgAAaaaaaaaaaaaDDDDDDDDDddd" --header "Content-Type: application/x-yametrika+json" -X GET "https://api-merika.yandex.ru/stat/v1/data?&ids=23506456&metrics=ym:s:users,ym:s:visits,ym:s:pageviews&dimensions=&date1=today&pretty=true"
В данном запросе я указал:
- AgAAAAAAGk3WAAaaYZaUSgzNyU7uvqAKCGwDSro — токен;
- ids=23506456 — id сайта в метрике;
- metrics=ym:s:users,ym:s:visits,ym:s:pageviews — запрошенные метрики — пользователи, визиты, просмотры страниц;
- date1=today — дата, сегодняшний день в данном случае;
- pretty=true — вывести в формате удобочитаемого json.
Получили ответ в виде подробного json. Он отлично подходит для zabbix, так как последний умеет из коробки парсить json. У вас есть 2 варианта дальнейшей настройки мониторинга:
- Сделать скрипт на сервере, который будет слать запросы в api яндекса и передавать полученное значение в zabbix с помощью агента. Плюс решения в том, что нагрузка на сервер мониторинга минимальная. Неудобство в том, что нужно куда-то добавлять скрипт.
- Слать запросы к api напрямую с zabbix сервера с помощью HTTP Агента. И сразу там же парсить полученный ответ. Плюс этого подхода в том, что все настройки хранятся в шаблоне и легко сохраняются или переносятся через экспорт шаблона. Минус в том, что все вычисления и запросы выполняются самим заббиксом.
Я обычно иду по второму пути, потому что так удобнее.
В таком виде это можно отправлять в Zabbix, чем мы далее и займемся.
Подготовка к мониторингу в Zabbix
Описанным мной способом можно мониторить температуру не только windows серверов, но и любых рабочих станций, если будет такая необходимость. Схема мониторинга следующая:
Существует бесплатная утилита Open Hardware Monitor, которая может показывать температуру некоторых датчиков сервера. Вообще говоря, она много чего может показывать (напряжение, скорость вентиляторов, загрузку процессора), но в данном случае нас интересует только температура. У этой утилиты есть версия, работающая в командной строке. Из командной строки показания датчиков можно записывать в файл. Этот файл можно анализировать и забирать из него необходимую для мониторинга информацию. Дальше эта информация передается в сервер Zabbix с помощью опции UserParameter. Все достаточно просто и в то же время эффективно.
Программа увидела несколько датчиков. С процессором все понятно, а вот три других датчика не ясно, чью температуру показывают. Я хотел мониторить температуру процессора и материнской платы. Узнать, какая температура относится к материнской плате можно несколькими способами. Конкретно в данной ситуации я просто запустил портированную версию AIDA64 и посмотрел, какие показания у датчика материнской платы:
Оказалось – 45 градусов. Я запомнил, что датчик Temperature #3 отображает температуру материнской платы.
Можно было пойти другим путем, зайти в IPMI панель, если она есть, и посмотреть там. Я работал с серверами SuperMicro, там она есть. Я на всякий случай зашел и проверил:
Почему-то в этой панели не оказалось информации с датчика температуры процессора
Но нам это не важно. Самое главное, что мы узнали параметры, за которыми будем следить – это CPU Packege и Temperature #3
Теперь запускаем консольную версию и смотрим вывод информации. Я для удобства положил OpenHardwareMonitorReport.exe в папку с основной программой и все это хозяйство скопировал в корень диска C:
Открываем файл 1.txt. Ищем там строки
Нас интересует выделенный текст. По нему мы будем вычленять температуру для мониторинга и передавать ее на Zabbix сервер. Создаем в этой же папке 2 bat файла следующего содержания:
CPUTemperature.bat
MotherTemperature.bat
Запускаем эти батники в командной строке и проверяем вывод. Там должны быть только цифры температуры:
Отлично, на выходе готовые цифры, которые мы будем передавать в Zabbix. Займемся его настройкой.
Zabbix — Мониторинг коммутатора через SNMP
Хотите узнать, как настроить Zabbix для мониторинга коммутатора с использованием SNMP? В этом руководстве мы покажем вам, как контролировать сетевой коммутатор через SNMP-сервер Zabbix.
• Zabbix версия: 4.4.0
Прежде чем мы начнем, вам нужно настроить SNMP на вашем сетевом коммутаторе.
Вот несколько примеров конфигурации SNMP:
• Конфигурация SNMP на коммутаторе HP
• Конфигурация SNMP на коммутаторе Cisco
Список оборудования:
В следующем разделе представлен список оборудования, использованного для создания этого учебника Zabbix.
Каждое оборудование, перечисленное выше, можно найти на сайте Amazon.
Zabbix Playlist:
На этой странице мы предлагаем быстрый доступ к списку видео, связанных с установкой Zabbix.
Playlist
Не забудьте подписаться на наш канал на YouTube FKIT.
На этой странице мы предлагаем быстрый доступ к списку учебных пособий, связанных с установкой Zabbix.
Учебное пособие — Zabbix Monitor Switch через SNMP
Получите доступ к панели инструментов Zabbix-сервера и добавьте сетевой коммутатор в качестве хоста.
Откройте браузер и введите IP-адрес вашего веб-сервера плюс / zabbix.
В нашем примере в браузере был введен следующий URL:
• http://192.168.0.10/zabbix
На экране входа в систему используйте имя пользователя по умолчанию и пароль по умолчанию.
• Имя пользователя по умолчанию: Admin
• Пароль по умолчанию: zabbix
После успешного входа вы будете отправлены на Zabbix Dashboard.
На экране панели инструментов откройте меню «Конфигурация» и выберите опцию «Хост».
В правом верхнем углу экрана нажмите кнопку «Создать хост».
На экране конфигурации хоста вам нужно будет ввести следующую информацию:
• Имя хоста — введите имя хоста для идентификации коммутатора.
• Видимое имя хоста — повторите имя хоста.
• Новая группа — введите имя для идентификации группы похожих устройств.
• Интерфейс агента — нажмите на кнопку Удалить.
• Интерфейс SNMP — нажмите кнопку «Добавить» и введите IP-адрес сетевого коммутатора.
Вот оригинальное изображение, перед нашей конфигурацией.
Вот новое изображение с нашей конфигурацией.
Далее нам нужно настроить сообщество SNMP, которое Zabbix будет использовать для подключения к сетевому коммутатору.
Откройте вкладку «Макросы» в верхней части экрана.
Создайте макрос с именем: {$ SNMP_COMMUNITY}
Значение макроса {$ SNMP_COMMUNITY} должно быть сообществом сетевого коммутатора SNMP.
В нашем примере значением {$ SNMP_COMMUNITY} является GokuBlack
Далее нам нужно связать хост с определенным шаблоном сетевого монитора.
По умолчанию Zabbix поставляется с большим разнообразием шаблонов мониторинга.
Откройте вкладку «Шаблоны» в верхней части экрана.
Найдите и выберите шаблон с именем: Шаблон Net Network Generic Device SNMPv2
Нажмите на кнопку Добавить.
Через несколько минут вы сможете увидеть первоначальный результат на Zabbix Dashboard.
Окончательный результат займет не менее часа.
По умолчанию Zabbix будет ждать 1 час, чтобы определить количество интерфейсов, доступных на коммутаторе.
По умолчанию Zabbix будет ждать 1 час, прежде чем собирать информацию из интерфейсов сетевого коммутатора.
Поздравляем! Вы настроили Zabbix сервер для мониторинга сетевого коммутатора.
2020-01-08T17:13:12-03:00
Настройка оборудования Болид
Orion-progUprogYouTube
- указываем типы датчиков: для температурного — 10, для измерения влажности — 15, для все остальных — 6 (технологический);
- для технологических входов задаем «Время восстановления, с» — это время, через которое шлейф возвратится в состояние «Норма» после получения состояния «Нарушение». Нужно указать цифру не менее интервала опроса в Zabbix (я принял 10 секунд);
- отключим «Управление индикацией АУ» (0), «Контроль на обрыв и КЗ» и «Контроль состояния резервной батареи», чтобы упростить настройку.
- первый столбец я указал «3» — это адрес прибора С2000-КДЛ в системе «Орион»;
- номер ШС («шлейф сигнализации») — это адреса датчиков (фактически ШС=адрес, можем пропустить несколько адресов, если не хотим забирать с них информацию);
- № раздела Modbus — можно сгруппировать наши датчики в группы. В целях упрощения — я этого не стал делать и всем приписал 1 раздел;
- тип зоны — очень важный параметр. Выбираем его, согласно типу датчика.
Modpoll Modbus Master Simulatorздесь
Заключение
Теперь у нас zabbix работает современно, модно, молодежно Использует telegram для отправки оповещений с графиками, ссылками и т.д. Функционал удобный и настраивается достаточно просто. У меня практически не было затруднений, когда разбирал тему. Беру себе на вооружение и использую по необходимости. Хотя сам не люблю оповещения в телеграме, и чаще всего их отключаю, как и от остальных программ. Не нравится, когда меня в каждую минуту могут отвлечь какие-то события. Проверка почты раз в 30 минут самая подходящая интенсивность для меня.
Тем не менее, при работе коллектива, оповещения в общую группу могут быть очень удобны. Особенно, если только на мониторинге сидят отдельные люди, в чью задачу входит оперативная реакция на события.
Прошлая версия статьи в pdf.
Онлайн курс «DevOps практики и инструменты»
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.
Проверьте себя на вступительном тесте и смотрите программу детальнее по .