測定値とグラフ

グラフデザイナーは 4 つのセクションに分かれています。

ここでは、ライブで表示されるグラフを正確に確認できます。また、すべての インタラクティブ機能も使用できます。

グラフに含まれる曲線は、ここで直接編集することができます。 このフィールドで曲線のタイトルを変更する場合は、Enter キーで確定してください。Styleは、グラフの値の表示方法を定義します。以下のオプションがあります。

次の 3 つのオプション、Mirrored Line 、Mirrored Area 、およびMirrored Stacked は、曲線がゼロ線から下向きに描画される点を除いて、同様です。 これにより、Checkmk の入力/出力グラフで一般的に使用されるようなグラフのスタイルを使用できます。

Actions 列には、作成した各メトリックを複製するためのボタンがあります。これを使用すると、たとえば、ホスト名を簡単に置き換えるなど、曲線をすばやくコピーすることができます。

Metrics ボックスを使用して、グラフに新しいメトリックを追加できます。 最初のフィールドに有効なホスト名を入力すると、2 番目のフィールドに ホストのサービスのリストが表示されます。このリストから選択すると、 3 番目のフィールドにこのサービスのメトリックのリストが表示されます。4 番目の最後のフィールドで 、統合機能を選択します。ここでは、Minimum 、Maximum 、Average のオプションがあります。これらの機能は、指定した時間範囲の RRD に保存されているデータが すでに圧縮されている場合に使用します。たとえば、30 分ごとに 1 つの値しか利用できない範囲では、この時間範囲の 最小値、最大値、または平均の元の測定値をプロットするように選択できます。 同じように、 機能を使用して、 のサービスの値を表示することができます。

同様に、Add new scalar 関数を使用して、WARN 、CRIT 、最大値、最小値の値を水平線として表示することができます。

グラフに定数を追加することもできます。これは、最初は 水平線として描画されます。定数は、計算式を生成するために必要な場合があります。 これについては後で詳しく説明します。

グラフ全体に影響するオプションがあります。

Unit 軸と凡例のラベルに影響します。 デフォルト値「 」は、既知の単位を持つカスタムグラフの最初のエントリを単位として使用することを指定します。 つまり、メトリックおよびスカラー単位は常に既知ですが、定数の単位は不明となります。 既知の単位を持つエントリがない場合、グラフは単位記号なしで表示されます。 代わりに [ ] を選択すると、単位を自分で定義できる詳細設定が表示されます。 異なる単位の 2 つのメトリックを 1 つのグラフに追加することは可能ですが、お勧めはしません。First entry with unit Custom

Explicit vertical range を使用すると、グラフの縦軸を事前に定義することができます。 Y 軸は通常、選択した時間範囲のすべての測定値がグラフに正確に収まるようにスケーリングされます。 たとえば、パーセンテージ値のグラフを作成する場合、0 から 100 までの値を常に表示するように選択することができます。ただし、ユーザー（および あなた自身）は、マウスを使用してグラフをスケーリングすることができるため、 この設定は無効になります。

グラフデザイナーでは、計算を使用して個々の曲線を組み合わせることができます。 次の例は、2 つの曲線を含むグラフを示しています。CPU 使用率、User およびSystem 。

このグラフでは、2 つの曲線の合計のみに関心があるとします。 そのためには、両方の曲線の選択ボックスをチェックします。 これが完了すると、Metrics パネルのOperation on selected metrics行に 、使用可能なすべての操作用の新しいボタンがいくつか表示されます。

「Sum 」をクリックすると、両方の曲線が新しい曲線に結合されます。この新しい曲線の 色は、2つの入力曲線の色の混合色になります。 新しい曲線は「Sum of User, System 」というタイトルが付けられます。計算に 使用された式は「Formula 」列に表示されます。さらに新しい シンボルが表示されます：

をクリックすると「元に戻す」として機能し、 元の個々の曲線を再び表示することができます。計算操作に関するその他のヒント ：

過去の測定値を見る場合、その期間における正確な詳細にはあまり興味がない場合もあります。 たとえば、「過去 7 日間の平均 CPU 使用率」など、大まかな概要の方が興味深いでしょう。 この例の場合、結果は 88% というパーセンテージの数字になります。

ホストまたはサービスのテーブルには、一定期間のメトリックの 平均、最小、最大、その他の要約を表す列を追加することができます。 この機能を使用すると、これらの列でソートしたレポートを作成することもできます。 たとえば、選択した期間に利用率が最も低かったESXi ホストのリストを表示することができます。

ビューに表示するには、次の手順に従います。

まず、列を追加するビューが必要です。これは、ホストのビューでも サービスのビューでもかまいません。ビューの作成または編集の詳細については 、ビューに関する記事を参照してください。

