如何多集合操作与无数据告警 - Simple Log Service - Alibaba Cloud ドキュメントセンター

Simple Log Service (SLS) は、複数のクエリ結果セットにわたる関連モニタリングと、データ収集の中断を検知するためのデータなしアラートに対応しています。

モニタリングの適時性

モニタリングの仕組み

アラートシステムは、チェック頻度 に基づいて、設定されたクエリ文を指定された時間範囲のデータに対して定期的に実行し、その結果をアラート条件と照合して評価します。条件が true と評価された場合、アラートがトリガーされます。
適時性に関する問題の分析
1. データインデックスのレイテンシー：データが Simple Log Service (SLS) に書き込まれてから、クエリ可能になるまでに遅延が発生します。わずかな遅延でも、クエリでデータが欠落するリスクが生じます。
  
  たとえば、アラートチェックが 12:03:30 に実行されるとします。クエリは直近 1 分間の相対時間範囲で設定されており、チェック頻度 は 1 分の固定間隔に設定されています。これにより、クエリの時間範囲は [12:02:30, 12:03:30) になります。12:03:29 に書き込まれたログエントリは、12:03:30 の時点ではインデックス化が完了しておらずクエリで利用できない場合があるため、クエリから漏れる可能性があります。
2. クエリ精度：同じ分内で異なるタイムスタンプを持つログがバッチで書き込まれた場合、SLS は最も早いログのタイムスタンプを使用してバッチ全体にインデックスを作成する場合があります。
  
  例えば、アラートチェックが 12:03:30 に実行され、相対時間範囲が 1 分間、つまり [12:02:30, 12:03:30) であるとします。複数のログエントリが 12:02:50 にバッチとして書き込まれたが、個々のタイムスタンプは 12:02:20、12:02:50 などであるとします。バッチ全体がタイムスタンプ 12:02:20 でインデックスされる可能性があります。その結果、時間範囲 [12:02:30, 12:03:30) を使用するクエリでは、これらのログを見つけることができません。
適時性を最適化するための推奨事項
- 精度の優先：重複アラートやアラートの欠落がなく、高いアラート精度が必要な場合は、以下の推奨事項に従ってください。
  - データインデックス作成の遅延に対処するには、[クエリ統計] ダイアログボックスで、終了時刻が少し前になるように相対的な 検索期間 を設定します。たとえば、相対的な 開始日時 を 70 秒前、終了時間 を 10 秒前に設定します。この 10 秒のバッファにより、インデックス作成の遅延によるデータの欠落を防ぐことができます。
  - クエリの不正確さに対処するには、検索期間 ダイアログボックスで、検索期間を 1 分 (時間枠)、5 分 (時間枠)、または 1 時間 (時間枠) などの固定の時間枠に合わせます。[チェック頻度]を、1 分、5 分、または 1 時間など、選択した時間枠に合わせて設定します。
- 適時性の優先：即時のアラートが必要で、重複アラートの可能性を許容できる場合は、以下の推奨事項に従ってください。
  - データインデックス作成のレイテンシーに対処するには、[クエリ統計] ダイアログボックスの 検索期間 で、相対 開始日時 時刻を、たとえば 70 秒前 (相対) のようにさらに過去にずらします。
  - クエリの不正確さに対処するには、[クエリ統計] ダイアログボックスで、前の間隔をカバーできるように、たとえば 検索期間 を相対 90 秒に、[チェック頻度] を 1 分に設定します。

クエリと分析の結果の関連付け

Simple Log Service のアラートシステムは、クエリ結果をセットとして扱い、複数のセットにわたる相関モニタリングをサポートしています。

設定ページでは、各クエリは番号 (0、1、または 2) で識別され、クエリエディターと時間範囲設定が含まれています。隣接するクエリは、[セット操作] ドロップダウンリストでリンクされています。並べ替えボタンを使用して、クエリを並べ替えたり削除したりできます。[グループ化された評価] オプションは下部にあります。

重要

