Причины, по которым сервер недостижим, Как расследовать?

Один из моих серверов, на которых размещается mongoDB, иногда и «случайно» недоступен.

Через некоторое время он вернулся, как будто ничего не случилось.

В течение этого периода невозможно открыть туннель ssh (тайм-аут, даже не запрашивать пароль), все подключения приложений к размещенному MongoDB-перерыву, …

Я даже не уверен, что сервер все еще работает, и эта проблема может произойти 2 раза в день, как 1 раз в неделю.

К сожалению, я не могу найти никаких следов позорного отключения / перезагрузки или любых других подсказок о том, что происходит в это время.

Что я сделал до сих пор, чтобы исследовать:

foo@bar:/var/log$ who -b system boot Jun 22 09:25 

Ничего подозрительного здесь, сервер не загружался через 1 месяц.

Это может быть подтверждено boot.log:

 foo@bar:/var/log# tail boot.log 2016/06/22 09:25:34 Processing completed for Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9001 2016/06/22 09:25:34 Finished processing ExtensionsConfig.xml monit: /opt/foo/common/lib/libcrypto.so.1.0.0: no version information available (required by monit) monit: /opt/foo/common/lib/libssl.so.1.0.0: no version information available (required by monit) * Starting daemon monitor monit ...done. * Stopping System V runlevel compatibility 

Еще раз, я проверил последнего зарегистрированного пользователя, ничего не кажется неправильным:

 foo@bar:/var/log# last -x localadm pts/0 16.618.3.75 Tue Jul 19 14:37 still logged in localadm pts/0 16.618.3.75 Tue Jul 19 13:59 - 14:36 (00:37) localadm pts/0 16.618.3.75 Tue Jul 19 13:18 - 13:53 (00:35) localadm pts/0 16.618.3.75 Tue Jul 19 07:45 - 09:15 (01:29) localadm pts/3 16.618.3.75 Mon Jul 18 15:14 - 15:51 (00:37) localadm pts/0 16.618.3.75 Mon Jul 18 14:57 - 15:22 (00:24) localadm pts/0 16.618.3.75 Mon Jul 4 10:01 - 10:06 (00:05) localadm pts/0 16.618.3.75 Mon Jul 4 09:03 - 09:19 (00:16) localadm pts/0 16.618.3.75 Mon Jul 4 08:16 - 08:19 (00:03) localadm pts/0 16.618.3.75 Mon Jul 4 08:07 - 08:14 (00:06) localadm pts/0 16.618.3.75 Mon Jul 4 08:00 - 08:04 (00:04) 

Я также проверил задания cron, ни один из них не влияет на уровень запуска:

 foo@bar:/var/log$ cat syslog Jul 20 07:02:01 bar CRON[28967]: (localadmin) CMD (cd /opt/foo/stats && ./agent.bin --run -D) Jul 20 07:17:01 bar CRON[29489]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jul 20 08:02:01 bar CRON[30754]: (localadmin) CMD (cd /opt/foo/stats && ./agent.bin --run -D) 

(Я также вручную проверил каждую таблицу CRON на глобальном уровне и уровне пользователя: less /etc/crontab )

Сервер фактически является частью Azure Cloud (я не знаю, может ли это быть связано с проблемой).

Вы знаете, что еще может вызвать эту проблему?

Любая идея, как я могу исследовать дальше?

2 Solutions collect form web for “Причины, по которым сервер недостижим, Как расследовать?”

Сервер фактически является частью Azure Cloud

Ошибка может происходить в любом месте по сетевому пути между клиентом ssh client / mongo и сервером. Это может представлять собой большое количество компонентов, к которым у вас не будет доступа.

Ваш следующий порт захода (после проверки перезагрузки) должен быть поддержкой Microsoft (удачи с этим).

В то же время:

Проверьте свои системные журналы на наличие сообщений, относящихся к вашим сетевым устройствам.

Если это ничего не изменит, вам нужно настроить какой-то удаленный мониторинг для отслеживания сбоев. Помимо предоставления полезной информации для сотрудников службы поддержки для расследования проблемы, она также предоставляет вам возможность выйти из вашего контракта и перейти к другому провайдеру.

Из вашего вопроса я предполагаю, что проблема с производительностью или доступностью отсутствует, и это похоже на проблему с сетевым подключением и может быть связано с брандмауэрами на вашем клиентском или целевом сервере.

Существует несколько способов исследования.

Проверьте ответ ping

Traceroute для сервера от клиента и от клиентов к серверу traceroute and tracepath команд traceroute and tracepath

Попробуйте подключиться как по домену FQDN, так и по IP-адресу, а также проверить записи имени-сервера в /etc/resolv.conf , убедитесь, что они являются адресами ipv4.

Проверьте конфигурацию sshd на сервере

Проверить настройки тайм-аута подключения tcp

Отключите брандмауэр и se-linux в течение некоторого времени и повторите попытку, если это связано с этим.

Проверьте некоторые подсказки в /var/log/messages и /var/log/secure или /var/log/auth , /var/log/audit/audit.log т. Д.

Используйте tcpdump для проверки пакетов, возможно, это связано с проблемой tcp keepalive.

Читайте также эту статью

  • Мош и терминальное мультиплексирование
  • Сервер SSH на Ubuntu не работает
  • Разрешить пользователю подключаться с использованием SSH или SFTP, но ограничить домашний каталог (Centos7)
  • Как я могу вызвать запрос на кодовую фразу ssh key во время выполнения скрипта?
  • как проверить, работает ли ssh без подключения к серверу
  • «Операция не поддерживается» для setfacl внутри скрипта python
  • Перезапуск сетевой службы для локальной виртуальной машины через SSH
  • ssh не расшифровывает закрытый ключ rsa
  • могу ли я использовать ssh для отправки команды сборки для построения Android?
  • Почему запуск firefox (из командной строки) в VM запускает firefox на главной машине и наоборот?
  • Сервер, отказывающийся от открытого ключа с PuTTY
  • Linux и Unix - лучшая ОС в мире.