次の例では、Monitor > Hosts > All hosts から開くことができる「All hosts 」ビューを選択します。 メニューから「Display > Customize view 」を選択します。 これにより、「Clone view 」ページが表示され、ビューを好みに合わせてカスタマイズすることができます。

元の「All hosts 」がコピーで覆い隠されないように、新しい ID と、後で「Monitor 」メニューに表示されるビューの新しいタイトルを選択します。

次に（オプションで）、さまざまなステータスにあるサービスの数を表示するすべての列を削除します。

次に、Services: Metric History タイプの列を追加します。 これはサービスの列であるため、ホストビューの場合は、ホストテーブルにサービス列を表示できるように、最初の選択として列タイプJoined column を選択する必要があります。 サービスビューの場合は、新しいColumn を追加するだけで十分です。

Metric で、履歴評価するメトリックの名前を選択します。 メトリックの名前がわからない場合は、Service Metrics エントリのサービス詳細で確認できます。

この例では、サービスの名前と同じ「 CPU utilization 」というメトリックを選択しています。

RRD consolidation では、Aggregation function で使用されている値と同じ値を選択することをお勧めします。これは、「最大値の最小値」などを計算してもあまり意味がないためです。RRD の選択オプションの詳細については、次の章「RRD データの編成」で説明します。

Time range は、調査したい過去期間です。 この例では、過去 7 日間、つまり正確に 168 時間です。

例では、Util @ 7 days をColumn title として選択しています。 後でTitle という名前のフィールドが表示されても驚かないでください。これは、ここでJoined column を使用した場合にのみ表示され、タイトルを指定できるからです。 2つ目のタイトルは空白のままにしておいてください。

最後に、Of Service フィールドに、上記で選択したメトリックが属するサービスの名前を入力します。 大文字と小文字を含むサービスの正確なスペルに注意してください。

保存すると、過去 7 日間の CPU 使用率の割合を示す列が追加された新しいビューが表示されます。

注

デフォルトでは、Checkmk は、すべてのメトリックの経過を4 年間の時間範囲にわたって記録するように設定されています。 使用される基本解像度は 1 分です。 これは、チェック間隔が 1 分に設定されており、1 分ごとにすべてのサービスから新しい測定データが正確に 1 回受信されるため、理にかなっています。

当然のことながら、4 年間に 1 分ごとに 1 つの値を保存するには、膨大な ドライブ容量が必要になります（ただし、RRD は測定値 1 つあたり 8 バイトしか必要としません ）。このため、データは時間の経過とともに圧縮されます。 最初の圧縮は 48 時間後に行われます。この時点から、5 分ごとに 1 つの値だけが保存されます 。さらに、10 日後と 90 日後に次の段階が実行されます。

ここで当然の疑問が浮かびます。5 つの値を 1 つに統合する最善の方法は？ このために、最大値、最小値、平均値などの統合機能があります。 実際に意味のある値は、アプリケーションや視点によって異なります。 たとえば、4 年間にわたってデータセンターの温度変動を監視する場合、記録された最高温度が最も重要でしょう。 一方、アプリケーションのアクセス率の場合、平均値がより興味深いかもしれません。アプリケーションのアクセス率の場合、 平均値がより興味深いかもしれません。

後での計算の柔軟性を最大限に高めるため、Checkmk の RRD は 最小値、最大値、平均値の3 つの値をすべて一度に保存するように あらかじめ設定されています。各圧縮レベルおよび統合機能について、RRD には「リング」スタイルの保存、いわゆるラウンドロビンアーカイブ (RRA) が含まれています。 標準構造では 12 個の RRA があります。したがって、Checkmk の標準構造では メトリックごとに 384,952 バイトが必要です。この数値は、2880 + 2880 + 4320 + 5840 測定ポイント、3 つの統合関数、 測定値 1 つあたり 8 バイトの 3 倍、合計でちょうど 382,080 バイトになります。2872 バイトのファイルヘッダーを追加すると、上記の最終的なサイズ 384,952 バイトになります。

興味深い代替スキームとしては、たとえば、1 分ごとに 1 つの値を 1 年間保存する方法があります。この方法には、RRD が 常に最適な解像度を保つため、統合が不要になり 、たとえば平均値のみを生成できるという小さな利点があります。365 x 24 × 60 の測定値を 8 バイトで計算すると、結果はメトリックあたりほぼ 正確に 4 MB になります。この方法では、RRD のストレージ要件は 10 倍になりますが 、実際には「ディスク I/O」は削減されます。その理由は、12 個の個別の RRA に保存および更新する必要が なくなり、1 つだけで済むからです。 9.2. RRD 構造のカスタマイズ

定義済みのストレージスキームが適切でない場合は、 ルールセット（ホスト またはサービスごとに異なるバージョンも使用可能）を使用して変更することができます。必要なルールセットは、 ルール検索（Setup メニュー）から最も簡単に見つけることができます。そこでは、単にRRD と入力してください。ここに、ルールセットConfiguration of RRD databases of services があります。ホストにも同様のルールセット がありますが、ホストには例外的な場合のみ測定値があります。 以下の画像は、デフォルト設定の RRD ルールを示しています。