Simple Log Service は、最大 3 つのセットにわたる相関モニタリングをサポートしています。
デフォルトでは、クエリ結果の最初の 1,000 行がセット操作に使用されます。3 つのクエリを使用し、[セット操作] を [マージなし] 以外の値に設定した場合、各クエリの最初の 100 行のみが使用されます。
3 つのセットを使用する場合、システムはまず最初の 2 つのセットに対して集合演算を実行し、次にその結果と 3 番目のセットに対して 2 回目の演算を実行します。例：
- セット A LEFT JOIN セット B LEFT JOIN セット C：システムはまずセット A とセット B に対して LEFT JOIN を実行し、次にその結果とセット C を別の LEFT JOIN で結合します。
- セット A JOIN セット B INNER JOIN セット C：システムはまずセット A とセット B に対して JOIN を実行し、次にその結果とセット C を INNER JOIN で結合します。
- セット A LEFT EXCLUDE JOIN セット B マージなしセット C：システムはセット A とセット B に対して LEFT EXCLUDE JOIN を実行し、セット C は無視されます。

[集合演算] ドロップダウンリストには、次の表で説明する 9 つのオプションが用意されています。

集合演算	図	説明
マージなし		2 つのセットは関連付けられません。セット A はクエリ結果を提供し、セット B はアラート通知テンプレートの変数のソースとしてのみ機能します。
CROSS JOIN	なし	セット A の各行をセット B の各行と組み合わせます。この演算は、通常、評価データをフィルター処理するために使用されます。
JOIN		セット A の行に、一致するセット B の行のフィールドをマージ (列を追加) します。
INNER JOIN		セット B に一致する行があるセット A の行のみを返します。これにより、セット B がセット A のホワイトリストとして効果的に機能します。
LEFT JOIN		セット A のすべての行を保持し、一致するセット B のデータで補完します。この場合、セット B はセット A のディメンションテーブルとして機能します。
RIGHT JOIN		セット A の一致するデータでセット B を補完します。この場合、セット A はセット B のディメンションテーブルとして機能します。
FULL JOIN		セット A とセット B の両方のすべての行をマージし、一致する行を他方のセットのデータで補完します。
LEFT EXCLUDE JOIN		セット B に一致するものがないセット A の行のみを返します。これにより、セット B がセット A のブラックリストとして効果的に機能します。
RIGHT EXCLUDE JOIN		セット A に一致するものがないセット B の行のみを返します。これにより、セット A がセット B のブラックリストとして効果的に機能します。

マージなし

要件

NGINX アクセスログを監視します。15 分間に 5xx エラーの数が 500 を超えた場合、アラートがトリガーされます。アラートでは、エラーを返した特定のホストを一覧表示する必要があります。
設定は次のとおりです。[クエリと統計 0] のクエリは status >= 500 | select count(1) as cnt で、[セット操作] は [マージなし] に設定されています。[クエリと統計 1] のクエリは status >= 500 | select host, count(1) as pv group by host order by pv desc limit 5 です。[グループ評価] は [グループ化なし] に、[トリガー条件] は [データあり] に設定されており、条件は cnt > 500 です。

結果

クエリと統計 0 の結果

15 分間の 5xx エラー数をカウントします。

cnt

1234

クエリと統計 1 の結果

15 分間における 5xx エラー数が最も多い上位 5 件のホストと、それに対応するエラー数を特定します。

host	pv
host1	60
host2	55
host3	47
host4	45
host5	30

セット操作の結果

[セット操作] が [マージなし] に設定されている場合、セット操作は Query と Statistics 0 の結果を返します。

CROSS JOIN

例 1

要件

Object Storage Service (OSS) と Server Load Balancer (SLB) からのアクセスログをモニターします。15分間に OSS からの 4xx エラーと SLB からの 5xx エラーの合計が 1,000 を超えた場合にアラートがトリガーされます。
設定：クエリ文 0 のクエリは status >= 400 and status < 500 | select count(1) as pv で、[集合演算] は [CROSS JOIN] に設定されています。クエリ文 1 のクエリは status >= 500 | select count(1) as pv です。アラートルールでは、[グループ評価] は [グループ化しない] に設定され、[トリガー条件] は条件 ($0.pv + $1.pv) > 1000 で [データあり] に設定されています。

結果

クエリ文 0 の結果

15分間の OSS からの 4xx エラー数。

890

クエリ文 1 の結果

15分間の SLB からの 5xx エラー数。

567

集合演算の結果

[集合演算] が [CROSS JOIN] に設定されている場合、結果は以下のとおりです。

$0.pv	$1.pv
890	567

追加の例

クエリ文 0 の結果

a	b
a1	b1
a2	b2
a5	b5

クエリ文 1 の結果

a	c
a1	c1
a3	c3

