Я работаю в небольшой компании в качестве системного администратора Linux и DB. Так как это более стандартное оборудование, я решил сначала попробовать суперпользователя. У нас иногда возникали странные проблемы с сетью. Каждый раз, когда я пытаюсь определить проблему, что-то сводит ее на нет.
В основном мы получаем тайм-ауты более 10 секунд в Nagios без какой-либо связи с проблемой. Они периодически и кажутся случайными, однако существуют определенные машины / подключения к Интернету, на которых он продолжает возникать. Я установил вторую копию Nagios на втором сервере разработки. Обе эти машины были установлены мной и интенсивно не используются. Минимальная установка CentOS с большинством пакетов yum устанавливается по мере необходимости.
Проблемы обнаруживаются как в Nagios, так и в других случаях, только в основном Nagios. Некоторые проверки выполняются каждые 5 минут, а некоторые - каждую минуту, так что я знаю о перекрытии, но оно не складывается.
Мы перезагрузили машины и сетевой материал. У нас есть 4 различных интернет-соединения, которые мы устанавливаем от Nagios, и все они работают в FIOS. Одной из проблем является наше подключение от Nagios к нашим машинам в стойке в реальном центре обработки данных. Машины там не сообщают или имеют какие-либо проблемы с сетью во время тайм-аута, только наш Nagios обнаруживает проблему с их получением. К счастью, сейчас эти машины попали в наше другое место, но мы бы хотели, чтобы они пришли в то место, где Нагиос находится для DR.
В другом месте есть кабели FIOS и Comcast, иногда Nagios их отключает. Наконец, он подключается к моему собственному серверу у меня дома по обычному кабелю comcast, который время от времени также истекает, и я могу проверить подключение, находясь на нем во время отключения.
ТАК, начиная с начала. У меня есть 2 экземпляра Nagios, работающих в местоположении A на FIOS, которые проверяют серверы в 3 других местах. Иногда тайм-ауты появляются на обоих Nagios, поэтому они кажутся «реальными» проблемами, в других случаях только один Nagios начинает колебаться, что не имеет смысла, так как оба сервера живут рядом друг с другом физически и в сети. Я просто перезагрузил основной Nagios снова.
Я собираюсь дождаться следующего выпуска и сообщить, что обнаруживают оба Нагиоса. Что я должен искать для устранения неполадок? Я просмотрел все журналы, настроил регистрацию на нашем маршрутизаторе, проверил сеть, пока проблема не возникает, и не могу понять, в чем проблема.
Спасибо за помощь!
Последнее обновление
Я обнаружил одну из проблем, которая не связана с ssh-атаками или другими проблемами на стороне сервера. У нас было 5-минутное отключение, из-за которого я не мог добраться до определенных мест из местоположения Nagios. Пинг остановился, но я смог пропинговать эти места / серверы из других мест. Я прослеживал во время и после простоя, который после 5-минутного периода время от времени происходил снова и снова, и обнаружил, что он останавливается на
G0-3-4-4.PHLAPA-LCR-22.verizon-gni.net (130.81.180.248)
Есть идеи или помощь? Вот трассировка во время проблемы, имена которой изменились:
[root@nagiosServer ~]# tracepath datacenterServer
1: ourdomain.com (192.168.1.55) 0.076ms pmtu 1500
1: ourRouter (192.168.1.1) 0.297ms
1: ourRouter (192.168.1.1) 0.258ms
2: L300.PHLAPA-VFTTP-164.verizon-gni.net (72.94.203.1) 4.817ms asymm 3
3: G0-3-4-4.PHLAPA-LCR-22.verizon-gni.net (130.81.180.248) 5.696ms
4: no reply
5: no reply
6: no reply
7: no reply
8: no reply
9: no reply
10: no reply
11: no reply
12: no reply
13: no reply
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
25: no reply
26: no reply
27: no reply
28: no reply
29: no reply
30: no reply
31: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
[root@nagiosServer ~]# date
Fri Apr 4 12:04:30 EDT 2014
[root@nagiosServer ~]#
И после того, как проблема решена:
[root@nagiosServer ~]# date
Fri Apr 4 12:04:51 EDT 2014
[root@nagiosServer ~]# tracepath datacenterServer
1: ourdomain.com (192.168.1.55) 0.081ms pmtu 1500
1: ourRouter (192.168.1.1) 0.253ms
1: ourRouter (192.168.1.1) 0.295ms
2: L300.PHLAPA-VFTTP-164.verizon-gni.net (72.94.203.1) 2.631ms asymm 3
3: G0-3-4-4.PHLAPA-LCR-22.verizon-gni.net (130.81.180.248) 6.390ms
4: so-3-1-0-0.PHIL-BB-RTR2.verizon-gni.net (130.81.22.60) 20.953ms asymm 5
5: 0.xe-2-1-0.BR2.IAD8.ALTER.NET (152.63.5.245) 13.855ms asymm 7
6: ae-20.r04.asbnva02.us.bb.gin.ntt.net (129.250.8.33) 13.123ms asymm 5
7: ge-100-0-0-20.r04.asbnva02.us.ce.gin.ntt.net (168.143.97.190) 14.057ms
8: core1-ten-2-1.nwrk1.hostmysite.net (67.59.145.33) 12.873ms asymm 15
9: ae5-dist1.nwk01.hosting.com (67.59.145.89) 12.912ms asymm 15
10: no reply
11: no reply
12: no reply
13: no reply
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
25: no reply
26: no reply
27: no reply
28: no reply
29: no reply
30: no reply
31: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
[root@nagiosServer ~]#
Обновление: сервер Nagios1 включен и работал (проверка SSH не выполнялась) в течение 3 часов, что, по моему мнению, является очень странной проблемой, поскольку сам Nagios проверяет, работает ли сама машина. Я проверил журналы и заметил попытку взлома в это же время в защищенном журнале, IP-адрес из Китая. Очевидно, что нам нужно заблокировать ssh и не предоставлять root, но я предполагаю, что если ssh имеет не более 10 устанавливающих соединений одновременно, это превышает его, предотвращая случайные сбои проверки ssh Nagios в это время. Надеемся, что после блокировки ssh/firewalling/ или использования ключей это устранит большинство проблем с тайм-аутом.
...
Host started flapping[03-22-2014 11:44:43] HOST FLAPPING ALERT: Nagios1;STARTED; Host appears to have started flapping (23.7% change > 20.0% threshold)
Host Up[03-22-2014 11:44:43] HOST ALERT: Nagios1;UP;HARD;1;SSH OK - OpenSSH_5.3 (protocol 2.0)
Host Down[03-22-2014 11:44:23] HOST ALERT: Nagios1;DOWN;HARD;2;Server answer:
Host Down[03-22-2014 11:43:33] HOST ALERT: Nagios1;DOWN;SOFT;1;Server answer:
Host Up[03-22-2014 11:43:23] HOST ALERT: Nagios1;UP;HARD;1;SSH OK - OpenSSH_5.3 (protocol 2.0)
Host Down[03-22-2014 11:42:53] HOST ALERT: Nagios1;DOWN;HARD;2;Server answer:
Host Down[03-22-2014 11:42:23] HOST ALERT: Nagios1;DOWN;SOFT;1;Server answer:
безопасный журнал:
...
Mar 22 11:43:02 Nagios1 sshd[12004]: Failed password for root from 59.63.167.224 port 60767 ssh2
Mar 22 11:43:02 Nagios1 sshd[11941]: Failed password for root from 59.63.167.224 port 58905 ssh2
Mar 22 11:43:02 Nagios1 sshd[11942]: Disconnecting: Too many authentication failures for root
Mar 22 11:43:02 Nagios1 sshd[11941]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=59.63.167.224 user=root
Mar 22 11:43:02 Nagios1 sshd[11941]: PAM service(sshd) ignoring max retries; 6 > 3
Mar 22 11:43:02 Nagios1 sshd[11995]: Failed password for root from 59.63.167.224 port 60545 ssh2
Mar 22 11:43:02 Nagios1 sshd[12009]: Failed password for root from 59.63.167.224 port 60919 ssh2
Mar 22 11:43:02 Nagios1 sshd[11997]: Failed password for root from 59.63.167.224 port 60632 ssh2
Mar 22 11:43:02 Nagios1 sshd[11952]: Failed password for root from 59.63.167.224 port 59362 ssh2
Mar 22 11:43:02 Nagios1 sshd[11960]: Failed password for root from 59.63.167.224 port 59716 ssh2
Mar 22 11:43:03 Nagios1 sshd[11943]: Failed password for root from 59.63.167.224 port 59237 ssh2
Mar 22 11:43:03 Nagios1 sshd[11988]: Failed password for root from 59.63.167.224 port 60277 ssh2
Mar 22 11:43:04 Nagios1 sshd[12004]: Failed password for root from 59.63.167.224 port 60767 ssh2
Mar 22 11:43:04 Nagios1 sshd[12001]: Failed password for root from 59.63.167.224 port 60672 ssh2
Mar 22 11:43:04 Nagios1 sshd[11995]: Failed password for root from 59.63.167.224 port 60545 ssh2
Mar 22 11:43:04 Nagios1 sshd[12009]: Failed password for root from 59.63.167.224 port 60919 ssh2
Mar 22 11:43:04 Nagios1 sshd[11997]: Failed password for root from 59.63.167.224 port 60632 ssh2
Mar 22 11:43:04 Nagios1 sshd[11952]: Failed password for root from 59.63.167.224 port 59362 ssh2
Обновление: только один новый тайм-аут, но на этот раз для хоста БД через соединение FIOS, а не через кабельное соединение. Nagios1 обнаружил это, но Nagios2 не сделал, это было кратко, поэтому он мог пропустить это.
Nagios1:
Service Ok[03-20-2014 21:34:53] SERVICE ALERT: hostDBFios;PG BACKENDS;OK;SOFT;2;POSTGRES_BACKENDS OK: DB "postgres" 9 of 100 connections (9%)
Service Critical[03-20-2014 21:34:03] SERVICE ALERT: hostDBFios;PG BACKENDS;CRITICAL;SOFT;1;CHECK_NRPE: Socket timeout after 10 seconds.
На хосте БД это находится в /var /log /messages:
Mar 20 21:34:01 hostdb nrpe[28248]: Could not read request from client, bailing out...
Mar 20 21:34:01 hostdb nrpe[28248]: INFO: SSL Socket Shutdown.
Я не понял, что это могло бы быть, ища ошибки, но большинство из них для постоянных проблем, а не случайных, возможно, что-то связанное с SSL/SSH?
ОБНОВЛЕНИЕ: новый тайм-аут ниже для проблемы 2.
Выпуск 2
До выпуска 1, который я опубликовал ниже, в [03-17-2014 19:37:50] произошел фактический сбой в одном из наших подключений к Интернету. Это бизнес-связь Comcast. Это иногда случается и случается до того, как я начал работать более года назад, но это проявляется в виде оповещения от DNS, упрощенного владельцем, а также Nagios1 и Nagios2. Мы можем списать это отключение, так и не получив ответа от Comcast, но, по крайней мере, оно определено для одного соединения и является полной потерей, которая быстро восстанавливается. Было бы неплохо устранить эту проблему, но это менее важно. Оба Нагиоса сообщают об этом отключении. У нас есть один сервер в этом соединении с несколькими предупреждениями, а другой сервер с именем hostDBCable здесь, у которого есть только предупреждение хоста, потому что его двойная сеть WAN - FIOS, и я наблюдаю за остальными службами в этом соединении:
Нагиос 2:
[03-17-2014 19:45:40] SERVICE ALERT: host81;DISK SPACE;OK;HARD;1;DISK OK - free space: / 410086 MB (94% inode=99%): /boot 81 MB (87% inode=99%): /dev/shm 3994 MB (100% inode=99%):
Service Ok[03-17-2014 19:45:10] SERVICE ALERT: host81;PGB BACKENDS;OK;HARD;1;POSTGRES_PGBOUNCER_BACKENDS OK: DB "pgbouncer" 1 of 1000 connections (1%)
Service Ok[03-17-2014 19:45:10] SERVICE ALERT: host81;PGB MAXWAIT;OK;HARD;1;POSTGRES_PGB_POOL_MAXWAIT OK: DB "pgbouncer" pgbouncer=0 * phoneworks=0 * phoneworksNew=0
Service Ok[03-17-2014 19:44:40] SERVICE ALERT: host81;MEMORY;OK;HARD;1;OK - 89.0% (7284288 kB) free.
Service Ok[03-17-2014 19:44:30] SERVICE ALERT: host81;MEMORY SWAP;OK;HARD;1;SWAP OK - 100% free (1983 MB out of 1983 MB)
Service Ok[03-17-2014 19:43:30] SERVICE ALERT: host81;CPU LOAD;OK;HARD;1;OK - load average: 0.14, 0.19, 0.18
Host Up[03-17-2014 19:41:50] HOST ALERT: host81;UP;HARD;1;SSH OK - OpenSSH_4.3 (protocol 2.0)
Service Ok[03-17-2014 19:41:40] SERVICE ALERT: host81;PGB MAX BACKEND;OK;HARD;2;OK - 2 connections
Service Ok[03-17-2014 19:41:40] SERVICE ALERT: host81;PGB MAXMAXWAIT;OK;HARD;2;OK - queries waiting 0.00 seconds
Service Ok[03-17-2014 19:41:40] SERVICE ALERT: host81;IVR LONG QUERY;OK;HARD;2;OK - No flag file
Service Ok[03-17-2014 19:41:40] SERVICE ALERT: host81;ERROR ASTERISK REBOOT;OK;HARD;2;OK - No ERROR found
Host Up[03-17-2014 19:41:10] HOST ALERT: hostDBCable;UP;HARD;1;SSH OK - OpenSSH_5.3 (protocol 2.0)
Service Critical[03-17-2014 19:40:40] SERVICE ALERT: host81;DISK SPACE;CRITICAL;HARD;1;Connection refused or timed out
Service Critical[03-17-2014 19:40:20] SERVICE ALERT: host81;PGB MAXWAIT;CRITICAL;HARD;1;CHECK_NRPE: Socket timeout after 10 seconds.
Service Critical[03-17-2014 19:40:10] SERVICE ALERT: host81;PGB BACKENDS;CRITICAL;HARD;1;Connection refused or timed out
Host Down[03-17-2014 19:40:10] HOST ALERT: hostDBCable;DOWN;HARD;2;CRITICAL - Socket timeout after 10 seconds
Service Critical[03-17-2014 19:39:50] SERVICE ALERT: host81;MEMORY;CRITICAL;HARD;1;CHECK_NRPE: Socket timeout after 10 seconds.
Service Critical[03-17-2014 19:39:30] SERVICE ALERT: host81;MEMORY SWAP;CRITICAL;HARD;1;Connection refused or timed out
Host Down[03-17-2014 19:39:00] HOST ALERT: host81;DOWN;HARD;2;CRITICAL - Socket timeout after 10 seconds
Host Down[03-17-2014 19:38:50] HOST ALERT: hostDBCable;DOWN;SOFT;1;No route to host
Service Critical[03-17-2014 19:38:50] SERVICE ALERT: host81;PGB MAXMAXWAIT;CRITICAL;HARD;2;CHECK_NRPE: Socket timeout after 10 seconds.
Service Critical[03-17-2014 19:38:50] SERVICE ALERT: host81;ERROR ASTERISK REBOOT;CRITICAL;HARD;2;CHECK_NRPE: Socket timeout after 10 seconds.
Service Critical[03-17-2014 19:38:40] SERVICE ALERT: host81;PGB MAX BACKEND;CRITICAL;HARD;2;Connection refused or timed out
Service Critical[03-17-2014 19:38:40] SERVICE ALERT: host81;IVR LONG QUERY;CRITICAL;HARD;2;Connection refused or timed out
Service Critical[03-17-2014 19:38:30] SERVICE ALERT: host81;CPU LOAD;CRITICAL;HARD;1;Connection refused or timed out
Host Down[03-17-2014 19:38:00] HOST ALERT: host81;DOWN;SOFT;1;CRITICAL - Socket timeout after 10 seconds
Service Critical[03-17-2014 19:37:50] SERVICE ALERT: host81;PGB MAXMAXWAIT;CRITICAL;SOFT;1;CHECK_NRPE: Socket timeout after 10 seconds.
Service Critical[03-17-2014 19:37:50] SERVICE ALERT: host81;PGB MAX BACKEND;CRITICAL;SOFT;1;CHECK_NRPE: Socket timeout after 10 seconds.
Service Critical[03-17-2014 19:37:50] SERVICE ALERT: host81;IVR LONG QUERY;CRITICAL;SOFT;1;CHECK_NRPE: Socket timeout after 10 seconds.
Service Critical[03-17-2014 19:37:50] SERVICE ALERT: host81;ERROR ASTERISK REBOOT;CRITICAL;SOFT;1;CHECK_NRPE: Socket timeout after 10 seconds.
Нагиос 2:
Host Up[03-19-2014 11:18:10] HOST ALERT: hostDBCable;UP;SOFT;2;SSH OK - OpenSSH_5.3 (protocol 2.0)
Host Down[03-19-2014 11:17:00] HOST ALERT: hostDBCable;DOWN;SOFT;1;CRITICAL - Socket timeout after 10 seconds
Выпуск 1
Отвечая на комментарии:
Трудно поймать некоторые из них или, если они возникают во время устранения неполадок, я не могу найти проблему. Последний тайм-аут был вчера и фактически остановлен, а не сервис, как в предыдущих выпусках. Проверка хоста - check_ssh.
Во время проблемы я работал из местоположения hostbw в. У меня не было проблем с интернетом, и я мог добраться до всех мест с hostbw. Nagios1 не может подключиться по ssh к hostbw, Nagios2 может. Казалось, это проблема с разрешением DNS, сервер Nagios1 мог nslookup hostbw найти правильный IP (это доменное имя для DynDNS), но он не мог ssh, сказал, что не может разрешить имя хоста, которое я считаю, но Nagios2 мог SSH. Я проверил оба сервера, и они настроены одинаково. Они оба имеют почти одинаковые /etc /hosts и /etc/resolv.conf, использующие маршрутизатор в качестве DNS. Есть идеи?
Nagios1:
Host stopped flapping[03-17-2014 19:23:50] HOST FLAPPING ALERT: hostbw;STOPPED; Host appears to have stopped flapping (3.9% change < 5.0% threshold)
Host Up[03-17-2014 15:39:00] HOST ALERT: hostbw;UP;HARD;1;SSH OK - OpenSSH_5.3 (protocol 2.0)
Host Down[03-17-2014 15:36:20] HOST ALERT: hostbw;DOWN;HARD;2;Usage:
Host Down[03-17-2014 15:35:10] HOST ALERT: hostbw;DOWN;SOFT;1;Usage:
Host Up[03-17-2014 15:29:00] HOST ALERT: hostbw;UP;HARD;1;SSH OK - OpenSSH_5.3 (protocol 2.0)
Host Down[03-17-2014 15:19:00] HOST ALERT: hostbw;DOWN;HARD;2;Usage:
Host Down[03-17-2014 15:18:30] HOST ALERT: hostbw;DOWN;SOFT;1;Usage:
Host Up[03-17-2014 14:59:00] HOST ALERT: hostbw;UP;HARD;1;SSH OK - OpenSSH_5.3 (protocol 2.0)
Host Down[03-17-2014 14:57:50] HOST ALERT: hostbw;DOWN;HARD;2;Usage:
Host Down[03-17-2014 14:56:40] HOST ALERT: hostbw;DOWN;SOFT;1;Usage:
Host Up[03-17-2014 14:54:00] HOST ALERT: hostbw;UP;HARD;1;SSH OK - OpenSSH_5.3 (protocol 2.0)
Host Down[03-17-2014 14:51:30] HOST ALERT: hostbw;DOWN;HARD;2;Usage:
Host started flapping[03-17-2014 14:50:20] HOST FLAPPING ALERT: hostbw;STARTED; Host appears to have started flapping (23.9% change > 20.0% threshold)
Host Down[03-17-2014 14:50:20] HOST ALERT: hostbw;DOWN;SOFT;1;Usage:
Host Up[03-17-2014 14:47:00] HOST ALERT: hostbw;UP;HARD;1;SSH OK - OpenSSH_5.3 (protocol 2.0)
Host Down[03-17-2014 14:45:10] HOST ALERT: hostbw;DOWN;HARD;2;Usage:
Host Down[03-17-2014 14:44:00] HOST ALERT: hostbw;DOWN;SOFT;1;Usage:
Host Up[03-17-2014 14:40:20] HOST ALERT: hostbw;UP;HARD;1;SSH OK - OpenSSH_5.3 (protocol 2.0)
Host Down[03-17-2014 11:03:30] HOST ALERT: hostbw;DOWN;HARD;2;Usage:
Host Down[03-17-2014 11:02:20] HOST ALERT: hostbw;DOWN;SOFT;1;Usage:
nagios2:
Host stopped flapping[03-17-2014 16:36:40] HOST FLAPPING ALERT: hostbw;STOPPED; Host appears to have stopped flapping (4.7% change < 5.0% threshold)
Host started flapping[03-17-2014 15:39:00] HOST FLAPPING ALERT: hostbw;STARTED; Host appears to have started flapping (20.1% change > 20.0% threshold)
Host Up[03-17-2014 15:39:00] HOST ALERT: hostbw;UP;HARD;1;SSH OK - OpenSSH_5.3 (protocol 2.0)
Host Down[03-17-2014 15:34:00] HOST ALERT: hostbw;DOWN;HARD;2;Usage:
Host Down[03-17-2014 15:33:30] HOST ALERT: hostbw;DOWN;SOFT;1;Usage:
Host Up[03-17-2014 15:27:40] HOST ALERT: hostbw;UP;HARD;1;SSH OK - OpenSSH_5.3 (protocol 2.0)
Host Down[03-17-2014 15:22:40] HOST ALERT: hostbw;DOWN;HARD;2;Usage:
Host Down[03-17-2014 15:22:00] HOST ALERT: hostbw;DOWN;SOFT;1;Usage:
Host Up[03-17-2014 12:46:00] HOST ALERT: hostbw;UP;HARD;1;SSH OK - OpenSSH_5.3 (protocol 2.0)
Host Down[03-17-2014 12:16:00] HOST ALERT: hostbw;DOWN;HARD;2;Usage:
Host Down[03-17-2014 12:15:40] HOST ALERT: hostbw;DOWN;SOFT;1;Usage:
Host Up[03-17-2014 11:22:00] HOST ALERT: hostbw;UP;HARD;1;SSH OK - OpenSSH_5.3 (protocol 2.0)
Host Down[03-17-2014 11:02:40] HOST ALERT: hostbw;DOWN;HARD;2;Usage:
Host Down[03-17-2014 11:02:10] HOST ALERT: hostbw;DOWN;SOFT;1;Usage: