Simple Log Service prend en charge l'analyse SQL des résultats de recherche.
Syntaxe de base
SLS Query Skill : interroger et analyser intelligemment les journaux : SLS propose une compétence Agent qui permet d'interroger et d'analyser les données de journal en langage naturel via un agent IA local.
Une requête se compose d'une instruction de recherche et d'une instruction d'analyse, séparées par une barre verticale (|). Le format est le suivant :
Search statement|Analytic statement
L'instruction de recherche s'exécute de manière indépendante. L'instruction d'analyse doit obligatoirement suivre une instruction de recherche. L'analyse des journaux traite les résultats de la recherche ou l'intégralité des données d'un Logstore.
Spécifiez au maximum 30 conditions de recherche par instruction de recherche.
En l'absence de clause FROM ou WHERE, une instruction d'analyse traite par défaut toutes les données du Logstore actuel. Les instructions d'analyse ne sont pas sensibles à la casse, ne prennent pas en charge la syntaxe offset et ne nécessitent pas de point-virgule (;) final.
|
Instruction |
Description |
|
Instruction de recherche |
Une instruction de recherche spécifie une ou plusieurs conditions : un mot-clé, une valeur numérique, une plage numérique, un espace ou un astérisque (*). Un espace ou un astérisque (*) correspond à tous les journaux sans appliquer de condition. |
|
Instruction d'analyse |
Une instruction d'analyse agrège ou analyse les résultats de recherche ou l'intégralité des données d'un Logstore. SLS prend en charge les fonctions et la syntaxe suivantes : |
Exemple :
* | SELECT status, count(*) AS PV GROUP BY status
Fonctions SQL et clauses SQL
Les fonctions SQL permettent de calculer, convertir et formater les données, par exemple en calculant des sommes, en manipulant des chaînes de caractères ou en traitant des dates. Les fonctions SQL sont généralement intégrées aux clauses SQL.
Les clauses SQL servent à construire des instructions complètes de requête et de traitement, en spécifiant les sources de données, les conditions, le regroupement et l'ordre de tri.
Exemple 1. Interroger les journaux de la veille
Utilise current_date pour obtenir la date du jour et date_add pour soustraire un intervalle. Les résultats s'affichent sous forme de tableau. (Démo)
-
Instruction de requête
* | SELECT * FROM log WHERE __time__ < to_unixtime(current_date) AND __time__ > to_unixtime(date_add('day', -1, current_date)) Résultats

Exemple 2. Interroger la distribution des adresses IP source des journaux
Utilise la fonction ip_to_province pour résoudre les provinces à partir des adresses IP, regroupe les données par adresse avec group by et compte les occurrences avec la fonction count. Les résultats s'affichent sous forme de diagramme circulaire. (Essayer la démo)
-
Instruction de requête
* | select count(1) as c, ip_to_province(remote_addr) as address group by address limit 100
Exemple 3. Interroger le trafic entrant et sortant NGINX
Utilise date_trunc pour aligner __time__ à l'heure près. __time__ est un champ système correspondant à l'heure d'ingestion du journal (horodatage Unix). La requête utilise date_format pour formater les horodatages, group by pour regrouper par heure et sum pour totaliser le trafic horaire. Les résultats s'affichent sous forme de graphique linéaire avec time sur l'axe X et net_out/net_in sur l'axe Y gauche. (Essayer la démo)
-
Instruction de requête
* | select sum(body_bytes_sent) as net_out, sum(request_length) as net_in, date_format(date_trunc('hour', __time__), '%m-%d %H:%i') as time group by date_format(date_trunc('hour', __time__), '%m-%d %H:%i') order by time limit 10000 -
Résultats

Exemple 4. Interroger les 10 URL les plus consultées dans NGINX
Utilise la fonction split_part pour diviser request_uri selon le caractère ?. Le premier élément du array correspond au chemin de la requête. Regroupe les données par chemin avec GROUP BY, compte les visites avec la fonction count et trie les résultats avec ORDER BY DESC. Les résultats s'affichent sous forme de diagramme en colonnes. (Essayer la démo)
-
Instruction de requête
* | select count(1) as pv, split_part(request_uri, '?', 1) as path group by path order by pv desc limit 10 -
Résultats

