Simple Log Service:Référence générale

* | where "A B" like '%error%'

Gestion des conflits de noms de champs

Lors du chargement des journaux ou de l'exécution SPL, le traitement sensible à la casse peut provoquer des conflits de noms de champs. Par exemple, un journal brut peut contenir à la fois les champs Method et method. SPL résout ces conflits différemment selon le scénario.

Pour éviter ces situations, standardisez les noms de champs dans vos journaux bruts.

Conflits dans les résultats de sortie

Pour obtenir la liste complète des champs réservés, consultez Champs réservés. SPL lit les données depuis la structure LogGroup en tant qu'entrée. Pour plus d'informations sur la définition de LogGroup, consultez Encodage des données. Si les données brutes écrites dans Simple Log Service ne sont pas encodées au format LogGroup standard, certains champs réservés peuvent apparaître dans LogContent au lieu de leur emplacement standard. SPL gère ces champs réservés comme suit :

• Pour les champs __source__, __topic__, __time__ et __time_ns_part__, SPL lit leurs valeurs à partir de la structure LogGroup standard et ignore tous les champs portant les mêmes noms dans LogContent.

• Pour les champs de tag avec le préfixe __tag__: , SPL tente d'abord de lire leurs valeurs à partir de la structure LogGroup standard. Si aucune valeur n'est trouvée, SPL la lit depuis LogContent. Par exemple, pour le champ __tag__:ip, SPL tente d'abord de lire le champ avec la clé ip depuis la liste LogTag. Si le champ n'existe pas, SPL lit ensuite le champ de journal avec la clé __tag__:ip depuis les champs de journal personnalisés dans LogContent.

Le champ __line__ pour la recherche en texte intégral

Pour filtrer les journaux bruts dans la console ou en utilisant l'opération d'API GetLogstoreLogs, utilisez le champ __line__.

Exemple

• Recherchez le mot-clé error dans les journaux.

  * | where __line__ like '%error%'

• Si un journal contient un champ nommé __line__, entourez le nom du champ de backticks pour y faire référence.

  * | where `__line__` ='20'

Types de données incohérents entre les anciennes et nouvelles valeurs

La valeur d'origine du champ d'entrée est conservée.

Exemple

• Exemple 1 : Un champ renommé à partir d'une instruction project présente un nom conflictuel.

  • Instruction SPL

    * 
    | extend status=cast(status as BIGINT) -- Convert the type of the status field to BIGINT.
    | project code=status -- The new value's type (BIGINT) differs from the old value's type (VARCHAR), so the old value is kept.

  • Données d'entrée

    status: '200'
    code: 'Success'

  • Résultat de sortie

    code: 'Success'

• Exemple 2 : Un champ extrait à partir d'une instruction parse-json présente un nom conflictuel.

  • Instruction SPL

    * 
    | extend status=cast(status as BIGINT) -- Convert the type of the status field to BIGINT.
    | parse-json content -- The old type of status is BIGINT and the new type is VARCHAR. The old value is retained.

  • Données d'entrée

    status: '200'
    content: '{"status": "Success", "body": "this is test"}'

  • Résultat de sortie

    content: '{"status": "Success", "body": "this is test"}'
    status: 200
    body: 'this is test'

Types de données cohérents entre les anciennes et nouvelles valeurs

Si la valeur d'entrée est nulle, la nouvelle valeur est utilisée. Sinon, le comportement est déterminé par le paramètre mode dans l'instruction, tel que défini dans le tableau suivant.

Exemple

• Exemple 1 : Un champ renommé à partir d'une instruction project présente un nom conflictuel et le même type. Le mode par défaut est overwrite.

  • Instruction SPL

  * | project code=status -- The old and new types of code are both VARCHAR. The new value is used based on the overwrite mode.

  • Données d'entrée

    status: '200'
    code: 'Success'

  • Résultat de sortie

    code: '200'

• Exemple 2 : Un champ extrait à partir d'une instruction parse-json présente un nom conflictuel et le même type. Le mode par défaut est overwrite.

  • Instruction SPL

    * | parse-json content -- The old and new types of status are both VARCHAR. The new value is used based on the overwrite mode.

  • Données d'entrée

    status: '200'
    content: '{"status": "Success", "body": "this is test"}'

  • Résultat de sortie

    content: '{"status": "Success", "body": "this is test"}'
    status: 'Success'
    body: 'this is test'

