Simple Log Service:Processeur de consommation

Fonctionnement

Un processeur de consommation utilise le langage SPL pour traiter les données SLS en temps réel. Il prend en charge les logiciels tiers, les applications multilingues, les produits cloud et les frameworks de calcul en flux continu. Le SPL est un langage haute performance conçu pour les journaux semi-structurés, permettant le filtrage des lignes, la sélection des colonnes et l'extraction par expressions régulières côté serveur. Après traitement, le client reçoit les données dans un format structuré. Pour plus d'informations sur la syntaxe SPL, consultez la rubrique Syntaxe SPL.

Avantages

• Réduction des coûts de transfert de données lors de la consommation via Internet.

  Par exemple, si vous écrivez des journaux dans SLS et les consommez via Internet, vous devrez peut-être les filtrer avant de les distribuer à vos systèmes internes. Avec la consommation basée sur le SPL, filtrez les journaux directement dans SLS pour empêcher de grands volumes de journaux non pertinents d'atteindre les consommateurs.

• Économie des ressources CPU locales et accélération du calcul.

  Par exemple, si vous écrivez des journaux dans SLS et les consommez sur une machine locale pour effectuer des calculs, la consommation basée sur le SPL déporte le traitement vers SLS, réduisant ainsi l'utilisation des ressources locales.

Règles de facturation

• Si votre Logstore utilise le mode de facturation « paiement selon les données écrites », l'utilisation d'un processeur de consommation n'entraîne aucun frais supplémentaire. Vous êtes facturé uniquement pour le transfert de données sortant lorsque vous extrayez des données depuis un endpoint public de Simple Log Service (SLS). Le coût est calculé sur la base du volume de données compressées. Pour plus d'informations, consultez la rubrique Éléments de facturation pour le mode paiement selon les données écrites.

• Si votre Logstore utilise le mode de facturation « paiement selon les fonctionnalités », l'utilisation d'un processeur de consommation entraîne des frais de calcul côté serveur. Des frais de transfert de données sortant peuvent également s'appliquer si vous utilisez un endpoint public. Pour plus d'informations, consultez la rubrique Éléments de facturation pour le mode paiement selon les fonctionnalités.

Cibles de consommation

Le tableau suivant répertorie les cibles de consommation prises en charge par les processeurs de consommation.

Remarques d'utilisation

• Les processeurs de consommation effectuent des calculs complexes sur le serveur. La latence côté serveur pour la lecture des données peut augmenter légèrement en fonction de la complexité du SPL et des caractéristiques des données. Par exemple, le traitement de 5 Mo de données peut ajouter entre 10 ms et 100 ms de latence. Toutefois, la latence globale de bout en bout, de l'extraction des données jusqu'à l'achèvement du calcul local, diminue généralement.

• Lorsque vous utilisez un processeur de consommation, des erreurs de syntaxe SPL ou l'absence de champs source dans les données peuvent entraîner une perte de données ou des échecs de consommation. Pour plus d'informations, consultez la rubrique Gestion des erreurs.

• La longueur maximale d'une instruction SPL dans la configuration d'un processeur de consommation est de 4 Ko.

• Les limites de lecture par shard pour les processeurs de consommation sont identiques à celles de la consommation en temps réel standard. Le trafic de lecture par shard pour un processeur de consommation est calculé sur la base du volume de données brutes avant le traitement SPL. Pour plus d'informations sur les limites, consultez la rubrique Lecture et écriture de données.

Limites

FAQ

• Comment gérer l'erreur ShardReadQuotaExceed lors de l'utilisation d'un processeur de consommation ?

  • Ce code d'erreur indique que le trafic de lecture par shard a dépassé le quota. Pour résoudre ce problème, appliquez l'une des solutions suivantes :

    • Si votre application cliente rencontre cette erreur, attendez un certain temps, puis réessayez l'opération.

    • Vous pouvez également diviser manuellement le shard. Cela réduit la vitesse de lecture pour chaque shard lorsque vous consommez de nouvelles données à partir des shards résultants.

• Quelle est la politique de modelage du trafic pour les processeurs de consommation ?

  • La politique de limitation du débit pour les processeurs de consommation est identique à celle de la consommation de données standard. Pour plus d'informations, consultez la rubrique Lecture et écriture de données. Le trafic d'un processeur de consommation est calculé sur la base du volume de données brutes avant le traitement SPL.

    • Par exemple, supposons que la taille des données brutes soit de 100 Mo (compressées). Après filtrage des données par l'instruction SPL * | where method = 'POST', les données renvoyées au client représentent 20 Mo (compressées). Le trafic pris en compte pour la limitation du débit est calculé sur la base de 100 Mo.

• Pourquoi le trafic sortant est-il faible dans le graphique « Trafic/min » de la rubrique Surveillance du projet après avoir utilisé une règle pour consommer des données ?

  • Le trafic sortant affiché dans le graphique Trafic/Minute de la surveillance du projet reflète le volume de données après traitement SPL, et non le volume de données brutes. Si votre instruction SPL inclut un filtrage des lignes ou une sélection des colonnes, le trafic sortant affiché peut être faible.