Analyse de série chronologique

Les services cloud et les appareils IoT génèrent des données de télémétrie qui peuvent être utilisées pour obtenir des insights tels que la surveillance de l’intégrité du service, les processus de production physique et les tendances d’utilisation. L’analyse des séries chronologiques est une façon d’identifier les écarts dans le modèle de ces métriques par rapport à leur modèle de base de référence classique.

Langage de requête Kusto (KQL) contient la prise en charge native de la création, de la manipulation et de l’analyse de plusieurs séries chronologiques. Dans cet article, découvrez comment KQL est utilisé pour créer et analyser des milliers de séries chronologiques en secondes, ce qui permet des solutions et des workflows de supervision en quasi-temps réel.

Création de série chronologique

Dans le cadre de cette section, nous allons créer un vaste ensemble de séries chronologiques régulières, de façon simple et intuitive, à l’aide de l’opérateur make-series, et renseigner les valeurs manquantes en fonction des besoins. La première étape de l’analyse d’une série chronologique consiste à partitionner et à transformer la table de données de télémétrie d’origine en un ensemble de séries chronologiques. La table contient généralement une colonne de type timestamp, des dimensions contextuelles et des métriques facultatives. Les dimensions sont utilisées pour partitionner les données. L’objectif est de créer des milliers de séries chronologiques par partition à intervalles réguliers.

La table d’entrée demo_make_series1 contient 600 000 enregistrements de trafic de service web arbitraire. Utilisez la commande suivante pour échantillonner 10 enregistrements :

Exécuter la requête

demo_make_series1 | take 10 

La table ainsi obtenue contient une colonne de type timestamp, trois colonnes de dimensions contextuelles et aucune métrique :

TimeStamp	BrowserVer	OsVer	Pays/Région
2016-08-25 09:12:35.4020000	Chrome 51.0	Windows 7	Royaume-Uni
2016-08-25 09:12:41.1120000	Chrome 52.0	Windows 10
2016-08-25 09:12:46.2300000	Chrome 52.0	Windows 7	Royaume-Uni
2016-08-25 09:12:46.5100000	Chrome 52.0	Windows 10	Royaume-Uni
2016-08-25 09:12:46.5570000	Chrome 52.0	Windows 10	République de Lituanie
2016-08-25 09:12:47.0470000	Chrome 52.0	Windows 8.1	Inde
2016-08-25 09:12:51.3600000	Chrome 52.0	Windows 10	Royaume-Uni
2016-08-25 09:12:51.6930000	Chrome 52.0	Windows 7	Pays-Bas
2016-08-25 09:12:56.4240000	Chrome 52.0	Windows 10	Royaume-Uni
2016-08-25 09:13:08.7230000	Chrome 52.0	Windows 10	Inde

À défaut de métriques, nous pouvons uniquement créer un ensemble de séries temporelles représentant le comptage du trafic proprement dit, partitionné par système d’exploitation à l’aide de la requête suivante :

Exécuter la requête

let min_t = toscalar(demo_make_series1 | summarize min(TimeStamp));
let max_t = toscalar(demo_make_series1 | summarize max(TimeStamp));
demo_make_series1
| make-series num=count() default=0 on TimeStamp from min_t to max_t step 1h by OsVer
| render timechart 

• Utilisez l’opérateur make-series pour créer un ensemble de trois séries chronologiques dans lequel :
  • num=count() : est la série chronologique du trafic
  • from min_t to max_t step 1h : la série chronologique est créée en compartiments de 1 heure dans l’intervalle de temps (timestamps les plus anciens et les plus récents des enregistrements de la table)
  • default=0 : spécifie la méthode de remplissage des compartiments manquants pour créer une série chronologique régulière. Vous pouvez également utiliser series_fill_const(), series_fill_forward(), series_fill_backward() et series_fill_linear() pour des modifications
  • by OsVer : partitionne par système d’exploitation
• La structure de données d’une série chronologique réelle est un tableau numérique de la valeur agrégée par compartiment de temps. Nous utilisons render timechart pour la visualisation.

Dans le tableau ci-dessus, nous avons trois partitions. Nous pouvons créer une série chronologique distincte (Windows 10 en rouge, Windows 7 en bleu et Windows 8.1 en vert) pour chaque version du système d’exploitation, comme dans le graphique ci-dessous :

Fonctions d’analyse de séries chronologiques

