ビジネスインテリジェンス（BI）

BIの実践的な適用を段階的に開始する前に、まずいくつかの用語を理解しておく必要があります:

BI で形式化された各アプリケーションは、多くの個々の状態から全体的な状態がアグリゲーションされるため、アグリゲーションと呼ばれます。

アグリゲーションは、オブジェクトの「ツリー」として構築されます。 これらのオブジェクトはノードと呼ばれます。 エンドノード（ツリーの葉）は、Checkmk サイトのホストおよびサービスです。 残りのノードは、人工的に作成された BI オブジェクトです。

各ノードはルールによって作成されます。 これは、ツリーのルート（最上位のノード）にも当てはまります。 これらのルールは、どのノードが別のノードに接続されるか、およびそれらの状態から上位のノードの状態をどのように決定するかを決定します。

集約のトップノード（ツリーのルート）も、ルールによって生成されます。 このようにして、1 つのルールで複数の集約を生成することができます。

これを理解する最も簡単な方法は、具体的な例を使用することです。 この記事のデモンストレーション用に、Mystery Applicationを特別に作成しました。 これは、不特定の組織における重要なアプリケーションであると仮定します。 とりわけ、5 台のサーバーと 2 台のネットワークスイッチが重要な役割を果たしています。 この例をよりよく理解するために、srv-mys-1 やswitch-1 などの単純な名前を使用します。 次の図は、この構造の概要を示しています。

以下の手順を 1 つずつ実行したい場合は、この例に示すように、監視オブジェクトを複製してください。 次の手順を 1 つずつ実行する場合は、例に示すように、既存のホストを複数回複製し、複製に適切な名前を付けるだけで十分です。 後で、いくつかのサービスを追加する必要がありますが、その時点で、監視に適切なホストを追加する時間があります。 ここでも、またごまかすことができます。 簡単なローカルチェックを行うと、すぐに一致するサービスを見つけることができます。

ホストは、監視画面では次のように表示されます。

まずは、できるだけ単純で意味のある集約、つまり 2 つのノードだけの集約という、簡単なものから始めましょう。 次に、ホストswitch-1 およびswitch-2 の状態をまとめます。 この集約は「Network」と名付け、両方のスイッチが利用可能な場合は「OK 」となるように設定します。 一部が故障した場合は、状態は「WARN 」となり、両方のスイッチがオフの場合は「CRIT 」となります。

開始:Setup > Business Intelligence > Business Intelligence を使用して BI を設定します。 ルールおよびアグリゲーションの設定は、設定パッケージ（BI パック）内で実行されます。 これらのパッケージは、より複雑な設定を適切に管理できるだけでなく、パッケージに許可を適用して特定の連絡先グループを割り当てたり、管理者権限のないユーザーにも設定の一部を編集する許可を与えたりすることができるため、実用性に優れています。 詳細については、後で説明します。

BI モジュールを初めて呼び出すと、次のような画面が表示されます。

Default Pack という名前のパッケージがすでに存在しています。 このパッケージには、個々のホストのデータを要約する集約のデモが含まれています。

この例では、[Add BI Pack ] ボタンを使用して、新しいパッケージを作成し、その名前を「Mystery 」と指定するのが最適です。 Checkmk ではいつものように、後で変更できない内部 ID (mystery) と、わかりやすいタイトルを指定します。 このパッケージに、他のユーザーが自分のルールや集約に使用したいルールがある場合、そのユーザーには [Public ] オプションが必要です。 おそらくは、一人で静かに実験を行いたいでしょうから、このオプションは使用不能のままにしておいてください。

作成後、メインリストに 2 つのパッケージが表示されます。

各エントリには、プロパティを編集するためのアイコン () と パッケージの実際のコンテンツを開くためのアイコン () があります。 ここでは、まず、Add rule から最初のルールを作成してください。

Checkmk ではいつものように、このルールにも一意の ID とタイトルが必要です。 ルールのタイトルは、ドキュメント機能だけでなく、後でこのルールによって作成されるノードの名前としても表示されます。

次のボックスは「Child Node Generation 」という名前で、最も重要です。 ここでは、このノード内のどのオブジェクトを要約するかを指定します。 これは、別の BI ルールを選択する他の BI ノード、または監視対象オブジェクト（ホストやサービス）のいずれかになります。

