このトピックでは、Log Service のアラート機能で使用される用語について説明します。
Term | 説明 |
---|---|
Logstore | Log Service では、ログデータを保存するために Logstore を使用します。 SQL-92 構文を使用してログデータをクエリし、分析できます。 アラートモニタリングタスクは、クエリおよび分析機能に基づいています。 |
Metricstore | Log Service は、時系列データを格納するために Metricstoreを使用します。 PromQL 構文と SQL- 92 構文を使用して時系列データをクエリし、分析できます。 アラートモニタリングタスクは、クエリおよび分析機能に基づいています。 |
アラート | アラートは、アラートイベントを指します。 特定のアラートモニタリングルールに基づいてアラートがトリガーされると、アラートイベントがアラート管理システムに送信され、次に通知管理システムに送信されます。
Log Service のアラートモジュールは、サブシステム、機能、エンティティ、さらにアラートモニタリングシステムやアラートルールなどのサブモジュールを提供します。 |
アラートモニタリングシステム | アラートモニタリングシステムは、アラートをトリガーするサブシステムです。 アラートモニタリングシステムは、アラートモニタリングルールとリソースデータで構成されます。
アラートモニタリングシステムは、アラートモニタリングルールに基づいてクエリと分析の結果を定期的にモニタリングし、評価します。 アラートモニタリングルールに基づいてアラートがトリガーまたはクリアされた場合、アラートモニタリングシステムは、モニタリングルールのオーケストレーションに基づいてアラートまたは回復通知をアラート管理システムに送信します。 |
アラート管理システム | アラート管理システムは、アラートのノイズを除去し、アラートのステータスを管理するサブシステムです。 アラート管理システムは、アラート ポリシー、アラート インシデント、およびアラート
ダッシュボードで構成されます。
アラート管理システムは、アラートポリシーに基づいてアラートをディスパッチ、抑制、重複排除、停止、結合し、処理済みのアラートを通知管理システムに送信します。 アラート管理システムでは、インシデントフェーズの切り替えおよびインシデントハンドラーの指定も行えます。 |
通知管理システム | 通知管理システムは、通知方法や受信者を管理するサブシステムです。 通知管理システムは、アクションポリシー、アラートテンプレート、カレンダー、ユーザー、ユーザーグループ、当番グループ、通知方法のクォータで構成されます。
指定された通知方法により、指定された受信者に通知が送信されます。 受信者は、ユーザー、ユーザー グループ、または当番グループです。 通知管理システムでは、アラートをエスカレーションし、カスタムアラートテンプレートを作成することもできます。 |
アラート取り込みシステム | アラート取り込みシステムは、外部アラートを取り込むために使用されるサブシステムです。 アラート取り込みシステムは、アラート取り込みサービスとアラート取り込みアプリケーションで構成されます。
アラート取り込みアプリケーションは、Zabbix や Prometheus などの外部サービスからアラートを取り込むための webhook URL を提供します。 外部アラートの取り込み後、アラート取り込みシステムはアラートを処理し、アラート管理システムに送信します。 回復通知を取り込むこともできます。 |
アラートモニタリングシステム
アラートは、アラートモニタリングシステムでトリガーされます。 アラートモニタリングシステムは、アラートモニタリングルールとリソースデータで構成されます。 下図に、ライブ Q&A スキームのアーキテクチャを示します。

