注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
大規模監視は、Foundry リソースの監視を時間をかけずに行う新機能を導入します。
すでに check groups を使用している場合、これをリソースの監視に追加のオプションと考えてください。既に設定しているワークフローまたはチェックグループを置き換えるものではありません。
リソースの監視は2つの方法で行うことができます：
既存のチェックグループをアップグレードするには、Data Health アプリケーションでチェックグループを開き、上部のバナーで Upgrade to Monitoring View を選択します。
新しい監視ビューを作成するか、すべてのチェックを既存の監視ビューに移動することができます。
新しい監視ビューを作成するには、Data Health アプリの右上隅にある Monitoring View タブに移動し、新しい監視ビューを作成します。
監視ルールを作成するには、Manage monitors タブに移動します。まず、監視するリソースタイプを選択します。リソースタイプにより、シングルスコープでそのリソースのみを監視するか、あるいは単一または複数のプロジェクトスコープでそのタイプのすべてのリソースを監視することができます。
リソースを監視し、それらに関するアラートを受信するには、リソースへのアクセス許可が必要です。
モニターはリソースが発行するメトリクスに設定されます。モニターを設定する際には、Foundry の健康基準に基づいた特定の設定を提案します。ただし、値を変更したり、特定のメトリクスのみを監視するように選択したりすることができます。また、アラートが失敗した場合の警告レベルを決定することもできます。現在、低、中、高の3つの重要度タイプがあります。
モニターのリストから選択し、表示されるサイドパネルで Edit を選択することで、モニターを編集することができます。
アラートの購読を行うには、Manage subscriptions タブに移動します。ここにはすべての購読ユーザーが表示されます。ユーザーとユーザーグループを追加し、そのアラートを重要度に基づいて設定することができます。モニタールールがアラートをトリガーすると、そのアラートが含まれる監視ビューを購読しているユーザーは、メールと Foundry の通知で通知を受け取ります。
監視ビューは、Foundry 内で生成された同等のアラートに対応する PagerDuty のアラートをトリガーし、解決することができます。この統合は PagerDuty V2 Events API を使用し、サービスユーザー、メール、または大部分のスタックでのカスタムホワイトリストまたはエグレス設定は必要ありません。単一の統合は、監視ビュー内の特定の重要度のすべてのアラートを、PagerDuty サービス内で定義された Events V2 API 統合にマップします。注意していただきたいのは、監視ビュー内で定義された複数の統合が同じ PagerDuty 統合キーにマップできるということです。
希望するエスカレーションポリシー、緊急度設定、サポート時間で PagerDuty サービスを設定します。サービスの Integrations タブで、新しい統合を追加します。統合タイプとして Events API V2 を選択し、Add をクリックします。（これは Most popular integrations セクションに表示されます。）統合が追加されると、歯車のシンボルをクリックすると詳細が表示され、次のステップで必要な Integration Key が表示されます。
監視ビューの Manage subscriptions タブに移動し、Pagerduty Notifications セクションでプラス記号 (+) をクリックして新しい PagerDuty 統合を作成します。統合の名前、前のステップでの統合キー、および重要度レベルを指定する必要があります。適用可能な各重要度レベルについて繰り返します。
デフォルトでは、監視ビューは監視ルールのアラートのための PagerDuty アラートを生成します。また、監視ビューにアップグレード/リンクされたチェックグループに属するレガシーヘルスチェックのために PagerDuty アラートをトリガーし、解決することも可能です。この機能を有効にするには、Enable PagerDuty for health checks チェックボックスを選択します。注意してください、中程度の重要度のヘルスチェックは MEDIUM 重要度の統合を使用し、重大な重要度のヘルスチェックは HIGH 重要度の統合を使用します。
以下のものを監視することができます：
| リソースタイプ | 対応スコープ |
|---|---|
| エージェント | シングル、プロジェクト |
| オブジェクトタイプ | シングル |
| リンクタイプ | シングル |
| スケジュール | シングル、プロジェクト |
| ストリーミングデータセット | シングル、プロジェクト |
| ライブデプロイメント | プロジェクト |
| データセット (近日公開) | プロジェクト |
すべてのヘルスチェックが監視ルールとして存在するわけではありませんが、最も重要なヘルスチェックには対応する監視ルールがあります。リンクされたチェックグループ内の監視ルールとヘルスチェックの組み合わせを使用することをお勧めします。監視ビューとヘルスチェックからのカバレッジをまとめると：
最も包括的なカバレッジを得るために、監視ビューを現在監視ビューで利用できないヘルスチェックで構成されたチェックグループにリンクすることをお勧めします。
モニターは単一のリソースではなく、全体のスコープをカバーします。つまり、そのスコープに追加のリソースが追加されたとき、そのルールによって自動的にカバーされます。例えば、プロジェクト内のすべてのエージェントを監視するように設定された監視ルールは、後からそのプロジェクトに追加された他のエージェントも監視します。
良い方法は、単一の監視ビューをチェックグループと同じように考えることです。一つの監視ビューは、そのビュー内のモニターに関心を持つユーザーのセットに関連するべきです。特定のユーザーセット [a, b, c] が特定のプロジェクト [x, y, z] に関心がある場合、それらのプロジェクト内のすべてのリソースで単一の監視ビューを作成します。特定のユーザーセットがエージェントの監視だけを気にしている場合、すべてのプロジェクトのすべてのエージェントを監視する単一の監視ビューを作成すべきです。
監視ビューはファイルシステムリソースであるため、ユーザーは ビューが保存されているプロジェクトまたはフォルダー への権限が必要です。アラートを受け取るためにリソース上に監視ルールを設定するには、ユーザーは監視したい プロジェクトリソース へのアクセスが必要です。すべての必要な権限を持つユーザーがユーザーまたはグループを監視ビューに登録しても、その新しいサブスクライバーはその監視ビューへの明示的なアクセス許可がない限り、どのリソースに対するアラートも受け取ることはありません。