拡張可用性（SLA）

Checkmk では、可用性を評価し、その評価に基づいて基本的なSLA 評価を設定することができます。 ただし、特定の期間における絶対的な可用性は、特に意味のある情報ではありません。 極端な例を挙げると、可用性が 99.9% の場合、年間ダウンタイムは 10 時間未満、正確には 8 時間 45 分 36 秒となります。 この 8.76 時間を 1 年間に配分すると、1 か月あたりの平均は 43 分強となり、多くのシステムでは許容範囲であると考えられます。 しかし、1 時間にわたって完全に停止すると、大きな損害が発生します。 このような停止は、可用性の評価に反映すべきであることは明らかです。

Checkmk の商業版をお使いの場合は、サービス品質保証 (SLA) 用の別機能をご利用いただけます。 SLA 機能は可用性データに基づいており、より詳細な評価が可能になります。

2つの基本的な評価タイプを実装できます：

複数のサイトに対して、1 つまたは両方のタイプを組み合わせることができます。たとえば、レポート期間中に特定のサービスが 90% 以上OK であり、2 分以上のイベントが 2 回までしか発生しない場合にCRIT 条件としてフラグが立てられるように設定できます。

これらの計算結果は、後で 2 つの形式でビューに表示することができます。

たとえば、ここでは、概要でファイルシステムの評価を確認できます。今日（右端の列に 3 つのアイコン）と過去 15 日間の評価が表示され、4 日前まで明らかな問題があったこともすぐにわかります。

では、これらの評価から何がわかりますか？ 一方では、完了したSLAの履行状況を確認でき、例えば顧客にこれらの評価を通知できます。 一方、障害の発生を事前に予測することもできます。 デフォルトでは、SLA 指標は、その値がCRIT を超えた場合に点灯します。 しかし、たとえば、サービスの許容CRIT 状態が80%に達した場合にCRIT に変わるように調整することもできます。その場合は、その前にWARN フラグに変わる可能性があります。

結局のところ、SLA は、ほとんどの場合、可用性データの分析から生成される非常に詳細なビューです。 これらは、後で 2 つの場所で表示されます。 1 つは、そこにリストされているすべてのホストおよびサービス（オプション）について、もう 1 つは、個々の SLA に具体的に関連付けられているサービスについてのみ、テーブルで表示されます。 2 つ目は、各サービスと SLA の組み合わせに関する包括的な詳細ページです。

SLA 機能の基礎は、可用性データです。 SLA 仕様に関する計算は、もちろん、生データインベントリ全体に適用されるわけではありません。結局のところ、SLA レポートは特定の期間を対象とする必要があります。 そのため、まず、SLA 要件を満たすべき期間、いわゆる「SLA 期間」を決定します。 たとえば、「毎月の監視期間において、サービスMyServiceの状態は、少なくとも 90% のOK でなければならない」とします。 この SLA 期間には、24 時間 365 日の運用におけるその月のすべてのデータが必ずしも（必然的に）使用されるとは限りません。 データは、セットアップで定義された期間に変換、つまり、おおよその勤務時間に制限することができます。

これにより、次のようなより具体的な要件になります。 「1 か月間（SLA 期間）の勤務時間（期間）である月曜日から金曜日 10:00 から 20:00 までの間、サービスMyServiceは 90%OK である必要があります（SLA 要求）」。 SLA と期間は相互に補完関係にあり、もちろん、期間は制限する必要はありません。 SLA 期間に生成されたすべての監視データを使用することができます。

要約すると、SLA 要件の計算のためのデータ基盤を制限するには、2 つの期間が必要です。

SLA 期間ごとに独立した結果が生成されます。 これらの個々の結果をテーブルにいくつ表示するかは、ビューで設定できます。 たとえば、営業日に限定した過去 5 週間を、5 つの個別の SLA 期間としてホストおよびサービスに直接表示することができます。

Checkmk では通常どおり、データソース（SLA 定義）と出力（ビュー）の間に、SLA 特定のサービスに割り当てるルールがあります。ただし、これは必須ではありません。 したがって、SLA は、指定されたサービスに適用される場合、通常 3 ステップのプロセスになります。

ビューを含む簡単な SLA を設定する方法は、次のとおりです。 ホストMyHost1 およびMyHost2 のファイルシステムは、1 週間のレポート期間において、少なくとも 90% の時間、OK の条件を満たしている必要があります（この例では、最大 80% に達しています）。 さらに、2 分以上、最大 5 回まで、WARN の条件を満たしてもかまいません。

まず、実際の SLA を作成します。 設定は、Customize > Business reporting > Service Level Agreements から行えます（なお、このメニュー項目は「もっと表示」モードでのみ表示されます）。

New SLA から新しい SLA を作成します。General Properties セクションで、まず一意の ID（ここではMySLA ）とタイトル（Filesystems など）を指定します。