最初の例では、2 番目の選択肢 (State of a host) を選択し、2 つのオブジェクトを子供として作成します。つまり、2 つのホストswitch-1 およびswitch-2 です。 これは、Add child node generator ボタンを使用して行います。 ここでは、当然のことながらState of a host を選択し、各ホストの名前を入力します。

3 番目の最後のボックス「Aggregation Function 」では、ノードの監視状態をどのように計算するかを指定します。 これは、常にサブノードの状態のリストに基づいて行われます。 さまざまな論理リンクが可能です。

事前選択されているのは、Best — take the best of all node states です。 これは、すべてのサブノードがCRIT またはDOWN の場合、ノードはCRIT になることを意味します。 前述のように、ここではそうはなりません。 代わりに、Count the number of nodes in state OK を選択して、状態OK のサブノードの数を基準としてください。 ここでは、閾値として 2 と 1 が提案されています。 これは、まさに必要な設定であるため、最適です。

完成したフォームは、次のようになります。

Create をクリックすると、最初のルールが作成されます。

注 — ルールはまだアグリゲーションではないことを理解しておくことが重要です。 Checkmk は、これがすべてなのか、それともより大きなツリーの一部なのかをまだ認識できません。 実際の BI オブジェクトは、アグリゲーションを作成すると、ステータスインターフェイスに作成され、表示されます。 これを行うには、アグリゲーションのリストに切り替えます。

ボタンをクリックすると、新しい集約を作成するためのフォームが表示されます。 ここで入力する項目はほとんどありません。Aggregation groups で、任意の名前を指定できます。 この名前は、ステータスインターフェイスにグループとして表示され、そのグループ名を持つすべての集約が表示されます。 これは、ハッシュタグやキーワードと同じ概念です。Aggregation ID も通常どおり自由に割り当てることができますが、後で変更することはできません。

集約の内容は、Add new element で定義します。Call a rule 設定を選択し、Rule: で、先ほど作成したルール（およびそのルールが属するルールパッケージ）を選択します。

ここで、で集約を保存すれば完了です。 最初の集約がステータスインターフェイスに表示されます。ただし、switch-1 またはswitch-2 のホストが少なくとも 1 つ存在することが前提です。

すべて正しく実行すると、ステータスインターフェイスに最初の集計が表示されます。 最も簡単な方法は、Monitor > Business Intelligence > All Aggregations を使用することです。

BI ツリーの表示を詳しく見てみましょう。 次の例は、2 つのスイッチのうち 1 つがDOWN 、もう 1 つがUP である場合の、ミニアグリゲーションの表示です。 希望どおり、アグリゲーションはWARN 状態になります。

また、ホストとサービスを標準化するために、DOWN のホストは、CRIT のサービスとほぼ同じように扱われていることがわかります。 同様に、UP は、それに応じてOK になります。

ツリーの葉は、ホストおよびサービスの状態を示しています。 ホスト名（およびサービスの場合はサービス名）はクリック可能で、対応するオブジェクトの現在の状態に移動します。 さらに、チェックプラグインからの最後の出力も確認できます。

各集約の左側には、2 つのアイコン と があります。 最初のアイコン をクリックすると、その集約のみを表示するページに移動します。 これは、複数の集約を作成した場合に主に役立ちます。 たとえば、ブックマークとして最適です。 をクリックすると、可用性の計算に移動します。 これについては後で詳しく説明します。

ホスト名の左側には、興味深いアイコンがあります。 これは「もし、もし」の分析を行うためのものです。 その考え方は簡単です。 このアイコンをクリックすると、オブジェクトが別の状態にテスト的に切り替わります。ただし、これは BI インターフェース上でのみ行われ、実際の状態には影響はありません。 アイコンを複数回クリックすると、 (OK) から (WARN)、 (CRIT)、 (UNKNOWN) を経て、 に戻ります。

BI は、想定される状態に基づいて完全なツリーを構築します。 次の図は、実際に失敗したswitch-1 の他に、switch-2 もDOWN であると仮定した場合の最小のアグリゲーションを示しています。

これにより、集約の全体的な状態は、WARN からCRIT に変化します。 同時に、状態の色はチェックパターンで強調表示されます。 このパターンは、実際の状態が実際には異なることを示しています。 ホストまたはサービスの一部の変更は、全体的な条件とは関係がなくなる場合があるため、これは常に当てはまるわけではありません。たとえば、問題のホストまたはサービスがすでにCRIT である場合などです。