集合演算の結果

[集合演算] が [CROSS JOIN] に設定されている場合、結果は次のようになります:

$0.a	$0.b	$1.a	$1.c
a1	b1	a1	c1
a1	b1	a3	c3
a2	b2	a1	c1
a2	b2	a3	c3
a5	b5	a1	c1
a5	b5	a3	c3

JOIN

例 1

要件

China (Beijing) リージョンと China (Shanghai) リージョンにある 2 つの LogStore の Nginx アクセスログをモニターします。15 分間で、両方の LogStore にわたって 5xx エラーが 30 を超えるホストの合計数が 10 を超えた場合に、アラートがトリガーされます。
設定は次のとおりです。[クエリ統計 0] のクエリ文は status > 500 | select host, count(*) as pv group by host having pv > 30 で、[集合演算] は [JOIN] に設定されています。[クエリ統計 1] のクエリ文は status > 500 | select host, count(*) as pv group by host having pv > 30 で、[グループ評価] は [グループ化なし]、[トリガー条件] は [特定の結果件数] が 10 より大きいと設定されています。

結果

クエリ文 0 の結果

このクエリは、15 分間で 5xx エラーが 30 を超えるホストを特定し、対応するエラー数を一覧表示します。

ホスト	Pv
host1	60
host2	55
host3	47
host4	45
host5	31

クエリ文 1 の結果

このクエリは、15 分間で 5xx エラーが 30 を超えるホストを特定し、対応するエラー数を一覧表示します。

ホスト	Pv
hosta	70
hostb	45
hostc	44
hostd	42

集合演算の結果

[集合演算] が [JOIN] に設定されている場合、結合結果は次のようになります：

ホスト	Pv
host1	60
host2	55
host3	47
host4	45
host5	31
hosta	70
hostb	45
hostc	44
hostd	42

その他の例

2 つのクエリ文の結果フィールドが一致しない場合、JOIN 演算は一致しないフィールドを None で埋めます。

クエリ文 0 の結果

A	B
a1	b1
a2	b2

クエリ文 1 の結果

B	C
b1	c1
b2	c2

集合演算の結果

A	B	C
a1	b1	None
a2	b2	None
None	b1	c1
None	b2	c2

3 つのクエリ文を使用する場合、システムはまずクエリ文 0 とクエリ文 1 に集合演算を実行し、その結果をクエリ文 2 の結果と結合します。

クエリ文 0 の結果

A	B
a1	b1
a2	b2

クエリ文 1 の結果

A	B
a1	b11
a2	b22
a3	b33

クエリ文 0 とクエリ文 1 の結合結果

条件 $0.a == $1.a による 内部結合 演算の結果は次のとおりです：

A	$0.b	$1.b
a1	b1	b11
a2	b2	b22

クエリ文 2 の結果

A	B
a3	b333
a4	b444

最終的な集合演算の結果

JOIN 演算の最終結果は次のとおりです：

説明

クエリ文 2 の結果の b フィールドの値が、最終結果の $0.b 列に設定されます。

A	$0.b	$1.b
a1	b1	b11
a2	b2	b22
a3	b333	None
a4	b444	None

内部結合

例 1

要件

指定したバケットの 5xx エラー数をモニターします。15 分間で 5xx エラー数が 1,000 を超えた場合、アラートをトリガーします。この要件を満たすには、バケットのホワイトリストを維持するためにリソースデータを追加する必要があります。
設定は次のとおりです。[クエリ文 0] のクエリ文は status >=500 | select bucket, count(*) as pv group by bucket having pv > 1000 limit 1000 です。[セット操作] は [INNER JOIN] に設定され、結合条件は $0.bucket = $1.bucket です。[クエリ文 1] では、OSS データソース (user.test) が選択され、バケット bucket_03、bucket_04、bucket_05、および bucket_06 が指定されています。[グループ評価] は [グループ化しない] に設定され、[トリガー条件] は [データが存在する] に設定されています。

結果

クエリ文 0 の結果

15 分間で 5xx エラー数が 1,000 を超えるバケットを特定します。

バケット	Pv
bucket_01	1600
bucket_02	1550
bucket_03	1470
bucket_04	1450

クエリ文 1 の結果

バケットのリソースデータ。

バケット	説明
bucket_03	for dev team
bucket_04	for test team
bucket_05	for service team
bucket_06	for support team

セット操作の結果

