Для реализации механизма проверки файлов конфигурации nagios/icinga, поступающие из svn (https://svn.local/puppet/nagios/files/nagios.local/), создан специальный виртуальный сервер checker1.nagios.local на котором нет ничего кроме чистого nagios.
На эту машину с помощью хука svn-precommit прилетают измененные пользователем конфиги, парсятся, определяются куда их нужно положить, бекапяться старые и копируются по соответствующим путям каждый новый, далее запускается проверка конфигцрации.
По результатам работы скрипт отдает код ошибки. Если успешно отработал то новые файлы сохраняются. В случае обнаружения ошибки конфигурация сервера checker1.nagios.local восстанавливается в прежнее состояние из файлов бекапов. Лог хранится по пути /tmp/svnlog-commit
Подробнее: Механизм проверки конфигов Nagios/IcingaРасширенный custom вывод status.cgi в Nagios
Icinga или Nagios позволяет просматривать текущее состояние всех узлов сети и сервисов, которые будут контролироваться. В стандартной поставке icinga поддерживает отображение в формате json статусов сервисов и хостов посредством cgi-программы status.cgi. Поддерживаются директивы notes_url, action_url и другие. Это работает так, например: https://nagios.corp.ru/nagios/cgi-bin/status.cgi?host=dhcp.infra.ru&jsonoutput
… "status": { "service_status": [ { "host_name": "dhcp.infra.ru", "host_display_name": "dhcp.infra.ru", "service_description": "DHCPD", "service_display_name": "DHCPD", "status": "OK", "last_check": "04-03-2015 09:17:32", "duration": "1d 19h 36m 0s", "attempts": "1/3", "state_type": "HARD", "is_flapping": false, "in_scheduled_downtime": false, "active_checks_enabled": false, "passive_checks_enabled": true, "notifications_enabled": true, "has_been_acknowledged": false, "action_url": "http://test.ru", "notes_url": "https://test2.ru", "status_information": "dhcpd is running as pid 17902."} ] } |
Встроенная (нативная) репликация версий PostgreSQL 9 и старше, реализована с помощью журнала опережающей записи WAL - Write-Ahead Log, посредством пересылки XLOG-ов с главного сервера (master) на подчиненный (slave). При настроенной репликации на мастере и слейве запускаются процессы «postgres: wal sender process» и «postgres: wal receiver process», соответственно.
О времени отставания slave от master можно понять сопоставляя текущие позиции записей журнала Write-Ahead Log (WAL). Текущую позицию на мастере можно получить используя запрос pg_current_xlog_location. Принятую/примененную позицию на слейве можно получить используя запрос pg_last_xlog_receive_location/pg_last_xlog_replay_location.
Например:
На master сервере
$psql -c "select pg_current_xlog_location()" -h localhost -Uuser1 template1 pg_current_xlog_location -------------------------- 0/178BFF0 (1 row) |
На slave
Подробнее: Мониторинг репликации PostgreSQLРассмотрим как написать собственный скрипт для Cacti. Для примера построим графики средней нагрузки многопроцессорного сервера.
Для начала определимся откуда брать загрузку процессора. На мониторируемом сервере необходимо установить и настроить snmp агент. Откуда и будем брать значения нагрузки процессоров для cacti. Например у меня:
#snmpwalk -c community -v 2c serverclient | grep ProcessorLoad HOST-RESOURCES-MIB::hrProcessorLoad.1 = INTEGER: 31 HOST-RESOURCES-MIB::hrProcessorLoad.2 = INTEGER: 24 #snmptranslate -On HOST-RESOURCES-MIB::hrProcessorLoad .1.3.6.1.2.1.25.3.3.1.2 |
Видим у нас два процессора с нагрузками: 1 — 31%, 2 -24%
В cacti есть готовые шаблоны для отображения загрузки процессоров, однако под Windows я ничего не нашел работающего, имеется по умолчанию только возможность отобразить графики по каждому процессору. Поэтому для средней нагрузки у меня получился такой вот небольшой скрипт:
Подробнее: Мониторинг нагрузки процессоров в CactiДля nagios существует очень много плагинов. В интернете можно найти подходящий для себя, поставить и радоваться как он здорово работает. Но, что делать если ни один плагин не устраивает? Напишем для примера свой простой!
Начнем.
Нагиос понимает 4 кода завершения работы плагина:
Подробнее: Пишем свой плагин для nagios