Dans le cadre de cette section, nous allons exécuter des fonctions de traitement de série classiques. Une fois qu’un ensemble de séries chronologiques est créé, KQL prend en charge une liste croissante de fonctions pour les traiter et les analyser. Nous allons décrire quelques fonctions représentatives pour le traitement et l’analyse des séries chronologiques.

Filtrage

Le filtrage est une pratique courante dans le traitement de signal, utile pour les tâches de traitement de séries chronologiques (par exemple, lissage d’un signal bruyant, détection de modifications).

• Il existe deux fonctions de filtrage génériques :
  • series_fir() : appliquant un filtre FIR. Utilisée pour effectuer un calcul simple de moyenne mobile et de différenciation des séries chronologiques pour la détection des modifications.
  • series_iir() : appliquant un filtre IIR. Utilisée pour effectuer un lissage exponentiel et calculer une somme cumulée.
• Étendre (Extend) l’ensemble de séries chronologiques en ajoutant une nouvelle série de moyennes mobiles de 5 compartiments (nommée ma_num) à la requête :

Exécuter la requête

let min_t = toscalar(demo_make_series1 | summarize min(TimeStamp));
let max_t = toscalar(demo_make_series1 | summarize max(TimeStamp));
demo_make_series1
| make-series num=count() default=0 on TimeStamp from min_t to max_t step 1h by OsVer
| extend ma_num=series_fir(num, repeat(1, 5), true, true)
| render timechart

Analyse de régression

Azure Data Explorer prend en charge l’analyse de régression linéaire segmentée pour estimer la tendance de la série chronologique.

• Utilisez series_fit_line() pour ajuster la meilleure droite à une série chronologique afin d’obtenir une détection de tendance générale.
• Utilisez series_fit_2lines() pour détecter des changements de tendances par rapport à une ligne de base, qui sont utiles dans les scénarios de surveillance.

Exemple de fonctions series_fit_line() et series_fit_2lines() dans une requête de série chronologique :

Exécuter la requête

demo_series2
| extend series_fit_2lines(y), series_fit_line(y)
| render linechart with(xcolumn=x)

• Bleu : série chronologique d’origine
• Vert : droite ajustée
• Rouge : deux droites ajustées

Notes

La fonction a détecté avec précision le point de saut (changement de niveau).

Détection de saisonnalité

De nombreuses métriques suivent un modèle saisonnier (périodique). Le trafic des utilisateurs des services cloud contient généralement des modèles quotidiens et hebdomadaires qui atteignent le niveau le plus élevé vers le milieu de journée, et le niveau le plus bas pendant la nuit et le week-end. Des capteurs IoT prennent des mesures à intervalles réguliers. Des mesures physiques, par exemple de température, de pression ou d’humidité, peuvent également suivre un modèle saisonnier.

L’exemple suivant applique une détection de saisonnalité au trafic d’un mois d’un service web (compartiments de 2 heures) :

Exécuter la requête

demo_series3
| render timechart 

• Utilisez series_periods_detect() pour détecter automatiquement des périodes dans la série chronologique.
• Utilisez series_periods_validate() si vous savez qu’une métrique doit comporter des périodes distinctes spécifiques et souhaitez vérifier qu’elles existent.

Notes

L’inexistence de périodes distinctes constitue une anomalie.

Exécuter la requête

demo_series3
| project (periods, scores) = series_periods_detect(num, 0., 14d/2h, 2) //to detect the periods in the time series
| mv-expand periods, scores
| extend days=2h*todouble(periods)/1d

periods	scores	jours
84	0,820622786055595	7
12	0,764601405803502	1

La fonction détecte les saisonnalités quotidienne et hebdomadaire. La saisonnalité quotidienne présente un score inférieur à celui de la saisonnalité hebdomadaire, car les jours du week-end diffèrent des jours de la semaine.

Fonctions par élément

Des opérations arithmétiques et logiques peuvent être appliquées à une série chronologique. À l’aide de series_subtract(), vous pouvez calculer une série chronologique résiduelle, qui est la différence entre une métrique brute d’origine et une métrique lissée, puis rechercher des anomalies dans le signal résiduel :

Exécuter la requête

let min_t = toscalar(demo_make_series1 | summarize min(TimeStamp));
let max_t = toscalar(demo_make_series1 | summarize max(TimeStamp));
demo_make_series1
| make-series num=count() default=0 on TimeStamp in from min_t to max_t step 1h by OsVer
| extend ma_num=series_fir(num, repeat(1, 5), true, true)
| extend residual_num=series_subtract(num, ma_num) //to calculate residual time series
| where OsVer == "Windows 10"   // filter on Win 10 to visualize a cleaner chart 
| render timechart

