Время ожидания удаленных подключений к SSH / HTTP параллельно из нескольких местоположений, но не PING, почему?

ВОПРОС: Время ожидания удаленных подключений к SSH / HTTP параллельно из нескольких мест, но НЕ ПИНГ, почему?

ВЫПУСК: Иметь веб-сервер с тайм-аутом удаленных подключений около 50% времени параллельно для подключений ssh / http, но НЕ пинг. Время простоя / безотказной работы нерегулярное и составляет периоды от 5 до 20 минут. Я провел проверки через две распределенные службы мониторинга, и журналы подтверждают, что я вижу локально. Выпуск идет 4-5 дней, круглосуточно.

ВОЗМОЖНЫЕ ВОПРОСЫ:

* Какие тесты я должен запустить с сервера на ресурсах?

* Какие тесты я должен выполнить для регистрации исходящих подключений с сервера?

* Какие тесты я должен запустить удаленно?

* Какие ключевые слова или фразы мне следует Google?

* Какие еще вопросы мне следует задать?

* Какую дополнительную информацию я должен предоставить?

ДОСТУП:

* У меня есть удаленный доступ ADMIN к серверу, но не физический доступ.

СИСТЕМА:

* Linux-CentOS-5.X, Apache-2.X

* Неизвестная виртуальная машина, но другие системы в той же сети не имеют проблем с удаленным подключением

СЕТЬ:

* Информация о сети неизвестна, но другие системы в той же сети не имеют проблем с удаленным подключением

Заранее спасибо!!!

_________________

ПОСЛЕДНИЕ ОБНОВЛЕНИЯ (1): «Ваш сервер по-прежнему отвечает на эхо-запрос во время этих отключений?» @Greg - Да, ping работает ... :-) ... но ssh / http не работают параллельно во время этих отключений. Кроме того, все тесты проводятся через статический IP-адрес. IP-адрес принадлежал IP-блоку в течение многих лет, но только назначался серверу.

ПОСЛЕДНИЕ ОБНОВЛЕНИЯ (2): Похоже, что PING от меня мешают подключению ssh / http. Выполнение автоматического набора из 10 запросов PING каждые 5 минут из распределенной сети компьютеров. Оставить PING включенным на следующие 10 часов, чтобы проверить, не работает ли ssh / http; что было бы новым шаблоном.

ПОСЛЕДНИЕ ОБНОВЛЕНИЯ (3): Итак, как пользователь SUDO я не могу просматривать журналы "/ var / log / messages" или Apache. Другие журналы не просматривались.

«ping» - это тестирование только до уровня 3/4 стека TCP / IP, где SSH и HTTP фактически являются приложениями, работающими на всех 7 уровнях. Приложения могут работать неправильно или перегружаться, в то время как стек TCP / IP продолжает работать. С учетом сказанного, некоторые возможные области для проверки включают:

Ведение журнала приложений для подключений (возможно, повторяется с одного или нескольких пультов)
Использование приложений и вспомогательных / вспомогательных приложений
Остановка и перезапуск приложений (если возможно / целесообразно) при сравнении условий / результатов регистрации
Проверка журналов брандмауэра
Запуск AWSTATS для возможного выявления тенденций HTTP, которые могут совпадать с событиями тайм-аута или журналированием

Таймауты HTTP и SSH происходят параллельно? Если это так, сопоставление журналов может также дать дополнительные подсказки относительно возможных общих событий / действий.

Бегать top для проверки памяти, пространства подкачки и количества процессов. У вас есть своп. Если нет, добавьте хотя бы подкачку на основе файлов.

Если количество процессов apache продолжает расти, возможно, вы захотите временно сократить количество процессов. Может быть атака отказа в обслуживании на Apache.

Вы можете использовать netstat для отслеживания входящих и исходящих соединений. netstat -nt | wc -l должен иметь относительно стабильное количество.

Попробуйте поискать отказ в обслуживании и утечки памяти.

Юзерленд жареный. Ядро может отвечать на эхо-запросы, но пользовательская среда заблокирована, поэтому ни одно приложение не может получать данные из сокетов.

Вы ждете определенного промежутка времени до перезагрузки (возможно, здесь помогает сторожевой таймер?), Поэтому существует короткий период отсутствия недостижимости ICMP ping.

Что показывают системные журналы? / var / log / messages и друзьям?