アラートノイズを削減するSNMPデータソースの作成方法

LogicMonitorには、事前に構築されたデータソース手動設定なしで数百台のデバイスを自動監視します。デバイスを追加するだけですぐに使用できます。

しかし、もしあなたが、ロジックモニター交換? サポートしている場合 SNMP バージョン、カスタム DataSource を構築して、必要なメトリックを正確に収集できます。

万能のブループリントはありません。デバイスや環境はそれぞれ異なります。しかし、適切なプロセスを採用することで、信頼性の高いSNMPデータソースを構築し、アラートノイズを増やすのではなく、削減することができます。

それでは、「このデバイスの可視性が必要です」という状況から、「信頼性が高く、ノイズの少ない、機能するデータソースを構築しました」という状況にどのように移行できるかを見てみましょう。

TL; DR

カスタムデータソースは、重要な早期警告メトリックに重点を置いて、固有のデバイスまたはサポートされていないデバイスを監視します。

必ず最初に既成のオプションを確認してください。既成のオプションがニーズを満たさない場合は、カスタムビルドが最適です。

適切な計画 (MIB のレビュー、構造化、スマートしきい値) により、データがクリーンに保たれ、アラートが制御されます。

データポイントとアラートを広範囲に展開する前に、実際の環境で検証します。

1. 監視すべきものを把握する

すべてのカスタムデータソースは、早期に発見したい問題から始まります。サーバーのメモリ不足かもしれません。スイッチポートが頻繁にフラッピングを起こし、ユーザーからの苦情が出るまで誰も気づかないかもしれません。あなたの目標は、障害に発展する前に、その問題を明らかにすることです。

これにはSNMPデータソースを使用します。SNMPデータソースを使用すれば、たとえカバーされていない情報であっても、環境内で実際に重要な情報を追跡できます。

まず、次の質問をします。

何が間違っているのでしょうか（または何が間違っているのでしょうか）？
もっと早くに発見できたのでしょうか?
次回は何について警告を受けたいですか?

CPU温度の上昇、エラー数の頻発、パフォーマンスの低下など、初期兆候が見られる問題もあれば、突然のドライブ障害など、兆候が見られない問題もあります。いずれにせよ、問題を把握することで、アラートノイズを増やすことなく適切なデータを表示する、焦点を絞った有用なデータソースを構築できます。

2. 自分で作るか、既存のものから始めるかを決める

あなたの前にカスタムデータソースを作成する本当に必要か、自分自身に問いかけてください。

LogicMonitorには、ルーター、スイッチ、サーバーなど、一般的なデバイス向けに構築済みのSNMPデータソースが豊富に用意されています。これらのデータソースはテスト済み、メンテナンス済みで、設定なしですぐに使用できます。お使いのデバイスが対象であれば、最初から設定する必要はありません。

しかし、すべての環境が標準的というわけではありません。ニッチなハードウェア、独自システム、あるいはエッジユースケースは、そのままではサポートされない場合があります。そのような場合は、カスタムメイドの導入が理にかなっています。

良い経験則:

データが利用可能であり、デバイスが一般的な場合は、すでに構築されているものから始めます。
メトリックが不足しているかカスタマイズが必要な場合は、独自のメトリックを作成するか、既存のテンプレートを変更します。

それでもまだ不安な場合は、類似のデータソースをインポートして微調整してみてください。データポイントを追加したり、しきい値を調整したり、インスタンス検出フィルターを整理したりといった調整が可能です。わずかな変更で、目的の結果が得られるかもしれません。

目標は、最小限の労力で信頼性の高い可視性を実現することです。そのため、効果的なものを活用し、必要に応じてカスタマイズしましょう。そして、疑問が生じた場合は、最初からやり直すのではなく、改善に注力しましょう。

SNMPデータソースを自分で作成する

UCCA現代美術センターがアップロードしたYouTubeで展覧会を見る

3. デバイスを少し偵察する

構築を始める前に、監視対象のデバイスについて理解を深めましょう。目標は、利用可能な指標、関連性のある指標、そして問題が深刻化する前にその兆候となる指標など、適切な指標を特定することです。

まずは引いてデバイスの管理情報ベース（MIB）。これにより、オブジェクト識別子（OID） SNMP経由で公開されます。そこから、どのようなデータを収集できるか、そしてそれが実際のパフォーマンスや障害にどのように対応しているかを調べます。

確認するときに、自分自身に次の質問をします。

最も壊れやすいもの、またはすでに壊れているものは何ですか?
失敗する前に早期警告サインはありますか?
問題を確認するだけの指標と、積極的に行動するのに役立つ指標はどちらですか?

すべてを監視する必要はありません。常に先手を打つのに役立つデータのみに焦点を当てましょう。ベンダーのドキュメントやコミュニティの知見が利用できる場合は、活用しましょう。

4. データソースの構造を計画する

次に、少し時間を取って構造を計画しましょう。これは単一インスタンスのDataSourceでしょうか、それとも複数のインスタンスが必要でしょうか？すべてをグループ化する方が良いでしょうか、それともメトリクスを特定のモジュールに分割する方が良いでしょうか？

これが私たちが提案するものです：

