如何多集合操作与无数据告警 - Simple Log Service

Corrélez les résultats de surveillance entre plusieurs ensembles de requêtes à l'aide d'opérations ensemblistes et configurez des alertes en cas d'absence de données pour détecter les interruptions de collecte.

Actualité de la surveillance

Fonctionnement de la surveillance

Le système d'alerte exécute périodiquement la requête configurée selon la valeur définie dans Check Frequency, l'exécute sur les données comprises dans une plage temporelle spécifiée et évalue les résultats par rapport à la condition d'alerte. Une alerte est déclenchée si la condition est vérifiée.
Analyse des problèmes d'actualité
1. Latence d'indexation des données : un délai existe entre l'écriture des données dans Simple Log Service et leur disponibilité pour l'interrogation. Même un court délai peut entraîner l'omission de données.
  
  Par exemple, une vérification d'alerte s'exécute à 12:03:30. La requête est configurée avec une plage temporelle relative correspondant à la dernière minute, et la valeur de Check Frequency est définie sur un intervalle fixe de 1 minute. La plage temporelle de la requête devient donc [12:02:30, 12:03:30). Une entrée de journal écrite à 12:03:29 risque de ne pas être indexée ni disponible pour interrogation à 12:03:30 et pourrait ainsi échapper à la requête.
2. Précision des requêtes : lorsque des journaux horodatés différemment au sein d'une même minute sont écrits par lot, Simple Log Service peut indexer l'intégralité du lot en utilisant l'horodatage du journal le plus ancien.
  
  Par exemple, une vérification d'alerte s'exécute à 12:03:30 avec une plage temporelle relative d'une minute, soit [12:02:30, 12:03:30). Supposons que plusieurs entrées de journal soient écrites en lot à 12:02:50, mais que leurs horodatages individuels soient 12:02:20, 12:02:50, etc. L'ensemble du lot pourrait être indexé sous l'horodatage 12:02:20. Par conséquent, une requête utilisant la plage temporelle [12:02:30, 12:03:30) ne trouverait pas ces journaux.
Recommandations pour optimiser l'actualité
- Priorité à la précision : suivez ces recommandations si vous exigez une grande précision des alertes, sans doublons ni omissions.
  - Pour pallier la latence d'indexation : dans la boîte de dialogue Query Statistics, spécifiez une valeur relative pour Query Time Range se terminant légèrement dans le passé. Par exemple, définissez Start At sur « il y a 70 secondes » et End Time sur « il y a 10 secondes ». Ce tampon de 10 secondes aide à éviter les pertes de données dues aux délais d'indexation.
  - Pour corriger l'imprécision des requêtes : dans la boîte de dialogue Query Time Range , alignez votre Query Time Range sur des fenêtres temporelles fixes, telles que 1 Minute (Time Frame), 5 Minute (Time Frame) ou 1 Hour (Time Frame). Ajustez la valeur de Check Frequency pour qu'elle corresponde à la fenêtre temporelle sélectionnée, par exemple 1 minute, 5 minutes ou 1 heure.
- Priorité à l'actualité immédiate : suivez ces recommandations si vous avez besoin d'alertes immédiates et pouvez tolérer la possibilité de doublons.
  - Pour pallier la latence d'indexation : dans la boîte de dialogue Query Statistics, sous Query Time Range , décalez la valeur relative de Start At plus loin dans le passé, par exemple sur « il y a 70 secondes » (relative).
  - Pour corriger l'imprécision des requêtes : dans la boîte de dialogue Query Statistics, assurez-vous que la valeur de Query Time Range est suffisamment large pour couvrir l'intervalle précédent, par exemple en la définissant sur une valeur relative de 90 secondes et en réglant la valeur de Check Frequency sur 1 minute.

Association des résultats de requête et d'analyse

Le système d'alerte de Simple Log Service traite les résultats de requête comme des ensembles et prend en charge la surveillance corrélée entre plusieurs ensembles.

Sur la page de configuration, chaque requête est identifiée par un numéro (0, 1 ou 2) et comprend un éditeur de requête ainsi que des paramètres de plage temporelle. Les requêtes adjacentes sont liées par la liste déroulante set operations. Utilisez les boutons de tri pour réorganiser ou supprimer des requêtes. L'option Grouped Evaluation se trouve en bas de page.

Important

