データソーススタイルガイドライン
最終更新日: 20 年 2023 月 XNUMX 日概要
監視エンジニアのチームは、データソースを効果的に作成するためのベストプラクティスやその他の推奨事項をいくつか考案しました。 データソースを作成または変更するときは、これらのガイドラインに従うことを強くお勧めします。
命名
- T彼はデータソース 名前 アカウント内でデータソースを識別するための一意の「キー」として機能します。 そのため、次のような命名基準をお勧めします。 ベンダー_製品_モニター 例えば： PaloAlto_FW_Sessions, EMC_VNX_LUN, Cisco_Nexus_温度, etc.
- 名前は「キー」として機能するため、お勧めします スペースを含まない.
- 一部のレガシーデータソースでは、マルチインスタンスとシングルインスタンスを区別するために名前の末尾にダッシュが含まれていましたが、これは不要になり、推奨されなくなりました。
- 表示名 デバイスツリー内のデータソースの表示目的でのみ使用されます。 そのため、デバイス自体の中でデータソースを識別するのに十分な詳細のみを含める必要があります。 たとえば、という名前のデータソース EMC_VNX_LUN の表示名を持つことができます LUN。
説明とテクニカルノート
- [説明]フィールドは、このデータソースによって監視される内容を簡単に説明するために使用されます。 この情報はデバイスツリーに含まれているため、説明するのに十分簡潔にする必要があります。 何 データソースはそうします。
- データソーステクニカルノートには、このモジュールを使用するために必要な実装の詳細が含まれている必要があります。 たとえば、親デバイスで特定のデバイスプロパティを設定する必要がある場合、またはこのデータソースが特定のOSまたはファームウェアバージョンにのみ関連する場合は、これらの詳細をここに記載する必要があります。
データソースグループ
- なぜなら データソース グループは、デバイスのデータソースツリー内に追加の層を提供します。グループ化は、特定のデバイスの補助データソースを「非表示」にする場合にのみ役立ちます。 たとえば、DNS、ホストステータス、および稼働時間のデフォルトのデータソースは、デバイスの主要な計測器ではないため、グループ化されています。 グループ化する必要があります システムの主要なインストルメンテーションを提供するデータソースのグループに使用されます。 たとえば、さまざまなNetAppメトリックを監視するための一連のデータソースをグループ化しないでください。これは、NetApp固有の監視をデバイスツリーで主要な可視性にするためです。
適用先と収集スケジュール
- の建設 に適用されます フィールドは、広すぎないように（たとえば、isLinux（）メソッドを使用して）、狭すぎないように（たとえば、単一のホストに）慎重に検討する必要があります。 通常、可能な場合は、DataSourceをsystem.categoryに（hasCategory（）メソッドを介して）適用し、対応するPropertySourceまたはSNMP SysOIDMapをビルドしてsystem.categoryを自動的に設定することをお勧めします。 使用の詳細については に適用されます フィールド、およびAppliesToスクリプト構文の概要については、を参照してください。 AppliesToスクリプティングの概要.
- コレクション Sスケジュールは、チェックするデータに適した間隔に設定する必要があります。 その計装 変化するs 迅速に（CPU）または迅速に警告することが重要（ping損失）には、 非常に 短い投票る などのサイクル 1 minute。 アラート間のより長い期間を許容できるアイテム、または変更頻度が少ないアイテム（RAIDシステムでのドライブ損失）、ディスク使用率 ）ポーリングサイクルを長くする必要があります - 多分 5 minutes。 ポーリングサイクルが長いほど、監視対象のサーバーにかかる負荷が少なくなります。、Cコレクター, およびLogicMonitor プラットフォーム.
アクティブディスカバリーの考慮事項
- Active Discoveryは、データソースが特定のタイプのXNUMXつ以上のインスタンスを監視するように設計されている場合、または頻繁に消えて再表示される可能性のある単一のインスタンスに対してのみ使用する必要があります。 監視対象のシステムに静的インスタンスがXNUMXつしかない場合は、PropertySourceを使用してインスタンスを検出し、それに応じてデバイスプロパティを設定することをお勧めします。
- 「インスタンスを自動的に削除しない」には注意が必要です。 設定。 このフラグを設定する必要があります の 監視対象のシステムに障害が発生すると、ActiveDiscoveryがインスタンスを検出できなくなる場合。 このような場合、「インスタンスを自動的に削除しない」を設定する必要があります。 そうしないと、障害の直後にActive Discoveryが実行されると、障害が発生したインスタンスが監視から削除され、アラートがクリアされます。 たとえば、ポート8888でTCP応答を監視するActiveDiscoveryによってアプリケーションインスタンスが検出された場合、アプリケーションに障害が発生してポート8888が応答しなくなった場合、ActiveDiscoveryでインスタンスを削除しないでください。
- Active Discoveryフィルターのコメントフィールドに適切な説明があることを確認します。これは、問題の診断にすぐに役立ちます。
- パラメータを定義するときは、値をハードコーディングするのではなく、デバイスプロパティの置換（## jmx.port ##など）を使用してみてください。
データポイントの構築
- [データポイント名]フィールドは、可能な場合、収集するオブジェクトを定義したエンティティによって使用される名前を反映する必要があります。 たとえば、SNMPデータポイントには、SNMPOIDに対応するオブジェクト名を使用して名前を付ける必要があります。 または、WMIデータポイントの場合、WMIに対応するWMIプロパティ名を使用する必要があります。
- すべてのデータポイントには、人間が読める形式の説明を含める必要があります。 特定のメトリックを説明することに加えて、説明フィールドには、測定で使用される単位を含める必要があります。
- 有効な値の範囲を設定して、受信データを正規化する必要があります。これにより、偽のデータがアラートをトリガーするのを防ぐことができます。
- アラートしきい値を持つ各データポイントのアラート遷移間隔は、慎重に検討する必要があります。 移行間隔は、アラート状態の即時通知（0または1の値）と一時的な状態（5以上の値）での潜在的なアラートの抑制のバランスを維持する必要があります。
- アラートしきい値が定義されているデータポイントには、カスタムアラートメッセージが必要です。 カスタマーアラートは、メッセージテキストの関連情報をフォーマットし、可能な場合はコンテキストと推奨される修正を提供する必要があります。
- 作成するすべてのデータポイントが、グラフ、複雑なデータポイント、またはアラートのトリガーのいずれかで使用されていることを確認してください。 それ以外の場合は使用されていません。
- アラートまたはレポートで使用する値を計算する必要がある場合にのみ、複雑なデータポイントを作成します。 表示目的でのみデータポイントを変換する必要がある場合は、仮想データポイントを使用してそのような計算をオンザフライで実行することをお勧めします。
グラフのスタイリング
- グラフ名は、グラフの表示内容を説明する固有名詞を使用する必要があります。 概要グラフの名前には、概要であることを示すtitleキーワードを含める必要があります（例： スループット別の上位インターフェース or LUNスループットの概要).
- グラフの垂直ラベルには、ユニット名（°C、％）、説明（bps、接続/秒、カウント）、またはステータスコード（0 = ok、1 =遷移、2 =失敗）のいずれかを含める必要があります。 スループットまたはその他のスケーリングされた単位を表示する場合は、から変換するのが最適です。 キロバイト/メガバイト/ギガバイトからバイトに変換し、グラフのスケーリングで単位乗数を処理します。
- グラフが適切にスケーリングされるように、グラフに適切な最小値と最大値を設定していることを確認してください。 ほとんどの場合、最小値は0で指定する必要があります。
- 表示の優先度を使用して、関連性の順序に基づいてグラフを並べ替え、最も重要な視覚化が最初に表示されるようにする必要があります。
- 行の凡例では、大文字とスペースが正しい適切な名前を使用する必要があります。
- グラフの色を選択するときは、ネガティブ/悪い状態には赤を使用し、ポジティブ/良い状態には緑を使用します。 たとえば、緑の「領域」を使用して合計ディスク容量を表し、前面の「赤」の領域を使用して使用済みディスク容量を表します。