この「もし」の分析は、次のようなさまざまな方法で利用できます。

後者のシナリオでは、テストとして、サービス対象デバイスまたはそのサービスをに設定します。 その後、アグリゲーション全体がOK のままの場合、その障害は現在、冗長性によって補完されていることを意味します。

BI アグリゲーションをテストする別の方法があります。 それは、オブジェクトの実際の状態を直接変更する方法です。 これは、テストシステムで特に実用的です。

この目的のために、コマンドには Fake check results というホスト/サービスコマンドがあります。 デフォルトでは、これは管理者ロールでのみ使用できます。 この方法は、たとえば、この記事で使用しているスクリーンショットの作成に使用されています。このスクリーンショットでは、switch-1 がDOWN に設定されています。 これが、Manually set to Down by cmkadmin というテキストが表示される理由です。

ここに役立つヒントがあります。 この方法を使用する場合は、関連するホストおよびサービスのアクティブチェックを無効にしておくことをお勧めします。 そうしないと、次のチェック間隔で、それらはすぐに実際の状態に戻ってしまいます。 面倒であれば、Master Control スナップインを使用して、グローバルに無効にしてください。 ただし、後で必ず有効に戻すことを忘れないでください。

集約を作成する際、Aggregation Groups 入力の可用性について簡単に説明しました。 例では、ここで提案されたMain を確認しました。 名前は自由に設定でき、集約を複数のグループに割り当てることも可能です。

グループは、表示したい集約の数が増えた場合に重要になります。 グループに移動するには、All aggregations ページに表示されているグループ名をクリックします。上記の例では、単に「Main 」の見出しをクリックします。 もちろん、現時点でこの単一の集約しかない場合は、ほとんど変化はありません。 しかし、よく見ると、次のようなことに気づくでしょう：

このビューを頻繁に表示したい場合は、ブックマークに登録してください。サイドバーのBookmarks エレメントをブックマークに登録するとよいでしょう。

BI アグリゲーションを設定すると、ホストおよびサービスのコンテキストメニューに新しいアイコンが表示されます。

このアイコンをクリックすると、影響を受けるホストまたはサービスが含まれるすべてのアグリゲーションのリストが表示されます。

少し興味深いツリーができたところで、CMK が提供するさまざまな表示オプションについてもう少し詳しく見ていきましょう。 これらのオプションは、Display メニューからアクセスできるModify display options から開始します。 これにより、さまざまなオプションを含むボックスが開きます。 ボックスの内容は、ページに表示されているエレメントに常に一致しています。 BI の場合、現在 4 つのオプションがあります。

最後に、Refresh interval を30、60、または90秒に設定し、Entries per row で列数を指定できます。

表形式の表示に加え、Checkmk は BI アグリゲーションの視覚化もマスターしています。 アグリゲーションを新しい視点から、より明確に表示することができます。BI Visualization は、通常のアグリゲーションビューの からアクセスできます。

背景をクリックするとツリーを自由に移動でき、マウスホイールで表示全体を拡大縮小できます。 マウスポインタを個々のノードに置くと、そのノードに関連する状態情報がホバーウィンドウに表示されます。 マウスホイールでツリーの枝の長さを拡大縮小できます。

リーフノードをクリックすると、ホストまたはサービスの詳細ビューに直接移動します。 他のノードを右クリックすると、ノードのタイプに応じて、表示オプションや、たとえば、責任のあるルール自体（下の画像では「Edit rule 」）にアクセスできます。

設定を続けます。 いよいよ本題に入ります。 これまでの例はとても単純で、アグリゲーション内のすべてのオブジェクトを個別にリストアップすることが難なくできました。 しかし、より複雑になった場合はどうでしょうか？ 同じまたは類似の依存関係を何度も繰り返し作成したい場合はどうでしょうか？ アプリケーションが 1 つではなく複数のサイトを含む場合はどうでしょうか？ データベースの何百もの個別サービスを 1 つの BI ノードにマージしたい場合はどうでしょうか？