用語 | 説明 |
---|---|
アラートモニタリングルール | アラートモニタリングルールには、クエリ分、クエリおよび分析対象のオブジェクト、関連するモニタリングルールのオーケストレーションなど、データのモニタリングを行うための条件を設定します。 クエリおよび分析の対象は、Logstore、Metricstore、およびリソースデータです。 詳細については、「ログに対するアラートモニタリングルールの作成」をご参照ください。 |
リソースデータ | Log Service は、さまざまなリソース設定とカスタムデータを保存するために、独立した変更可能な表形式のストレージ構造を採用しています。 リソースデータを使用して、ユニオンクエリを実行できます。
たとえば、リソースデータを使用してブラックリストとホワイトリストをモニタリングできます。
詳細については、「リソースデータの作成」をご参照ください。 |
アラートの重大度 | アラートの重大度は、アラートの非識別属性です。 アラートの重大度は、重大、高、中、低、報告です。 詳細については、「アラートの重大度の指定」をご参照ください。
外部アラートがアラート取り込みシステムに取り込まれると、Log Service はアラートのキーワードを使用して、アプリケーションプロトコルに基づいて重大度を照合します。 アラートのキーワードに一致する重大度がない場合、アラートの重大度は中と見なされます。 |
グループ評価 | アラートモニタリングルールを作成する際に、グループ評価パラメーターを指定する必要があります。 アラートモニタリングシステムでは、クエリ結果を計算して結果を分析する際、指定されたフィールドに基づいてクエリ結果をグループ化できます。 各グループの結果は、指定されたトリガー条件に基づいて評価されます。 グループの結果がトリガー条件を満たしている場合、アラートがトリガーされます。 アラートモニタリングルールを使用して、クエリ結果および分析結果の複数のグループを同時にモニタリングできます。 各グループのアラートとインシデントを管理できます。 詳細については、「グループ評価」をご参照ください。 |
評価式 | 評価式は特定の構文をサポートしています。 Log Service は、指定されたトリガー条件が満たされているかどうかを確認し、評価式の結果に基づいてアラートの重大度を評価します。
論理比較および計算を実行する場合、評価式でクエリと分析結果のフィールドを使用できます。 評価式の結果が true の場合、クエリおよび分析の結果は評価式と一致します。 詳細については、「評価式の構文」をご参照ください。 |
アラートのラベル | アラートのラベルは、アラートの非識別属性です。 ラベルはキーと値のペアで構成されます。 アラートモニタリングルールを設定する際にラベルを追加できます。 ルールに基づいてアラートがトリガーされると、ラベルがアラート属性としてアラートに追加されます。
ラベルはアラートテンプレートで参照できます。 アラートを管理するためにアクションポリシーを設定する際、アラート属性としてラベルを指定できます。
詳細については、「ラベル」をご参照ください。 |
アラートの注釈 | アラートの注釈は、アラートの非識別属性です。 注釈はキーと値のペア構成されます。 アラートモニタリングルールを設定する際に注釈を追加できます。 アラートがトリガーされると、注釈がアラート属性として使用されます。 注釈はアラートテンプレートで参照できます。 アラートを管理するためにアクションポリシーを設定する際、アラート属性として注釈を指定できます。 詳細については、「注釈」をご参照ください。 |
回復通知 | 回復通知は特別なアラート通知です。 回復通知では、アラートステータスは解決済みです。 通常のアラート通知では、アラートステータスは発火です。 たとえば、アラートモニタリングルールで回復通知機能が有効化されている場合、 前回のチェックでアラートがトリガーされ、現在のチェックでトリガー条件が満たされない場合、回復通知が送信されます。 複数のモニタリングタスクを設定する場合は、回復通知機能を有効化することを推奨します。 これにより、アラートがクリアされた後の最初の機会に通知を受け取ることができます。 詳細については、「回復通知」をご参照ください。 |
アラート管理システム
アラート管理システムは、アラートのノイズを除去し、アラートのステータスを管理します。 アラート管理システムは、アラート ポリシー、アラート インシデント、およびアラート ダッシュボードで構成されます。 下図に、ライブ Q&A スキームのアーキテクチャを示します。

