操作シナリオ
ログまたはメトリックに基づいてアラートポリシーを設定し、特定の条件を満たすログまたはメトリックが発生した場合にアラートを送信します。例えば、errorログの数が多すぎる場合や、インターフェースの応答時間が長すぎる場合などです。
前提条件
データはログまたはメトリックトピックにアップロードされました。
操作手順
CLSコンソールにログインし、アラートポリシー管理ページに進みます。左上にある新規作成をクリックし、以下の主要情報を設定します。 1. 基本情報
アラート名：文字数は1～255文字です。
有効状態：現在のアラートポリシーを有効にするかどうかです。アラートポリシーが無効の場合、アラートや通知は一切生成されません。
Tag：現在作成中のアラートポリシーにTagを設定し、異なる次元からリソースを分類管理しやすくします。
構成方法：
カスタム構成：監視対象のログトピック、クエリ文、トリガー条件を手動で指定します。柔軟性が高い一方で、構成はやや複雑です。本書では後ほどこの構成方法について詳しく説明します。
テンプレート構成：プリセットテンプレートを使用してアラートポリシーを作成します。クエリ文やトリガー条件を手動で記述する必要がなく、構成が簡単です。現在はTKEの監査ログとイベントログのみをサポートしており、今後はより多くのクラウド製品ログをサポートする予定です。詳細はアラートポリシーテンプレートをご参照ください。 2. 監視対象
監視対象のログまたはメトリックトピックを選択します。以下の2つの選択方法をサポートしています：
すべての実行ステートメントが同じ監視対象を使用します（デフォルト）：複数選択に対応しており、最大20個のトピックを選択できます。リージョンをまたぐ選択には対応していません。各トピックはトリガー条件を満たしているかどうかを個別に判定し、同時に複数のトピックがトリガー条件を満たした場合は、同時に複数のアラートが生成されます。
各実行ステートメントで監視対象を個別に選択します：実行ステートメントごとにトピックを個別に設定できます。単一選択であり、リージョンをまたぐ設定には対応していません。各実行ステートメントの結果をまとめて、トリガー条件を満たしているかどうかを判定します。例えば、Aトピックのエラーログ数 + Bトピックのエラーログ数が10より大きい場合に1つのアラートがトリガーされます。
3. 監視タスク
実行ステートメント：ログまたはメトリックトピックに作用するクエリ文です。
実行ステートメント：ログ検索分析ステートメントです。詳細は構文規則をご参照ください。 例1：ステータスがerrorのログstatus:error
例2：ドメイン名domain:aaa.comの平均応答時間を統計します。domain:"aaa.com" | select avg(request_time) as Latency
クエリ時間範囲：最大時間範囲は直近24時間です。
実行ステートメント：PromQLです。詳細は構文規則をご参照ください。 例1：ファイルシステムの使用率が50%を超えた場合にアラートがトリガーされます。filesystem_usage_pct > 0.5
例2：直近5分間のCPU負荷の最大値が1より大きい場合にアラートがトリガーされます。max_over_time(node_load1[5m]) > 1
トリガー条件：トリガー条件を満たした場合にアラートを実行します。「インタラクティブモード」と「ステートメントモード」の2種類の設定方法に対応しています。
インタラクティブモード：
アラートレベル、実行ステートメント、変数名、比較方法を順に選択し、その後アラートしきい値を設定します。
複数のアラートレベルを設定できます。条件を満たすと対応するレベルのアラートがトリガーされ、複数の条件を同時に満たす場合は複数のアラートがトリガーされます。アラートレベルに応じて通知チャネルグループで異なる通知ルールを設定できます。例えば、「緊急」アラートは電話で通知し、「警告」アラートはSMSで通知し、「注意」アラートは通知しません。
ステートメントモード：
アラートレベル：注意、警告、緊急の3つのレベルに対応しています。条件を満たすと対応するレベルのアラートがトリガーされ、複数の条件を同時に満たす場合は複数のアラートがトリガーされます。
グループトリガー：グループトリガー機能を使用するかどうかです。
グループトリガー機能を使用する場合、ある実行ステートメントに複数の結果があるとき、指定されたグループフィールドに基づいてこれらの複数の結果をグループ化します。グループごとにアラートトリガー条件を満たすかどうかを判断し、トリガー条件を満たす各グループはそれぞれ個別にアラートをトリガーします。
グループフィールド：実行ステートメントの実行結果からグループ化の基準として使用するフィールドを選択します。少なくとも1つのフィールドを選択してください。
例：
実行ステートメント：* | select avg(request_time) as request_time, domain group by domain order by request_time desc limit 5
トリガー条件：$1.request_time > 5
実行ステートメントの結果：
合計1件のアラートがトリガーされました：
|
aaa.com | 12.56 | トリガー条件を満たし、アラートが1件トリガーされました。 |
bbb.com | 9.45 |
|
ccc.com | 7.23 |
|
ddd.com | 5.21 |
|
eee.com | 4.78 | トリガー条件を満たさないため、アラートはトリガーされません。 |
$1.domainをグループ化フィールドとして5つのグループに分けます。グループ1～グループ4がトリガー条件を満たし、それぞれ個別に1件のアラートをトリガーするため、合計4件のアラートがトリガーされます：
|
aaa.com | グループ1 | 12.56 | トリガー条件を満たし、アラートを1件単独でトリガーします。 |
bbb.com | グループ2 | 9.45 | トリガー条件を満たし、アラートを1件単独でトリガーします。 |
ccc.com | グループ3 | 7.23 | トリガー条件を満たし、アラートを1件単独でトリガーします。 |
ddd.com | グループ4 | 5.21 | トリガー条件を満たし、アラートを1件単独でトリガーします。 |
eee.com | グループ5 | 4.78 | トリガー条件を満たさないため、アラートはトリガーされません。 |
注意：
グループトリガー機能を使用する場合、1回のアラート実行で多数の実行結果がトリガー条件を満たす可能性があります。それにより同時に多数のアラートが発生し、アラートストームを引き起こす可能性があります。グループフィールドとトリガー条件を適切に設定してください。
グループフィールドを指定する場合、実行結果を最大1000個のグループに分割できます。範囲を超えたグループはアラートをトリガーしません。
実行周期：監視タスクの実行頻度です。以下の2種類の周期設定方法を提供します：
|
固定頻度 | 一定の時間間隔で監視タスクを1回実行します。1～1440分に対応しています。 | 5分ごとに監視タスクを1回実行します。 |
固定時間 | 一定の時間に監視タスクを1回実行します。00:00～23:59に対応しています。 | 毎日02:00に監視タスクを1回実行します。 |
Cron式 | Cron式に従って監視タスクを実行します。最小粒度は分です。 | */5 8-20 * * *
毎日8時から20時まで、5分ごとに監視タスクを1回実行します。 |
4. 多次元分析
アラート発生時、多次元分析を使用して元のログをさらに分析し、分析結果をアラート通知に添付することで、アラート原因の特定を支援できます。多次元分析はアラートトリガー条件に影響しません。
|
| 検索条件に一致する生ログを取得し、表示するログフィールド、件数、表示形式を設定できます。 例えば、errorログが多すぎてアラートが発生した場合、アラート内で対応する詳細ログを確認できます。 |
| アラートがトリガーされた時間範囲内のすべてのログに対して、指定したフィールドでグループ化してログ件数を集計し、上位5件のフィールド値とその割合を取得します。 例えば、errorログが多すぎてアラートが発生した場合、ログに対応するTop5 URL、Top5レスポンスステータスコードなどです。 |
| アラートがトリガーされた時間範囲内のすべてのログに対して、カスタム検索分析ステートメントを実行します。
例1：* | select avg(timeCost) as time,URL group by URLを使用して、各インターフェースのリクエスト時間を取得します。
例2：status:>499を使用して、エラーログを取得します。 |
説明
「関連する元のログ」と「フィールドTOP5および割合統計」は、指定された実行ステートメント内の検索条件（SQLのフィルタリング条件、例えばwhereは含まれません）に自動的に関連付けることをサポートします。これは、条件を満たす元のログに対して多次元分析を行う必要があることを示します。
メトリクストピックは現在、多次元分析をサポートしていません。
5. アラート通知
アラート頻度：
継続周期：トリガー条件を継続的に満たす回数が一定回数（デフォルトは1、有効値範囲：1 - 10）に達した後にのみ通知を送信します。
間隔時間：前回の通知送信後、指定された間隔時間内は通知を再送信しません。例えば、15分ごとにアラートを1回送信する場合、15分以内に受信できるアラート通知は最大1回のみです。
通知方法：
SMS、メール、電話、WeChat、WeCom、DingTalk、Feishu、カスタムインターフェースコールバック（webhook）などの通知方法をサポートします。2種類の構成タイプをサポートしており、いずれか1つを選択すれば十分です。
|
| CLSでのみ使用します。 | ログ監視アラートのみを対象とし、TCOPのその他のタイプ（例えばクラウド製品監視）の監視アラートは対象としません。 |
| TCOPで作成し、共有します。 | ログとTCOPのその他のタイプ（例えばクラウド製品監視）の監視アラートを同時に注視する必要があります。 当番表、アラートメッセージのSCFへの配信機能を使用する必要があります。 |
追加分類フィールド：
アラートを分類します。キーと値の形式（key:value）で構成します。keyはアルファベット、数字、アンダースコアのみをサポートし、アルファベットで始まる必要があります。keyは最大50文字、valueは最大200文字まで構成できます。通知チャネルグループでこのフィールドに基づいて異なる通知ルールを構成でき、追加通知内容およびカスタムインターフェースコールバックで{{.Label}}を使用してこのフィールドを参照することもできます。
例えば分類フィールドを service:payService（現在のアラートに対応するサービス名が payService であることを表します）に設定します：
通知チャネルグループで通知ルールを構成し、service に payService が含まれる場合にアラートを対応するチームに送信します。
カスタムインターフェースコールバック設定で{{.Label}}または{{.Label.service}}を使用してこのフィールドの値を取得します（それぞれ{"service":"payService"}、payService）。サードパーティプラットフォームがインターフェースコールバックを受信すると、このアラートに対応するサービス名を識別できます。
追加通知内容：アラート通知にテキストを追加して、アラート通知内容をより充実させることができます。アラート通知変数を使用して動的に生成できます。 実行周期とクエリ時間範囲の詳細説明
CLSはアラートポリシーを実行する際、アラートポリシーの実際の実行時間を自動的に調整し、多くのアラートポリシーが同時刻に集中して実行されることによる遅延を回避します。そのため、アラートポリシーの実際の実行時間は、指定されたアラート実行周期に基づいて秒単位で変動します。
例えば12:00:00に2つのアラートポリシーを同時に作成し、いずれも1分ごとに実行する設定ですが、実際の実行時間は完全には一致しません：
1つ目のアラートポリシーの実際の実行時間は12:01:12、12:02:12、12:03:12、12:04:11、12:05:11...です。
2つ目のアラートポリシーの実際の実行時間は12:01:27、12:02:27、12:03:27、12:04:27、12:05:27...です。
同時に、自動スケジューリングの場合でもアラートが漏れないようにするため、アラートクエリ時間範囲は自動的に丸められ、さらに30秒のクエリ遅延が追加されます（データ報告には通常10秒程度の遅延があります。実際の時間通りにアラートを実行すると、最新データがまだ報告されていないためにアラートが漏れる可能性が高いため、追加で30秒のクエリ遅延を設けています）。
例えばアラートポリシーは1分ごとに1回実行され、毎回直近1分間のデータをクエリします。実際の実行時間および対応するクエリ時間範囲は以下の通りです：
|
12:01:12 | 11:59:30 ～ 12:00:30 |
12:02:12 | 12:00:30 ～ 12:01:30 |
12:03:12 | 12:01:30 ～ 12:02:30 |
12:04:11 | 12:02:30 ～ 12:03:30 |
12:05:11 | 12:03:30 ～ 12:04:30 |
Cron 式
アラートポリシー実行周期は、最小粒度が分単位の Cron 式をサポートします。この式は5つのスペース区切り時間フィールドで構成され、各フィールドは1つの時間単位を表します。構造は以下の通りです：
各フィールドの意味は以下の通りです：
1番目のフィールド：分（0 - 59）
2番目のフィールド：時（0 - 23）
3番目のフィールド：日（1 - 31）
4番目のフィールド：月（1 - 12）
5番目のフィールド：曜日（0 - 6）（日曜日は0）
注意：
すべてのリージョンにおいて、Cron式の実行タイムゾーンはすべてUTC+8タイムゾーンです。
式では、より複雑な時間ルールを表すためにいくつかの特殊文字を使用できます：
*：任意の値に一致することを表します。分フィールドで*を使用する場合、毎分1回実行されることを表します。
?：指定なしフィールドを表し、日と曜日の2つのフィールドにのみ使用できます。
-：範囲の一致を表します。例えば、分フィールドで5-20を使用する場合、5分から20分の間、毎分1回実行されることを表します。
/：開始時間から実行を開始し、一定時間ごとに1回実行することを表します。例えば、分フィールドで5/20を使用する場合、5分から開始し、20分ごとに1回実行します。つまり、25分と45分にそれぞれ1回実行します。
,：列挙値をリストすることを表します。例えば、分フィールドで5,20を使用する場合、5分と20分にそれぞれ1回実行されることを表します。
例：
|
0 12 * * * | 毎日正午12:00に1回実行します。 |
15 10 * * * | 毎日午前10:15に1回実行します。 |
* 14 * * * | 毎日14:00～14:59の時間帯に、1分ごとに1回実行します。 |
0/5 14 * * * | 毎日14:00～14:55の時間帯に、5分ごとに1回実行します。 |
0/5 14,18 * * * | 毎日14:00～14:55、18:00～18:55の時間帯に、5分ごとに1回実行します。 |
0-5 14 * * * | 毎日14:00～14:05の時間帯に、1分ごとに1回実行します。 |
10,44 14 * 3 3 | 毎年3月の毎週水曜日、午後14:10と14:44にそれぞれ1回実行します。 |
15 10 * * 1-5 | 毎週月曜日から金曜日まで、毎日午前10:15に1回実行します。 |
ベストプラクティス