このような要件には、より強力な設定方法が必要になります。 そして、まさにこれが Checkmk BI が他のツールと一線を画す点であり、残念ながら、この点に関しては学習曲線が少し急になります。 また、Checkmk BI で「ドラッグアンドドロップ」による設定ができない理由もここにあります。 しかし、その可能性を知ったら、きっと手放せなくなるでしょう。

まず、パラメータから始めましょう。 次のような状況を考えてみてください。 2 つのスイッチがUP であるかどうかだけでなく、アップリンクを担当する 2 つのポートの状態も知りたいとします。 これは、全体としては次の 4 つのサービスに依存しています。

ここで、ノードSwitch 1 & 2 を拡張して、スイッチ 1 および 2 の 2 つのホスト状態を置き換え、それぞれにホスト状態と2 つのアップリンクインターフェースを示すサブノード を追加します。 この 2 つのサブノードは、Switch 1 またはSwitch 2 である必要があります。

実際には、2 つの新しいルール（スイッチごとに 1 つずつ）が必要になります。 新しいswitch ルールを作成し、それにパラメータを設定してこれを行うのが良いでしょう。 このパラメータは、親ノードからルールを呼び出すときに呼び出す変数です。ここでは、古いSwitch 1 & 2 ルールから提供することができます。 この例では、1 または2 のいずれかを渡すだけで済みます。 パラメータには、自由に名前をつけることができます。 ここでは、NUMBER という名前を使用します。 大文字のスペルは、ここではまったく任意です。 小文字の方が美しいと思う場合は、小文字を使用してもかまいません。

ルールの見出しは、次のように表示されます。

新しいルールの ID として「switch 」を選択できます。Parameters には、変数の名前「NUMBER 」を入力してください。 ここで重要なのは、変数がルールの「Rule Title 」で使用されていることです。そうしないと、両方のノードが「switch 」と呼ばれ、同じ名前になってしまうからです。 変数を使用する場合は、Checkmk の多くの場所で通常どおり、先頭と末尾にドル記号を付けます。 その結果、2 つのノードは「Switch 1 」と「Switch 2 」と呼ばれます。

正規表現については、もう一度詳しく見ておく価値があります。 サービス名の一致では、基本的に正規表現のみに関係することを暗黙のうちに前提としていました。 前述のように、プレフィックス一致があります。

したがって、BI ノードで、たとえばサービス名にdisk を指定した場合、Disk で始まる、当該ホストのすべてのサービスがキャプチャされます。

以下の原則が一般的に適用されます：

これは、最初は少し大胆すぎると思われるかもしれません。 なぜなら、存在すべき項目をコメントも付けずに単に省略することは危険ではないのか、と。

しかし、この概念がどれほど実用的であるかは、時間が経てばお分かりになると思います。 この概念により、さまざまな状況に対応できる「スマート」なルールを作成することができるからです。 アプリケーション内のすべてのサイトに存在しないサービスがありますか？ 問題ありません。そのサービスが存在するかどうかのみが考慮されます。 ホストやサービスを監視から一時的に除外することはできますか？ その場合は、エラーなどになることなく、BI から単に消えるだけです。 BI は、監視設定が完全であるかどうかを確認するためのものではありません。

ちなみに、この原則は明示的に定義されたサービスにも適用されます。 サービス名は、.* などの特殊文字が含まれていなくても、常に正規表現としてビューされるため、実際には存在しないからです。 これは常に自動的に検索パターンになります。

しかし、さらに自動化を進め、とりわけ変更に柔軟に対応することは可能です。 例で示した 2 つのアプリケーションサーバーsrv-mys-1 およびsrv-mys-2 の例を続けてみましょう。 ツリーは引き続き拡大します。Infrastructure ノードはレベル 2 に移動します。 そして、最終的なルートとして、The Mystery Application というタイトルのルールを設定し、その下にすべてを配置します。Infrastructure の横に、Mystery Servers という名前のノードを作成します。 このノードの下に、現在 2 台の不明なサーバーを配置します。 それぞれに、いくつかの汎用サービスがアグリゲーションされます。 結果は次のようになります。

ホスト検索と同様に、Create nodes based on a service search という子ジェネレータタイプもあります。 以下に例を示します。

ここでは、() （部分式を括る）をホストとサービスの両方で使用できます。 ここで、

また、インラインヘルプはいつでも を使用して表示できることをお忘れなく。

