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

transmission имеет инструмент для этого

$ transmission-show debian-stretch-DI-rc1-amd64-netinst.iso.torrent 
Name: debian-stretch-DI-rc1-amd64-netinst.iso
File: debian-stretch-DI-rc1-amd64-netinst.iso.torrent

GENERAL

  Name: debian-stretch-DI-rc1-amd64-netinst.iso
  Hash: 13d51b233d37965a7137dd65858d73c5a2e7ded4
  Created by: 
  Created on: Fri Jan 13 12:29:09 2017
  Comment: "Debian CD from cdimage.debian.org"
  Piece Count: 1184
  Piece Size: 256.0 KiB
  Total Size: 310.4 MB
  Privacy: Public torrent

TRACKERS

  Tier #1
  http://bttracker.debian.org:6969/announce

FILES

  debian-stretch-DI-rc1-amd64-netinst.iso (310.4 MB)
1
25.07.2016, 02:38
2 ответа

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

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

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

Между тем:

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

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

1
27.01.2020, 23:35

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

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

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

Трассировка к серверу от клиента и от клиента к серверу команды traceroute и tracepath

Попробуйте подключиться как по FQDN, так и по IP-адресу, проверьте записи name-server в /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.

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

1
27.01.2020, 23:35

Теги

Похожие вопросы