セット操作 が INNER JOIN に設定され、条件が $0.bucket == $1.bucket の場合、セット操作の結果は次のようになります。

バケット	Pv	説明
bucket_03	1470	for dev team
bucket_04	1450	for test team

例 2

要件

China (Beijing) リージョンと China (Shanghai) リージョンにある 2 つのログストアに、Nginx アクセスログが保存されています。システムは 15 分ごとに、5xx エラーが 30 を超えるクライアントをクエリします。両方のリージョンで 5xx エラーが発生し、かつ China (Beijing) リージョンのエラー数が China (Shanghai) リージョンのエラー数より多い場合、システムはアラートをトリガーします。
設定は次のとおりです。[クエリ文 0] のクエリ文は status >= 500 | select client_ip, count(1) as pv group by client_ip having pv > 30 です。[セット操作] は [INNER JOIN] に設定され、結合条件は $0.client_ip = $1.client_ip および $0.pv > $1.pv です。[クエリ文 1] のクエリ文は status >= 500 | select client_ip, count(1) as pv group by client_ip having pv > 30 です。[グループ評価] は [グループ化しない] に、[トリガー条件] は [データあり] に設定されます。

結果

クエリ文 0 の結果

15 分間で 5xx エラーが 30 を超える China (Beijing) リージョンのクライアントと、そのエラー数を特定します。

クライアント IP	Pv
192.0.2.4	60
192.0.2.5	55
192.0.2.6	47
192.0.2.7	45
192.0.2.8	31

クエリ文 1 の結果

15 分間で 5xx エラーが 30 を超える China (Shanghai) リージョンのクライアントと、そのエラー数を特定します。

クライアント IP	Pv
192.0.2.5	70
192.0.2.6	45
192.0.2.7	44
192.0.2.8	42
192.0.2.9	42

セット操作の結果

集合演算 が INNER JOIN に設定され、$0.client_ip == $1.client_ip、および $0.pv > $1.pv の場合、集合演算の結果は次のようになります。

クライアント IP	Pv
192.0.2.6	47
192.0.2.7	45

その他の例

2 つのクエリ文の結果セットに、結合キーではない同名のフィールドが含まれている場合、システムは最終的な結果セットでは、これらのフィールド名の先頭に自動的に $0. と $1. を追加します。

クエリ文 0 の結果

A	B	C	D
a1	b1	c1	d1
a2	b2	c2	d2
a3	b3	c3	d3

クエリ文 1 の結果

A	B	C
a1	b11	c11
a2	b22	c22

セット操作の結果

[集合演算] が [INNER JOIN] で、かつ [$0.a == $1.a] の場合、集合演算の結果は次のようになります。

A	$0.b	$0.c	D	$1.b	$1.c
a1	b1	c1	d1	b11	c11
a2	b2	c2	d2	b22	c22

LEFT JOIN

クエリ文 0 の結果

A	B
a1	b1
a2	b2
a3	b3

クエリ文 1 の結果

A	B	C
a1	b11	c1
a2	b22	c2

セット操作の結果

[セット操作] を [LEFT JOIN] に、結合条件を $0.a == $1.a に設定した場合、結果は次のとおりです：

A	$0.b	$1.b	C
a1	b1	b11	c1
a2	b2	b22	c2
a3	b3	NULL	NULL

右結合

クエリ 0 の結果

a	b	c
a1	b11	c1
a2	b22	c2

クエリ 1 の結果

a	b
a1	b1
a2	b2
a3	b3

集合演算の結果

[集合演算] が RIGHT JOIN で、条件が $0.a == $1.a の場合、結果は次のようになります：

a	$0.b	c	$1.b
a1	b11	c1	b1
a2	b22	c2	b2
a3	NULL	NULL	b3

完全外部結合

ソースデータ 0

a	b	c
a1	b1	c1
a2	b2	c2
a5	b5	c3

ソースデータ 1

a	b	d
a1	b11	d1
a2	b22	d2
a3	b33	d3

集合演算の結果

[集合演算] パラメーターを [FULL JOIN] に、結合条件を $0.a == $1.a に設定した場合、結果は次のとおりです：

a	$0.b	c	$1.b	d
a1	b1	c1	b11	d1
a2	b2	c2	b22	d2
a5	b5	c3	NULL	NULL
a3	NULL	NULL	b33	d3

LEFT EXCLUDE JOIN

