利用可能

Checkmk は、すべてのホストおよびサービスを定期的に継続的に監視 するため、それらの可用性を後で評価するための優れた基盤を提供します。 それだけでなく、オブジェクトが指定された時間範囲の何パーセントで指定された状態または複数の状態にあったか、 その状態がどのくらいの頻度で発生したか、最長の停止時間など、さまざまな情報を計算することもできます。 すべての計算は、選択したオブジェクトと、過去における指定した時間範囲に基づいて行われます。

すべての計算は、選択したオブジェクトと指定した 過去の時間範囲に基づいて行われます。Checkmk は、この時間範囲内で 、選択したすべてのオブジェクトの状態を時系列で再構築します。 各状態について、その時間が合計され、表に表示されます。 この表では、たとえば、特定のサービスが、定義された時間範囲内で 99.95 % のOK 、および 0.005 % のWARN の状態であったことを示すことができます。

このような計算を行う場合、Checkmk は、スケジュールダウンタイム、サービスダウンタイム、監視対象外の時間範囲、 その他の特別な要因も正しくアカウントに考慮し、 状態の要約、および「一時的な中断」の無視を可能にします。 また、数多くのカスタマイズオプションも利用可能です。BI アグリゲーションも利用可能です。 1.2. 可能な状態

スケジュールダウンタイムや同様の特別な状態を含めることで 理論的には、状態の組み合わせは膨大な数になります。 例えば、「CRIT + In Planned Downtime + In Service Time + Flapping」などです。 このような組み合わせのほとんどはあまり有用ではないため、Checkmk はこれらを 少数の組み合わせに絞り込み、優先順位に従って処理します。 上記の例では、サービスはスケジュールダウンタイム中でしたのでin scheduled downtime 状態が適用され、実際の状態は無視されます。 これにより、可能な状態のリストは次のように削減されます。

この図は、状態が優先される順序を示しています。後で、一部の状態を無視したり組み合わせたりする方法も説明します。 以下に、状態を詳細に示します：

可用性分析の生成は非常に簡単です。まず、ホスト、サービス、またはBI アグリゲーションのビューを取得します。 そこで、メニューのServices （可用性）またはHosts （アグリゲーション）にAvailability （可用性分析）項目があり、選択したオブジェクトの可用性の計算に直接移動できます。 データは表形式で表示されます。

この表には、前のビューで表示されたのと同じオブジェクトが表示されます。 各列には、要求された時間範囲のうち、オブジェクトが クエリの対象となった状態であった割合が表示されます。 値は、デフォルトでは小数点以下 2 桁のパーセンテージで表示されますが 、これは簡単にカスタマイズすることもできます。

時間範囲のクエリは、 Availability > Change display options > Time Rangeメニュー項目でカスタマイズできます。 これについては後で詳しく説明します。

このテーブルを PDF 形式で受け取ることもできます (商業版のみ)。 CSV 形式でデータをダウンロードすることも可能です。(Export as CSV) 上記の例では、次のように表示されます。

URL 経由で自身を認証できるオートメーションユーザーを使用すると 、データを取得することもできます（例：wget またはcurl ）。そして、スクリプト制御でデータを自動的にプロセス処理することができます 。

この記号は、テーブルのすべての行にあります。 このボタンをクリックすると、関連するオブジェクトのタイムライン表示に移動し 、指定した時間範囲（ここでは省略）に発生した状態の変化が正確に項目別に表示されます 。

役立つヒント：

前述のように、 記号を使用すると、タイムライン に期間に注釈を追加することができます。 コメントを入力するための事前入力済みのフォーム（「プロパティ」）が用意されています。

これにより、必要に応じて、さまざまな値で時間範囲を定義および拡張することができます 。これは、たとえば、繰り返し状態変化が発生した より大きな時間スライスに注釈を付けたい場合に便利です。 サービスの入力を省略すると、注釈はホストに対して作成されます。 これにより、その注釈はホストのすべてのサービスに自動的に関連付けられます。

すべての可用性ビューでは、時間範囲および 表示されているオブジェクトに適用されるすべての注釈が自動的に表示されます。

しかし、注釈には追加機能があります。 ダウンタイムを遡って入力したり、逆に削除したりすることができます。 可用性分析では、これらの修正は「通常の」ダウンタイムとまったく同じように アカウントに反映されます。これには、少なくとも 2 つの正当な理由があります。 運用中に、計画されたダウンタイムが誤って入力される場合があります。

ダウンタイムを再分類するには、[Reclassify downtime of this period ] チェックボックスを選択してください。

