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