C ++アプリケーションの監視

新しい集中監視ソリューション（Zenoss）を実装しています。サーバー、ネットワーキング、およびJavaプログラムの組み込みは、SNMPとJMXを使用すると簡単です。

ただし、問題は、大規模な異種（Solaris x86、RHEL Linux、Windows）環境でカスタムC ++アプリケーションを監視および管理するためのベストプラクティスは何ですか？

私が見る可能性は次のとおりです。

1. ネットSNMP

• メリット

1. 各サーバーに単一の中央デーモン
2. よく知られた規格
3. 監視ソリューションへの簡単な統合
4. サーバーでNet SNMPデーモンをすでに実行しています

1. 複雑な実装（MIB、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回記述する）
2. 起こりうる安定性の問題
3. かなり多くのメモリを使用して、各プロセスにJVMが必要
4. JMXはC ++開発者向けの新しいテクノロジーです
5. 各プロセスには独自のJMXポートがあります（各マシンで多くのプロセスを実行します）

• メリット

1. 各サーバーに単一の中央デーモン
2. JavaとC ++の両方の一貫した管理インターフェース
3. よく知られた規格
4. 監視ソリューションへの簡単な統合

1. 複雑さ（基本的に管理コードを2回記述する）
2. そのようなデーモンを見つけるか書く必要がある
3. JMXデーモンとC ++プロセスの間にプロトコルが必要
4. JMXはC ++開発者向けの新しいテクノロジーです

• メリット

1. JavaとC ++の両方の一貫した管理インターフェース
2. よく知られた規格
3. 監視ソリューションへの簡単な統合
4. 共有JVMモードで実行される場合、各サーバー上の単一の中央デーモン
5. やや単純な実装（コード生成が必要）

1. 複雑さ（コード生成、プロキシされたコードを生成するためにGUIと数回の調整が必要）
2. 可能なJNI安定性の問題
3. 各プロセスでJVMを必要とし、かなり多くのメモリを使用します（埋め込みモード）
4. Solaris x86（ディールブレーカー）をサポートしていません
5. Solaris x86をサポートしていたとしても、コンパイラ互換性の問題が発生する可能性があります（SolarisではSTLPortとForteの奇妙な組み合わせを使用しています）
6. 埋め込みモードで実行すると、各プロセスに独自のJMXポートがあります（各マシンで多くのプロセスを実行します）
7. 非C ++プロセスの共有JMXサーバーを除外する可能性があります（？）

合理的に標準化された簡単な解決策はありますか？

他に合理的な解決策がない場合、これらの解決策のどれがカスタムC ++プログラムに通常使用されますか？

私の直感は、Net SNMPが人々がこれを行う方法であるということですが、私は決定を下す前に、他の人の入力と経験が欲しいです。

私はZenossに精通していませんが、この種のことにnagiosを使用していたときは、c / c ++プロセスにソケットをリッスンさせ、診断とステータス情報を引き渡すカスタムnagiosプラグインを作成します。

最初のステップは、プロセスをリッスンするために使用するlibを選択することです。C++ソケットライブラリのようなものがそれを行います。そこには複雑なことは何もありません。プロセスをリッスンするだけです。

次に、特定の刺激が与えられたときにプロセスが送信する応答を定義する必要があります。これは本当に（少なくともnagiosでは）「サービス」を定義し、そのサービスに対応するシグナルをプロセスに送信することを意味していました。実行できる最も簡単なことは、実行中のプロセスに正常に接続できるかどうかを確認する「プロセスping」を作成することです。あなたがカスタムnagiosプラグインよりもそうする場合、少なくともプロセスはまだ生きています。

あなたができるはるかに洗練されたものがありますが、アイデアは十分に単純です。オブジェクト内にカプセル化されたプロセスリスニングコードの独自の小さなlibを記述し、実行可能ファイルを1つ（またはすべて）ビルドするときはいつでも、標準化された方法でカスタムc ++に組み込むことができます。

私の理解では、Zenossはこれを行うことができますされすぎ。

おそらくZenossはpythonであるため、リスニングc ++実行可能ファイルに接続するためにTwistedなどのカスタムプラグインを作成します。

私はあなたが名前を付けたこれらの製品に精通していませんが、Windowsの場合、perfmonを使用してメモリ消費を監視します。非ページプールフォールトなど、プログラムにメモリリークが含まれているかどうかを示す特別なカウンターがいくつかあり、それらは少ないため、時間がかかる場合があります監視する時間ですが、私の意見では、これは簡単なチェック方法です。

Windowsでは、リモートでもperfmonを使用して多くのことができます。または、WMIを使用して同じカウンターに接続し、それを（wmiで）自動化してアクションを実行します。

私は最近あなたと同じようなプロセスを経験したのでこれを取り上げています：C / C ++サービス（およそ3000です）。

SNMPが最も近くなりましたが、ソースと監視システムへの統合は面倒で、リアルタイムプロセスには適していません。

最終的に、共有メモリ技術を使用してオープンソースにするCMXという新しいソリューションを開発することにしました。こちらで確認できます： www.cern.ch/cmx。

私はC ++の側面についてはあまり詳しくありませんが、Javaでは、グラファイトと組み合わせてCodaHaleメトリックを幅広く使用しています。CodaHaleは、インスタンスごとにメトリックをインスタンスのローカルメモリに保存し、バックグラウンドスレッドを使用してメトリックを毎分グラファイトサーバーにフラッシュします（構成可能）。グラファイトでは、インスタンス全体を集計したり、障害のあるインスタンスを特定したりできます。グラファイトクラスターを維持する複雑さを望まない場合は、HostedGraphiteを使用できます。

このセットアップは、メトリック集計またはレポートの単一障害点がないことを意味します（時間ベースの集計はノード自体で発生し、レポート集計は分散グラファイトクラスター（またはホストされたグラファイト）で発生します）。

最後に、Seyrenを使用して、監視データに加えてアラートを提供できます。

Windowsを使用している場合は、イベントログに書き込み、WMIまたは同様のプロセスを使用してイベントを読み取る傾向があります。監視が必要な場合は、パフォーマンスモニターカウンターをアプリに追加し、perfmonにそれらを読み取らせます。どちらもWindowsのシステムサービスです。

Linuxでは明らかに柔軟性が高くなる傾向がありますが、nagiosスタイルのサーバーにデータを送信するカスタムソケットを使用して、nagiosスタイルのモニターが実装されているのを見てきました。

とは言っても、SMNPが使用されているいくつかの場所を見てきましたが、率直に言って、SMTPを使用しない理由がわかりません。特に、完全に異種混合の環境を実行している場合はそうです。