Simple Log Service prend en charge la surveillance corrélée sur jusqu'à trois ensembles.
Par défaut, les 1 000 premières lignes des résultats de requête sont utilisées pour les opérations ensemblistes. Si vous utilisez trois requêtes et que vous définissez la valeur de set operation sur une option autre que No Merge, seules les 100 premières lignes de chaque requête sont prises en compte.
Si vous utilisez trois ensembles, le système effectue d'abord une opération ensembliste sur les deux premiers ensembles, puis une seconde opération sur ce résultat et le troisième ensemble. Par exemple :
- Ensemble A LEFT JOIN Ensemble B LEFT JOIN Ensemble C : le système effectue d'abord un LEFT JOIN sur l'ensemble A et l'ensemble B, puis joint ce résultat à l'ensemble C via un autre LEFT JOIN.
- Ensemble A JOIN Ensemble B INNER JOIN Ensemble C : le système effectue d'abord un JOIN sur l'ensemble A et l'ensemble B, puis joint ce résultat à l'ensemble C via un INNER JOIN.
- Ensemble A LEFT EXCLUDE JOIN Ensemble B No Merge Ensemble C : le système effectue un LEFT EXCLUDE JOIN sur l'ensemble A et l'ensemble B, et ignore l'ensemble C.

La liste déroulante set operations propose les neuf options suivantes.

Set operations	Illustration	Description
No Merge		Les deux ensembles ne sont pas associés. L'ensemble A fournit les résultats de requête, tandis que l'ensemble B sert uniquement de source de variables pour le modèle de notification d'alerte.
CROSS JOIN	Aucune	Combine chaque ligne de l'ensemble A avec chaque ligne de l'ensemble B. Cette opération est généralement utilisée pour filtrer les données avant évaluation.
JOIN		Fusionne les données de l'ensemble B dans les lignes correspondantes de l'ensemble A, en alignant les lignes par nom de champ.
INNER JOIN		Renvoie uniquement les lignes de l'ensemble A qui possèdent une ligne correspondante dans l'ensemble B. Cela revient à utiliser l'ensemble B comme liste blanche pour l'ensemble A.
LEFT JOIN		Enrichit l'ensemble A avec les données correspondantes de l'ensemble B. Dans ce cas, l'ensemble B agit comme table de dimension pour l'ensemble A.
RIGHT JOIN		Enrichit l'ensemble B avec les données correspondantes de l'ensemble A. Dans ce cas, l'ensemble A agit comme table de dimension pour l'ensemble B.
FULL JOIN		Fusionne toutes les lignes des ensembles A et B, en enrichissant les lignes correspondantes avec les données de l'autre ensemble.
LEFT EXCLUDE JOIN		Renvoie uniquement les lignes de l'ensemble A qui n'ont pas de correspondance dans l'ensemble B. Cela revient à utiliser l'ensemble B comme liste noire pour l'ensemble A.
RIGHT EXCLUDE JOIN		Renvoie uniquement les lignes de l'ensemble B qui n'ont pas de correspondance dans l'ensemble A. Cela revient à utiliser l'ensemble A comme liste noire pour l'ensemble B.

No merge

Exigence

Surveillez les journaux d'accès NGINX. Déclenchez une alerte si le nombre d'erreurs 5xx dépasse 500 sur une période de 15 minutes. L'alerte doit lister les hôtes spécifiques ayant renvoyé des erreurs.
La configuration est la suivante : la requête pour Query and Statistics 0 est status > 500 | select count(1) as cnt et la valeur de set operation est définie sur No merge. La requête pour Query and Statistics 1 est status > 500 | select host, count(1) as pv group by host order by pv desc limit 5. La valeur de group evaluation est définie sur No Grouping et la trigger condition est définie sur has data, avec la condition cnt > 500.

Résultat

Résultats de Query and Statistics 0

Compte le nombre d'erreurs 5xx sur une période de 15 minutes.

cnt

1234

Résultats de Query and Statistics 1

Identifie les 5 hôtes présentant le plus grand nombre d'erreurs 5xx sur une période de 15 minutes, ainsi que leurs nombres d'erreurs respectifs.

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

Résultat de l'opération ensembliste

Lorsque la valeur de set operation est définie sur No merge, l'opération ensembliste renvoie le résultat de Query and Statistics 0.

CROSS JOIN

Exemple 1

Exigence

Surveillez les journaux d'accès d'Object Storage Service (OSS) et de Server Load Balancer (SLB). Déclenchez une alerte si le total combiné des erreurs 4xx provenant d'OSS et des erreurs 5xx provenant de SLB dépasse 1 000 sur une période de 15 minutes.
Configuration : la requête pour Query Statement 0 est status >= 400 and status < 500 | select count(1) as pv et la valeur de Set Operations est définie sur CROSS JOIN. La requête pour Query Statement 1 est status >= 500 | select count(1) as pv. Pour la règle d'alerte, la valeur de Group Evaluation est définie sur Ungrouped et la Trigger Condition est définie sur Data exists avec la condition ($0.pv + $1.pv) > 1000.