• Exemple 3 : Un champ extrait à partir d'une instruction parse-json présente un nom conflictuel et le même type. Le mode est défini sur preserve.

  • Instruction SPL

    * | parse-json -mode='preserve' content -- The old and new types of status are both VARCHAR. The old value is retained based on the preserve mode.

  • Données d'entrée

    status: '200'
    content: '{"status": "Success", "body": "this is test"}'

  • Résultat de sortie

    content: '{"status": "Success", "body": "this is test"}'
    status: '200'
    body: 'this is test'

Conversion de type de données

Type initial

Lorsque SPL traite les données, tous les champs d'entrée sont initialement de type VARCHAR, à l'exception des champs de temps des journaux. Si le traitement ultérieur nécessite un type de données différent, vous devez effectuer une conversion de type explicite.

Exemple

Pour filtrer les journaux d'accès avec un code d'état 5xx, convertissez le champ status en type BIGINT avant la comparaison.

* -- The initial type of the status field is VARCHAR.
| where cast(status as BIGINT) >= 500 -- Convert the type of the status field to BIGINT, and then perform the comparison.

Conservation du type

Après avoir utilisé l'instruction extend pour convertir le type de données d'un champ, le traitement ultérieur conserve le type converti.

Exemple

* -- A Logstore is used as input data. Except for time fields, all fields are initially of the VARCHAR type.
| where __source__='127.0.0.1' -- Filter on the __source__ field.
| extend status=cast(status as BIGINT) -- Convert the type of the status field to BIGINT.
| project status, content
| where status>=500 -- The type of the status field remains BIGINT, so it can be directly compared with the number 500.

Génération de valeurs nulles

Lors du traitement des données SPL, des valeurs nulles sont générées dans les scénarios suivants :

1. Si un champ utilisé dans une expression SPL n'existe pas dans les données d'entrée, sa valeur est traitée comme nulle lors des calculs.

2. Si une exception se produit lors du calcul d'une expression SPL, le résultat est nul. Par exemple, une conversion de type cast échoue ou un index de tableau est hors limites.

Exemple

1. Si un champ n'existe pas, sa valeur est traitée comme nulle dans les calculs.

   • Instruction SPL

     * | extend withoutStatus=(status is null)

   • Données d'entrée

     # Entry 1
     status: '200'
     code: 'Success'
     
     # Entry 2
     code: 'Success'

   • Résultat de sortie

     # Entry 1
     status: '200'
     code: 'Success'
     withoutStatus: false
     
     # Entry 2
     code: 'Success'
     withoutStatus: true

2. Si une exception se produit lors du calcul, le résultat est nul.

   • Instruction SPL

     *
     | extend code=cast(code as BIGINT) -- Failed to convert the code field to BIGINT.
     | extend values=json_parse(values)
     | extend values=cast(values as ARRAY(BIGINT))
     | extend last=arr[10] -- Array index out of bounds.

   • Données d'entrée

     status: '200'
     code: 'Success'
     values: '[1,2,3]'

   • Résultat de sortie

     status: '200'
     code: null
     values: [1, 2, 3]
     last: null

Élimination des valeurs nulles

Pour éliminer les valeurs nulles lors des calculs, utilisez l'expression COALESCE. Elle renvoie la première valeur non nulle d'une liste d'expressions. Vous pouvez également spécifier une valeur par défaut à utiliser si toutes les expressions sont évaluées à nul.

Exemple

Lisez le dernier élément d'un tableau. Si le tableau est vide, la valeur par défaut est 0.

• Instruction SPL

  *
  | extend values=json_parse(values)
  | extend values=cast(values as ARRAY(BIGINT))
  | extend last=COALESCE(values[3], values[2], values[1], 0)

• Données d'entrée

  # Entry 1
  values: '[1, 2, 3]'
  
  # Entry 2
  values: '[]'

• Résultat de sortie

  # Entry 1
  values: [1, 2, 3]
  last: 3
  
  # Entry 2
  values: []
  last: 0

Guillemets simples

Les guillemets simples sont utilisés pour entourer un littéral de chaîne. Si le littéral de chaîne contient un guillemet simple, vous devez utiliser un guillemet simple supplémentaire pour l'échapper.

Guillemets doubles

Les guillemets doubles sont utilisés pour entourer un nom de champ. Si le nom de champ contient un guillemet double, vous devez utiliser un guillemet double supplémentaire pour l'échapper.