リソース グループの概要 (新しい UI)
最終更新日: 27 年 2023 月 XNUMX 日LogicMonitor でリソースをグループ化すると、管理が大幅に容易になり、アラートのしきい値、ダッシュボード、レポート、アラート ルーティング、およびリソース プロパティを構成するときに時間を節約できます。
リソース グループを使用すると、次のことができます。
- リソース ツリー内でリソースを整理し、ナビゲーションと読み込み時間を改善します。
- リソースのパフォーマンス、アラートのしきい値、およびプロパティをグループ レベルで管理します。
- グループ内のすべてのアイテムのダッシュボードとレポートビューを簡単に作成できます。
- グループまたはサブグループに基づいてユーザー権限をカスタマイズします。
一般的なグループ化戦略
リソースをグループ化する正しい方法は XNUMX つではありませんが、作業を効率化するための一般的な方法がいくつかあります。 通常、リソースのグループ化方法を変更することはそれほど難しくないため、リソース グループ構造が環境に最適になるように微調整する余地があることに注意してください。
重要度に応じたグループ化
運用にとっての重要度に基づいて、リソースをグループ化することを検討してください。 パフォーマンス メトリックが遅い重要なインフラストラクチャは、関心が高い可能性が高く、同じパフォーマンスの遅い QA リソースとはアラートのしきい値が異なります。 重要度が類似したリソースをグループ化すると、グループ内のすべてのアイテムにグループ アラートのしきい値を設定できるため、何百ものアイテムに対して個別のしきい値を構成することなく、運用インフラストラクチャのクリティカル CPU アラートとテスト環境インフラストラクチャのクリティカル CPU アラートを区別できます。 見る データポイントの静的しきい値の調整.
さらに、同様の重要度のリソースをグループ化すると、グループごとにアラートをルーティングできます。 たとえば、運用チームのメンバーに 24 時間年中無休で通知をルーティングする運用インフラストラクチャのエラー/重大なアラートに一致するアラート ルールをセットアップできます (例: 真夜中のテキスト メッセージまたは電話)。テスト環境のエラー/重大なアラートに一致し、午後 7:7 を過ぎた場合にチケット システムに通知をルーティングする別のルール。
チーム/組織構造に従ったグループ化
組織の構造に基づいてリソースをグループ化することを検討してください。 あなたの組織はどのように運営され、責任を分担していますか? 組織構造を反映したリソース グループ構造を持つことで、アカウント構成の他のすべての領域 (特にユーザー ロールとアクセス許可) が大幅に簡素化されます。 このようなリソース グループ構造は、チームが自分の仕事に関連するリソースをすばやく見つけるのに役立ち、各チームが担当するリソースにのみ変更を加えることができるように、各グループの役割を設定することができます。
組織構造に基づくグループ化は、次の方法でグループ化することを意味する場合があります。
- 機能 (例: データベース グループ、ネットワーク グループ、サーバー グループなど)
- 場所 (例: 各オフィスまたはデータセンターの場所のグループ)
- 顧客 (例: あなたは MSP で、顧客ごとにグループを持っています)
- ビジネス アプリケーション (たとえば、特定の Web サイトにサービスを提供するすべてのリソースをグループ化する)
さらに、この概念はサブグループにも適用されます。 たとえば、多数のリソースの監督を担当する NOC チームと、それらのリソースのサブセットを担当する小規模な機能チームがある場合、リソース グループの構造は次のようになります。
- NOC
- データベース
- ネットワーキング
- サーバー
リソースの関係によるグループ化
トラブルシューティングを迅速化し、関連するリソースのダウンタイムをスケジュールしやすくするために、相互の依存関係に基づいてリソースをグループ化することを検討してください。 たとえば、組織には、特定のリソース セットが使用できなくなる定期的なメンテナンス ウィンドウがありますか? これらのリソースをグループ化すると、メンテナンスによるダウンタイムをより明確に識別し、メンテナンス以外のリソースで発生する問題をより明確に識別できます。 単一のアプリケーションを構成するリソースをグループ化することもできます。 一般に、相互の関係に基づいてリソースをグループ化すると、特定のイベントがインフラストラクチャに与える影響を簡単に確認でき、その原因をより迅速に特定できるようになります。
サブグループ
必要な数のサブグループを追加できます。 上記の戦略はすべて、サブグループにも適用されます。 サブグループを導入する際に留意すべきXNUMXつの重要な点は次のとおりです。
- アカウント全体 (ダッシュボード、レポート、アラート ルール、ユーザー ロールなど) でリソース グループまたはサブグループを参照する場合は、グループ名の末尾にワイルドカードを追加する必要があります (「Production*」など)。 ワイルドカードを含むグループ名には、グループのサブグループのリソースが含まれます。
- プロパティ & しきい値 サブグループグループレベルで設定すると、親（またはそれ以上）のグループレベルで同じプロパティとしきい値の値が上書きされます。
リソースを複数のグループに含める
リソースは、複数のリソース グループのメンバーになることができます。 これらのグループ間で同じプロパティが定義されている場合、最も深いレベルのグループで設定されたプロパティが優先されることに注意することが重要です。 同じレベルの XNUMX つのグループで同じプロパティが設定され、リソースがこれらのグループの両方のメンバーである場合、どちらのプロパティが有効になるかの選択は非決定論的です。
静的リソース グループと動的リソース グループ
リソース グループには、手動と動的の XNUMX 種類があります。
静的リソース グループ
静的リソース グループには、静的メンバーシップがあります。 リソースまたはサブグループを手動グループに手動で追加または削除する必要があります (ただし、リソースは、 ネットワーク検出スキャン）。 LogicMonitor の API を使用して、手動グループからリソースを追加および削除することもできます。
動的リソース グループ
動的グループには動的メンバーシップがあります。 これは、リソースが特定の共通特性に基づいてグループに自動的に追加または削除されることを意味します。 通常、動的グループ化は、手動グループ化より少ない労力で組織化を強化するため、可能な限り動的グループ化を使用することをお勧めします。
注： リソースの「管理」権限を持つユーザーのみが動的グループを管理できます。 見る 役割.
動的グループは、グループへのリソースの自動割り当ての AppliesTo 基準を指定することによって作成されます。 見る リソース グループの追加 & AppliesToスクリプティングの概要.
リソースを動的グループに手動で追加することはできず、グループ基準を満たさなくなると自動的に削除されます。 たとえば、次のカスタム クエリを使用して、サンフランシスコ オフィスのグループを作成できます。 location =~ "San Francisco". リソースがサンフランシスコからロサンゼルス オフィスに転送され、 location プロパティが更新され、サンフランシスコグループに表示されなくなります。
動的グループのプロパティとしきい値は、手動リソース グループの場合と同じ方法で管理でき、グループ メンバーに継承されます。
注： 循環参照を回避するために、動的グループに自動割り当てされるリソースを決定する基準は、ホスト自体のプロパティのみを評価でき、ホストがメンバーであるグループから継承されたプロパティは評価できません。 同様の理由で、クエリ自体がクエリの結果を変更し、無限ループが発生する可能性があるため、systems.group プロパティも動的グループの ApplyTo スクリプトでの使用から除外されます。 グループ メンバーシップに依存する動的グループを作成する場合は、AppliesTo スクリプトでプロパティ system.staticgroups を使用します: join(system.staticgroups,”,”) =~ “production”.
次に、動的グループを使用する場合のいくつかのシナリオを示します。
- リソースのサブセットがカスタム ポートを使用する場合—たとえば、「ALT」で始まるすべての SQL サーバー名に MySQL 用に構成されたカスタム ポートがある場合、名前が「ALT」で始まるすべてのリソースを含む動的グループを作成できます。 その後、MySQL DataSource のクローンを作成し、それを編集してカスタム ポートを使用し、そのグループのみに適用できます。 名前が「ALT」で始まるアカウントに追加されたすべての既存および新規の MySQL サーバーには、元の MySQL DataSource ではなく、カスタム ポートを使用して複製された DataSource が自動的に割り当てられます。
- ダッシュボードウィジェットまたはレポートを生成するには— たとえば、特定のタイプのリソースのデータを表示するウィジェットまたはレポートがある場合、そのタイプのリソースのみを含む動的グループを作成し、ウィジェットまたはレポートを参照するように構成できます。動的グループ。 動的グループ基準に一致するアカウントに追加された新しいリソースは、ウィジェットまたはレポートに自動的に追加されます。
- 包括的に監視されていないリソースを特定するには— LogicMonitor は、DataSources をリソースに部分的に基づいて適用します。
system.sysinfo財産。 見る データソースをリソースに適用する方法. 通常、このプロパティは、リソースが追加されると自動的に設定されます。 ただし、system.sysinfoがリソースに設定されていない場合、LogicMonitor は、ping、http など、リソース固有ではない一般的なメトリックのみを適用する可能性があります。このシナリオでは、クエリを使用して動的グループを作成できます。system.sysinfo =~ ‘’コレクターが検出中に識別できなかったすべてのリソースをアカウントに含めます。 これにより、可能な限り包括的に監視されていないアカウント内のリソースを特定できます。
動的グループクエリの例は次のとおりです。
system.sysinfo =~ "Linux"–すべてのLinuxホストの動的グループを作成します。system.hostname =~ "lax"–LAXデータセンター内のすべてのホストの動的グループを作成します。hasCategory("Netscaler")–すべてのCitrixNetScalerの動的グループを作成します。system.hostname =~ "nyc" && system.hostname =~ "prod"–NYCのすべての本番ホストの動的グループを作成します。