Моніторинг програм C ++

Ми впроваджуємо нове рішення централізованого моніторингу (Zenoss). Включення серверів, мереж та програм Java зрозуміло для SNMP та JMX.

Питання, однак, які найкращі практики для моніторингу та управління користувацькими додатками C ++ у великих, неоднорідних (Solaris x86, RHEL Linux, Windows) середовищах?

Я бачу такі можливості:

1. Чистий SNMP

• Переваги

1. єдиний центральний демон на кожному сервері
2. добре відомий стандарт
3. проста інтеграція в рішення для моніторингу
4. ми вже запускаємо чисті демони SNMP на своїх серверах

1. комплексна реалізація (MIB, Net SNMP library)
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. єдиний центральний демон на кожному сервері при запуску в спільному режимі JVM
5. дещо проста реалізація (вимагає генерації коду)

1. складність (створення коду, для створення проксі-коду потрібен графічний інтерфейс і кілька раундів налаштування)
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 зробить для цього. Нічого складного там немає .. просто змушуйте процес слухати.

Тоді вам слід визначити відповідь, яку ваш процес надішле, даючи певний стимул. Це справді означало (принаймні, з нагіосів) визначення «послуги», а потім надсилання процесу сигналу, який відповідав цій службі. Найпростіша річ, яку ви можете зробити, - це створити «ping-процес», просто побачити, чи вдало ви можете підключитися до запущеного процесу Якщо ви не користувальницький плагін 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 , і, чесно кажучи, я не можу побачити причину, чому ви б не скористалися ним, особливо якщо у вас повністю гетерогенне середовище.