Apprendre Apache Flume par la pratique [Eng]
Apprendre Apache Flume par la pratique
...
La sémantique dans Flume fournit une fiabilité de bout en bout du flux.
Flume utilise une approche transactionnelle pour garantir la fiabilité des événements. Les sources et les puits encapsulent dans une transaction le stockage / récupération, respectivement, des événements placés dans ou fournis par une transaction fournie par le canal. Cela garantit que l'ensemble des événements est passé de manière fiable d'un point à un autre dans le flux. Dans le cas d'un flux à sauts multiples, les transactions du collecteur du saut précédent et de la source du saut suivant ont toutes deux pour but de garantir que les données sont stockées en toute sécurité dans le canal du saut suivant.
Récupérabilité
Les événements sont organisés dans le canal, qui gère la reprise après incident. Flume prend en charge un canal de fichier durable qui est soutenu par le système de fichiers local. Il existe également un canal mémoire qui stocke simplement les événements dans une file d'attente en mémoire, ce qui est plus rapide, mais aucun événement restant dans le canal mémoire à la fin du processus d'un agent ne peut pas être récupéré.
Installer
Mise en place d'un agent
La configuration de l'agent Flume est stockée dans un fichier de configuration local. Ceci est un fichier texte qui suit le format de fichier de propriétés Java. Les configurations pour un ou plusieurs agents peuvent être spécifiées dans le même fichier de configuration. Le fichier de configuration comprend les propriétés de chaque source, puits et canal dans un agent, ainsi que la manière dont ils sont reliés pour former des flux de données.
Configuration de composants individuels
Chaque composant (source, récepteur ou canal) du flux a un nom, un type et un ensemble de propriétés spécifiques au type et à l'instanciation. Par exemple, une source Avro a besoin d'un nom d'hôte (ou adresse IP) et d'un numéro de port pour recevoir des données. Un canal mémoire peut avoir une taille de file d'attente maximale («capacité») et un récepteur HDFS doit connaître l'URI du système de fichiers, le chemin pour créer les fichiers, la fréquence de rotation du fichier («hdfs.rollInterval»), etc. Tous ces attributs d'un composant doit être défini dans le fichier de propriétés de l’agent d’hébergement Flume.
Câbler les morceaux ensemble
L'agent doit savoir quels composants individuels doivent être chargés et comment ils sont connectés afin de constituer le flux. Pour ce faire, vous devez répertorier les noms de chacune des sources, des puits et des canaux de l'agent, puis spécifier le canal de connexion de chaque puits et de chaque source. Par exemple, un agent transmet les événements d'une source Avro appelée avroWeb à HDFS, puis coule hdfs-cluster1 via un canal de fichier appelé fichier-canal. Le fichier de configuration contiendra les noms de ces composants et canal de fichier en tant que canal partagé pour avroWeb source et hdfs-cluster1.
Démarrage d'un agent
Un agent est démarré à l'aide d'un script shell appelé flume-ng, situé dans le répertoire bin de la distribution Flume. Vous devez spécifier le nom de l'agent, le répertoire config et le fichier config sur la ligne de commande:
$ bin / flume-ng agent -n $ nom_agent -c conf -f conf / flume-conf.properties.template
Maintenant, l'agent va commencer à exécuter la source et les puits configurés dans le fichier de propriétés donné.
Un exemple simple
Nous donnons ici un exemple de fichier de configuration décrivant un déploiement de Flume à un seul nœud. Cette configuration permet à un utilisateur de générer des événements et les enregistre ensuite dans la console.
#: Une configuration de canal unique à noeud
# Nommez les composants sur cet agent a1.sources = r1 a1.sinks = k1 a1.channels = c1
# Décrire / configurer la source = netcat = localhost = 44444
# Décrivez l'évier = enregistreur
# Utilisez un canal qui met en mémoire tampon les événements en mémoire = mémoire a1.channels.c1.capacity = 1000 a1.channels.c1.transactionCapacity = 100
# Lie la source et le puits au canal a1.sources.r1.channels = c1 a1.sinks.k1.channel = c1
Cette configuration définit un seul agent nommé a1. a1 a une source qui écoute les données sur le port 44444, un canal qui stocke en mémoire les données d’événement et un collecteur qui enregistre les données d’événement sur la console. Le fichier de configuration nomme les différents composants, puis décrit leurs types et paramètres de configuration. Un fichier de configuration donné peut définir plusieurs agents nommés. quand un processus Flume donné est lancé, un drapeau lui est transmis lui indiquant quel agent nommé doit être manifesté.
Avec ce fichier de configuration, nous pouvons démarrer Flume comme suit:
$ bin / flume-ng agent --conf conf --conf-file --name a1 .logger = INFO, console
Notez que dans un déploiement complet, nous inclurons généralement une option supplémentaire: --conf =. Le répertoire comprendrait un script shell et potentiellement un fichier de propriétés log4j. Dans cet exemple, nous passons une option Java pour forcer Flume à se connecter à la console et nous allons sans script d’environnement personnalisé.
À partir d'un terminal séparé, nous pouvons ensuite utiliser le port telnet 44444 et envoyer un événement à Flume:
$ telnet localhost 44444
Essayer 127.0.0.1
Connecté à localhost.localdomain (127.0.0.1).
Le caractère d'échappement est '^]'.
Bonjour le monde! D'accord
Le terminal Flume d'origine émettra l'événement dans un message de journal.
12/06/19 15:32:19 INFO source.NetcatSource: Source à partir
12/06/19 15:32:19 INFO source.NetcatSource: Création du .ServerSocketChannelImpl [/127.0.0.1:44444]
12/06/19 15:32:34 INFO sink.LoggerSink: Evénement: {en-têtes: {} corps: 48 65 6C 6C 6F 20 77 6F 72 6C 64 21 0D Bonjour tout le monde !. }
Félicitations - vous avez correctement configuré et déployé un agent Flume! Les sections suivantes traitent de la configuration de l'agent de manière beaucoup plus détaillée.
Utilisation de variables d'environnement dans les fichiers de configuration
Flume a la capacité de substituer des variables d'environnement dans la configuration. Par exemple:
a1.sources = r1 = netcat = 0.0.0.0 = $ {NC_PORT} a1.sources.r1.channels = c1
NB: cela ne fonctionne actuellement que pour les valeurs, pas pour les clés. (Par exemple, uniquement sur le «côté droit» de la marque = des lignes de configuration.)
Cela peut être activé via les propriétés du système Java lors de l'appel de l'agent en définissant propertiesImplementation = .EnvVarResolverProperties.
Par exemple::
$ NC_PORT = 44444 agent / flume-ng –conf conf –conf-fichier –nom a1 .logger = INFO, console -
.EnvVarResolverProperties
Notez que ce qui précède n’est qu’un exemple. Les variables d’environnement peuvent être configurées de différentes manières, notamment en étant définies.
Enregistrement de données brutes
La consignation du flux brut de données transitant par le pipeline d'ingestion n'est pas un comportement souhaité dans de nombreux environnements de production, car cela pourrait entraîner une fuite des données sensibles ou des configurations liées à la sécurité, telles que des clés secrètes, dans les fichiers journaux Flume. Par défaut, Flume n'enregistrera pas ces informations. D'autre part, si le pipeline de données est rompu, Flume tentera de fournir des indices pour le débogage du problème.
Un moyen de résoudre les problèmes liés aux pipelines d’événements consiste à configurer un canal mémoire supplémentaire connecté à un collecteur de journalisation, qui produira toutes les données d’événement dans les journaux Flume. Dans certaines situations, toutefois, cette approche est insuffisante.
Afin de permettre la journalisation des données relatives aux événements et à la configuration, certaines propriétés système Java doivent être définies en plus des propriétés log4j.
Pour activer la journalisation liée à la configuration, définissez la propriété du système Java .printconfig = true. Cela peut être passé sur la ligne de commande ou en le définissant dans la variable JAVA_OPTS dans.
Pour activer la journalisation des données, définissez la propriété du système Java .rawdata = true de la manière décrite ci-dessus. Pour la plupart des composants, le niveau de journalisation log4j doit également être défini sur DEBUG ou TRACE pour que la journalisation spécifique à un événement apparaisse dans les journaux de canal.
Voici un exemple d'activation de la consignation de la configuration et de la consignation des données brutes tout en définissant le niveau de journalisation Log4j sur DEBUG pour la sortie de la console:
$ bin / flume-ng agent --conf conf --conf-fichier --nom a1 .logger = DEBUG, console .printco
Configuration basée sur Zookeeper
Flume prend en charge les configurations d'agent via Zookeeper. Ceci est une fonctionnalité expérimentale. Le fichier de configuration doit être chargé dans le Zookeeper, sous un préfixe configurable. Le fichier de configuration est stocké dans les données du nœud Zookeeper. Voici l’arborescence des nœuds Zookeeper pour les agents a1 et a2.
- / canal
| - / a1 [Fichier de configuration de l'agent]
| - / a2 [Fichier de configuration de l'agent]
Une fois le fichier de configuration téléchargé, démarrez l'agent avec les options suivantes
$ bin / flume-ng agent –conf conf -z zkhost: 2181, zkhost1: 2181 -p / flume –nom a1 .logger = INFO, console
Nom de l'argument
Défaut
La description
Chaîne de connexion Zookeeper. Liste de noms d'hôtes séparée par des virgules: port
/buse
Chemin de base dans Zookeeper pour stocker les configurations de l'agent
Installer des plugins tiers
Flume a une architecture entièrement basée sur des plugins. Bien que Flume soit livré avec de nombreuses sources, canaux, puits, sérialiseurs, etc. similaires, il existe de nombreuses implémentations livrées séparément de Flume.
Bien qu'il ait toujours été possible d'inclure des composants Flume personnalisés en ajoutant leurs fichiers JAR à la variable FLUME_CLASSPATH dans le fichier, Flume prend désormais en charge un répertoire spécial appelé plugins.d, qui sélectionne automatiquement les plugins emballés dans un format spécifique. Cela facilite la gestion des problèmes d'emballage des plug-ins, ainsi que le débogage et le dépannage de plusieurs classes de problèmes, en particulier les conflits de dépendances de bibliothèques.
Le répertoire plugins.d
Le répertoire plugins.d se trouve à l'emplacement $ FLUME_HOME / plugins.d. Au démarrage, le script de démarrage flume-ng recherche dans le répertoire plugins.d les plug-ins conformes au format ci-dessous et les inclut dans les chemins appropriés lors du démarrage de java.
Structure de répertoire pour les plugins
Chaque plugin (sous-répertoire) dans plugins.d peut avoir jusqu'à trois sous-répertoires:
- lib - le (s) fichier (s) du plugin
- libext - le (s) fichier (s) de dépendance du plugin
- native - toutes les bibliothèques natives requises, telles que les fichiers .so
Exemple de deux plugins dans le répertoire plugins.d:
plugins.d /
plugins.d / custom-source-1 /
plugins.d / custom-source-2 /
Ingestion de données
Flume prend en charge un certain nombre de mécanismes pour ingérer des données à partir de sources externes.
RPC
Un client Avro inclus dans la distribution Flume peut envoyer un fichier donné à la source Avro de Flume en utilisant le mécanisme RPC d'avro:
$ bin / flume-ng avro-client -H localhost -p 41414 -F /usr/logs/log.10
La commande ci-dessus enverra le contenu de /usr/logs/log.10 à la source Flume qui écoute sur ces ports.
Exécuter des commandes
Il existe une source exec qui exécute une commande donnée et utilise la sortie. Une seule «ligne» de sortie, à savoir. suivi du retour chariot ("\ r") ou du saut de ligne ("\ n") ou des deux à la fois.
Flux de réseau
Flume prend en charge les mécanismes suivants pour lire des données à partir de types de flux de journaux courants, tels que:
- Avro
- l'épargne
- Syslog
- Netcat
Réglage du flux multi-agents
Pour que les données circulent entre plusieurs agents ou sauts, le récepteur de l'agent précédent et la source du saut actuel doivent être de type avro, le récepteur pointant vers le nom d'hôte (ou l'adresse IP) et le port de la source.
Consolidation
Un scénario très courant dans la collecte de journaux est un grand nombre de clients producteurs de journaux qui envoient des données à quelques agents consommateurs connectés au sous-système de stockage. Par exemple, les journaux collectés à partir de centaines de serveurs Web envoyés à une douzaine d'agents écrivant dans un cluster HDFS.
Cela peut être réalisé dans Flume en configurant un certain nombre d’agents de premier niveau avec un évier avro, tous pointant vers une source avro d’agent unique (vous pouvez également utiliser les sources d’économie / puits / clients dans un tel scénario). Cette source sur l'agent de deuxième niveau regroupe les événements reçus dans un seul canal qui est consommé par un puits jusqu'à sa destination finale.
Multiplexer le flux
Flume prend en charge le multiplexage du flux d'événements vers une ou plusieurs destinations. Pour ce faire, vous définissez un multiplexeur de flux capable de répliquer ou d'acheminer sélectivement un événement vers un ou plusieurs canaux.
L'exemple ci-dessus montre une source de l'agent «foo» répartissant le flux sur trois canaux différents. Cette sortie peut être répliquée ou multiplexée. En cas de flux de réplication, chaque événement est envoyé aux trois canaux. Dans le cas du multiplexage, un événement est remis à un sous-ensemble de canaux disponibles lorsqu'un attribut d'événement correspond à une valeur préconfigurée. Par exemple, si un attribut d’événement appelé «txnType» est défini sur «client», il doit alors accéder à channel1 et channel3, s’il s’agit du «fournisseur», puis à channel2, sinon channel3. Le mappage peut être défini dans le fichier de configuration de l’agent.
Configuration
Comme indiqué dans la section précédente, la configuration de l'agent Flume est lue à partir d'un fichier qui ressemble à un format de fichier de propriétés Java avec des paramètres de propriétés hiérarchiques.
Définir le flux
Pour définir le flux au sein d'un seul agent, vous devez lier les sources et les puits via un canal. Vous devez répertorier les sources, les puits et les canaux pour l'agent donné, puis pointer la source et le puits sur un canal. Une instance source peut spécifier plusieurs canaux, mais une instance de récepteur ne peut spécifier qu'un seul canal. Le format est le suivant:
# liste les sources, les puits et les canaux pour l'agent
.sources =
.sinks =
.channels =
# définir le canal pour la source
.sources..channels =
# régler le canal pour l'évier
.sinks..channel =
Par exemple, un agent nommé agent_foo lit les données d'un client avro externe et les envoie à HDFS via un canal mémoire. Le fichier de configuration weblog.config pourrait ressembler à:
# liste les sources, puits et canaux pour l'agent agent_foo.sources = avro-appserver-src-1 agent_foo.sinks = hdfs-sink-1 agent_foo.channels = mem-channel-1
# définir le canal pour la source
-appserver-src-1.channels = mem-channel-1
# régler le canal pour l'évier
-sink-1.channel = mem-channel-1
Ainsi, les événements s'écouleront d'avro-AppSrv-source vers hdfs-Cluster1-sink via le canal mémoire mem-channel-1. Lorsque l'agent est démarré avec weblog.config en tant que fichier de configuration, il instancie ce flux.
Configuration de composants individuels
Après avoir défini le flux, vous devez définir les propriétés de chaque source, puits et canal. Cette opération s'effectue de la même manière dans l'espace de noms hiérarchique, où vous définissez le type de composant et d'autres valeurs pour les propriétés spécifiques à chaque composant:
# propriétés pour les sources
.sources .. =
# propriétés pour les canaux
.canal .. =
# propriétés pour éviers
.sources .. =
La propriété "type" doit être définie pour chaque composant afin que Flume puisse comprendre le type d'objet dont il a besoin. Chaque source, collecteur et type de canal possède son propre ensemble de propriétés requises pour fonctionner comme prévu. Tous ceux qui doivent être définis au besoin. Dans l'exemple précédent, nous avons un flux d'avro-AppSrvsource vers hdfs-Cluster1-sink via le canal de mémoire mem-channel-1. Voici un exemple qui montre la configuration de chacun de ces composants:
agent_foo.sources = avro-AppSrv-source agent_foo.sinks = hdfs-Cluster1-sink agent_foo.channels = mem-channel-1 # définition du canal pour les sources, les puits
# propriétés de avro-AppSrv-source
= avro = localhost = 10000
# propriétés de mem-channel-1
= memory-channel-1.capacity = 1000-channel-1.transactionCapacity = 100
# propriétés de hdfs-Cluster1-sink
= hdfs
= hdfs: // namenode / flume / webdata #
Ajout de plusieurs flux dans un agent
Un seul agent Flume peut contenir plusieurs flux indépendants. Vous pouvez lister plusieurs sources, puits et canaux dans une configuration. Ces composants peuvent être liés pour former plusieurs flux:
# liste les sources, les puits et les canaux pour l'agent
.sources =
.sinks =
.channels =
Ensuite, vous pouvez relier les sources et les puits aux canaux correspondants (pour les sources) du canal (pour les puits) afin de configurer deux flux différents. Par exemple, si vous devez configurer deux flux dans un agent, l’un allant d’un client avro externe à un HDFS externe et l’autre de la sortie d’une queue à un évier, voici la configuration à suivre:
# liste les sources, les puits et les canaux de l'agent agent_foo.sources = avro-AppSrv-source1 exec-tail-source2 agent_foo.sinks = hdfs-Cluster1-sink1 avro-forward-sink2 agent_foo.channels = mem-channel-1 fichier- canal-2