:Vue d'ensemble

Introduction

Log Service stocke les données au format JSON et utilise les groupes de journaux comme unité de base pour les opérations de lecture et d'écriture. Pour plus d'informations sur les groupes de journaux, consultez la rubrique Termes. Par conséquent, il est impossible d'interroger et d'analyser les journaux dans Log Service selon des conditions spécifiques. Par exemple, vous ne pouvez pas interroger ni analyser les données de journal d'une application sur les 12 dernières heures.

LogHub Shipper convertit les données de journal de Log Service en données structurées, puis les écrit en temps réel dans des tables de données Tablestore. Cette approche fournit des services en ligne précis et performants en temps réel.

Exemples de données

Par exemple, Log Service contient des données de journal au format suivant :

{"__time__":1453809242,"__topic__":"","__source__":"47.100.XX.XX","ip":"47.100.XX.XX","time":"26/Jan/2016:19:54:02 +0800","url":"POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0U***45A&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1.1","status":"200","user-agent":"aliyun-sdk-java"}

LogHub Shipper écrit les données dans une table de données Tablestore dont les colonnes de clé primaire sont ip et time, selon le format suivant.

Ainsi, vous pouvez récupérer efficacement et avec précision les données historiques associées à une adresse IP spécifique à un instant donné dans la table de données Tablestore.

LogHub Shipper propose des règles de mappage de données flexibles. Vous pouvez configurer les correspondances entre les champs des données de journal et les colonnes d'attribut des tables de données, et convertir les données de manière efficace.

Termes

Termes des services connexes

Avant d'utiliser LogHub Shipper, vous devez comprendre les termes liés aux services connexes. Le tableau suivant décrit ces termes.

Tables de données

Les tables de données stockent les données de journal nettoyées et converties.

Lors de l'utilisation des tables de données, tenez compte des points suivants :

• Vous devez créer manuellement une table de données pour stocker les données de journal nettoyées et converties. LogHub Shipper ne crée pas automatiquement les tables de données.

• Si Log Service et Tablestore sont disponibles, la latence entre le moment où un journal entre dans Log Service et le moment où il est écrit dans Tablestore est de quelques centaines de millisecondes.

• Si Tablestore n'est pas disponible, LogHub Shipper attend jusqu'à 500 millisecondes avant de réessayer.

• LogHub Shipper enregistre régulièrement des points de contrôle persistants.

• Si LogHub Shipper devient indisponible en raison d'un problème tel qu'une mise à niveau, il reprend la consommation des journaux à partir du dernier point de contrôle après récupération.

• Nous vous recommandons de veiller à ce que différents journaux d'un même Logstore soient écrits dans différentes lignes de la table de données. Cela garantit la cohérence à terme entre la table de données et le Logstore, même lorsque LogHub Shipper retente la consommation des données.

• LogHub Shipper écrit les données dans les tables de données à l'aide de l'opération UpdateRow de Tablestore. Par conséquent, plusieurs instances de LogHub Shipper peuvent écrire des données dans la même table de données. Dans ce cas, nous vous recommandons de veiller à ce que les instances de LogHub Shipper écrivent les données dans différentes colonnes d'attribut.

Tables d'état

LogHub Shipper utilise la table d'état que vous créez dans Tablestore pour vous fournir des informations connexes.

Lors de l'utilisation de la table d'état, tenez compte des points suivants :

• Plusieurs instances de LogHub Shipper peuvent partager la même table d'état.

• En l'absence d'erreur, chaque container LogHub Shipper ajoute un enregistrement à la table d'état toutes les 5 minutes.

• Lorsqu'une erreur se produit mais que Tablestore reste disponible, le container LogHub Shipper ajoute immédiatement un enregistrement à la table d'état.

• Nous vous recommandons de définir une durée de vie (TTL) au niveau journalier pour la table d'état. Ainsi, la table d'état ne conserve que les données récentes.

La table d'état contient les quatre colonnes de clé primaire suivantes :

• project_logstore : type String. Le projet et le Logstore de Log Service, séparés par des barres verticales (|).

• shard : type Integer. Le numéro du shard dans Log Service.

• target_table : type String. Le nom de la table de données qui stocke les données de journal nettoyées et converties.

• timestamp : type Integer. L'heure à laquelle un container LogHub Shipper ajoute un enregistrement à la table d'état. La valeur est un horodatage UNIX. Unité : millisecondes.

Les colonnes d'attribut suivantes enregistrent l'état de l'importation des données. Toutes les colonnes d'attribut d'une ligne de la table d'état sont facultatives et peuvent être absentes.

• shipper_id : type String. L'ID d'un container LogHub Shipper. Il s'agit du nom de l'hôte du container.

• error_code : type String. Le code d'erreur défini dans Tablestore. Si aucune erreur ne se produit, cette colonne d'attribut n'existe pas. Pour plus d'informations, consultez la rubrique Codes d'erreur.

• error_message : type String. Le message d'erreur spécifique renvoyé par Tablestore. Si aucune erreur ne se produit, cette colonne d'attribut n'existe pas.

