Лучший подход для диагностики отказа веб-сервера
Вчера мои сайты не работали в течение короткого времени. Я вошел в систему на моем сервере, и моя первая реакция была перезапустить веб-сервер Apache. После этого все работало нормально. Поэтому я начинаю проверять показатели ганглиев, чтобы увидеть, что произошло. Было ясно, что за одну минуту до перезапуска Apache количество запросов к веб-серверу было очень высоким, превысив пределы Apache и заблокировав другие запросы.
Я проверил вручную журналы apache, отфильтровывая минуты трафика до и после перезапуска. Там не было никаких признаков что-то не так. Я также анализирую логи с помощью некоторых инструментов (awstats, скрипт для ботов и т. Д.) С похожими результатами. Я делаю то же самое с журналами ошибок, тщательно проверяя некоторые странные действия. Нет успеха
Поэтому я почти уверен, что проблема заключалась в внезапном увеличении количества запросов к веб-серверу apache. Но я не знаю, как это произошло, если это была атака, какая-то неприятная ошибка, проблема в приложении или что-то еще, чего я не знаю. Что вы будете делать, если на вашем веб-сервере произойдет нечто подобное? Какие еще инструменты вы используете? Какие еще логи вы проверяете? Было ли неправильно перезапустить веб-сервер в качестве первой меры для решения проблемы?
2 ответа
Re: перезагрузите сервер в качестве первой меры... Еще один замечательный пример "Это зависит":-)
Если это система, которая ДОЛЖНА БЫТЬ UP сервером, я не думаю, что перезагрузил бы ее сначала.
Я бы просмотрел логи, возможно, имел бы хвост -f в журнале apache, чтобы увидеть, что происходит в реальном времени.
Я также, вероятно, открыл бы другое окно и проверил бы, есть ли что-нибудь подозрительное через wireshark, просто чтобы посмотреть, какой трафик поражает (и уходит) систему.
В противном случае проверьте загрузку системы, активность диска, список процессов, активность сетевой карты, чтобы убедиться, что это трафик, а не программное обеспечение. Проверьте использование памяти / подкачки. Проверьте количество процессов Apache и посмотрите, не превышены ли они.
В большинстве случаев перезагрузка не обязательна, и хотя она и устраняет проблему, очевидно, она не решает, что вызвало проблему, означающую, что вы можете получить другой вызов (возможно, даже в более неудобное время), чтобы поторопиться и исправить его снова. Ни один сервер не должен обслуживаться с периодической незапланированной перезагрузкой.
Перезагрузка может быть способом отвлечь старших или пользователей от спины, когда тепло включено, но, с другой стороны, вы, возможно, упустили шанс выяснить, что именно происходит с проволокой. Странно, что атака внезапно прекратилась бы с перезагрузкой, если только это не был сканер портов или сканер веб-сервера, и в этот момент ваш "исчезающий" сервер мог сигнализировать о своем движении.
Если это система, которая должна быть постоянно включена, вам, возможно, придется рассмотреть какое-то решение по отказоустойчивости и балансировке нагрузки. Это также поможет с устранением неполадок и предоставит вам большую гибкость в диагностике проблем без потери соединения (хотя вам нужно иметь более автоматизированный мониторинг, чтобы сообщить вам, что система A имеет проблемы, но сайт все еще работает благодаря B, поэтому пользователи не будут скажу вам, что есть проблема).
У меня есть грубая, но довольно эффективная мера, которую я использую на веб-сервере apache, проявляющий подобные симптомы. У меня есть работа cron, которая работает каждую минуту
curl -s http://localhost/server-status > `date!`
Таким образом, если очередь сервера apache заполняется запросами (что иногда происходит по неизвестным причинам: Apache "забивается" определенными запросами), у меня есть журнал того, что произошло, что привело к запросам. Это также полезно для устранения неполадок в моменты высокой нагрузки.
Я также настоятельно рекомендую Cacti и Nagios для мониторинга