試みるうちに、子ジェネレータState of remaining services に遭遇したかもしれません。 これは、BI アグリゲーションにまだ分類されていないホストのサービスに対してノードを生成します。 これは、BI を使用してホストのすべてのサービスの状態を、付属の例のように、わかりやすく整理されたグループに結合する場合に便利です。

再び、ルールパッケージに戻ります。 BI でのすべての編集操作には、通常、管理者ロールが必要です。 より正確には、BI には 2 つの許可があり、これらはSetup > Users > Roles & permissions:

通常の監視ユーザーロールでは、2 つの許可のうち最初の 1 つだけがデフォルトで有効になっています。 したがって、通常の監視ユーザーは、自分が連絡先として定義されているルールパッケージでのみ作業することができます。 これは、[ルールパッケージの詳細] で設定します。

次の例「Permitted Contact Groups 」では、連絡先グループ「The Mystery Admins 」が認可されています。したがって、このグループのすべてのメンバーは、このパッケージのルールを編集できるようになりました。

ちなみに、Public > Allow all users to refer to rules contained in this pack を使用すると、他のユーザーに、ここに含まれるルールを少なくとも使用（つまり、他の場所で独自のルールを定義）することを許可し、そのルールをサブノードとして呼び出すことができます。

ステータスインターフェイスでの集約の実際の表示状況はどうなっていますか？ どの連絡先が何かを見ることができますか？

BI アグリゲーション自体には、権限を割り当てることはできません。 これは、ホストおよびサービスの表示設定によって間接的に行われ 、See all hosts and services のオプションによって制御されます。Setup > Roles & Permissions:

User ロールでは、この許可はデフォルトで使用不能になっています。 通常のユーザーは、共有ホストおよびサービスのみを表示できます。 BI では、これらは、少なくとも 1 つの共有ホストまたはサービスを含む BI アグリゲーションをすべて正確に表示できる形で表現されます。 ただし、このようなアグリゲーションには、認可されたオブジェクトのみが含まれるため、多少「薄め」になる場合があります。 つまり、ユーザーによって状態が異なる場合があります。

これが良いか悪いかは、お客様の要望によって異なります。 疑問がある場合は、許可を切り替えて、BI を経由して、一部のユーザーまたはすべてのユーザーが、連絡先ではないホストおよびサービスを表示できるようにし、アグリゲーションの状態がすべての人にとって常に同じになるようにすることができます。

もちろん、この問題は、実際には、一部のユーザーだけがその特定の部分の連絡先となっている、非常にカラフルにまとめられた集約がある場合にのみ問題になります。

BIはスケジュールダウンタイムを実際にどのように管理するのでしょうか？ この問題について、弊社では熟考を重ね、多くのユーザーと議論を重ねた結果、以下の結論に達しました。

BI が「ダウンタイム中」の状態を計算するルールを理解するには、スケジュールダウンタイムの実際の考え方を再確認しておくと役立ちます。 問題のオブジェクトは現在処理中です。障害が発生する可能性があります。オブジェクトが現在「OK 」であっても、そのオブジェクトに依存してはなりません。オブジェクトはいつでも「CRIT 」になる可能性があります。これは既知であり、文書化されています。したがって、通知はトリガーされないはずです。

この考え方は、BI にそのまま適用できます。 アグリゲーションには、現在ダウンタイム中のホストやサービスがいくつかあるかもしれません。 これらがOK であるかCRIT であるかは問題ではありません。メンテナンス作業中にオブジェクトが時々オフになったりオンになったりするのは、実際には偶然であるからです。 集約にダウンタイムオブジェクトがあるからといって、その集約をマッピングするアプリケーション自体が「脅威にさらされている」とすぐに判断して、「ダウンタイム中」とマークする必要はありません。 アプリケーションには、ダウンタイム中のオブジェクトの障害を補う冗長性がインストールされている場合もあります。 そのような障害が実際に集約の「CRIT 」状態につながる場合、つまり、冗長性が不十分で集約が実際に脅威にさらされている場合にのみ、Checkmk はそれを「ダウンタイム中」とマークします。 ここでも、オブジェクトの現在の状態は一般的に問題ではありません。

より簡潔に言えば、正確なルールは次のとおりです。