Résultats

Résultats de query statement 0

Nombre d'erreurs 4xx provenant d'OSS sur une période de 15 minutes.

pv

890
Résultats de query statement 1

Nombre d'erreurs 5xx provenant de SLB sur une période de 15 minutes.

pv

567

Résultats de l'opération ensembliste

Lorsque la valeur de Set Operations est définie sur CROSS JOIN, les résultats sont les suivants :

$0.pv	$1.pv
890	567

Autres exemples

Résultats de query statement 0

a	b
a1	b1
a2	b2
a5	b5

Résultats de query statement 1

a	c
a1	c1
a3	c3

Résultats de l'opération ensembliste

Lorsque la valeur de Set Operations est définie sur CROSS JOIN, les résultats sont les suivants :

$0.a	b	$1.a	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

Exemple 1

Exigence

Surveillez les journaux d'accès Nginx provenant de deux LogStores, l'un dans la région Chine (Pékin) et l'autre dans la région Chine (Shanghai). Déclenchez une alerte si le nombre total d'hôtes présentant plus de 30 erreurs 5xx dans les deux LogStores dépasse 10 sur un intervalle de 15 minutes.
La configuration est la suivante : pour Query Statistics 0, l'instruction de requête est status > 500 | select host, count(*) as pv group by host having pv > 30 et la valeur de Set Operation est JOIN. Pour Query Statistics 1, l'instruction de requête est status > 500 | select host, count(*) as pv group by host having pv > 30, la valeur de Group Evaluation est No Grouping et la Trigger Condition est has specific number of results supérieure à 10.

Résultat

Résultats de Query Statement 0

Cette requête identifie les hôtes présentant plus de 30 erreurs 5xx sur une période de 15 minutes et liste leurs nombres d'erreurs respectifs.

Host	Pv
host1	60
host2	55
host3	47
host4	45
host5	31

Résultats de Query Statement 1

Cette requête identifie les hôtes présentant plus de 30 erreurs 5xx sur une période de 15 minutes et liste leurs nombres d'erreurs respectifs.

Host	Pv
hosta	70
hostb	45
hostc	44
hostd	42

Résultat de l'opération ensembliste

Lorsque la valeur de Set Operations est définie sur JOIN, le résultat combiné est le suivant :

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

Autres exemples

Si les champs de résultat de deux instructions de requête ne correspondent pas, l'opération JOIN remplit les champs non correspondants par None.

Résultats de Query Statement 0

A	B
a1	b1
a2	b2

Résultats de Query Statement 1

B	C
b1	c1
b2	c2

Résultat de l'opération ensembliste

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

Lorsque vous utilisez trois instructions de requête, le système effectue d'abord une opération ensembliste sur Query Statement 0 et Query Statement 1, puis joint ce résultat aux résultats de Query Statement 2.

Résultats de Query Statement 0

A	B
a1	b1
a2	b2

Résultats de Query Statement 1

A	B
a1	b11
a2	b22
a3	b33

Résultat de la jointure entre Query Statement 0 et Query Statement 1

Le résultat de l'opération INNER JOIN avec la condition $0.a == $1.a est le suivant :

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

Résultats de Query Statement 2

A	B
a3	b333
a4	b444

Résultat de l'opération ensembliste finale

Le résultat final de l'opération JOIN est le suivant :

Remarque

Les valeurs du champ b issues des résultats de Query Statement 2 remplissent la colonne $0.b dans le résultat final.

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

Inner join

Exemple 1

Exigence

Surveillez le nombre d'erreurs 5xx dans un bucket spécifié. Déclenchez une alerte si le compte dépasse 1 000 sur une période de 15 minutes. Pour répondre à cette exigence, vous devez ajouter des données de ressource afin de maintenir une liste blanche de buckets.
La configuration est la suivante : l'instruction de requête pour Query Statement 0 est status >=500 | select bucket, count(*) as pv group by bucket having pv > 1000 limit 1000. La valeur de Set Operations est définie sur INNER JOIN avec la condition de jointure $0.bucket = $1.bucket. Pour Query Statement 1, la source de données OSS (user.test) est sélectionnée, spécifiant les buckets bucket_03, bucket_04, bucket_05 et bucket_06. La valeur de Group Evaluation est définie sur Ungrouped et la Trigger Condition est définie sur Data exists.