要件

ブラックリストにあるものを除き、すべてのバケットの 5xx エラーをモニターします。15 分間にエラー数が 1,000 を超えた場合、アラートがトリガーされます。これを行うには、リソースデータを使用してバケットのブラックリストを維持します。
設定は以下の通りです。[クエリステートメント 0] のクエリは status >=500 | select bucket, count(*) as pv group by bucket having pv > 1000 limit 1000 です。[セット操作] は [LEFT EXCLUDE JOIN]、結合条件は $0.bucket = $1.bucket です。[クエリステートメント 1] では、OSS データソースは (user.test)、バケットは bucket_03 と bucket_04 です。[グループ評価] は [グループ化なし]、[トリガー条件] は [データあり] に設定されます。

結果

クエリ文 0 の結果

15 分間に 1,000 を超える 5xx エラーがあるバケットを特定します。

バケット	PV
bucket_01	1060
bucket_02	1055
bucket_03	1047
bucket_04	1045

クエリ文 1 の結果

バケットのリソースデータです。

バケット	説明
bucket_03	for dev team
bucket_04	for test team

集合演算の結果

[集合演算] を [LEFT EXCLUDE JOIN] に設定し、条件を [$0.bucket = $1.bucket] とした場合、結果は次のようになります：

バケット	PV
bucket_01	1060
bucket_02	1055

右除外結合

要件

ブラックリストにないすべてのバケットの 5xx エラーを監視します。15 分以内にエラー数が 1,000 を超えた場合、システムはアラートをトリガーします。これを行うには、リソースデータを追加してバケットのブラックリストを維持します。
設定は次のとおりです：[クエリ文 0] では、OSS データソース (user.test) を選択し、bucket_03 と bucket_04 を指定します。[セット操作] を、結合条件 $0.bucket = $1.bucket で [右除外結合] に設定します。[クエリ文 1] では、クエリ文を status > 500 | select bucket, count(*) as pv group by bucket having pv > 1000 limit 1000 に設定します。[グループ評価] を [グループ化なし] に設定し、[トリガー条件] を [データあり] に設定します。

結果

クエリ文 0 の結果

ブラックリストにあるバケットのリソースデータを返します。

バケット	説明
bucket_03	開発チーム用
bucket_04	テストチーム用

クエリ文 1 の結果

15 分以内に 1,000 件を超える 5xx エラーが発生したバケットを返します。

バケット	Pv
bucket_01	1060
bucket_02	1055
bucket_03	1047
bucket_04	1045

集合演算の結果

[セット操作] が結合条件 $0.bucket = $1.bucket で [右除外結合] に設定されている場合、結果は次のようになります：

バケット	Pv
bucket_01	1060
bucket_02	1055

データなしアラート

データなしアラートは、データ収集中に見過ごされがちなデータ損失の検知に役立ちます。たとえば、各ホストの CPU 使用率をモニターするアラートルールを作成し、次のいずれかの条件を満たした場合にアラート通知を受信できます：

CPU 使用率が 95% を超える。
クエリと分析からデータが返されない。

アラートルールを次のとおり設定します：

クエリ統計：CPU 使用率を算出するクエリを指定します。
```
* | select promql_query_range('cpu_util') from metrics limit 1000
```
[トリガー条件]：式に一致するデータ、値>95、重大度：Medium

クエリと分析の結果に含まれる値フィールドが 95 を超えた場合、重大度が Medium のアラートがトリガーされます。
[連続トリガーのしきい値]：アラートを生成するために、トリガー条件を連続して満たす必要がある回数。
データなしアラート：データなしアラート スイッチをオンにし、重大度とアノテーションを設定します。

有効にすると、連続してデータが返されないクエリの回数が連続トリガーのしきい値を超えた場合にアラートがトリガーされます。

データなしアラートには、個別の重大度とアノテーションを設定できます。

ページは次のとおり設定します：

グルーピング評価では、ラベルで自動を選択します。アノテーションの追加セクションで、タイトルを ${alert_name} alert triggered に、説明を ${alert_name} alert triggered に設定します。自動アノテーションと復旧通知を無効にします。詳細設定で、連続トリガーのしきい値を 1 に設定します。データなしアラートを有効にし、その重大度をMediumに、アノテーションのタイトルを${alert_name}: No dataに、説明をNo data was returned when this alert rule was evaluatedに設定します。