用語 | 説明 |
---|---|
アラートポリシー | アラートポリシーは、アラート管理システムの設定エンティティです。 外部アラートを取り込むときにアラートポリシーを設定し、アラートモニタリングルールを設定できます。 アラート管理システムがアラート (回復通知を含む) を受信すると、アラートポリシーに基づいてアラートのノイズ除去または結合を実行します。 次に、アラート管理システムはマージセットを通知管理システムに送信し、通知管理システムはアラート通知を送信します。 |
アラートのフィンガープリント | アラート管理システムは、各アラートのフィンガープリントを計算します。 同じフィンガープリントを持つアラートは、同じアラートと見なされます。 フィンガープリントは、アラートの識別属性に基づいて計算されます。 アラートの識別属性には、アラートが属する Alibaba Cloud アカウント、アラートが存在するプロジェクト、モニタリングルールの ID、ラベルが含まれます。 詳細については、「フィンガープリントに基づくアラートの重複除去」をご参照ください。 |
アラートの停止 | アラートポリシーの設定時に、停止ポリシーを指定できます。 無音期間中にアラートがトリガーされ、アラートが指定された条件に一致する場合、アラート通知は送信されません。 詳細については、「停止ポリシー」をご参照ください。 |
アラートの抑制 | アラートポリシーの設定時に、抑制ポリシーを設定できます。 アラート管理システムが抑制ポリシーの条件に一致するアラートを受信した場合、アラートは抑制されます。 たとえば、Kubernetes クラスターが重大なアラートをトリガーし、重大ではないアラートを抑制したい場合、抑制ポリシーを作成します。 詳細については、「アラートの抑制」をご参照ください。 |
ルート統合ポリシー | アラートポリシーの設定時に、ルート統合ポリシーを設定できます。 アラート管理システムがルート統合ポリシーの条件に一致するアラートを受信した場合、アラート管理システムは、ルート統合ポリシーに基づいてアラートを異なるマージセットにグループ化します。 続いて、ルート統合ポリシーに基づいてマージセットの遅延および重複排除を行い、通知管理システムに送信します。 詳細については、「アラートの統合」をご参照ください。 |
マージセット | マージセットには、マージおよびグループ化されたアラートが保存されます。 各マージセットには、1 つ以上のフィンガープリントを設定できます。 アラート管理システムは、ルート統合ポリシーに基づいてマージセットの遅延および重複排除を行い、通知管理システムに送信します。 |
アラートインシデント | アラート管理システムに送信されたアラートは、ルート統合ポリシーに基づいてさまざまなマージセットにグループ化されます。 インシデントは、マージセットごとに自動的に作成されます。
Log Service コンソールで、インシデントフェーズの切り替えおよびインシデントハンドラーの指定を実行できます。 インシデントのステータスには、確認済み、解決済み、無視、および評価保留が含まれます。
詳細については、「インシデントフェーズの切り替え」をご参照ください。
Log Service は、インシデントステータスを自動的に更新し、アラートをエスカレーションできます。 たとえば、解決済みの状態にあるアラートインシデントに対してアラートが再度トリガーされると、アラートインシデントのステータスは自動的に評価待ちに変わります。 確認済み状態のアラートインシデントの復旧通知を受信すると、アラートインシデントのステータスは自動的に解決済みに変わります。 |
通知管理システム
通知管理システムは、通知方法とアラート通知の受信者を管理します。 通知管理システムは、アクションポリシー、アラートテンプレート、カレンダー、ユーザー、ユーザーグループ、当番グループ、通知方法のクォータで構成されます。 下図に、通知管理システムのアーキテクチャを示します。