Résultats

Résultats de Query Statement 0

Identifie les buckets présentant plus de 1 000 erreurs 5xx sur une période de 15 minutes.

Bucket	Pv
bucket_01	1600
bucket_02	1550
bucket_03	1470
bucket_04	1450

Résultats de Query Statement 1

Données de ressource pour les buckets.

Bucket	Description
bucket_03	for dev team
bucket_04	for test team
bucket_05	for service team
bucket_06	for support team

Résultats de l'opération ensembliste

Lorsque la valeur de Set Operation est définie sur INNER JOIN avec la condition $0.bucket == $1.bucket, le résultat de l'opération ensembliste est le suivant :

Bucket	Pv	Description
bucket_03	1470	for dev team
bucket_04	1450	for test team

Exemple 2

Exigence

Deux logstores, l'un dans la région Chine (Pékin) et l'autre dans la région Chine (Shanghai), stockent des journaux d'accès Nginx. Toutes les 15 minutes, le système recherche les clients présentant plus de 30 erreurs 5xx. Une alerte est déclenchée si des erreurs 5xx surviennent dans les deux régions et si le nombre d'erreurs dans la région Chine (Pékin) dépasse celui de la région Chine (Shanghai).
La configuration est la suivante : l'instruction de requête pour Query Statement 0 est status >= 500 | select client_ip, count(1) as pv group by client_ip having pv > 30. La valeur de Set Operations est définie sur INNER JOIN avec les conditions de jointure $0.client_ip = $1.client_ip et $0.pv > $1.pv. L'instruction de requête pour Query Statement 1 est status >= 500 | select client_ip, count(1) as pv group by client_ip having pv > 30. La valeur de Group Evaluation est définie sur Ungrouped et la Trigger Condition est définie sur Data exists.

Résultats

Résultats de Query Statement 0

Identifie les clients de la région Chine (Pékin) présentant plus de 30 erreurs 5xx sur une période de 15 minutes, ainsi que leurs nombres d'erreurs respectifs.

Client 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

Résultats de Query Statement 1

Identifie les clients de la région Chine (Shanghai) présentant plus de 30 erreurs 5xx sur une période de 15 minutes, ainsi que leurs nombres d'erreurs respectifs.

Client 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

Résultats de l'opération ensembliste

Lorsque la valeur de Set Operations est définie sur INNER JOIN, avec les conditions $0.client_ip == $1.client_ip et $0.pv > $1.pv, le résultat de l'opération ensembliste est le suivant :

Client ip	Pv
192.0.2.6	47
192.0.2.7	45

Autres exemples

Si les ensembles de résultats de deux instructions de requête contiennent des champs portant des noms identiques qui ne sont pas des clés de jointure, le système préfixe automatiquement ces noms de champs par $0. et $1. dans l'ensemble de résultats final.

Résultats de Query Statement 0

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

Résultats de Query Statement 1

A	B	C
a1	b11	c11
a2	b22	c22

Résultats de l'opération ensembliste

Lorsque la valeur de Set Operation est INNER JOIN et que la condition est $0.a == $1.a, le résultat de l'opération ensembliste est le suivant :

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

LEFT JOIN

Résultats de query statement 0

A	B
a1	b1
a2	b2
a3	b3

Résultats de query statement 1

A	B	C
a1	b11	c1
a2	b22	c2

Résultats de l'opération ensembliste

Lorsque la valeur de Set Operations est définie sur LEFT JOIN avec la condition de jointure $0.a == $1.a, le résultat est le suivant :

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

Right join

Résultats pour Query 0

a	b	c
a1	b11	c1
a2	b22	c2

Résultats pour Query 1

a	b
a1	b1
a2	b2
a3	b3

Résultat de l'opération ensembliste

Lorsque la valeur de Set Operations est définie sur RIGHT JOIN avec la condition $0.a == $1.a, le résultat est le suivant :

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

Full join

Source de données 0

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

Source de données 1

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

Résultats de l'opération ensembliste

Lorsque vous définissez le paramètre Set Operations sur FULL JOIN avec la condition de jointure $0.a == $1.a, le résultat est le suivant :

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

LEFT EXCLUDE JOIN

Exigence