SLA settings で、SLA period を希望する期間（Weekly など）に設定します。 これにより、この 1 週間の期間中は、以下の要件が常に有効になります。

ただし、実際の要件を設定する前に、[Filtering and computation options] で さらに制限を追加し 、この単純な SLA では必要のないオプションを設定することもできます。

次に、[SLA requirements ] セクションで、Add new timeperiod を使用して実際の要件を指定します。 期間を指定している場合は、前述の一般的な可用性について述べたように、SLA でもその期間を使用できます。Active in timeperiod で期間を選択するか、この例のように24X7 - Always を選択して、24 時間 365 日の運用に関する要件を定義します。Title で、90 percent OK などの意味のある名前を付けます。

Computation Type では、最初の要求に対して Service state percentage を選択し、Add state configuration から新しい基準を追加します。Monitoring state requirement の新しい段落が開きます。 90% 以上の可用性を要求するには、このレコードをOK 、minimum 、90 に設定します。 この値が不足すると、SLA は違反とみなされ、結果ページで後でわかるように、CRIT の状態になります。

おそらく、SLA は破られるまで待ってからCRIT に移行するのではなく、バッファが 50% 消費された時点でWARN に直接移行し、バッファが 10% 残った時点でCRIT に移行すべきでしょう。 SLA を実際に破るものは、broken を生成しますが、それ以上の状態の変化はありません（詳細については、以下の「SLA 詳細ページ」セクションで説明します）。 このような設定の場合は、Levels for SLA monitoring のボックスをチェックしてください。 ここでは、WARN およびCRIT への移行の残値を入力できます。 これで最初のリクエストは完了です。

次に、Add new timeperiod で2 番目のリクエストを追加します。 再び期間を設定し、Title で、 たとえば、Max 5 warnings of 2 minutes を名前として指定し、この場合は、Computation Type をMaximum number of service outages に設定します。 実際のリクエストは、Maximum 5 times WARN with duration 0 days 0 hours 2 mins 0 secs となります。

SLA によると、SLA 期間ごとに、サービスは、SLA が違反とフラグが立てられることなく、指定した状態を最大 5 回、1 回あたり 2 分まで発生することが許可されます。 この時点で、WARN の代わりに別の状態を指定することももちろん可能です。 また、Levels for SLA monitoring を使用して、SLA が実際にWARN またはCRIT で違反となるまでに、警告を発するインシデントの残数をさらに詳しく指定および決定することもできます。

前述のように、このような要件を追加して、詳細な SLA を組み合わせることができます。 しかし、この SLA に「反応」するサービスはまだありません。この例では、ルールがこの接続を行う必要があります。 このような SLA サービス接続がない状態で、これまでに作成した設定を使用する方法については、以下の「列固有の SLA 表示」で説明します。

SLA は、Setup > Services > Service monitoring rules > Assign SLA definition to service ルールセットを介してサービスに接続されます。 ルールを作成し、ルール固有のオプションAssign SLA to service を有効にして、SLA 定義MySLA （ここでは、タイトルFilesystems でリストされています）を選択します。

次に、[Services ] セクションの [Conditions ] で、目的のサービスに対するフィルタをさらに定義します。 これまでと同様に、ここでは正規表現を使用でき、この例のように、Filesystem を使用して SLA 定義をすべてのローカルファイルシステムにリンクすることができます。 オプションで、フォルダ、ホストタグ、および明示的なホストに対するルール固有のフィルタを使用して、すべてを制限することもできます。 この例では、ホストはMyHost1 およびMyHost2 です。

もちろん、この時点でサービスフィルタリングを省略し、SLA をすべてのサービスにバインドすることもできます。 列固有の SLA ビューを使用してそれを行う方がよい理由とその方法は、以下で説明します。

これで、SLA 定義MySLA を作成し、Filesystem で始まる 2 つのホストのすべてのサービスに SLA を関連付けました。 次に、SLA の新しいビューを作成します。 SLA の例では、2 つのホストと、そのファイルシステムサービスおよび SLA を表示する単純なビューで十分です。 明確にするために、現在 SLA が関連付けられていない Checkmk サービスも追加しています。 結果は、この章の最後にある画像のように表示されます。

Customize > Visualization > Views > Add view で新しいビューを作成します。 最初のクエリで、All services をDatasource として指定します。 単一のオブジェクトの情報をデフォルト値で表示するかどうか、次のクエリで確認します。No restrictions to specific objects.

General Properties に、ID (ここではMySLAView_Demo)、タイトル (My SLA Demo View など)、そして最後に、後で[Monitor] メニューの別の項目で SLA ビューを表示したい場合は、Workplace などのテーマを選択します。 このテストでは、その他の値はすべて変更せずにそのままにしておきます。