• failed_sample : type String. Le journal pour lequel une erreur est signalée. La valeur est une chaîne JSON.

• __time__ : type Integer. La valeur maximale du champ __time__ des données de journal que le container LogHub Shipper écrit dans Tablestore après la dernière mise à jour de la table d'état par le container. Pour plus d'informations, consultez la rubrique Termes.

• row_count : type Integer. Le nombre de journaux que le container LogHub Shipper écrit dans Tablestore après la dernière mise à jour de la table d'état par le container.

• cu_count : type Integer. Le nombre d'unités de capacité (CU) consommées par le container LogHub Shipper après la dernière mise à jour de la table d'état par le container. Pour plus d'informations, consultez la rubrique Débit de lecture/écriture.

• skip_count : type Integer. Le nombre de journaux nettoyés par le container LogHub Shipper après la dernière mise à jour de la table d'état par le container.

• skip_sample : type String. L'un des journaux ignorés par le container LogHub Shipper après la dernière mise à jour de la table d'état par le container. La valeur est une chaîne JSON. Le journal du container enregistre chaque journal ignoré ainsi que la raison de cet abandon.

Configurations

Lors de la création de LogHub Shipper, vous devez spécifier les variables d'environnement suivantes pour le container :

• access_key_id et access_key_secret : l'AccessKey ID et l'AccessKey secret du compte Alibaba Cloud utilisé par LogHub Shipper.

• loghub : les configurations de Log Service requises par LogHub Shipper. La valeur est un objet JSON composé des paramètres suivants :

  • endpoint

  • logstore

  • consumer_group

• tablestore : les configurations de Tablestore requises par LogHub Shipper. La valeur est un objet JSON composé des paramètres suivants :

  • endpoint : l'endpoint de la région où se trouve l'instance Tablestore.

  • instance : le nom de l'instance Tablestore.

  • target_table : le nom de la table de données. La table de données doit se trouver dans l'instance spécifiée.

  • status_table : le nom de la table d'état. La table d'état doit se trouver dans l'instance spécifiée.

• exclusive_columns : la liste de blocage des colonnes d'attribut. La valeur est un tableau JSON composé de chaînes JSON.

  Si vous spécifiez cette variable d'environnement, LogHub Shipper n'écrit pas les champs spécifiés dans la table de données en tant que colonnes d'attribut. Par exemple, si la table de données contient la clé primaire A, que la variable d'environnement exclusive_columns est définie sur ["B", "C"] et qu'un journal contient trois champs : A, B et D, alors une seule ligne est écrite dans la table de données. Cette ligne contient la clé primaire A et la colonne d'attribut D. Le champ C n'existe pas dans le journal. Par conséquent, LogHub Shipper n'écrit pas la colonne C dans la table de données. Le champ B existe dans le journal, mais la colonne B est spécifiée comme colonne exclusive. Par conséquent, LogHub Shipper n'écrit pas la colonne B dans la table de données.

• transform : une conversion simple. La valeur est un objet JSON. La clé de la variable correspond au nom de la colonne dans la table de données. La colonne peut être une colonne de clé primaire. La valeur est l'expression de conversion simple que LogHub Shipper définit selon les règles suivantes :

  • Un champ de journal est une expression.

  • Un entier non signé est une expression.

  • Une chaîne entre guillemets doubles est une expression. Les chaînes peuvent contenir les caractères d'échappement \" et \\\\.

  • ( func arg... ) est également une expression. Zéro ou plusieurs espaces ou tabulations peuvent exister avant et après les parenthèses. Au moins un espace existe entre func et le paramètre qui suit func, ainsi qu'entre les différents paramètres. Chaque paramètre doit être une expression. Le système prend en charge les fonctions suivantes :

    • ->int : convertit une chaîne en entier. Cette fonction nécessite deux paramètres. Le premier paramètre est la base, qui peut aller de 2 à 36. Le second paramètre est la chaîne que LogHub Shipper doit convertir. La lettre dans le second paramètre n'est pas sensible à la casse et représente un nombre supérieur à un chiffre décimal, allant de 10 à 35.

    • ->bool : convertit une chaîne en valeur booléenne. Cette fonction nécessite un paramètre dont la valeur est la chaîne que LogHub Shipper doit convertir. "true" correspond à la valeur true et "false" correspond à la valeur false. Les autres chaînes sont considérées comme invalides.

    • crc32 : calcule le CRC32 d'une chaîne et renvoie le résultat sous forme de valeur Integer. Cette fonction nécessite un paramètre dont la valeur est la chaîne pour laquelle LogHub Shipper doit effectuer le calcul.

Si un journal est manquant ou si une erreur se produit lors de la conversion, la colonne correspondant à la clé est considérée comme manquante. En cas d'erreur, le journal du container enregistre les détails de l'erreur.

Le nettoyage des données suit une seule règle : si une colonne de clé primaire est manquante, LogHub Shipper nettoie le journal correspondant.