マルチインスタンス: ネットワークインターフェイス、電源、ファンなどの繰り返し使用されるコンポーネントに最適です。
単一インスタンス: 合計メモリや全体的な CPU 使用率などのシステム全体のメトリックに最適です。

すべてを1つのデータソースにまとめることも可能ですが、必ずしもそれが最善策とは限りません。CPU、メモリ、その他のメトリックグループを、それぞれ適切な名前を付けた個別のデータソースに分割すると、グラフ作成、アラート生成、継続的な管理がはるかに容易になります。

事前に少し構造化しておくと、後々多くの時間を節約できます。早い段階で正しく構築しておけば、残りのビルドがより速く進み、後で見直したときに理解しやすくなります。

5. 重要な指標を使ってラフバージョンを作成する

いよいよプロトタイプを構築しましょう。問題を早期に発見したり、効果的な対策を講じたりするのに役立つ指標から始めましょう。主要な指標ごとに、デバイスのMIBから適切なOIDにマッピングし、データソースのデータポイントとして定義します。

すべてのOIDが役立つわけではありません。CPU負荷、温度、使用可能なメモリといった実用的な情報を提供してくれるものもあれば、静的な値や、何の役にも立たない分かりにくいカウンターを返すものもあります。そういったOIDは無視しましょう。

何を含めるかを決めるときは、次の質問をしてください。

これは、問題が拡大する前にそれを捕捉するのに役立ちますか?
この値が変更された場合、アクションを実行しますか?

答えが「いいえ」の場合、クリーンかつ焦点を絞った DataSource の方が管理が容易で、生成されるアラートも少なくなるため、省略してください。

また、LogicMonitor でデータがどのように表示されるかをプレビューするのに適したタイミングです。メトリックのグラフが時間経過とともにどのように変化するかを確認し、ポーリングの動作を理解し、出力が使用可能であることを確認してください。最初から完璧である必要はありません。しかし、しっかりとした基盤を構築しておくことで、将来のチューニングやスケーリングがはるかに容易になります。

すべての急上昇にアラートが必要なわけではありません。チームが24時間7日グラフを監視する必要はありません。

6. アラート疲れを避けるためにスマートなしきい値を設定する

プロトタイプが動作したら、アラートのしきい値を微調整します。このステップにより、機能的なデータソースが本番環境で実際に役立つものへと変化します。

誤検知を回避し、真の問題に関するアラートを受け取ることが私たちの目標です。CPU使用率の急上昇やメモリ不足が常に重大なアラートをトリガーするようでは、チームはフラストレーションを感じ、重要なアラートを無視してしまう可能性があります。

機能するしきい値を設定する方法は次のとおりです。

意図を持って始める: 各データポイントが何を伝えているのか考えてみましょう。すぐに行動を起こす必要があるものか、それとも時間をかけて監視する必要があるものか？ インフォ (NAIST) と警告重要でない変更をフラグ付けし、 エラー (NAIST) と クリティカル 真のインパクトのために。
現実世界の行動に基づいて閾値を設定する: 履歴データを参考にして制限値を設定します。CPU使用率が一時的に急上昇するのは正常かもしれませんが、持続的に上昇するのは正常ではありません。動的なしきい値を設定することで、誤検知を減らし、アラートをより的確に把握できるようになります。
重要でないものをフィルタリングする: マルチインスタンスデータソースでは、検出フィルターを使用して、重要でないインスタンスからのノイズを除去します。影響の少ないインターフェースからの200件もの同じアラートではなく、関連性のあるアラートのみを検知する必要があります。
実用的な警告メッセージを書く「しきい値を超えました」のような曖昧なラベルを、「メモリ使用量が高い。暴走プロセスがないか確認してください」といった文脈に置き換えることで、中断が発生した場合の時間を節約できます。

しきい値を適切に設定するには、おそらく数回繰り返す必要がありますが、今努力することで、後でアラートのトリアージに費やす時間を何時間も節約できます。

7. 実際の環境でテストして、どのように機能するかを確認する

しきい値を設定し、LogicMonitor でデータソースが適切に表示されたら、実際の環境で検証します。ターゲットデバイスで実行し、ライブデータの収集を開始します。

次の 2 つの点を確認してください。

データは正確かつ完全ですか?
アラートは予想どおりに、それ以上でもそれ以下でもなく発動していますか?

ギャップが見られる場合はデータソースグラフ予期しない値や欠落データなど、何かがおかしい。 OIDが一貫してデータを返さない検出設定が広すぎるか狭すぎる可能性があります。スケールアウトする前に、これらの問題を修正しましょう。

可能であれば、実際の障害シナリオをシミュレーションしてください。ケーブルを外す、CPUのストレステストを行う、重要なサービスを停止するなどです。データソースが捕捉する条件をトリガーし、適切なアラートが発動することを確認してください。視覚的なレイヤーも見逃さないでください。明確で構造化されたグラフは、適切に調整されたアラートと同様に、トラブルシューティングを迅速化します。

すべてが期待どおりに動作することを確認したら、自信を持って DataSource を追加のデバイスに展開できます。

今、数時間テストを行うことで、後で週末にクリーンアップする必要がなくなります。