次に、Columns ボックスに移動し、最初はAdd column から、ビューの基礎となる 3 つの一般的な列Services: Service state 、Hosts: Hostname 、Services: Service description を追加します。

列セレクタには、SLA 専用の 2 つの列「Hosts/Services: SLA - Service specific 」および「Hosts/Services: SLA - Column specific 」も含まれています。 後者は、ビュー内の各サービスに対する固定の SLA 定義を表示します。これは、前述のように、すべてのサービスに対する SLA よりも優れた選択肢です。これについては後で詳しく説明します。

ここで、Hosts/Services: SLA - Service specific 列を追加します。 これで、SLAの結果を表示するためのさまざまなオプションが利用可能になります：

SLA timerange：SLA の結果を表示する期間を設定します。 たとえば、SLA 定義でレポート期間を「Monthly 」に設定し、ここで「Last Year 」に設定すると、12 件の個別結果が表示されます。 この例では、「SLA period range 」オプションを使用して、表示するレポート期間の数を直接指定しています。 5 期間/結果を設定するには、「Starting from period number 」を「0 」に、「Looking back 」を「4 」に設定します。

Layout options: デフォルトでは、このオプションはOnly Display SLA Name に設定されています。 SLA の結果を実際に表示するには、ここでDisplay SLA statistics を選択してください。 最大 3 つの異なるエレメントを選択できます。

この例では、3つのオプションすべてを有効にします。

Generic plugin display options: この時点で、停止/割合 SLA の表示について、レポート期間の概要 (テキスト) または個々の結果 (アイコン) のどちらを表示するかを定義します。 両方を表示するには、Show separate result for each SLA period の割合 SLA オプションをそのままにして、Service outage count display options をShow aggregated info over all SLA periods に設定します。

ビューを個々のホストごとにグループ化したい場合は、Grouping に列Hosts: Hostnameを追加してください。これにより、ホストが視覚的に分離されます。

ビューにはMyHost1 およびMyHost2 ホストのみを表示するため、最後のステップで、Context / Search Filters でHostname のフィルタを設定する必要があります。MyHost1|MyHost2 。 よりわかりやすいビューにするために、Service でフィルタを設定することもできます。たとえば、filesystem.*|Check_MK.* などです。 これにより、SLA によって監視されているファイルシステムサービスと、監視されていない対応する Checkmk サービスが表示されます。これにより、サービス固有の SLA 表示を使用した結果がよりわかりやすくなります。

これでビューの設定は完了です。Monitor メニューで選択すると、結果として、パーセンテージSLAの単一の結果として5つのステータスアイコンと、停止SLAのパーセンテージの要約が表示されます。もちろん、ファイルシステムサービスの行のみ表示され、Checkmkの行は空のままです。

サービス固有のビューには欠点があります。 同じサービスを異なる SLA に割り当てる複数のルールを作成することはできますが、これらのルールの最初のルールに割り当てられた SLA しか表示できません。2 番目の制御ルールの SLA を 2 番目の列に表示する方法はありません。

ただし、異なる固定の指定 SLA を持つ複数の列を簡単に表示することはできます。 このような列固有のビューは、たとえば、一部のホストまたはすべてのホストのすべてのサービスに適用する複数の SLA が必要な場合に便利です。 たとえば、ゴールド、シルバー、ブロンズの SLA を、ホストのサービスの隣にある別々の列で定義することができます。 これにより、サービス/ホストがどの SLA 定義を満たしているかが一目でわかります。 つまり、列固有のビューを使用すると、サービスに対して 1 つの SLA だけでなく、複数の SLA を表示することができます。

上記の例では、冒頭で述べた 3 つの手順、つまり SLA を作成し、それをサービスにバインドし、ビューにインストールしました。 列固有のビューの場合は、2 番目の手順を省略できます。 SLA を作成し、Hosts/Services: SLA - Column specific 列を含むビューを配置するだけです。 SLA の結果は、それぞれのサービスとは無関係に各行に表示されます。

次の図は、MyHost1 の上記の SLA ビューに、各サービスの SLA 結果 (Checkmk サービスの最大 3 回の停止) を表示する列を追加したものです。

これにより、サービス固有の表示と列固有の表示の違いが明確になります。 また、次のことも明らかになります。 Checkmk サービス用に特別に設計された SLA は、ファイルシステム列では当然、あまり意味がありません。 したがって、実装を開始する前に、これを徹底的にプランニングしておくことが重要です。

もう 1 つ、小さな注意点があります。サービス固有のビューのオプションで、上記の「Generic plugin display options 」に、停止時間と割合の SLA の設定があります。 列固有のビューのオプションにも、この 2 つが表示されますが、SLA に実際に停止時間と割合の基準が含まれている場合のみです。 ここでは、generic は適切ではなく、静的な、固定の SLA 定義が呼び出されます。 この SLA に属するオプションのみが表示されます。

