Мониторинг приложений C ++

Мы внедряем новое решение для централизованного мониторинга (Zenoss). Объединить серверы, сетевые и Java-программы просто с SNMP и JMX.

Однако возникает вопрос: каковы наилучшие методы мониторинга и управления пользовательскими приложениями C ++ в больших гетерогенных средах (Solaris x86, RHEL Linux, Windows)?

Возможности, которые я вижу:

1. Чистый SNMP

• преимущества

1. один центральный демон на каждом сервере
2. общеизвестный стандарт
3. простая интеграция в решения для мониторинга
4. мы уже запускаем Net SNMP-демоны на наших серверах

1. комплексная реализация (MIBs, библиотека Net SNMP)
2. новая технология для разработчиков на C ++

• преимущества

1. один центральный демон на каждом сервере
2. общеизвестный стандарт
3. неизвестная интеграция в решения для мониторинга (я знаю, что они могут делать оповещения на основе текста, но насколько хорошо это будет работать для отправки телеметрии, такой как использование памяти, глубина очереди, емкость потока и т. д.)
4. простая реализация

1. возможные проблемы интеграции
2. несколько новая технология для разработчиков C ++
3. возможные проблемы с портированием, если мы переключаем поставщиков мониторинга
4. вероятно, предполагает разработку специального коммуникационного протокола (или использование структурированных данных RFC5424; я не знаю, поддерживает ли это Zenoss без специального кодирования Zenpack)

• преимущества

1. согласованный интерфейс управления для Java и C ++
2. общеизвестный стандарт
3. простая интеграция в решения для мониторинга
4. несколько простая реализация (мы уже делаем это сегодня для других целей)

1. сложность (JNI, слой между нативным C ++ и Java, в основном дважды пишу код управления)
2. возможные проблемы со стабильностью
3. требует JVM в каждом процессе, используя значительно больше памяти
4. JMX - новая технология для разработчиков на C ++
5. каждый процесс имеет свой собственный порт JMX (мы запускаем много процессов на каждой машине)

• преимущества

1. один центральный демон на каждом сервере
2. согласованный интерфейс управления для Java и C ++
3. общеизвестный стандарт
4. простая интеграция в решения для мониторинга

1. сложность (в основном, написание кода управления дважды)
2. нужно найти или написать такого демона
3. нужен протокол между демоном JMX и процессом C ++
4. JMX - новая технология для разработчиков на C ++

• преимущества

1. согласованный интерфейс управления для Java и C ++
2. общеизвестный стандарт
3. простая интеграция в решения для мониторинга
4. один центральный демон на каждом сервере при работе в режиме общей виртуальной машины Java
5. несколько простая реализация (требует генерации кода)

1. сложность (генерация кода, требуется GUI и несколько раундов настройки для создания прокси-кода)
2. возможные проблемы со стабильностью JNI
3. требует JVM в каждом процессе, используя значительно больше памяти (во встроенном режиме)
4. Не поддерживает Solaris x86 (прерыватель сделки)
5. Даже если он поддерживает Solaris x86, возможны проблемы совместимости компилятора (мы используем странную комбинацию STLPort и Forte в Solaris
6. каждый процесс имеет свой собственный порт JMX при запуске во встроенном режиме (мы запускаем много процессов на каждой машине)
7. возможно исключает общий JMX-сервер для процессов не на C ++ (?)

Есть ли какое-то достаточно стандартное, простое решение, которое мне не хватает?

Если нет других разумных решений, какое из этих решений обычно используется для пользовательских программ на C ++?

Мне кажется, что люди используют Net SNMP, но я хотел бы узнать мнение и опыт других, прежде чем принять решение.

Я не очень знаком с Zenoss, но когда я использовал nagios для такого рода вещей, мы заставляли процесс c / c ++ слушать в сокете и писать собственный плагин nagios, который передавал бы диагностическую информацию и информацию о состоянии.

Первый шаг - выбрать библиотеку , которую вы хотите использовать для прослушивания вашего процесса. Для этого подойдет что- то вроде C ++ Socket Library . Ничего сложного там нет ... просто заставь процесс слушать.

Затем вы должны определить ответ, который ваш процесс отправит на определенный стимул. Это действительно означало (по крайней мере, с помощью nagios) определение «сервиса» и последующую отправку процессу сигнала, соответствующего этому сервису. Самое простое, что вы можете сделать, это создать «пинг процесса», просто посмотрите, сможете ли вы успешно подключиться к запущенному процессу. Если вы это сделаете, то пользовательский плагин nagios знает, что процесс еще жив.

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

Насколько я понимаю, Zenoss тоже может это сделать .

Возможно, поскольку Zenoss - это python, вы напишите свой собственный плагин для него, используя что-то вроде Twisted для подключения к исполняемому файлу c ++ для прослушивания.

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

В Windows вы можете многое сделать с помощью perfmon, даже удаленно, или использовать WMI для подключения к тем же счетчикам, а также выполнить некоторую автоматизацию с ним (в wmi) для выполнения действий.

Я подхожу к этому, поскольку недавно мы прошли через тот же процесс, что и вы: мы искали легкое, неблокирующее решение с открытым исходным кодом, которое позволяло бы выставлять и впоследствии удаленно отслеживать метрики из служб C / C ++ ( у нас около ~ 3000).

SNMP подошел ближе всего, но интеграция в источник и систему мониторинга является проблемой и не подходит для наших процессов в реальном времени.

В итоге мы решили разработать новое решение под названием CMX, которое использует технологию разделяемой памяти, и сделали его открытым исходным кодом. Вы можете проверить это здесь: www.cern.ch/cmx .

Я не очень знаком с аспектом c ++, но в Java мы широко используем метрики CodaHale в сочетании с Graphite . CodaHale хранит метрики для каждого экземпляра в локальной памяти экземпляра, а затем использует фоновый поток, чтобы каждую минуту сбрасывать метрики на графитовый сервер (настраивается). В графите мы можем объединять экземпляры, а также выявлять неисправные экземпляры. Если вы не хотите усложнять обслуживание графитового кластера, вы можете использовать HostedGraphite .

Эта настройка означает отсутствие единой точки отказа для агрегирования метрик или создания отчетов, поскольку (агрегация на основе времени происходит на самих узлах, а агрегация отчетов происходит в распределенном графитовом кластере (или размещенном графите).

Наконец, вы можете использовать Seyren для предоставления оповещений поверх данных мониторинга.

Если вы работаете в Windows, вы, как правило, записываете в журнал событий, а затем используете WMI или аналогичный процесс для чтения событий. Если вам нужен мониторинг, вы добавляете счетчики монитора производительности в свое приложение и позволяете perfmon их читать. Оба являются системными службами в Windows.

В Linux он, очевидно, более гибок, но я всегда видел, как реализованы мониторы в стиле nagios с настраиваемым сокетом, отправляющим данные на сервер в стиле nagios.

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