Surveillez les erreurs 5xx pour tous les buckets, à l'exception de ceux figurant sur la liste noire. Déclenchez une alerte si le nombre d'erreurs dépasse 1 000 sur une période de 15 minutes. Pour ce faire, utilisez des données de ressource afin de maintenir la liste noire de buckets.
La configuration est la suivante : la requête pour Query Statement 0 est status >=500 | select bucket, count(*) as pv group by bucket having pv > 1000 limit 1000. La valeur de set operation est définie sur LEFT EXCLUDE JOIN avec la condition de jointure $0.bucket = $1.bucket. Pour Query Statement 1, la source de données OSS est (user.test) et les buckets sont bucket_03 et bucket_04. La valeur de Group Evaluation est définie sur Ungrouped et la trigger condition est définie sur data exists.

Résultat

Résultats de Query Statement 0

Identifie les buckets présentant plus de 1 000 erreurs 5xx sur une période de 15 minutes.

Bucket	Pv
bucket_01	1060
bucket_02	1055
bucket_03	1047
bucket_04	1045

Résultats de Query Statement 1

Données de ressource pour les buckets.

Bucket	Description
bucket_03	for dev team
bucket_04	for test team

Résultat de l'opération ensembliste

Lorsque la valeur de set operation est définie sur LEFT EXCLUDE JOIN avec la condition $0.bucket = $1.bucket, le résultat est le suivant :

Bucket	Pv
bucket_01	1060
bucket_02	1055

Right exclude join

Exigence

Surveillez les erreurs 5xx pour tous les buckets ne figurant pas sur la liste noire. Déclenchez une alerte si le nombre d'erreurs dépasse 1 000 sur une période de 15 minutes. Pour ce faire, ajoutez des données de ressource afin de maintenir la liste noire de buckets.
Configurez les paramètres comme suit : pour Query Statement 0, sélectionnez la source de données OSS (user.test) et spécifiez bucket_03 et bucket_04. Définissez la valeur de Set Operations sur RIGHT EXCLUDE JOIN, avec la condition de jointure $0.bucket = $1.bucket. Pour Query Statement 1, définissez l'instruction de requête sur status > 500 | select bucket, count(*) as pv group by bucket having pv > 1000 limit 1000. Définissez la valeur de Group Evaluation sur No Grouping et la Trigger Condition sur Data exists.

Résultat

Résultats de Query Statement 0

Renvoie les données de ressource pour les buckets figurant sur la liste noire.

Bucket	Description
bucket_03	for dev team
bucket_04	for test team

Résultats de Query Statement 1

Renvoie les buckets présentant plus de 1 000 erreurs 5xx sur une période de 15 minutes.

Bucket	Pv
bucket_01	60
bucket_02	55
bucket_03	47
bucket_04	45

Résultat de l'opération ensembliste

Lorsque la valeur de Set Operations est définie sur RIGHT EXCLUDE JOIN avec la condition de jointure $0.bucket = $1.bucket, le résultat est le suivant :

Bucket	Pv
bucket_01	60
bucket_02	55

Alerte en cas d'absence de données

Les alertes en cas d'absence de données détectent les pertes de données passées inaperçues lors de la collecte. Par exemple, créez une règle d'alerte pour surveiller l'utilisation du CPU de chaque hôte et recevez une notification d'alerte si l'une des conditions suivantes est remplie :

L'utilisation du CPU dépasse 95 %.
Aucune donnée n'est renvoyée par la requête et l'analyse.

Configurez la règle d'alerte comme suit :

Query statistics : spécifiez une requête pour calculer l'utilisation du CPU.
```
* | select promql_query_range('cpu_util') from metrics limit 1000
```
Trigger Condition : Data matches the expression, value>95, Severity: Medium

Si la valeur du champ value dans les résultats de requête et d'analyse dépasse 95, une alerte de gravité moyenne est déclenchée.
Threshold of Continuous Triggers : nombre de fois consécutives où la condition de déclenchement doit être satisfaite avant qu'une alerte ne soit générée.
No-data alert : activez l'option no-data alert et définissez la gravité et l'annotation.

Une fois activée, une alerte est déclenchée si le nombre de requêtes consécutives ne renvoyant aucune donnée dépasse le seuil de déclenchement continu.

Vous pouvez définir une gravité et une annotation distinctes pour les alertes en cas d'absence de données.

La page est configurée comme suit :

Pour grouping evaluation, sélectionnez Automatic by label. Dans la section Add annotation, définissez le titre sur ${alert_name} alert triggered et la description sur ${alert_name} alert triggered. Désactivez automatic annotation et recovery notification. Dans advanced settings, définissez le continuous trigger threshold sur 1. Activez no-data alert et définissez sa severity sur Medium, son titre d'annotation sur ${alert_name}: No data et sa description sur No data was returned when this alert rule was evaluated.