 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. 必須の監視タスク
ホストを追加し、いくつかの重要なツールを確認しました。これで、実際の監視を開始する準備が整いました。 結局のところ、Checkmk の真の目的は、設定に常時時間を割くことではなく、IT 運用をサポートすることです。
デフォルトで利用できるビュー、またはOverview スナップインなどでは、現在存在する問題の数や種類を非常に正確に確認できます。 しかし、監視によるワークフロー、つまり「体系的な作業手順」をモデル化するには、以下の点についてもう少し詳しい情報が必要です。
問題の承認
問題発生時の通知の送信
スケジュールダウンタイムの設定
この章では、上記の点のうち、最初と最後の点についてのみ説明します。 通知については、このトピックには特別な準備が必要であるため、別の章で後で説明します。
2. 問題の承認
概要では、問題は 未処理または 処理済みとしてフラグを付けることができることをすでに説明しました。承認とは、 未処理の問題を処理済み問題に変える操作です。これは、必ずしも 誰かが実際にその問題に取り組んでいることを意味するわけではありません。問題の中には、 自然に解決するものもあります。しかし、承認を行うことで、概要を把握し、ワークフローを確立することができます。
問題が承認されると、実際には何が起こるのでしょうか？
Overview では、その問題はホストまたはサービスの「Unhandled 」列にカウントされなくなります。
ダッシュボードにもその問題がリストされなくなります。
オブジェクト (ホストまたはサービス) は、ビューで 記号でマークされます。
オブジェクトの履歴にエントリが作成されるため、後でアクションを追跡することができます。
設定されている場合、繰り返しの通知は停止されます。
では、問題の承認はどのように行うのでしょうか？
まず、問題を含むビューを呼び出します。 最も簡単な方法は、[Monitor > Problems > Host problems ] または [Service problems ] メニューの定義済みビューを使用することです。 ちなみに、[Overview] の問題件数をクリックすると、これらのビューにほぼすぐに移動できます。
リストで問題のあるホストまたはサービスをクリックし、その詳細ページで、この個々のホストまたはサービスのみについて承認を行うことができます。 ただし、ここでは 1 つの問題のみ、または複数の問題を一度に承認するためのすべてのオプションがリストページにあるため、リストページのままにしておきます。
1 つの操作で複数の (関連する) 問題を承認したい場合がよくあります。 これは、[Show checkboxes ] をクリックして、リストに新しい最初の列を表示すると、各行の前にチェックボックスが表示されます。 チェックボックスは、選択はユーザー次第であるため、すべてチェックされていません。操作を行う各ホストまたはサービスのチェックボックスを選択してください。
重要:チェックボックスのないリストのあるページでアクションを実行すると、そのアクションはリストのすべてのエントリに対して実行されます。
次に、Acknowledge problems をクリックすると、ページの上部に次のパネルが表示されます：
コメントを入力し、[Acknowledge problems] をクリックしてください — 「本当に確認しますか？」という確認メッセージが表示されます …
… 選択したすべての問題が承認済みとしてフラグが付けられます。
最後に、いくつかのヒントです：
[Commands > Remove acknowledgments ] メニューから承認を削除することもできます。
承認は自動的に実行することができます。Expire on オプションは、この目的のために使用しますが、商業版でのみ利用可能です。
承認アクションのすべてのオプションの詳細については、承認に関する記事をご覧ください。
3. スケジュールダウンタイムの設定
事故で「故障」するだけでなく、意図的に「故障」させる場合もあります。より正確に言えば、必要な停止は許容できる場合もあります。 結局のところ、すべてのハードウェアやソフトウェアは、時折メンテナンスが必要であり、その作業中は、監視対象のホストやサービスが「DOWN 」または「CRIT 」状態になる可能性が非常に高くなります。
Checkmk で問題に対応すべき担当者にとっては、もちろん、計画されたダウンタイムを把握し、「偽アラーム」によって貴重な時間を無駄にしないことが非常に重要です。 これを確実にするため、Checkmk にはスケジュールダウンタイム（またはより短いダウンタイム）の概念があります。
そのため、オブジェクトのメンテナンス期日が近づいた場合は、そのオブジェクトをスケジュールダウンタイムに設定することができます。
スケジュールダウンタイムの設定は、問題の承認のプロセスとよく似ています。 まず、スケジュールダウンタイムを設定する対象オブジェクト (ホストまたはサービス) を含むビューから開始します。 たとえば、Overview でホストまたはサービスの合計をクリックすると、すべてのオブジェクトのリストが表示されます。
表示されるリストで、[Show checkboxes ] を使用してチェックボックスを表示し、該当するエントリをすべて選択します。
次に、Schedule downtimes をクリックします。 これにより、ページの最上部に以下のパネルが表示されます：
スケジュールダウンタイムには、さまざまなオプションがあります。 それぞれの場合にコメントを入力する必要があります。 時間範囲を定義するには、ダウンタイムを即座に定義する単純な「2 hours 」から 将来のダウンタイムを定義するためにも使用できる、明確な時間範囲の指定まで、さまざまなオプションがあります。 承認とは対照的に、スケジュールダウンタイムには、常に事前に設定された終了時間があります。
以下のヒントもご参照ください：
ホストのダウンタイムをスケジュールすると、そのホストのすべてのサービスも自動的にスケジュールされるため、同じ作業を 2 回行う必要がありません。
柔軟なスケジュールダウンタイムは、実際には、オブジェクトがOK 以外の状態に変化したときにのみ開始されます。
商業版を使用している場合は、定期的なスケジュールダウンタイム（たとえば、週に 1 回の強制再起動）も定義できます。
Monitor > Overview > Scheduled downtimes で、現在進行中のスケジュールダウンタイムの概要を確認できます。
スケジュールダウンタイムの影響は次のとおりです。
Overview では、影響を受けるホストおよびサービスは問題として表示されなくなります。
ビューでは、選択したホストまたはサービスが案内コーンでマークされます。 すべてのサービスがダウンタイムに送られたホストの場合、サービスにはサーバーと小さな案内コーンが付いたアイコンが表示されます。
これらのオブジェクトについては、スケジュールダウンタイム中は問題の通知がオフになります。
ダウンタイム期間の開始時と終了時に、特別な通知がトリガーされます。
可用性分析では、スケジュールされたダウンタイムは個別にアカウントに計上されます。
上記のすべての機能およびその他の機能の詳細については、スケジュールダウンタイムに関する記事をご覧ください。