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

リソースにより発行される各メトリックに対して、次のリソース動作を定義するアラームを作成します:

• リスクあり。リソースは、メトリック値で示されるように、動作しなくなるリスクがあります。
• 非最適。リソースは、メトリック値で示されるように、非最適化レベルで実行しています。
• リソースが稼働中または停止。リソースにアクセスできないか、または操作ができません。

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

リスクありの例

CpuUtilizationメトリックの典型的なリスクありのしきい値は、80パーセントを超える任意の値です。このしきい値を破るコンピュート・インスタンスは、動作しなくなるリスクがあります。多くの場合、この動作の原因は、CPUの消費率が高い1つ以上のアプリケーションです。

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

NonOptimal例

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

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

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

リソースの可用性の一般的なインジケータは、CpuUtilizationメトリックの5分間の不在です。このしきい値を破るコンピュート・インスタンスはアクセスできないか、または操作できません。リソースが応答を停止したか、接続の問題が原因でリソースが使用できなかった可能性があります。

この例では、インスタンスをオンラインに戻すために修復が必要なため、操作チームにただちに通知することにし、不在アラームの重大度を「クリティカル」に設定します。PagerDutyと電子メールの両方で、担当チームへのアラーム通知を構成し、調査とワークロードを別の使用可能なリソースに移動することをリクエストします。繰返し通知は1分ごとに設定します。アラーム通知に応答したら、アラームを抑制するベスト・プラクティスを使用して、通知を一時的に停止します。CpuUtilizationメトリックがリソースから再び検出されると、抑制が削除されます。

メトリックが発行される頻度に基づいてアラーム間隔を選択します。たとえば、5分ごとに発行されるメトリックには、5分以上のアラーム間隔が必要です。ほとんどのメトリックは1分ごとに発行されるため、任意のアラーム間隔がサポートされます。特定のメトリックに対して有効なアラーム間隔を決定するには、関連するサービスのメトリック参照を確認します。

チーム・メンバーがアラームに応答すると、問題の調査または軽減中の通知が抑制されます。通知を一時的に停止することによって、調査中や緩和中の注意が散漫になることを回避できます。問題が解決されたときは抑制を削除します。手順については、ディメンション固有のアラーム抑制の追加およびアラーム全体の抑制の追加を参照してください。

毎週など、定期的に、最適な構成になるようにアラームを確認してください。各アラームのしきい値、重大度および通知の詳細(方法、頻度、ターゲット対象者など)を調整します。

最適なアラーム構成は、次の要因に対処します。

• リソースのクリティカル度。
• 適切なリソースの動作。サービス・エコシステムのコンテキスト内で、動作を単独で評価します。特定の期間のメトリック値の変動を確認し、必要に応じてしきい値を調整します。
• 許容可能な通知ノイズ。通知方法(電子メールやPagerDuty)、適切な受信者、繰返し通知の頻度を評価します。

次の表に、アラーム補正の例を示します。

手順は、アラームの更新を参照してください。