用語 | 説明 |
---|---|
アクションポリシー | アクションポリシーは、アラート管理システムの設定エンティティです。 アラートと回復通知は、ルート統合ポリシーに基づいて異なるマージセットにグループ化され、その後、マージセットは通知管理システムに送信されます。
指定された通知方法により、指定された受信者に通知が送信されます。 受信者は、ユーザー、ユーザーグループ、当番グループのいずれかに設定できます。 通知管理システムで、時間内に処理されないインシデントのエスカレーションを行うこともできます。
アクションポリシーの設定時に、アラートのエスカレーション条件を指定できます。 アクションポリシーの設定方法については、「アクションポリシーの作成」をご参照ください。 |
Webhook の統合 | Webhook の統合機能は、Webhook の通知方法を管理するために使用します。 アクションポリシーの設定時に、作成済みの Webhook を使用できます。 Log Service は、DingTalk Webhook、Enterprise WeChat Webhook、Lark Webhook、Slack Webhook、および汎用 Webhook をサポートしています。 詳細については、「Webhook の作成」をご参照ください。 |
アラートのエスカレーション | アラートインシデントが指定された期間内に確認または解決されない場合、インシデントは [セカンダリアクションポリシー] タブで指定されたアクション ポリシーに基づいて処理されます。 この方法により、アラートを迅速に処理できます。 詳細については、「アラートインシデントのエスカレーション」をご参照ください。 |
アラートテンプレート | Log Service は、アラートテンプレートで指定された内容に基づいてアラート通知を送信します。 アラートテンプレートの通知方法ごとに内容を指定できます。 テンプレート変数を参照してアラート属性を指定することもできます。 Webhook を使用してアラート通知を送信する場合、特定のプロトコルに基づいて通知形式を指定できます。 たとえば、Enterprise WeChat の要件に従った形式を設定できます。 詳細については、「アラートルールの作成」をご参照ください。 |
カレンダー | 通知管理システムではカレンダーを使用できます。 グローバルデフォルトカレンダーを使用するか、またはカスタムカレンダーを使用できます。
|
ユーザー | ユーザーは、アラート通知を受け取る受信者を指します。 ユーザー情報には、ユーザーID、ユーザー名、電話番号、メールアドレスが含まれます。 アクション ポリシーの設定時に、アラート通知の受信者としてユーザーを指定できます。
インシデントを管理するときに、インシデントを処理するユーザーを指定できます。
バケットを作成する方法の詳細については、「バケットの作成」をご参照ください 。 |
ユーザーグループ | ユーザーグループは、複数のユーザーを表す設定エンティティです。 ユーザーグループ情報には、ユーザーグループ ID、ユーザーグループ名、およびユーザーが含まれます。
各ユーザー グループには、1 人以上のユーザーが含まれます。 アクション ポリシーの設定時に、アラート通知の受信者としてユーザーグループを指定できます。
ユーザーグループを作成する方法の詳細については、「ユーザーグループの作成」をご参照ください。 |
当番グループ | 当番グループは、ユーザーとユーザーグループを表す設定エンティティです。 当番グループ情報には、当番グループ ID、当番グループ名、ローテーションシフト、代替シフト、およびカレンダー設定が含まれます。
当番グループには、1 以上のユーザーまたはユーザー グループが含まれます。 アクション ポリシーの設定時に、通知を受信する当番グループを指定できます。
当番ユーザーグループの作成方法については、「当直グループの作成」をご参照ください。 |
ローテーションシフト | 当番グループのユーザーまたはユーザーグループに対してローテーションシフトを設定できます。 当番グループに、複数のローテーションシフトを追加できます。 カレンダーで選択した曜日に基づいてローテーションシフトを設定できます。
非連続時間のローテーション シフトを設定することもできます。
詳細については、「ローテーションシフトと代替シフト」をご参照ください。 |
代替シフト | 当番グループのユーザーまたはユーザーグループに対して代替シフトを設定できます。 稼働中グループに複数の代替シフトを追加できます。
詳細については、「ローテーションシフトと代替シフト」をご参照ください。 |
通知方法のクォータ | Log Service では、SMS メッセージ、音声通話、メールのいずれかを使用して指定された受信者に送信されるアラート通知に対して、1 日あたりのクォータを設定できます。
指定された通知方法で受信者に送信されたアラート通知の数がクォータに達すると、受信者は同じ通知方法でアラート通知を受信できなくなります。 受信者が 1 日あたりに受信できるアラート通知のクォータを指定できます。
詳細については、「通知クォータの設定」をご参照ください。 |
アラート取り込みシステム
アラート取り込みシステムは、外部アラートの取り込みに使用されます。 アラート取り込みシステムは、アラート取り込みサービスとアラート取り込みアプリケーションで構成されます。
用語 | 説明 |
---|---|
アラート取り込みアプリケーション | アラート取り込みアプリケーションは、Grafana や Prometheus などの外部サービスからアラートを Log Service に取り込むためののプロトコルおよび Webhook URL を用意します。 デフォルトでは、すべてのリージョンで LAN またはインターネット経由でアラートを取り込むことができます。 HTTP および HTTPS プロトコルがサポートされます。 サードパーティのサービスからアラートを受信すると、Log Service は事前に設定されたアラートポリシーを使用してアラートを管理します。 |
アラート取り込みサービス | アラート取り込みサービスは、取り込みアプリケーションのコンテナーまたは名前空間です。 アラート取り込みサービスには、複数のアラート取り込みアプリケーションを設定できます。 たとえば、O&M チームが Grafana と Prometheus からアラートを受信したい場合、アラート取り込みサービスに、プロトコルがそれぞれ Grafana と Prometheus の 2 つのアラート取り込みアプリケーションを作成できます。 |