ホスト/サービスの「CRIT 」状態が、アグリゲーションの「CRIT 」状態につながる場合 そのホスト/サービスの「in downtime」状態は、アグリゲーションの「in downtime」状態になります。

重要：ホスト/サービスの実際の現在の状態は計算には影響しません。ダウンタイムにあるものは、BI ロジックでは「CRIT 」とみなされます。 なぜでしょうか？ スケジュールされたダウンタイム中に「UP 」または「OK 」の状態になることは、まったくの偶然であるからです。たとえば、ホストが、複数の再起動の間に数秒間「UP 」を報告した場合などです。

ここに別の例があります。 スペースを節約するため、2 台の謎のサーバーではなく、1 台のみの場合のバリエーションです。

まず、ホストswitch-1 がダウンタイム中です。Infrastructure ノードには、これは影響しません。switch-2 はダウンタイム中ではないため、Infrastructure もダウンタイム中ではないからです。 したがって、派生ダウンタイムを示すアイコンは表示されません。

しかし、srv-mys-1 のサービスMemory もダウンタイム中です。 これは冗長ではありません。 したがって、ダウンタイムは親ノードMystery Server 1 に継承され、Mystery Servers まで続き、最終的には最上位ノードThe Mystery Application まで続きます。 したがって、この最上位ノードもダウンタイムになります。

BI アグリゲーションをスケジュールダウンタイムに手動で設定することはできない、と上記で述べました。 しかし、実際には BI アグリゲーションでスケジュールダウンタイムを設定するコマンドがあるため、これは半分しか真実ではありません。 ただし、このコマンドは、アグリゲーション内の各ホストおよびサービスについてダウンタイムエントリを記録するだけです。 もちろん、これにより通常、アグリゲーション自体がダウンタイムとしてフラグが付けられますが 、これは間接的な手順にすぎません。

上記で、スケジュールダウンタイムの計算は、CRIT 状態を想定して行われていることを説明しました。 集約のプロパティでは、WARN 状態を想定するノードをダウンタイムとしてマークするように、アルゴリズムをカスタマイズすることができます。 このオプションは、Escalate downtimes based on aggregated WARN state と呼ばれています。

ダウンタイム中のオブジェクトは「CRIT 」であるという基本的な仮定は変わりません。 唯一の違いは、CRIT がWARNになることができる集約関数がある場合です。これは、最初の例「Count the number of nodes in state OK 」の場合でした。 この場合、2 つのスイッチのうち 1 つだけがダウンタイム中であれば、スケジュールダウンタイムはすでに受け入れられていたことになります。

スケジュールダウンタイムのプロセスとよく似ていますが、問題が承認された場合、その情報も BI によって自動的に計算されます。 この場合、オブジェクトの状態は確かに重要な役割を果たします。

ここでの考え方は、次の概念を BI に転送することです。 オブジェクトに問題があります (WARN 、CRIT) が、この問題は認識されており、誰かが対応しています ()。

この状態をアグリゲーションとして計算するには、次のようにします：

ただし、集約がWARN またはCRIT のままの場合、それは承認されたとはみなされません。 なぜなら、その場合は、承認されていない重要な問題が少なくとも 1 つ存在することになり、その結果、OK 状態が集約から削除されるからです。

ちなみに、BI アグリゲーションの問題を承認するためのコマンドも表示されますが、 これは、アグリゲーションで検出されたすべてのホストおよびサービス（現在問題のあるもののみ）が承認されることを意味するだけです。

凍結機能の使用は非常に簡単です： Aggregation Properties で「New aggregations are frozen 」オプションを有効にします。

これにより、保存時に集約が凍結されます。また、チェックマークが新たに設定されるたびに、集約が凍結されます。 集約が以前に存在していた場合でも（New aggregations …​ を参照している場合でも）、凍結されます。 凍結状態を解除するには、チェックマークを削除してください。

監視では、集約の横に新しい雪の結晶アイコンが表示されます。 これをクリックすると、相違点を表示するビューに移動します。 左側に凍結されたツリー、右側に変更が強調表示された現在のツリー（ここでは、backup3 サービスの削除）が表示されます。

現在の状態を再び凍結したい場合は、Commands > Freeze aggregations から実行できます。 ただし、注意してください。凍結された現在の状態は常に 1 つだけで、古い状態を含むヒストリーは保存されません。