Exemple 5. Interroger les catégories de méthodes de requête et les tendances PV
Utilise date_trunc pour aligner les horodatages à la minute près, regroupe les données par heure et par request_method afin de calculer le nombre de pages vues (PV), puis trie les résultats par heure. Les résultats s'affichent sous forme de graphique en aires empilées avec l'heure sur l'axe X, le nombre de PV sur l'axe Y et request_method comme série. (Essayer la démo)
-
Instruction de requête
* | select date_format(date_trunc('minute', __time__), '%m-%d %H:%i') as t, request_method, count(*) as pv group by t, request_method order by t asc limit 10000 -
Résultats

Exemple 6. Comparer les PV d'aujourd'hui et d'hier
Utilise la fonction count pour les PV du jour et la fonction compare pour effectuer une comparaison jour par jour. (Démo)
-
Instruction de requête
* | select diff [1] as today, round((diff [3] -1.0) * 100, 2) as growth FROM ( SELECT compare(pv, 86400) as diff FROM ( SELECT COUNT(1) as pv FROM log ) ) Résultats

Exemple 7. Prévoir le nombre de PV à partir des journaux d'accès NGINX
L'expression time - time % 60 aligne les horodatages à la minute près sous la forme stamp. La requête regroupe les données par stamp avec group by et compte les événements par minute à l'aide de la fonction count. Cette sous-requête alimente la fonction ts_predicate_simple pour prévoir six points de données. Les résultats s'affichent sous forme de graphique de séries chronologiques. (Essayer la démo)
-
Instruction de requête
* | select ts_predicate_simple(stamp, value, 6) from ( select __time__ - __time__ % 60 as stamp, COUNT(1) as value from log GROUP BY stamp order by stamp ) LIMIT 1000 -
Résultats

Exemple 8. Agréger et classer les requêtes par agent utilisateur
Regroupe les données par http_user_agent pour compter les requêtes et sommer le trafic de réponse. Utilise la fonction round pour convertir les valeurs en byte en MB. Une expression case when classe les codes de status en 2xx, 3xx, 4xx et 5xx et calcule le pourcentage de chaque catégorie. Les résultats s'affichent sous forme de tableau. (Essayer la démo)
-
Instruction de requête
* | select http_user_agent as "User agent", count(*) as pv, round(sum(request_length) / 1024.0 / 1024, 2) as "Request traffic (MB)", round(sum(body_bytes_sent) / 1024.0 / 1024, 2) as "Response traffic (MB)", round( sum( case when status >= 200 and status < 300 then 1 else 0 end ) * 100.0 / count(1), 6 ) as "Percentage of status code 2xx (%)", round( sum( case when status >= 300 and status < 400 then 1 else 0 end ) * 100.0 / count(1), 6 ) as "Percentage of status code 3xx (%)", round( sum( case when status >= 400 and status < 500 then 1 else 0 end ) * 100.0 / count(1), 6 ) as "Percentage of status code 4xx (%)", round( sum( case when status >= 500 and status < 600 then 1 else 0 end ) * 100.0 / count(1), 6 ) as "Percentage of status code 5xx (%)" group by "User agent" order by pv desc limit 100
Exemple 9. Calculer le ratio de requêtes en erreur dans les journaux NGINX
Compte les requêtes dont les codes de statut sont supérieurs ou égaux à 400, puis divise ce nombre par le total des requêtes pour obtenir le ratio d'erreur. Les résultats s'affichent sous forme de graphique statistique. (Démo)
-
Instruction de requête
* | select round((errorCount * 100.0 / totalCount), 2) as errorRatio from ( select sum( case when status >= 400 then 1 else 0 end ) as errorCount, count(1) as totalCount from log ) Résultats