可用性テーブルでは、タイムラインの記号の横に、さらに別の 記号があります。これをクリックすると、 関連するオブジェクトとクエリの時間範囲が事前に設定されたフィルタが適用された監視履歴のビューが表示されます。 ここでは、可用性分析の基礎となったイベント（状態の変化）だけでなく、 関連する通知や類似のイベントも表示されます。 ここで表示されないのは、クエリの開始時点におけるオブジェクトの状態です。

ここで表示されないのは、クエリの期間開始時のオブジェクトの状態です。 可用性計算は、開始状態を確実に決定するために、さらに過去までさかのぼって 確認します。

表示のフォーマットに影響を与えるオプションは数多くありますが、その中には 計算方法に影響を与えるものもあります。まず、表示について見てみましょう。

導入部で説明した状態は、さまざまな方法でカスタマイズ および凝縮することができます。これにより、非常に多様な評価フォームを 柔軟に生成することができます。このためには、さまざまなオプションがあります。

監視では、一時的な問題メッセージが頻繁に発生する場合がありますが、 通常の条件では、次のチェックが実行される（1 分後）までに、オブジェクトはすでにOK になっています。 また、閾値などを調整して、このようなケースを確実に把握する方法も見つかっていません。 一般的な解決策は、Maximum number of check attempts を 1 から 3 に設定して、通知がトリガーされるまでに許容する障害の数を増やすことです。これにより 、Soft states （ ）という概念が開発されました。これは、WARN 、CRIT 、または UNKNOWN状態を意味し、許容される試行回数が 「使い果たされる」まで

この機能を使用しているユーザーから、Checkmk の可用性 モジュールには、Hard states だけを使用して計算する機能がないのかという質問が時折寄せられます。 その理由は、より優れた解決策があるからです。 ハードステートを基準として使用することができます…​

Short time Intervals オプションははるかに柔軟でありながら、 非常にシンプルです。単に、状態が評価される前に超える必要がある時間長を定義するだけです。

時間値が 2.5 分 (150 秒) に設定されているとします。 サービスが継続的に「OK 」の状態であり、その後 2 分間「CRIT 」の状態になり、その後 「OK 」の状態に戻った場合、短い「CRIT 」間隔は単に「OK 」と評価されます。 ちなみに、逆の状況も同様に機能します。長い「WARN 」フェーズ内の短い「OK 」も同様に「WARN 」と評価されます。 一般的に、同じ状態が前後で短い時間間隔で続いた場合、同じ状態が評価されます。

一般的に、同じ状態が前後で 続く短い間隔は、同じ状態として評価されます。OK 、次に 2 分間のWARN 、そしてCRIT というシーケンスの場合、WARNは、定義された時間よりも短い時間であったとしても、持続します 。

時間を定義する際には、Checkmk の標準チェック間隔は 1 分であることをご留意ください。 したがって、すべての状態の持続時間は、おおよそ1 分の倍数になります。 エージェントの実際の応答時間は若干変動するため、これは 61 秒または 59 秒になる場合もあります。 そのため、値に正確な分を入力するのではなく、バッファを含める方が安全です。 そのため、この例では 2.5 分を使用しています。 3.5. 期間の影響

Checkmkの商業版 における可用性計算の重要な機能 は、これらの計算を期間に依存させることができることです。 これにより、個々のホストまたはサービスごとに時間を定義することができます。 この時間には、ホスト/サービスが利用可能であり、その状態が計算に使用されることが期待されます。 したがって、すべてのオブジェクトにはService period 属性があります。 手順は次のとおりです。

ここでは 3 つの簡単な方法があります。デフォルトのBase report only on service times は、定義された サービス時間以外の時間を非表示にします。非表示になった時間は 100% に算入されません。 サービス時間内の時間範囲のみが実際に考慮されます。 タイムライン表示では、残りの時間は「灰色」で表示されます。

Base report only on non-service times は逆の動作を行い 、実際には逆の表示を計算します。サービス時間外の可用性はどの程度でしたか？ 3 番目のオプションxml-ph-0000@deepl.internal は

3 番目のオプションInclude both service and non-service times は、 サービス時間の概念を完全に無効にし、 月曜日 00:00 から日曜日 24:00 までのすべての時間の計算を表示します。

ちなみに、ホストがサービス時間外の場合、Checkmk では、そのホスト上のサービスもサービス時間外であると 自動的に判断されるわけではありません。Service period for services では、サービスには常に独自のルールが必要です。

