Oracle Cloud Infrastructureドキュメント

アラームのベスト・プラクティス

このトピックでは、アラームの操作のベスト・プラクティスについて説明します。

各メトリックに対するアラームのセットの作成

リソースが発生した各メトリックについて、「アラームの作成」は次のリソースの動作を定義します:

  • リスクあり。 リソースは、メトリック値で示されるように動作不能になるリスクがあります。
  • 非最適。 リソースは、メトリック値で示される非最適なレベルで稼働しています。

次の例では、「oci_computeagentメトリック・ネームスペース」が発行するCpuUtilizationメトリックを使用します。 このメトリックは、Computeインスタンスの使用率、およびインスタンスで実行されているサービスとアプリケーションのアクティビティ・レベルをモニターします。 CpuUtilizationは、ComputeインスタンスのCPU使用率を示し、パフォーマンスの問題の調査に使用できるため、クラウド・サービスのキー・パフォーマンス・メトリックです。 CPU使用率の詳細は、次のURLを参照してください。:https://en.wikipedia.org/wiki/CPU_time

リスクありの例

CpuUtilizationメトリックの通常のリスクありしきい値は、80パーセントより大きい任意の値です。 Computeインスタンスがこのしきい値を無効にするリスクがあります。 多くの場合、この動作の原因は、CPUの高い割合を消費する1つ以上のアプリケーションです。

この例では、運用チームにただちに通知し、アラームの重大度をクリティカルに設定することを決定します。なぜなら、インスタンスを最適な運用レベルに戻すために修復が必要なからです。 アラームを構成して、PagerDutyとeメールの両方を担当することで、インスタンスが動作不能な状態になる前に、調査および適切な修正をリクエストします。 繰返し通知を分ごとに設定します。 誰かがアラーム通知に応答するとき、アラームを抑止するためのベスト・プラクティスを使用して一時的に通知を停止します。 メトリックが最適な値に戻ったら、抑制を削除します。

最適ではない例

CpuUtilizationメトリックの最適でないしきい値は、60から80パーセントになります。 Computeインスタンスのメトリック値がこの範囲内にある場合、インスタンスは最適な操作範囲を超えています。

この例では、アプリケーションまたはプロセスが通常よりも多くのCPUを消費していることを適切な個人またはチームに通知することを決定します。 CPUを調査して減らすために即時のアクションは必要ないため、適切な連絡先に1日に1回通知し、アラームの重大度を警告に設定するようにアラームを構成します。 Eメール通知ノイズを削減するため、24時間ごとに繰返し通知を使用して、適切な開発者またはチームに向けてeメールのみに通知を設定します。

リソースが稼働中または停止中の例

リソース可用性の典型的なインジケータは、CpuUtilizationメトリックが5分間なくなることを示します。 Computeインスタンスがこのしきい値を超えているか、アクセスできないか、または動作していません。 リソースが応答を停止したか、接続の問題によりリソースが使用不可になった可能性があります。

この例では、インスタンスをオンラインにするために修復が必要なため、運用チームにただちに通知し、「休暇欠勤アラーム」の重大度をクリティカルに設定することを決定します。 PagerDutyとeメールの両方で、調査をリクエストし、作業負荷を使用可能な別のリソースに移動することによって、アラーム通知をチームに構成します。 繰返し通知を分ごとに設定します。 誰かがアラーム通知に応答するとき、「アラームの抑止」のベスト・プラクティスを使用して一時的に通知を停止します。 リソースからCpuUtilizationメトリックが再度検出されると、抑制は削除されます。

調査中のアラームの抑制

チーム・メンバーがアラームに応答した後、問題を調査または軽減するための作業の期間にわたって通知を抑止します。 一時的に通知を停止することで、調査中の混乱を回避して軽減できます。 問題が解決されている場合は抑制を削除します。 手順については、「アラームを抑制するには」を参照してください。

アラームのルーチン的な調整

週次などの定期的な基準で、アラームを確認して最適な構成にします。 それぞれのアラームしきい値、重大度、および通知の詳細(メソッド、頻度、ターゲット・オーディエンスを含む)を測定します。

♪このイメージは、ルーチン・チューニング用のアラームの週次レビューを示しています。

最適なアラーム構成は、次のファクタに対処します:

  • リソースの重要性。
  • 適切なリソース動作。 サービス・エコシステムのコンテキスト内で、単に行動を評価します。 特定の期間のメトリック値の変動をレビューし、必要に応じてしきい値を調整します。
  • 許容される通知ノイズです。 通知メソッド(たとえば、EメールまたはPagerDuty)、適切な受信者、繰返し通知の頻度を評価します。

手順については、「アラームを更新するには」を参照してください。