• Bleu : série chronologique d’origine
• Rouge : série chronologique lissée
• Vert : série chronologique résiduelle

Workflow de série chronologique à grande échelle

L’exemple ci-dessous montre comment ces fonctions peuvent être appliquées à grande échelle à des milliers de séries chronologiques en quelques secondes à des fins de détection d’anomalies. Pour voir quelques exemples d’enregistrements de télémétrie d’une métrique de nombre de lectures d’un service de base de données sur quatre jours, exécutez la requête suivante :

Exécuter la requête

demo_many_series1
| take 4 

timestamp	Loc	Op	DB	DataRead
2016-09-11 21:00:00.0000000	Loc 9	5117853934049630089	262	0
2016-09-11 21:00:00.0000000	Loc 9	5117853934049630089	241	0
2016-09-11 21:00:00.0000000	Loc 9	-865998331941149874	262	279862
2016-09-11 21:00:00.0000000	Loc 9	371921734563783410	255	0

Et statistiques simples :

Exécuter la requête

demo_many_series1
| summarize num=count(), min_t=min(TIMESTAMP), max_t=max(TIMESTAMP) 

num	min_t	max_t
2177472	2016-09-08 00:00:00.0000000	2016-09-11 23:00:00.0000000

La création d’une série chronologique en compartiments de 1 heure de la métrique de lecture (total de quatre jours * 24 heures = 96 points), entraîne une fluctuation du modèle normal :

Exécuter la requête

let min_t = toscalar(demo_many_series1 | summarize min(TIMESTAMP));  
let max_t = toscalar(demo_many_series1 | summarize max(TIMESTAMP));  
demo_many_series1
| make-series reads=avg(DataRead) on TIMESTAMP from min_t to max_t step 1h
| render timechart with(ymin=0) 

Le comportement décrit ci-dessus est trompeur, car la série chronologique normale unique est agrégée à partir de milliers d’instances différentes qui peuvent suivre des modèles anormaux. C’est pourquoi, nous créons une série chronologique par instance. Une instance est définie par Loc (emplacement), Op (opération) et DB (ordinateur spécifique).

Combien de séries chronologiques pouvons-nous créer ?

Exécuter la requête

demo_many_series1
| summarize by Loc, Op, DB
| count

Count
18339

Nous allons à présent créer un ensemble de 18339 séries chronologiques de la métrique du nombre de lectures. Nous ajoutons la clause by à l’instruction make-series, appliquons une régression linéaire, et sélectionnons les deux premières séries chronologiques en termes de tendance décroissante la plus significative :

Exécuter la requête

let min_t = toscalar(demo_many_series1 | summarize min(TIMESTAMP));  
let max_t = toscalar(demo_many_series1 | summarize max(TIMESTAMP));  
demo_many_series1
| make-series reads=avg(DataRead) on TIMESTAMP from min_t to max_t step 1h by Loc, Op, DB
| extend (rsquare, slope) = series_fit_line(reads)
| top 2 by slope asc 
| render timechart with(title='Service Traffic Outage for 2 instances (out of 18339)')

Afficher les instances :

Exécuter la requête

let min_t = toscalar(demo_many_series1 | summarize min(TIMESTAMP));  
let max_t = toscalar(demo_many_series1 | summarize max(TIMESTAMP));  
demo_many_series1
| make-series reads=avg(DataRead) on TIMESTAMP from min_t to max_t step 1h by Loc, Op, DB
| extend (rsquare, slope) = series_fit_line(reads)
| top 2 by slope asc
| project Loc, Op, DB, slope 

Loc	Op	DB	slope
Loc 15	37	1151	-102743.910227889
Loc 13	37	1249	-86303.2334644601

En moins de deux minutes, près de 20 000 séries chronologiques ont été analysées et deux séries chronologiques anormales dans lesquelles le nombre de lectures soudainement supprimé ont été détectées.

Ces fonctionnalités avancées combinées à des performances rapides fournissent une solution unique et puissante pour l’analyse de séries chronologiques.

Contenu connexe

• Découvrez la détection et la prévision des anomalies avec KQL.
• Découvrez les fonctionnalités de Machine Learning avec KQL.