可用性を計算する場合、選択したオブジェクトの履歴全体を 再度開く必要があります。その詳細については 以下で説明します。特にCheckmk Raw では、そのコアには必要なデータのキャッシュがなく、 テキストベースのログデータを順番に検索する必要があるため、分析に時間がかかる場合があります。

意図せずに開始された可能性のある過度に複雑なクエリが Apache プロセスを拘束し、CPU を消費して 「ハング」状態にならないように、計算の継続時間を制限する 2 つのオプションがあります。 どちらもデフォルトで有効になっています。

Query time limit は、監視コアの基盤となるクエリの実行時間を 指定した時間内に制限します。これは 30 秒に事前定義されています。 この時間を超えた場合、分析は中止され、エラーが強調表示されます。 分析を長時間実行しても問題がないことが確実な場合は 、タイムアウトを手動で延長してください。

Limit processed data オプションは、多くのオブジェクトを含む計算から保護します。 ここでは、ビューと同様の制限が適用されます。 監視コアへのクエリが5000以上の期間を生成する場合、計算は警告とともに中止されます。 この制限は、データが収集されるコアで事前に処理されます。

Checkmk の可用性計算の強力な機能は、BI アグリゲーションから可用性を計算できることです。 この機能の大きな魅力は、Checkmk が、この目的のために、個々のホストおよびサービスの状態のプロトコルを使用して、特定の時点における各アグリゲートの正確な状態を遡って再構築する点にあります。 なぜこれほど時間と労力を費やす必要があるのでしょうか？ アクティブなチェックで BI アグリゲーションをクエリし、その可用性を表示すれば良いのではないでしょうか？ その答えは、ユーザーにとって多くの利点があるからです。

なぜこれほど手間と時間がかかるのでしょうか？アクティブチェックで BI アグリゲーションをクエリし、その可用性を表示すれば良いのではないでしょうか？ この手間には、ユーザーにとって多くの利点があります。 BI アグリゲーションの構築は後から変更でき、その可用性を再計算することができます。

可用性ビューの取得は、最初はホストおよびサービスの可用性ビューの取得と同様です。 1 つ以上の BI アグリゲーションを含むビューを選択し、[BI Aggregations > Availability ] メニュー項目を選択します。 ここでは、2 つ目の方法も利用できます。すべての BI アグリゲーションには、 記号を使用して、その可用性への直接パスが

計算自体は、サービスの場合と最初は同様ですが、Host down （利用可能）およびflapping （利用不可）列は、BI には存在しないため、表示されません。 4.3. タイムトラベル

大きな違いは、タイムラインビューにあります。 次の例は、デモサーバーの集約で、1 秒という非常に短い間隔でCRITになった場合です（これは、Short time intervals オプションの使用例として適しています ）。

障害の原因を知りたい場合は、魔法の杖を クリックするだけです。これにより、障害が発生した正確な時点に タイムトラベルし、その時点での BI アグリゲーションの表示が開きます。 次の画像では、 すでに正しい場所で表示されています。

可用性を計算するために、Checkmk はアーカイブされた監視ヒストリー ログにアクセスし、その際に状態の変化を基準とします。 たとえば、2021 年 10 月 20 日 17:14 にサービスの状態が「CRIT 」に変更され 、その後 17:24 に「OK 」に戻った場合、この 10 分間の 期間、サービスは「CRIT 」の状態であったことがわかります。

これらの状態の変化は、監視ログに記録され、アラートタイプはHOST ALERT またはSERVICE ALERT となり、例えば次のように表示されます。

現在の時点までの最新のアクティビティのエントリを含む現在のログファイルと、 それ以前の期間のアーカイブを含むディレクトリが常に存在します。 これらのファイルの場所は、使用している監視コアによって異なります。 /var/check_mk/core/history

ユーザーインターフェースはこれらのファイルに直接アクセスするのではなく 監視コアから発行されるライブステータスクエリを使用してそれらを照会します。 これは、とりわけ 分散監視では、ヒストリーファイルはGUIと同じシステムには保存されない ため、重要です。

ライブステータスクエリは、statehist テーブルを使用します。log テーブルは、ヒストリーに「そのまま」アクセスできるのに対し 、statehist テーブルは、時間のかかる初期計算をすでに実行しているため、こちらを使用します。このテーブルは、とりわけ、ヒストリーをさかのぼって初期状態を決定する チェック、および同じ状態の期間、その開始、 継続時間、終了を計算するタスクを担当します。 この状態の圧縮手順は、この記事の冒頭で説明したように、ユーザー概要で アベイラビリティモジュールによって実行されます。

状態の凝縮手順は、この記事の冒頭で説明したように、ユーザー概要で 可用性モジュールによって実行されます。