Нагадаю, що скрипти можна запускати віддалено, використовуючи nrpe-демон чи щось подібне, чи локально на самому сервері. У першому випадку слід описати перевірку в nrpe.cfg, щось на зразок такого:
# vim /etc/nagios/nrpe.cfg
...
command[check_value]=/usr/lib/nagios/plugins/check_value -w 5 -c 10
...
А на Nagios-сервері check має бути описаний подібним чином
define service{
use generic-service
host_name your.server.com
service_description Info About Check
check_command check_nrpe!check_value
}
Або ж в другому випадку перевірку необхідно описати в конфігураційному файлі /etc/nagios-plugins/config/value.cfg (або щось на зразок цього, можливо, за іншою адресою):
define command {
command_name check_value
command_line /usr/lib/nagios/plugins/check_value -H '$HOSTADDRESS$' -w '$ARG1$' -c '$ARG2$'
}
define service{
use generic-service
host_name your.server.com
service_description Info About Check
check_command check_value!5!10
}
Тобто ARG1 - це критичне значення 5, а ARG2 - відповідно 10.
По замовчуванню Nagios-сервер спілкується з клієнтом через 5666 порт, тому він має бути відкритий. Також на nrpe-клієнті сервер має бути описаний в директиві allowed_hosts у конфігураційному фалі nrpe.cfg. На малюнку продемонстровано схему роботи перевірки віддалених хостів через nrpe, не буду вдаватись в подробиці його роботи.
Коротко опишу стандартні скрипти, що вже активовані після установки nrpe із репозиторіїв. Так проходить перевірка к-ті користувачів, що ввійшли в систему:
# ./check_users -w 5 -c 10
USERS OK - 2 users currently logged in |users=2;5;10;0
Перевірка Load Average:
# ./check_load -w 15,10,5 -c 30,25,20
OK - load average: 0.04, 0.06, 0.06|load1=0.040;15.000;30.000;0; load5=0.060;10.000;25.000;0; load15=0.060;5.000;20.000;0;
Перевірка місця, що доступне на диску:
# ./check_disk -w 20% -c 10% -p /dev/sda1
DISK OK - free space: / 6511 MB (78% inode=85%); /dev 487 MB (99% inode=99%); /run 198 MB (99% inode=99%); /run/lock 5 MB (100% inode=99%); /run/shm 497 MB (100% inode=99%); /boot 160 MB (74% inode=99%);| /=1739MB;6959;7829;0;8699 /dev=0MB;389;438;0;487 /run=0MB;158;178;0;198 /run/lock=0MB;4;4;0;5 /run/shm=0MB;397;447;0;497 /boot=54MB;181;204;0;227
Можна перевірити лише окремий розділ, використавши ключ -p.
Підрахунок кількості zombie-процесів:
# ./check_procs -w 5 -c 10 -s Z
PROCS OK: 0 processes with STATE = Z
Та всіх процесів:
# ./check_procs -w 80 -c 100
PROCS OK: 75 processes
Це всі перевірки що пропонує дефолтна інсталяція nrpe-серверу (пакет nagios-nrpe-server в Ubuntu). Далі я опишу скрипти-перевірки, що слідкуватимуть за іншими параметрами системи і роботою демонів, якими сам користуюсь і, можливо, будуть корисні і вам.
RAM. Не зрозуміло, чому в стандартний пакет nagios-plugins не входить жодний скрипт для перевірки оперативної пам'яті. Запускати його потрібно наступним чином:
# ./check_mem -w 80 -c 90
Memory: OK Total: 12039 MB - Used: 4301 MB - 35% used|TOTAL=12623962112;;;; USED=4508446720;;;; CACHE=4903997440;;;; BUFFER=408313856;;;;
Дані після "|" можуть відображатись на графіках за допомогою Nagiosgraph чи Pnp4nagios.
Active Connections. Скрипт підраховує активні з'єднання і в разі їх перевищення від заданого значення Nagios буде про це інформувати. Написаний на bash та парсить вивід команди ss:
# ./check_connections -w 20 -c 30
CONNECTIONS OK - There are 11 established connections. | established=11;; waiting=0;; listeners=19;;
Disk I/O. Плагін показує статистику використання диску для чого використовує дані від програми iostat.
# ./check_iostat -d sda1 -w 400,4000,3000 -c 700,6000,5000
OK - I/O stats tps=229.60 KB_read/s=1181.43 KB_written/s=1644.17 | 'tps'=229.60; 'KB_read/s'=1181.43; 'KB_written/s'=1644.17;
Скрипт перевіряє 3 параметри: транзакції за секунду (tps), Кб за секунду, що читаються з диску (KB_read/s) та Кб за секунду, що записуються на диск. Є також дещо новіша версія даного скрипта.
Apache. Для збирання статистики по веб-серверу Apache я використову стандартну перевірку, яка доступна в пакеті nagios-nrpe-server.
# ./check_httpd_status -H host.my.com -p 80
HTTPD_STATUS OK - 0.102 s - 1/3 Busy/Idle, 12/16 Open/Total, 0.0 requests/s, 0.0 B/s, 0 B/request | ReqPerSec=0.030req/s;; BytesPerSec=0.00B/s;; BytesPerReq=0.00B/req;; Starting=0;; Sending=1;; Keepalive=0;; Waiting=3;; Closing=0;; DNS=0;; OpenSLot=12;; Idle=0;; Reading=0;; Finishing=0;; Logging=0;; FreeWorker=15;;
Для цього звісно має бути ввімкнена статистика на боці сервера, який буде перевірятись і активований модуль mod_status:
...
<Location /server-status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from your.nagios.server
</Location>
...
Nginx. Часто буває необхідно переглядати статистику роботи веб-серверу Nginx. Для цього спершу необхідно додати новий location до конфігураційного файлу віртуалхосту:
location /nginx_status {
stub_status on;
access_log off;
allow nagios-server_IP;
deny all;
}
Додати звісно необхідно в блок server {..}. В результаті за адресою http://yourserver.com/nginx_status має з'явитись подібна інформація:
Active connections: 43
server accepts handled requests
7368 7368 10993
Reading: 0 Writing: 5 Waiting: 38
Потім із сервера Nagios можна збирати таку статистику:
# ./check_nginx_status -H 1.2.3.4 -s yourserver.com -t 8 -w 1000,10,20 -c 2000,20,30 -p 80
NGINX OK - 0.077 sec. response time, Active: 1 (Writing: 1 Reading: 0 Waiting: 0) ReqPerSec: 0.000 ConnPerSec: 0.000 ReqPerConn: 1.003|Writing=1;;;; Reading=0;;;; Waiting=0;;;; Active=1;;;; ReqPerSec=0.000000;;;; ConnPerSec=0.000000;;;; ReqPerConn=1.002955;;;;
Php-fpm. Все аналогічно як і у попередньому випадку. Для роботи перевірки необхідно розкоментувати опцію статусу в конфігураційному файлі пулу php-fpm та додати ще один location до віртуалхосту:
location ~ ^/status$ {
auth_basic off;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/var/run/php-fpm.sock;
allow nagios-server_IP;
deny all;
}
У залежності від php-пула варто також відредагувати наступний конфігураційний файл:
# vim /etc/php5/fpm/pool.d/default.conf
[default]
...
pm.status_path = /status
...
Запускається скрипт таким чином:
# ./check_phpfpm_status -H yourserver.com -u /status -p 81
PHP-FPM OK - default, 0.100 sec. response time, Busy/Idle 1/1, (max: 6, reached: 0), ReqPerSec 0.0, Queue 0 (len: 0, reached: 0)|Idle=1; Busy=1; MaxProcesses=6; MaxProcessesReach=0; Queue=0; MaxQueueReach=0; QueueLen=0; ReqPerSec=0.015152;
# ./check_mysql_health --hostname localhost -username root --password Jieve8Shelee --mode open-files --warning 500 --critical 700
OK - 0.58% of the open files limit reached (48 of max. 8302) | pct_open_files=0.578%;500.000;700.000 open_files=48;41510;58114
Так можна зафіксувати час, що витрачається на підключення до бази:
# ./check_mysql_health --hostname localhost -username root --password your_password --mode connection-time
OK - 0.02 seconds to connect as root | connection_time=0.0209s;1;5
Перевірити кількість тредів:
# ./check_mysql_health --hostname localhost -username root --password your_password --mode threads-connected
OK - 1 client connection threads | threads_connected=1;10;20
Чи спостерігати за повільними запитами чи запитами, що довго тривають:
# ./usr/lib/nagios/plugins/check_mysql_health --hostname localhost -username root --password Jieve8Shelee --mode slow-queries
OK - 0 slow queries in 235 seconds (0.00/sec) | slow_queries_rate=0.00%;0.1;1
# ./check_mysql_health --hostname localhost -username root --password Jieve8Shelee --mode long-running-procs
OK - 0 long running processes | long_running_procs=0;10;20
# ./check_mongodb -A connect -W 2 -C 4 -D
OK - Connection took 0 seconds |connection_time=0.0;2.0;4.0
Так можна переглянути чи не вичерпались всі можливі відключення:
# ./check_mongodb -A connections -W 70 -C 80 -D
OK - 0 percent (1 of 819 connections) used |used_percent=0;70.0;80.0 current_connections=1.0 available_connections=818.0
Стан пам'яті:
# ./check_mongodb -A memory -W 20 -C 28 -D
OK - Memory Usage: 0.30GB resident, 70.30GB virtual, 35.04GB mapped, 70.09GB mappedWithJournal |memory_usage=0.30;20.0;28.0 memory_mapped=35.04 memory_virtual=70.30 mappedWithJournal=70.09
Наявність локів в базі:
# ./check_mongodb -A lock -W 5 -C 10 -D
OK - Lock Percentage: 0.00% |lock_percentage=0.00;5.0;10.0
Та інше:
# ./check_mongodb -A flushing -W 100 -C 200 -D
OK - Average Flush Time: 33.58ms |average_flush_time=33.58ms;100.0;200.0
# ./check_mongodb -A last_flush_time -W 200 -C 400 -D
OK - Last Flush Time: 22.00ms |last_flush_time=22.00ms;200.0;400.0
# ./check_mongodb -A index_miss_ratio -W .005 -C .01 -D
OK - Miss Ratio: 0.00 |index_miss_ratio=0.00;0.005;0.01
Кількість баз данних та колекцій:
# ./check_mongodb -A databases -W 300 -C 500 -D
OK - Number of DBs: 4 |databases=4;300.0;500.0
# ./check_mongodb -A collections -W 4500 -C 6000 -D
OK - Number of collections: 3312 |collections=3312;4500.0;6000.0
К-ть запитів в секунду, що надходять до бази:
# ./check_mongodb -A queries_per_second -W 200 -C 150 -D
OK - Queries / Sec: 0.104478
# ./check_memcached -H localhost -w 10 -E 5 -t 0.3 -T 10 -n 10
OK: hits=38 misses=0 evictions=0 interval=10 mins|time=1399328567 cmd_get=371926 cmd_set=58696 get_hits=356282 get_misses=15644 evictions=0 delta_time=606 delta_cmd_get=38 delta_cmd_set=11 delta_get_hits=38 delta_get_misses=0 delta_evictions=0
Щоб переглянути список опцій необхідно запустити скрипт без жодних ключів. Також є простіший варіант, якщо цікаво лиш знати, що демон працює:
# ./check_memcached -H localhost -p 11211
MEMCACHE OK: memcached 1.4.15 on localhost:11211, up 82 days 12 hours
# ./check_varnish --spec=cache_hit_percent --spec=cache_hit --spec=cache_miss --spec=cache_hitpass --spec=backend_fail --spec=client_conn --spec=client_req --spec=n_wrk --spec=n_wrk_max --spec=n_lru_nuked --spec=n_expired
OK - all counters in range; | cache_hit_percent=-;;;; cache_hit=0;;;; cache_miss=0;;;; cache_hitpass=0;;;; backend_fail=0;;;; client_conn=23137;;;; client_req=22553;;;; n_wrk=10;;;; n_wrk_max=0;;;; n_lru_nuked=0;;;; n_expired=0;;;;
Всі доступні параметри можна переглянути запустивши скрипт із опцією --list:
# ./check_varnish --list
Solr. Solr - це платформа повнотекстового пошуку, що досить часто використовується у веб-проектах. Скрипт перевірки написаний на Перлі, запускається так:
# ./check_solr -H localhost -u /solr/dev/admin/ping -p 8983 -o ping
OK - Solr ping status |
Головне - правильно обрати URL (core), в чому може допомогти будь-який консольний браузер.
Перевірка запитів до кешів:
# ./check_solr -H localhost -u /solr/dev/admin/stats.jsp -p 8983 -o cache
OK - Solr Core: dev - schema: drupal-3.0-0-solr3 | 'queryResultCache hit ratio'=1.00%;;;; 'documentCache hit ratio'=0.00%;;;; 'fieldValueCache hit ratio'=0.00%;;;; 'filterCache hit ratio'=0.00%;;;;
За допомогою опції -o можна обрати варіанти перевірки ping/cache/response/numdocs/updates.
Час, що затрачається на відповідь:
# ./check_solr -H localhost -u /solr/dev/admin/stats.jsp -p 8983 -o response
OK - Solr Core: dev - schema: drupal-3.0-0-solr3 - standard avgResponseTime=1.2379041 | 'standard avgResponseTime'=1.2379041ms;;;; 'standard requests'=38856c;;;; 'standard qps'=0.067832775;;;;
К-ть різних оновлень та документів в індексах:
# ./check_solr -H localhost -u /solr/dev/admin/stats.jsp -p 8983 -o updates
OK - Solr Core: dev - schema: drupal-3.0-0-solr3; cumulative_adds=194256; commits=1683; optimizes=0; docsPending=0; deletesById=0; deletesByQuery=0 | cumulative_adds=194256;;;; commits=1683;;;; optimizes=0;;;; docsPending=0;;;; deletesById=0;;;; deletesByQuery=0;;;;
# ./check_solr -H localhost -u /solr/dev/admin/stats.jsp -p 8983 -o numdocs
OK - Solr Core: dev - schema: drupal-3.0-0-solr3 - numDocs=5127 | numDocs=5127;;;;
# ./check_fail2ban -p -w 2 -c 5
CHECK FAIL2BAN ACTIVITY - OK - 1 detected jails with 0 current banned IP(s) | ssh.currentBannedIP=0
Для роботи скрипта від користувача nagios необхідно додати таке до /etc/sudoers:
# visudo
...
nagios ALL=(ALL) NOPASSWD: /usr/lib/nagios/plugins/check_fail2ban
...
К-ті підключень до бази:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=postgres --dbpass=your_password --action backends --showtime=0
POSTGRES_BACKENDS OK: DB "postgres" (host:localhost) 15 of 100 connections (15%) | test1=4;90;95;0;100 test_with_module=6;90;95;0;100 bi_test=0;90;95;0;100 db_test=0;90;95;0;100 db_test_to_m=0;90;95;0;100 jira=0;90;95;0;100 terp=0;90;95;0;100 terp7=4;90;95;0;100 postgres=1;90;95;0;100 template0=0;90;95;0;100 template1=0;90;95;0;100
За допомогою ключа --action проходить задання конретних перевірок.
Слідкування за розміром бази:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=postgres --dbpass=your_password --action database_size -w 500M -c 600M --showtime=0
POSTGRES_DATABASE_SIZE OK: DB "postgres" (host:localhost) db_test: 364053304 (347 MB) test_with_module: 252363576 (241 MB) ... template0: 6201860 (6057 kB) | db_test=364053304;524288000;629145600 test_with_module=252363576;524288000;629145600 ... template0=6201860;524288000;629145600
В Performance data потраплять також дані щодо найбільших баз.
Виведення кількість запитів (хітів) до кожної із баз:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --dbpass=your_password --action hitratio --showtime=0
POSTGRES_HITRATIO OK: DB "postgres" (host:localhost) db_test: 35.66 db_test_to_m: 98.54 open7: 98.67 open: 98.87 test: 99.22 test_with_module: 99.28 bi_test: 99.31 blabla: 99.77 template1: 99.87 postgres: 99.93 | db_test=35.66; db_test_to_m=98.54;; open7=98.67;; open=98.87;; test=99.22;; test_with_module=99.28;; bi_test=99.31;; jira=99.77;; template1=99.87;; postgres=99.93;
Також можна слідкувати за розмірами індексів:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=test --dbpass=your_password --action index_size -w 300000 -c 500000 --showtime=0 --showperf=0
POSTGRES_INDEX_SIZE CRITICAL: DB "test" (host:localhost) largest index is "ir_translation_ltns": 944 kB
Наявністю блокувань в базах:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=test --dbpass=your_password --action locks --showtime=0
POSTGRES_LOCKS OK: DB "test" (host:localhost) total=1 | test.total=0;100;150 test_with_module.total=0;100;150 bi_test.total=0;100;150 db_test.total=0;100;150 dbtest_to_m.total=0;100;150 bebe.total=0;100;150 open.total=1;100;150 open7.total=0;100;150 postgres.total=0;100;150 template1.total=0;100;150
Перевірка часу виконання запитів:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=test --dbpass=your_password --action query_time -w 5 -c 10 --showtime=0
POSTGRES_QUERY_TIME OK: DB "test" (host:localhost) longest query: 0s | query_time=0s;5;10
Перевірка розміру relation-данних:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=test --dbpass=your_password --action relation_size -w 1M -c 2M --showperf=0
POSTGRES_RELATION_SIZE OK: DB "test" (host:localhost) largest relation is table "pg_catalog.pg_proc": 456 kB
Перевірка кількості запитів в стані "idle in transaction" для окремої бази та часу їх перебування в такому стані:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=test --dbpass=your_password --action txn_idle -w 1 -c 2 --showtime=0
POSTGRES_TXN_IDLE OK: DB "test" (host:localhost) no idle in transaction | transaction_time=0;1;2
Перевірка часу виконання транзакцій:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=test --dbpass=your_password --action txn_time -w 1 -c 2 --showtime=0
MySQL. Скрипт має багато опцій, в залежності від яких і буде показано відповідну статистику. К-ть відкритих файлів можна прослідкувати так:
# ./check_mysql_health --hostname localhost -username root --password Jieve8Shelee --mode open-files --warning 500 --critical 700
OK - 0.58% of the open files limit reached (48 of max. 8302) | pct_open_files=0.578%;500.000;700.000 open_files=48;41510;58114
Так можна зафіксувати час, що витрачається на підключення до бази:
# ./check_mysql_health --hostname localhost -username root --password your_password --mode connection-time
OK - 0.02 seconds to connect as root | connection_time=0.0209s;1;5
Перевірити кількість тредів:
# ./check_mysql_health --hostname localhost -username root --password your_password --mode threads-connected
OK - 1 client connection threads | threads_connected=1;10;20
Чи спостерігати за повільними запитами чи запитами, що довго тривають:
# ./usr/lib/nagios/plugins/check_mysql_health --hostname localhost -username root --password Jieve8Shelee --mode slow-queries
OK - 0 slow queries in 235 seconds (0.00/sec) | slow_queries_rate=0.00%;0.1;1
# ./check_mysql_health --hostname localhost -username root --password Jieve8Shelee --mode long-running-procs
OK - 0 long running processes | long_running_procs=0;10;20
Про інші можливості цього скрипта можна прочитати на сайті розробника.
MongoDB. Попередньо для функціонування скрипта необхідно встановити пакет python-pymongo. Скрипт має широкий функціонал, згадаю лише базові перевірки:
# ./check_mongodb -A connect -W 2 -C 4 -D
OK - Connection took 0 seconds |connection_time=0.0;2.0;4.0
Ключ -D в попередній та кожній наступній перевірці відповідає за появу Performance Data, використовуючи яку можна будувати графіки.
Так можна переглянути чи не вичерпались всі можливі відключення:
# ./check_mongodb -A connections -W 70 -C 80 -D
OK - 0 percent (1 of 819 connections) used |used_percent=0;70.0;80.0 current_connections=1.0 available_connections=818.0
Стан пам'яті:
# ./check_mongodb -A memory -W 20 -C 28 -D
OK - Memory Usage: 0.30GB resident, 70.30GB virtual, 35.04GB mapped, 70.09GB mappedWithJournal |memory_usage=0.30;20.0;28.0 memory_mapped=35.04 memory_virtual=70.30 mappedWithJournal=70.09
Наявність локів в базі:
# ./check_mongodb -A lock -W 5 -C 10 -D
OK - Lock Percentage: 0.00% |lock_percentage=0.00;5.0;10.0
Та інше:
# ./check_mongodb -A flushing -W 100 -C 200 -D
OK - Average Flush Time: 33.58ms |average_flush_time=33.58ms;100.0;200.0
# ./check_mongodb -A last_flush_time -W 200 -C 400 -D
OK - Last Flush Time: 22.00ms |last_flush_time=22.00ms;200.0;400.0
# ./check_mongodb -A index_miss_ratio -W .005 -C .01 -D
OK - Miss Ratio: 0.00 |index_miss_ratio=0.00;0.005;0.01
Кількість баз данних та колекцій:
# ./check_mongodb -A databases -W 300 -C 500 -D
OK - Number of DBs: 4 |databases=4;300.0;500.0
# ./check_mongodb -A collections -W 4500 -C 6000 -D
OK - Number of collections: 3312 |collections=3312;4500.0;6000.0
К-ть запитів в секунду, що надходять до бази:
# ./check_mongodb -A queries_per_second -W 200 -C 150 -D
OK - Queries / Sec: 0.104478
Опції -W та -C описують рівень для попередження та тривоги.
І тому подібне.
Memcached. Скрипт входить до стандартного набору плагінів nagios-nrpe-server. Кориcтуватись ним можна наступним чином:
# ./check_memcached -H localhost -w 10 -E 5 -t 0.3 -T 10 -n 10
OK: hits=38 misses=0 evictions=0 interval=10 mins|time=1399328567 cmd_get=371926 cmd_set=58696 get_hits=356282 get_misses=15644 evictions=0 delta_time=606 delta_cmd_get=38 delta_cmd_set=11 delta_get_hits=38 delta_get_misses=0 delta_evictions=0
Щоб переглянути список опцій необхідно запустити скрипт без жодних ключів. Також є простіший варіант, якщо цікаво лиш знати, що демон працює:
# ./check_memcached -H localhost -p 11211
MEMCACHE OK: memcached 1.4.15 on localhost:11211, up 82 days 12 hours
Хоча глянувши у вміст скрипта, виявилось що він не такий уже і простіший. )
Varnish. Varnish - це http-акселератор. Для надання статистики скрипт парсить вивід команди varnishstat. Я запускаю моніторю такі параметри Varnish-а:
# ./check_varnish --spec=cache_hit_percent --spec=cache_hit --spec=cache_miss --spec=cache_hitpass --spec=backend_fail --spec=client_conn --spec=client_req --spec=n_wrk --spec=n_wrk_max --spec=n_lru_nuked --spec=n_expired
OK - all counters in range; | cache_hit_percent=-;;;; cache_hit=0;;;; cache_miss=0;;;; cache_hitpass=0;;;; backend_fail=0;;;; client_conn=23137;;;; client_req=22553;;;; n_wrk=10;;;; n_wrk_max=0;;;; n_lru_nuked=0;;;; n_expired=0;;;;
Всі доступні параметри можна переглянути запустивши скрипт із опцією --list:
# ./check_varnish --list
Solr. Solr - це платформа повнотекстового пошуку, що досить часто використовується у веб-проектах. Скрипт перевірки написаний на Перлі, запускається так:
# ./check_solr -H localhost -u /solr/dev/admin/ping -p 8983 -o ping
OK - Solr ping status |
Головне - правильно обрати URL (core), в чому може допомогти будь-який консольний браузер.
Перевірка запитів до кешів:
# ./check_solr -H localhost -u /solr/dev/admin/stats.jsp -p 8983 -o cache
OK - Solr Core: dev - schema: drupal-3.0-0-solr3 | 'queryResultCache hit ratio'=1.00%;;;; 'documentCache hit ratio'=0.00%;;;; 'fieldValueCache hit ratio'=0.00%;;;; 'filterCache hit ratio'=0.00%;;;;
За допомогою опції -o можна обрати варіанти перевірки ping/cache/response/numdocs/updates.
Час, що затрачається на відповідь:
# ./check_solr -H localhost -u /solr/dev/admin/stats.jsp -p 8983 -o response
OK - Solr Core: dev - schema: drupal-3.0-0-solr3 - standard avgResponseTime=1.2379041 | 'standard avgResponseTime'=1.2379041ms;;;; 'standard requests'=38856c;;;; 'standard qps'=0.067832775;;;;
К-ть різних оновлень та документів в індексах:
# ./check_solr -H localhost -u /solr/dev/admin/stats.jsp -p 8983 -o updates
OK - Solr Core: dev - schema: drupal-3.0-0-solr3; cumulative_adds=194256; commits=1683; optimizes=0; docsPending=0; deletesById=0; deletesByQuery=0 | cumulative_adds=194256;;;; commits=1683;;;; optimizes=0;;;; docsPending=0;;;; deletesById=0;;;; deletesByQuery=0;;;;
# ./check_solr -H localhost -u /solr/dev/admin/stats.jsp -p 8983 -o numdocs
OK - Solr Core: dev - schema: drupal-3.0-0-solr3 - numDocs=5127 | numDocs=5127;;;;
Fail2ban. Fail2ban - демон, що використовується для запобігання brute force атак. Перевірка для Nagios-сервера буде сигналізувати про наявність критичної к-ті заблокованих IP-адрес.
# ./check_fail2ban -p -w 2 -c 5
CHECK FAIL2BAN ACTIVITY - OK - 1 detected jails with 0 current banned IP(s) | ssh.currentBannedIP=0
Для роботи скрипта від користувача nagios необхідно додати таке до /etc/sudoers:
# visudo
...
nagios ALL=(ALL) NOPASSWD: /usr/lib/nagios/plugins/check_fail2ban
...
PostgreSQL. Скрипт дуже функціональний і може бути використаний не лише для Nagios. Змінюючи значення ключа --output, скрипт вміє збирати статистику для MRTG, Cacti та ін. Використання його мною обмежилось перевіркою таких параметрів:
К-ті підключень до бази:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=postgres --dbpass=your_password --action backends --showtime=0
POSTGRES_BACKENDS OK: DB "postgres" (host:localhost) 15 of 100 connections (15%) | test1=4;90;95;0;100 test_with_module=6;90;95;0;100 bi_test=0;90;95;0;100 db_test=0;90;95;0;100 db_test_to_m=0;90;95;0;100 jira=0;90;95;0;100 terp=0;90;95;0;100 terp7=4;90;95;0;100 postgres=1;90;95;0;100 template0=0;90;95;0;100 template1=0;90;95;0;100
За допомогою ключа --action проходить задання конретних перевірок.
Слідкування за розміром бази:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=postgres --dbpass=your_password --action database_size -w 500M -c 600M --showtime=0
POSTGRES_DATABASE_SIZE OK: DB "postgres" (host:localhost) db_test: 364053304 (347 MB) test_with_module: 252363576 (241 MB) ... template0: 6201860 (6057 kB) | db_test=364053304;524288000;629145600 test_with_module=252363576;524288000;629145600 ... template0=6201860;524288000;629145600
В Performance data потраплять також дані щодо найбільших баз.
Виведення кількість запитів (хітів) до кожної із баз:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --dbpass=your_password --action hitratio --showtime=0
POSTGRES_HITRATIO OK: DB "postgres" (host:localhost) db_test: 35.66 db_test_to_m: 98.54 open7: 98.67 open: 98.87 test: 99.22 test_with_module: 99.28 bi_test: 99.31 blabla: 99.77 template1: 99.87 postgres: 99.93 | db_test=35.66; db_test_to_m=98.54;; open7=98.67;; open=98.87;; test=99.22;; test_with_module=99.28;; bi_test=99.31;; jira=99.77;; template1=99.87;; postgres=99.93;
Також можна слідкувати за розмірами індексів:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=test --dbpass=your_password --action index_size -w 300000 -c 500000 --showtime=0 --showperf=0
POSTGRES_INDEX_SIZE CRITICAL: DB "test" (host:localhost) largest index is "ir_translation_ltns": 944 kB
Наявністю блокувань в базах:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=test --dbpass=your_password --action locks --showtime=0
POSTGRES_LOCKS OK: DB "test" (host:localhost) total=1 | test.total=0;100;150 test_with_module.total=0;100;150 bi_test.total=0;100;150 db_test.total=0;100;150 dbtest_to_m.total=0;100;150 bebe.total=0;100;150 open.total=1;100;150 open7.total=0;100;150 postgres.total=0;100;150 template1.total=0;100;150
Перевірка часу виконання запитів:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=test --dbpass=your_password --action query_time -w 5 -c 10 --showtime=0
POSTGRES_QUERY_TIME OK: DB "test" (host:localhost) longest query: 0s | query_time=0s;5;10
Перевірка розміру relation-данних:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=test --dbpass=your_password --action relation_size -w 1M -c 2M --showperf=0
POSTGRES_RELATION_SIZE OK: DB "test" (host:localhost) largest relation is table "pg_catalog.pg_proc": 456 kB
Перевірка кількості запитів в стані "idle in transaction" для окремої бази та часу їх перебування в такому стані:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=test --dbpass=your_password --action txn_idle -w 1 -c 2 --showtime=0
POSTGRES_TXN_IDLE OK: DB "test" (host:localhost) no idle in transaction | transaction_time=0;1;2
Перевірка часу виконання транзакцій:
# ./check_postgres.pl -v --host=localhost --dbuser=postgres --db=test --dbpass=your_password --action txn_time -w 1 -c 2 --showtime=0
POSTGRES_TXN_TIME OK: DB "test" (host:localhost) longest txn: 0s | transaction_time=0s;1;2
Коротко зауважу щодо ключів до скрипта:
# ./check_postfix_queue -w 100 -c 200
1 mail(s) in queue | mail_queue=1
А підрахунок відправлених та прийнятих листів відбувається наступним чином:
# ./check_postfix_processed2 -w 50 -c 100
Messages processed in the last 240 seconds: 0 | mailsprocessed=0
Перевірка порта стандартна, все просто:
# ./check_smtp -H localhost -w 2 -c 1
SMTP OK - 0.046 sec. response time|time=0.045532s;2.000000;1.000000;0.000000
Останню перевірку можна запускати як із самого сервера, так із Nagios-сервера.
HTTP. Основна перевірка запускається тривіально:
# ./check_http -H yoursite.com -p 81
HTTP OK: HTTP/1.1 301 Moved Permanently - 419 bytes in 0.277 second response time |time=0.277004s;;;0.000000 size=419B;;;0
Запуск перевірки у разі коли на сторінці, що перевіряємо, встановлено авторизацію:
# ./check_http -H yoursite.com -a your_login:your_password
RabbitMQ - сервер черг, платформа, що реалізує систему обміну повідомленнями між компонентами програмної системи на основі стандарту AMQP (Advanced Message Queuing Protocol).
Готові deb-пакети вже присутні в репозиторіях сучасних версій Ubuntu, проте для 14.04 необхідно додати ppa-репозиторій:
# add-apt-repository ppa:gason/nagios-plugins-rabbitmq
# aptitude update
# aptitude install nagios-plugins-rabbitmq
Чеки встановляться в директорію /usr/lib/nagios/plugins-rabbitmq:
# ls -1
check_rabbitmq_aliveness
check_rabbitmq_connections
check_rabbitmq_objects
check_rabbitmq_overview
check_rabbitmq_partition
check_rabbitmq_queue
check_rabbitmq_server
check_rabbitmq_shovels
check_rabbitmq_watermark
Для запуску перевірок необхідний користувач, пароль для нього та vhost. Приклад його створення в RabbitMQ:
# rabbitmqctl add_vhost /test
# rabbitmqctl add_user check_user alive
# rabbitmqctl set_permissions -p /test check_user ".*" ".*" ".*"
Запуск перевірок відбувається наступним чином:
# ./check_rabbitmq_aliveness -H localhost -u check_user -p alive --vhost /test --port 15672
RABBITMQ_ALIVENESS OK - vhost: /test
# ./check_rabbitmq_objects -H localhost -u check_user -p alive --port 15672
RABBITMQ_OBJECTS OK - Gathered Object Counts | vhost=1;; exchange=13;; binding=0;; queue=0;; channel=0;;
# ./check_rabbitmq_overview -H localhost -u check_user -p alive --port 15672
RABBITMQ_OVERVIEW OK - messages OK (0) messages_ready OK (0) messages_unacknowledged OK (0) | messages=0;; messages_ready=0;; messages_unacknowledged=0;;
# ./check_redis.py --server redis.host --warn 2048 --critical 4096 --rss-warn 3000 --rss-critical 5000
Uptime is 32 days, 10:28 h, Used Memory: 0.50 MB, Connected Clients: 1, Connected Slaves: 0|uptime=2802507s;900;60 connectedClients=1;1;2 connectedSlaves=0;0;0 usedMemory=0.50MB;10.0;20.0
# ./check_smart -d /dev/sda -i megaraid,4
OK: no SMART errors detected. |Reallocated_Sector_Ct=0 Power_On_Hours=6921 Power_Cycle_Count=8 ... Power-off_Retract_Count=88712 Available_Reservd_Space=0 Media_Wearout_Indicator=0 Total_LBAs_Written=21043 Total_LBAs_Read=43743
Коротко зауважу щодо ключів до скрипта:
--showtime=0 - відключає інформацію у виводі, щодо часу, котрий було витрачено на відпрацювання перевірки.
--showperf=0 - відключити performance data (технічні дані після власне перевірки). Тобто якщо малювати графік не потрібно, то можна їх відключити.
Postfix. Для моніторингу Postfix, окрім перевірки 25-порту, я користуюсь перевірками черги листів та кількості листів, що було оброблено. Перша запускається так:
# ./check_postfix_queue -w 100 -c 200
1 mail(s) in queue | mail_queue=1
А підрахунок відправлених та прийнятих листів відбувається наступним чином:
# ./check_postfix_processed2 -w 50 -c 100
Messages processed in the last 240 seconds: 0 | mailsprocessed=0
Перевірка порта стандартна, все просто:
# ./check_smtp -H localhost -w 2 -c 1
SMTP OK - 0.046 sec. response time|time=0.045532s;2.000000;1.000000;0.000000
Останню перевірку можна запускати як із самого сервера, так із Nagios-сервера.
HTTP. Основна перевірка запускається тривіально:
# ./check_http -H yoursite.com -p 81
HTTP OK: HTTP/1.1 301 Moved Permanently - 419 bytes in 0.277 second response time |time=0.277004s;;;0.000000 size=419B;;;0
Запуск перевірки у разі коли на сторінці, що перевіряємо, встановлено авторизацію:
# ./check_http -H yoursite.com -a your_login:your_password
check_http присутній у стандартному наборі скриптів. Також тут можна знайти дещо більше можливих варіантів використання такої перевірки.
RabbitMQ - сервер черг, платформа, що реалізує систему обміну повідомленнями між компонентами програмної системи на основі стандарту AMQP (Advanced Message Queuing Protocol).
Готові deb-пакети вже присутні в репозиторіях сучасних версій Ubuntu, проте для 14.04 необхідно додати ppa-репозиторій:
# add-apt-repository ppa:gason/nagios-plugins-rabbitmq
# aptitude update
# aptitude install nagios-plugins-rabbitmq
Чеки встановляться в директорію /usr/lib/nagios/plugins-rabbitmq:
# ls -1
check_rabbitmq_aliveness
check_rabbitmq_connections
check_rabbitmq_objects
check_rabbitmq_overview
check_rabbitmq_partition
check_rabbitmq_queue
check_rabbitmq_server
check_rabbitmq_shovels
check_rabbitmq_watermark
Для запуску перевірок необхідний користувач, пароль для нього та vhost. Приклад його створення в RabbitMQ:
# rabbitmqctl add_vhost /test
# rabbitmqctl add_user check_user alive
# rabbitmqctl set_permissions -p /test check_user ".*" ".*" ".*"
Запуск перевірок відбувається наступним чином:
# ./check_rabbitmq_aliveness -H localhost -u check_user -p alive --vhost /test --port 15672
RABBITMQ_ALIVENESS OK - vhost: /test
# ./check_rabbitmq_objects -H localhost -u check_user -p alive --port 15672
RABBITMQ_OBJECTS OK - Gathered Object Counts | vhost=1;; exchange=13;; binding=0;; queue=0;; channel=0;;
# ./check_rabbitmq_overview -H localhost -u check_user -p alive --port 15672
RABBITMQ_OVERVIEW OK - messages OK (0) messages_ready OK (0) messages_unacknowledged OK (0) | messages=0;; messages_ready=0;; messages_unacknowledged=0;;
Redis - розподілене сховище пар ключ-значення, які зберігаються в оперативній пам'яті, з можливістю забезпечувати довговічність зберігання за бажанням користувача. Скрипт перевірки слідкує за часом роботи, за зайнятою пам'яттю, клієнтами, що підключені та слейвами:
# ./check_redis.py --server redis.host --warn 2048 --critical 4096 --rss-warn 3000 --rss-critical 5000
Uptime is 32 days, 10:28 h, Used Memory: 0.50 MB, Connected Clients: 1, Connected Slaves: 0|uptime=2802507s;900;60 connectedClients=1;1;2 connectedSlaves=0;0;0 usedMemory=0.50MB;10.0;20.0
--warn та ін значення зазначаються в мегабайтах.
Зупинимось поки на моніторингу софту та перейдемо до моніторингу хардової частини. І почнемо із дискової підсистеми.
S.M.A.R.T. SMART - це технологія оцінки стану жорсткого диска вбудованою апаратурою самодіагностики, а також механізм передбачення часу виходу його з ладу. Його звісно необхідно моніторити в першу чергу, адже лишитись без данних, мабуть, жахливіше за все.
Скрипт, яким я користуюсь вміє перевіряти різні дискові системи та різні типи їх підключень, серед яких ata (звичайні диски, які зазвичай підключаються на десктоп чи дешеві сервери), scsi, контролери 3ware, areca, hpt, cciss, megaraid. Так наприклад, перевіряється megaraid контроллер:
# ./check_smart -d /dev/sda -i megaraid,4
OK: no SMART errors detected. |Reallocated_Sector_Ct=0 Power_On_Hours=6921 Power_Cycle_Count=8 ... Power-off_Retract_Count=88712 Available_Reservd_Space=0 Media_Wearout_Indicator=0 Total_LBAs_Written=21043 Total_LBAs_Read=43743
А так звичайний ata-диск:
# ./check_smart -d /dev/sda -i ata
WARNING: Attribute Airflow_Temperature_Cel failed at In_the_past|Raw_Read_Error_Rate=127995811 Spin_Up_Time=0 Start_Stop_Count=13 Reallocated_Sector_Ct=0 Seek_Error_Rate=239527523 ... Current_Pending_Sector=0 Offline_Uncorrectable=0 UDMA_CRC_Error_Count=0 Head_Flying_Hours=9234179708526 Total_LBAs_Written=3071031956 Total_LBAs_Read=3974819020
Вивід залежить від самого диску і які можливості SMART він підтримує.
Таким чином можна перевірити групу дисків, що підключені по інтерфейсу scsi
# ./check_smart -g /dev/sd -i scsi
OK: [/dev/sda] - Device is clean --- [/dev/sdb] - Device is clean|
Скрипт парсить вивід команди smartctl, що працює лише від користувача root, тому для успішної роботи скрипта необхідно додати права на запуск smartctl без пароля:
# visudo
...
#nagios
nagios ALL=(root) NOPASSWD: /usr/sbin/smartctl
...
RAID. Часто диски об'єднують в рейд-масиви, тож непогано перевіряти стан кожного із них. Хардовий RAID (LSI MegaRAID) перевіряється наступним чином:
# ./check_raid -p megacli
OK: megacli:[Volumes(2): DISK0.0:Optimal,DISK1.1:Optimal; Devices(3): 06,05,04=Online]
Скрипт працює із такими хардовими рейдами https://github.com/glensc/nagios-plugin-check_raid#supported-raids
А так софтовий RAID в ОС Linux, що створений за допомогою утиліти mdadm:
# ./check_raid -p mdstat
OK: mdstat:[md6(29.30 GiB raid1):UU, md9(1.44 TiB raid1):UU, md5(29.30 GiB raid1):UU, md3(9.76 GiB raid1):UU, md8(292.97 GiB raid1):UU, md7(9.76 GiB raid1):UU, md1(6.83 GiB raid1):UU]
Ключ -p вказує на плагін, що слід використовувати для отримання необхідної інформації. Може мати значення megacli, mpt, tw_cli, mdstat та інші, в залежності від заліза.
Ethernet. Скрипт перевіряє чи піднятий заначений мережевий інтерфейс та слідкує за його швидкість, в противному випадку буде відправлено повідомлення про проблему.
# ./check_link eth0 100
OK: Interface eth0 link at 100Mb/s
Скрипт використовує для своєї роботи утиліту ethtool, тому вона має бути встановлена та її запуск має бути дозволений без пароля:
# visudo
...
nagios ALL=(ALL) NOPASSWD: /sbin/ethtool eth0
...
Можливо, варто задуматись про додаткові перевірки, скажімо, помилок на інтерфейсах і т.п.
Sensors. Перевірка даних сенсорів залежить власне від датчиків, що встановлені в сервері. Універсальним варіантом може бути скрипт, що парсить вивід утиліт lm-sensors (відповідний пакет звісно має бути установленим та проведено детектування існуючих датчиків) та hddtemp. Спочатку варто дізнатись які датчики "бачить" скрипт:
# ./check_lm_sensors --list
found temperature for drive sdb Temp (sdb Temp = 36)
found temperature for drive sda Temp (sda Temp = 37)
found sensor Physical id 0 (43.0)
found sensor Core 0 (35.0)
found sensor Core 1 (38.0)
found sensor Core 2 (43.0)
found sensor Core 3 (37.0)
LM_SENSORS OK - |
І вже після цього обрати необхідні сенсори та сформувати команду:
# ./check_lm_sensors --high "Core 0"=60,70 --high "Core 1"=60,70 --high "Core 2"=60,70 --high "Core 3"=60,70 --high "sda Temp"=50,60 --high "sdb Temp"=50,60
LM_SENSORS OK - Core 3=46.0 Core 0=43.0 sdb Temp=35 Core 2=53.0 Core 1=48.0 sda Temp=37|Core 3=46.0;60;70;; Core 0=43.0;60;70;; sdb Temp=35;50;60;; Core 2=53.0;60;70;; Core 1=48.0;60;70;; sda Temp=37;50;60;;
Якщо в сервері присутні IPMI-сенсори, то їх показання можна переглянути за допомогою цього скрипта:
# ./check_ipmi_sensor -H localhost -L user -T Temperature
Sensor Type(s) Temperature Status: OK | 'CPU1 Temp'=44.00 'CPU2 Temp'=39.00 'System Temp'=28.00 'Peripheral Temp'=34.00 'PCH Temp'=47.00 '10G Temp'=39.00 'P1-DIMMA1 ...TEMP'=31.00 'P2-DIMMF1 TEMP'=29.00 'P2-DIMMF2 TEMP'=29.00 'P2-DIMMG1 TEMP'=33.00 'P2-DIMMG2 TEMP'=32.00 'P2-DIMMH1 TEMP'=32.00 'P2-DIMMH2 TEMP'=32.00
Перегляд швидкості обертання кулерів:
# ./check_ipmi_sensor -H localhost -L user -T Fan
Sensor Type(s) Fan Status: OK | 'FAN1'=6300.00 'FAN2'=6300.00 'FAN3'=6300.00 'FAN4'=6525.00 'FAN5'=6300.00
Напруга на вузлах:
# ./check_ipmi_sensor -H localhost -L user -T Voltage -x 2952,3086
Sensor Type(s) Voltage Status: OK | 'VTT'=1.04 'CPU1 Vcore'=0.88 'CPU2 Vcore'=0.85 'VDIMM AB'=1.34 'VDIMM CD'=1.34 'VDIMM EF'=1.36 'VDIMM GH'=1.34 '3.3V'=3.36 '5V'=4.99 '12V'=12.19 'VBAT'=3.07
Ключ -x дозволяє відкинути деякі показання датчиків із виводу.
Переглянути всі можливі IPMI-сенсори можна за допомогою команди ipmimonitoring:
# ipmimonitoring -h localhost -l user -u monitoring -p relation
Other Hardware Checks. Загальну перевірку складових серверу я реалізував за цією статтею. Тобто за це буде відповідати mcelog, що аналізує MCE (Machine Check Exception) стан в CPU AMD і Intel, який може вказати на проблеми з пам'яттю і з кешем CPU, помилки обміну даними між CPU і чіпсетом материнської плати. Щоб додати перевірку необхідно спершу встановити mcelog:
# aptitude install mcelog
Додати крон-завдання:
# crontab -e
...
*/5 * * * * root test -x /usr/sbin/mcelog -a ! -e /etc/mcelog-disabled && /usr/sbin/mcelog --ignorenodev --filter >> /var/log/mcelog
@reboot root test -f /var/log/mcelog && mv /var/log/mcelog /var/log/mcelog.0
...
І створимо сам скрипт перевірки:
# vim /usr/lib/nagios/plugins/check_hardware
LDAP. Я користуюсь скриптом, що входить до стандартного набору перевірок до пакету nagios-plugins:
# ./check_ldap -H ldap.my.com -b 'dc=my,dc=com' -D 'cn=nagios-user,ou=My,dc=my,dc=com' -P aM2frffffo -3
LDAP OK - 0.002 seconds response time|time=0.001965s;;;0.000000
-H - хост до якого звертаємось
-b - базовий DN
-D - запис, що буде перевірятись
-P - пароль
-3 - використовувати протокол LDAPv3
Multi Checks. Багато однотипних перевірок можна сховати під одним пунктом у Nagios. В житті це виглядає так:
Як на мене це досить зручно і не засмічує Nagios.
Щоб скористатися ним необхідно його спочатку встановити:
# aptitude install nagios-plugin-check-multi
Описати використання чека в /etc/nagios-plugins/config:
# vim /etc/nagios-plugins/config/multi.cfg
define command {
command_name check_multi
command_line /usr/lib/nagios/plugins/check_multi -r 2 -l /usr/lib/nagios/plugins/ -f /etc/nagios3/conf.d/check_multi/$ARG1$ $ARG2$ $ARG3$ $ARG4$
}
$ARG1$ - це список перевірок, які необхідно запускати:
# vim /etc/nagios3/conf.d/check_multi/check_memcached.cmd
command[memcached_1]=/usr/lib/nagios/plugins/check_nrpe -H yourserver.com -c check_memcached1
command[memcached_2]=/usr/lib/nagios/plugins/check_nrpe -H yourserver.com -c check_memcached2
command[memcached_3]=/usr/lib/nagios/plugins/check_nrpe -H yourserver.com -c check_memcached3
command[memcached_4]=/usr/lib/nagios/plugins/check_nrpe -H yourserver.com -c check_memcached4
command[memcached_5]=/usr/lib/nagios/plugins/check_nrpe -H yourserver.com -c check_memcached5
command[memcached_6]=/usr/lib/nagios/plugins/check_nrpe -H yourserver.com -c check_memcached6
command[memcached_7]=/usr/lib/nagios/plugins/check_nrpe -H yourserver.com -c check_memcached7
command[memcached_8]=/usr/lib/nagios/plugins/check_nrpe -H yourserver.com -c check_memcached8
command[memcached_9]=/usr/lib/nagios/plugins/check_nrpe -H yourserver.com -c check_memcached9
state [ CRITICAL ] = COUNT(CRITICAL) > 2
state [ WARNING ] = COUNT(WARNING) > 1 || COUNT(CRITICAL) > 1
state [ UNKNOWN ] = COUNT(UNKNOWN) > 1
Або щось подібне по аналогії. Check_memcached звісно має бути описаний в nrpe-демоні на yourserver.com.
Посилання:
http://www.yourownlinux.com/2014/06/how-to-create-nagios-plugin-using-bash-script.html
Посилання:
http://www.yourownlinux.com/2014/06/how-to-create-nagios-plugin-using-bash-script.html
Цікаво))
ВідповістиВидалитиПлюсую
ВідповістиВидалити