#目的

アラートは、プラットフォーム上でデプロイされたインスタンスのメトリクスを監視するために設定できます。APIの状態やクエリエンジンのCPU使用率などです。これらはプラットフォーム上でヘルスチェックアラートと呼ばれます。

ヘルスチェックアラートは、ターゲットを指定することで設定されます。また、トリガー条件とトリガーオプションも指定します。

#アラートのターゲットを設定する

新しいヘルスチェックアラートを作成する場合、監視するデプロイメントの種類を選択する必要があります。利用可能な種類は次のとおりです。

• Data Processing Engineの常時稼働デプロイメント
• APIs
• アプリケーション

まだ行っていない場合は、アラートを作成するプロジェクトも選択する必要があります。

特定のオブジェクト（アプリ、APIなど）を監視することを選択した場合、その特定のインスタンスがトリガー条件を満たす場合にのみアラートがトリガーされます。 例えば、下のスクリーンショットのように、API「public」が1分間以上RAMの99%以上を使用した場合にのみアラートがトリガーされます。

#アラートのトリガー条件を設定する

アラートのトリガー条件は、メトリクス、演算子、および値からなる論理的なステートメントです。複数の条件を同じアラートに追加することができます。その場合、それらはAND条件で結合されます。各評価ループ（1分ごとに発生）で、プラットフォームは各アラートトリガーで定義された式を実行します。アラートのステータスは、すべてのトリガー条件がアラートの待機期間（プロセスの下流で設定可能）より長く真である場合、アクティブに変わります。

新しいトリガー条件を追加するには、対応するパネルで追加を押します。

デプロイされたインスタンスの次のメトリクスにトリガーを設定できます。

• ステータス：監視対象が利用できない場合（値DOWN）にアラートが発行されます。
  • 監視対象がユーザーによって手動で停止/再起動された場合、ステータスDOWNはアラートを発行しません
• CPU使用率（%）：監視対象のCPU使用率が一定の閾値を上回る/下回った場合にアラートが発行されます
• RAM使用率（%）：監視対象のメモリ使用率が一定の閾値を上回る/下回った場合にアラートが発行されます
• ログ検出（近日公開!）

#アラートのトリガーオプションを設定する

トリガーオプションは、上記のトリガーに基づいてアラートがどのようにトリガーされるか、および通知がサブスクライバーにどのように送信されるかを指定するために使用されます。

#アラートの待機期間を指定する

待機期間は、アラートが実際にトリガーされるためにアラートのトリガーが真である必要がある期間です。

このオプションのパラメータにより、プラットフォームはアラートのトリガー条件（高いCPU使用率のインスタンスなど）を初めて満たしたときから、アラートをアクティブとカウントするまでの間、一定の期間待機します。

この期間が0（デフォルト値）の場合、トリガー条件がすべて真になるとすぐにアラートがアクティブ状態にトリガーされます。 この期間が0より大きい場合、プラットフォームがこの待機期間に達するためにトリガー条件を継続的に検証する評価ループが十分に実行されるまで、アラートは監視状態のままです。その後、アラートはアクティブ状態にトリガーされます。

#通知頻度を指定する

各アラートについて、次のいずれかを選択できます。

• サブスクライバーにトリガー時（アラートがアクティブ状態に遷移したとき）のみ通知します。アラートが解決されるまで、サブスクライバーには再度通知されません。
• アラートがアクティブである限り、サブスクライバーに定期的に通知します。アラートごとに通知頻度を設定できます。

また、解決通知を有効にすることもできます。これにより、アラートが解決されたときにすべてのサブスクライバーに通知が送信されます。これは、評価されたトリガー条件がもはや検証されなくなった時点で自動的に行われます。

#さらに詳しく

ソリューションの実装に関するトレーニングや技術的なアシスタンスが必要な場合は、営業担当者にお問い合わせください。または、専門家によるプロジェクト分析と見積もりを受けるために、Professional Servicesページをご覧ください。

Data Platformを構築しているチームと直接質問し、フィードバックを共有し、交流するには、専用のDiscordチャネルをご利用ください。

OVHcloudサービスについてサポートが必要な場合は、Help Centreでリクエストを作成してください。

ユーザーコミュニティに参加してください。