SLA、サービス、およびビューを統合する方法は数多くあります。SLA で正確に表示したい内容を事前にしっかりとプランニングしておく必要があります。

SLA 情報をテーブルに統合することで概要をすばやく把握できますが、もちろん結果を詳細に検討することも可能です。 ビューで SLA データを含むセルをクリックすると、影響を受けるサービスの SLA 結果の詳細ページに直接移動します。

ここでは4種類の異なる情報が確認できます：

General information：ここでは、生可用性データ、つまり各期間の状態の概要としての SLA 計算結果、その下に SLA 要件の集計結果を見ることができます。

その後に、個々の SLA 要件に関する表が続きます。Timeline にはすべての状態が表示され、Result 行には個々のレポート期間の結果が表示されます。 ここには特別な機能があります。 例で説明したように、SLA レベルを設定しており、SLA が破られる前にCRIT になった場合、ここでは通常の赤いバーではなく、オレンジ色のバーで表示されます。 SLA が破られると、バーは赤色に変わります。 それを確認したら、結果バーにマウスポインタを移動すると、ツールチップで、その状態の原因となった個々のイベントを確認できます。 次の図では、3 つの許容停止のうち 2 つしか残っていないため、状態は「WARN」です。

このツールチップには、「SLA broken 」というメッセージも表示されます。

ビューの使用に関する小さな注意： 期間の「Aggregated results 」または「Result 」の結果バーにマウスを置くと、その期間が強調表示されます。これは、個々の要件と「General information 」の下の要約の両方で表示されます。 クリックすると、1 つまたは複数の期間を選択/選択解除できます。

最後に、SLA specification の下には、SLA の設定データが表示され、表示された結果を評価し理解するのに役立ちます:

可用性に関する記事では、BI アグリゲーションの可用性の使用方法についてすでに説明しました。 SLA は、少し回り道をして、アグリゲーションでも利用できます。 BI アグリゲーションの状態は、通常のサービスとして BI スペシャルエージェントで監視できます。 これは、たとえば、ビューに「Aggr Disk & Filesystems 」として表示され 、上記で既に使用した「Assign SLA definition to service 」ルールを介して SLA に関連付けることができます。 その結果、次のような表示になります。

スペシャルエージェントルールは、Setup > Agents > Other integrations > BI Aggregations にあり、ルールセットの説明はBI 記事に記載されています。

スペシャルエージェントには、関連するサイト、およびリモートサイトの場合はそのログインデータが必要です。 主な設定は、Filter aggregations で行います。 ここでは、監視に個別のサービスとして含めるすべての集約を指定します。By aggregation name (exact match) に、集約のトップレベルルールのタイトルを入力します（たとえば、Disk & Filesystems ）。その後、Aggr を新しいサービスAggr Disk & Filesystems として追加します。

必要なルール/集約の正確な名前は、たとえば、Setup > Business Intelligence > Business Intelligence > Default Pack - Aggregations:

注：ここでは混乱が生じるおそれがあります。 BI 設定では、ルールを使用して実際の集約、つまりロジックを作成します。これらのルールは、そのタイトルとしてAggregation Name としてここに入力されます。

実際には、SLA は、SLA 自体、ビューおよびサービスオプション、期間、ルール、そしてもちろん可用性データなど、さまざまな要素が相互に作用して成り立っています。 SLA の結果が予想と異なる場合は、チェーン全体をもう一度確認してください。 疑問点がある場合は、ペンと紙を使ってプロセス全体を視覚化すると、関連する情報を一目で把握でき、役立ちます。 以下の点を基本的なチェックリストとしてご利用ください。 期間

構成をチェックしたら、ビュー内のオブジェクトにコマンドを適用して、手動（偽の）状態変更およびスケジュールダウンタイムを使用して、SLA の機能を確認できます。

その場合は、影響を受けるビューの設定を開き、まず明らかなことを確認してください。 SLA を含む列がありますか？ ただし、矛盾するフィルタが原因である可能性が高いです。 ルールを使用して SLA をサービスに関連付けた場合、そのサービスは、[Context / Search Filters] のビューオプションから除外されていない必要があります。

サービスにバインドされた SLA には、もう 1 つエラーの原因があります。 前述のように、ビューには、各サービスに対して 1 つのルールにリンクされた SLA しか表示できません。 つまり、最初に一致したルールの SLA です。 対応するルールを作成した場合、それらは単に無視されます。 このような場合は、列固有の表示に切り替えることができます。

最も単純なフォームでは、SLA ステータスは、その要件が違反した場合にのみ GUI ビューで変更されます。 ステータスの変更を事前に通知するには、SLA レベルを設定する必要があります。