Я ищу способ диагностировать проблемы, такие как смерть подкачки, когда процесс всплытия памяти заполняет подкачку и убивает всю машину (например, apache).
Я уже использую кактусы, и я могу настроить nagios (хотя предпочел бы этого не делать) или munin, но, насколько я могу судить, они не могут записывать использование отдельных программ - только общий статус.
Я знаю, что могу запускать сценарий, который >> в какой-то файл каждые 30 секунд, но мне бы хотелось посмотреть, существует ли уже существующее зрелое решение.
Опять же, в идеале это было бы:
Имена процессов не известны и не должны быть известны заранее - идея состоит в том, чтобы просто позволить ему отслеживать, а затем взглянуть на основных нарушителей.
Моя система - Linux (OpenSUSE).
Если вам нужны только главные преступники, подумайте о том, чтобы бежать top с относительно большим интервалом (60 секунд плюс) в пакетном режиме. Вам может понадобиться более одного top работает, чтобы поймать главных нарушителей на нескольких ресурсах. Я настроил системы для запуска top в течение нескольких циклов при чрезмерном использовании ресурса.
Рассмотрите возможность бега sar в пакетном режиме для отслеживания использования ресурсов. Я понимаю, что это сервер, но он полезен для определения времени, когда возникают проблемы.
Бегать munin и включить уведомления. Это может дать вам возможность войти и посмотреть, как сервер выходит из строя. Возможно, вы сможете исправить проблему до того, как она выйдет из строя.
В случае утечек памяти постоянное увеличение использования подкачки указывает на проблему. Однажды я наблюдал, как сервер медленно умирает в течение нескольких дней. Проблемной службой была программа, отслеживающая другие процессы на предмет утечек памяти. Системный администратор настаивал на том, что увеличивающееся использование подкачки не является проблемой, вплоть до тех пор, пока сервер не перестал отвечать.
Вы можете обнаружить, что cfengineОбнаружение аномалий может использоваться для запуска сценария для захвата состояния системы, когда что-то идет не так. Вам может потребоваться много информации, помимо процессов, использующих наибольшее количество ресурсов. Для внезапного увеличения количества пользователей вам может потребоваться список сетевых подключений (по адресу, а не по имени). Использование памяти также полезно.
sysstat сделано в значительной степени именно для ваших целей.
Раньше я использовал поверх:
http://freshmeat.net/projects/atop/
"Atop - это полноэкранный монитор производительности ASCII, который может сообщать об активности всех процессов (даже если процессы завершились в течение определенного интервала), ежедневное ведение журнала активности системы и процессов для долгосрочного анализа, выделение перегруженных системных ресурсов с помощью цвета и т. д. Через регулярные промежутки времени он показывает активность на уровне системы, связанную с ЦП, памятью, подкачкой, дисками и сетевыми уровнями, и для каждого активного процесса показывает использование ЦП, рост памяти, приоритет, имя пользователя, состояние, и код выхода. "
Вы пробовали собирать?
Он очень мощный и настраиваемый.
Имеет множество плагинов и может быть интегрирован с nagios.
Центреон на вершине Нагиоса, Нагиос в сочетании с NRPE. Затем вы можете написать собственные сценарии для отчета о данных в ЛЮБОМ формате, который вы хотите для NRPE. Затем Nagios опрашивает данные с удаленных серверов с помощью NRPE, а Centreon создает красивый график и добавляет массу гибкости пользователям. Мы используем это в http://beyondhosting.net У меня уже есть шаблон VZ Container с настройкой centreon + nagios, если вы этого хотите.
Графики сборок centreon hostthenpost.org/tyler/2010-07-23_1719.png
nmon - отличный инструмент, который сделает то, что вы ищете. Разработано для AIX и Linux. Производит тонны подробных результатов и легко помещается в отчеты. Если вы погуглите, то найдете вики-страницу IBM, в которой есть куча документации и дополнительные утилиты для анализа данных.
Плотность сервера делает именно то, что вы описываете.
Я использую его на одном из наших производственных серверов и очень этому рад. Его главной особенностью является возможность просматривать диаграммы, щелкать пик и видеть потребление ЦП / памяти сервера в это текущее время, включая все запущенные процессы. Они называют это снимки.
Он постоянно улучшается. Одна из последних функций - обнаружение аномалии, что позволяет легко обнаруживать аномалии. Вы также можете установить различные пороги
http://studyhat.blogspot.com/2010/08/user-activity-view-processes-display.html
посмотрите выше ссылку небольшой код, который дает вам доступ к памяти процессора и т. д.
Ответы, предложенные, когда я спросил аналогичную вопрос:
Мунин это самый простой способ получить графики времени безотказной работы с минимальными усилиями при установке и настройке. Я также использую atop для совокупного использования процессора каким-либо процессом, но это не то, о чем Вы просили.
я использую собирать для записи загрузки системы среди ряда других параметров. Он хранит данные в RRD магазины, которые можно построить в виде графиков и иным образом проанализировать с помощью множества доступных инструментов и скриптов. Я использую модифицированную версию этот сценарий для моего графика (образец вывода).
В Collectd есть плагины для мониторинга большого количества вещей (всего, что обычно просят, и еще несколько вещей), и создание собственного не должно быть трудным, если вам нужно что-то специализированное, что делает инструмент очень гибким. Настройка графиков в rrd.cgi - это очень ручной процесс, хотя и не сложный, хотя вы вполне можете найти более удобный инструмент для работы с файлами RRD, поддерживаемыми collectd.
Мунин сделает все, что вам нужно, из коробки, не требуя Nagios или каких-либо других инструментов. Для OpenSUSE доступны пакеты RPM.
Может, старый добрый OProfile делает то, что вам нужно? Это профилировщик системного уровня на основе ядра с небольшими (несколько процентов) накладными расходами.
Тогда есть отличный сценарий Perl, PSMon, который позволяет вам устанавливать все виды ограничений ЦП / памяти. Если они превышены, psmon зарегистрирует ошибку и / или убьет нарушивший процесс.
Последний не будет предоставлять вам никаких отчетов о профилировании, но если он решает снова и снова прекращать один и тот же процесс, вы, вероятно, нашли мерзкого ублюдка, которого искали. :-)
