Я использую сервер Ubuntu Linux с Apache, wsgi, django и mysql. Недавно что-то случилось и процессы wsgi зависли. Перезапуск apache решил проблему. Как и в случае со многими действующими системами, лучше вернуть систему в рабочее состояние, чем возиться. Однако у нас возникают проблемы с диагностикой проблемы, поскольку все выглядело нормально, и мы не знаем полного состояния проблемы.
Есть ли какой-либо инструмент / команда (в linux / debian / ubuntu (или в любом другом варианте * nix, я могу скомпилировать любую команду)), которая при вызове запишет в файл некоторые сведения о состоянии системы как сейчас? Если / Когда это произойдет снова, мы можем просто запустить эту команду, затем приступить к тушению пожаров (перезапуск apache / сервера и т. Д.), А затем мы можем попытаться диагностировать проблему.
Список желаний, которые он будет записывать:
Теоретически это простой набор команд, и если никто другой этого не сделал, мы просто напишем свои собственные сценарии, но было бы лучше, если бы мы могли использовать подходящий инструмент.
В mod_wsgi 4.0 ведется работа по устранению проблемы, когда все потоки запросов WSGI блокируют что-то, что в конечном итоге и будет причиной этого. Как это затем приводит к блокировке Apache в целом и почему вы не можете выйти из Apache по этому поводу, в основном понятно.
Как часть нового механизма восстановления, который был реализован, mod_wsgi перед перезапуском заблокированного процесса демона попытается зарегистрировать минимальную трассировку стека каждого потока запроса WSGI, чтобы вы могли видеть, где был заблокирован код.
Также ведется работа по отслеживанию и отчету об использовании потоков, чтобы вы могли знать, когда потоки запросов по какой-то причине начинают блокироваться в вашем коде. Эти данные можно будет передать в такой инструмент, как New Relic, чтобы вы могли составить диаграмму, а затем проанализировать ее вместе со всей другой информацией о веб-запросах, которые агент New Relic Python собирает о вашем приложении.
New Relic также теперь имеет мониторинг сервера, поэтому он также может отслеживать разумный объем информации о системе в целом, активности диска, сетевой активности, процессоре, процессах и т.д. и т. Д. Таким образом, New Relic в целом является одним из возможных вариантов мониторинга ваша система.
В целом, по мере того, как позволяет время, делается много работы, чтобы упростить мониторинг mod_wsgi и улучшить его способность автоматически восстанавливаться, когда ваше приложение начинает зависать по той или иной причине.
Вы можете подумать о том, чтобы попасть в список рассылки mod_wsgi и следить за сообщениями об этом, или задать какие-либо конкретные вопросы по этому поводу, которые могут возникнуть в списке рассылки.
В общем, я надеюсь, что моя система мониторинга уловит условия, которые могут привести к сбою или спровоцировать его. Наличие какого-либо решения для мониторинга на основе истории поможет вам определить тенденции. Orca, Кактусы, Мунин... все они хорошо подходят для этого, если это отдельная система.
На стороне Red Hat / CentOS / Fedora у нас есть sosreport утилита, которая собирает подробную информацию об оборудовании и процессах.
Поскольку вы используете Ubuntu, это не совсем доступно. Я думаю ты можешь использовать Аппорт для некоторых бит (если вы можете привязать к своему приложению), но все остальное может быть комбинацией утилит: dmesg, dpkg, lshw, udevadm, dmidecode ...