Consolidation functions およびRRA configuration で 、統合で使用する圧縮フェーズの数とサイズを定義および設定できます。Step (precision) フィールドは、解像度を秒単位で定義し、 ルールでは 60 秒 (1 分) に設定されています。チェック間隔が 1 分未満のサービスでは 、この数値を小さく設定することをお勧めします。ただし、Number of steps aggregated into one data point フィールドの数値は、分ではなくStep (precision) で設定された時間間隔を表すことに注意してください。

RRD 構造への変更は、最初は 新しく作成されたRRD、つまり、監視に新しく組み込まれたホストまたはサービス にのみ影響します。Checkmk で既存の RRD を再構築することもできます。 これは、cmk --convert-rrdsコマンドで実行し、-v (詳細) オプションを必ず指定します。 Checkmk は、既存のすべての RRD を検査し、必要に応じて 定義されたターゲット形式に再構築します。

重要：RRD に含まれるデータの整合性を確保するため、既存の RRD をcmk --convert-rrdsで変換する前に、必ずサイト（omd stop ）を停止してください。

このコマンドは、すでに 希望する構造を持つ RRD を認識する

新しいフォーマットの方が解像度が高い場合や、追加の統合機能がある場合、 既存のデータは可能な限り補間され、RRD に 可能な限り意味のある値が格納されます。ただし、 たとえば、2 日間の 1 分間隔の値の代わりに 5 日間の 1 分間隔の値が必要になった場合、 既存のデータの精度を遡って向上させることはできません。

上記のルールには、さらに別の設定があります。RRD storage format これにより、Checkmk が RRD を作成する際に使用する 2 つの方法から選択することができます。 One RRD per host/service （略して Checkmk 形式）では、ホストまたはサービスのすべてのメトリックが 単一の RRD ファイルに保存されます。 これにより、ドライブへのデータの書き込みがより効率的になり、1 回の操作でメトリックの完全なセットを常に書き込むことができます。 これらの メトリックは隣接するストレージブロックに配置されるため、ディスクに書き込む必要のあるブロックの数が 減少します。

Checkmk サイトが、1.2.8 よりも古いバージョンの商業版で作成されている場合、 測定データが現在のより効率的な形式に変換されているかどうかを詳しく確認することをお勧めします。 データがまだ PNP 形式で保存されている場合は、上記のルールセットに示すルールを適用して、 Checkmk 形式に変換することができます。 ここでも、既存の RRD を変換する前に、必ずサイトを停止してください。

ここでも、cmk --convert-rrds コマンドが必要になります。また、既存の RRD を変換する前に、必ずサイトを停止してください。

警告により、Checkmk は最初に既存のファイルを変更しないことがわかります。 これにより、逆方向の変換は不可能であるため、疑問がある場合は元のデータ形式に戻すことができます。--delete-rrds オプションを使用すると、このコピーが作成されない、または後で削除されるようになります。 後で、コマンドを再度使用して、手動で簡単に削除することができます。 9.4. RRD キャッシュデーモン (rrdcached)

ディスクドライブへの書き込みアクセス数を（大幅に）削減するために 、補助サービスである RRD キャッシュディーモン (rrdcached) を使用することができます。これは 、サイトが起動すると起動するサービスの 1 つです。

RRD の新しい測定値はすべて、Checkmk Micro Core (商業版) または NPCD (Checkmk Raw) からrrdcached に送信されます。これにより、データは RRD に直接書き込まれるのではなく、コレクションとして後でそれぞれの RRD に書き込むためにメインメモリに保持されます 。これにより、ディスクドライブ (または SAN!) への書き込みアクセス回数が大幅に削減されます。

再起動時にデータが失われないように、更新はジャーナルログファイルにも追加で 書き込まれます。これも書き込みアクセスですが、データは 順番に並べられているため、IO はほとんど発生しません。

RRD キャッシュディーモンが効率的に動作するには、大量のメイン メモリが必要です。必要な容量は、RRD の数と データをキャッシュする期間によって異なります。後者は、~/etc/rrdcached.conf ファイルで定義できます。標準設定は 7200 秒（2 時間）ですが、この値はユーザーによってカスタマイズできます。さらに、0～1800 秒のランダムな 範囲も設定できます。RRD ごとにこのランダムな遅延を設定することで、「パルス」状の書き込みが回避され、IO が時間的に均等に分散されます。 ~/etc/rrdcached.conf

このファイルの設定を変更するには、次のコマンドを実行します：

測定値および RRD に関連する最も重要なファイルおよびディレクトリの概要は、次のとおりです （これらはすべて、サイトのホームディレクトリに関連しています）。