Splunk Connect for Syslog : une GDI clé en main et évolutive pour les données syslog – Partie 2

Dans la partie 1 de cette série, nous avons étudié la philosophie de conception de Splunk Connect for Syslog (SC4S), ses objectifs et la nouvelle architecture de transport basée sur HEC. Cette fois, nous allons voir la configuration de pointe de SC4S et mettre en évidence les sections concernées de la documentation où trouver les informations nécessaires pour le déploiement dans un environnement de production.

La configuration de SC4S est modulaire et repose sur des modèles, et s’accompagne de sections de configuration de syslog-ng détaillées plus bas. Dans la version en conteneurs de SC4S, l’essentiel est complètement masqué pour l’administrateur et seul un point de montage local est exposé à des fins de configuration locale. Dans la version BYOE, la configuration complète peut être inspectée et modifiée.  

Les sections ci-dessous décrivent la configuration de SC4S avec des sources de données « prêtes à l’emploi » et des modifications mineures.

Flux de données syslog-ng

Lorsqu’un message arrive sur le serveur syslog, il est soumis à un certain nombre d’opérations de filtrage visant à déterminer son traitement. Dans le cas de SC4S, l’objectif de ce traitement est d’envoyer le message à Splunk et à l’index approprié, correctement formaté et accompagné des métadonnées appropriées (sourcetype, horodatage, etc.). Quel que soit le format de source de données (généralement, mais pas toujours, défini simplement par le fournisseur), un ensemble de filtres est développé et encapsulé dans un « chemin de log ». Ces chemins de log définissent quels filtres (et dans quel ordre) sont appliqués à un message pour vérifier s’il appartient à une catégorie spécifique (ce qui, dans Splunk, correspond au sourcetype).

Une fois cette catégorie déterminée, des interpréteurs sont appliqués pour formater le message de manière appropriée, les métadonnées sont définies et l’ensemble est empaqueté dans un blob JSON puis envoyé à Splunk par lots via le point de terminaison HEC /event. L’utilisation du point de terminaison /event permet également d’envoyer des métadonnées enrichies supplémentaires et d’opérer une classification plus poussée. C’est notamment utile pour la PCI, le rayon géographique et bien d’autres scénarios d’utilisation.

Personnalisation de l’environnement SC4S

Nous aborderons l’architecture en conteneurs dans la section suivante ; l’architecture « BYOE » est similaire et utilise les mêmes concepts que ceux décrits ici. En général, SC4S est configuré par un ensemble très spécifique de variables d’environnement qui sont encapsulées dans un fichier. Le contenu de ce fichier est documenté dans le guide « Bien démarrer » et les documents d’exécution qui l’accompagnent, et permet à l’administrateur de personnaliser une grande partie de SC4S sans une connaissance approfondie de la syntaxe de syslog-ng à proprement parler. Les étapes suivantes sont les tâches de configuration de pointe nécessaires à la configuration de SC4S :

Configuration de base (obligatoire)

SC4S n’a besoin que de quelques éléments pour démarrer :

• URL HEC (soit une liste de points de terminaison, soit un VIP d’équilibrage de charge) ;
• jeton HEC ;
• port de collecte des données par défaut (généralement 514) ;
• nombre de points de terminaison HEC (nécessaire pour configurer correctement syslog-ng à grande échelle) ;
• taille de la mémoire tampon du disque ;
• un répertoire vide à « monter » dans le conteneur pour les personnalisations locales, qui sera rempli avec des exemples de modèles lors de la première exécution de SC4S. De nombreuses équipes en auront besoin pour contourner les index par défaut.

Ceux-ci sont définis via des variables d’environnement dans le fichier détaillé ci-dessus. Si vous ne faites rien d’autre que de configurer ce qui précède, vous bénéficierez d’une véritable expérience « prête à l’emploi » de SC4S !

Personnalisation avant instanciation (en option)

Le conteneur doit « connaître » certains éléments clés avant de démarrer.  Il s’agit des informations suivantes :

• le(s) port(s) TCP, UDP ou TLS à écouter (en-dehors du port par défaut, généralement TCP/UDP 514). Ces ports peuvent être personnalisés et constituent souvent le seul critère de filtrage d’un « chemin de log » utilisé pour déterminer un ou plusieurs sourcetypes ;
• l’utilisation ou non de certificats TLS et/ou personnalisés.

Chacun de ces points doit être déterminé avant le démarrage du conteneur, et ils sont fixes quelle que soit la nature du trafic arrivant sur les ports d’écoute. Pour modifier la configuration syslog-ng sous-jacente afin de définir correctement ces paramètres, une opération de modélisation est réalisée pour que syslog-ng puisse démarrer avec les paramètres port/TLS appropriés en place, en s’appuyant sur les valeurs des variables d’environnement définies par l’administrateur. Ces variables d’environnement sont documentées dans la section « Configuration » des documents. Cette opération de modélisation est automatique pour les sources prêtes à l’emploi. Lors du développement de chemins de log personnalisés (ci-dessous), certains éléments du modèle sont exposés à l’administrateur et doivent être correctement pris en compte.

Personnalisation du runtime (facultatif)

Vous pouvez également personnaliser SC4S en fonction d’autres caractéristiques des données entrantes en plus de la configuration du port source/TLS décrite ci-dessus. Les sources de données peuvent être classées (filtrées) grâce à la reconnaissance du nom d’hôte avec caractère générique (globs) et les blocs CIDR entrants, et elles peuvent être utilisées (comme la configuration du port source ci-dessus) comme mécanismes pour différencier un sourcetype particulier. Enfin, toutes les métadonnées peuvent être écrasées ou modifiées lors de cette étape de personnalisation.

La personnalisation du runtime se distingue des étapes de pré-instanciation ci-dessus pour une raison très importante : au lieu de modifier les variables d’environnement, un petit extrait du fichier de configuration syslog-ng sous-jacent est exposé à l’administrateur via un « point de montage » local sur le conteneur. Il faut veiller à fournir la syntaxe appropriée (qui sera vérifiée avant le démarrage) et c’est le seul endroit où une connaissance rudimentaire de la syntaxe du fichier de configuration syslog-ng est utile. Vous apprendrez rapidement que la meilleure approche pour réussir consiste à copier le code existant et à le modifier en fonction de vos besoins !

Développement de chemin de log personnalisé (facultatif)

Une partie du point de montage local comprend une arborescence de répertoires complète qui permet de développer in situ des chemins de log et des filtres personnalisés (et accessibles depuis le conteneur via le point de montage local). Nous allons approfondir ce processus dans la partie 3 de cette série, mais en attendant, vous trouverez des exemples documentés dans le répertoire local pour vous aider dans ce processus, et la suite complète de filtres, réécritures et parseurs prédéfinis SC4S est disponible. Encore une fois, étudier les exemples et copier/coller (en suivant les conseils des commentaires) est la meilleure façon de réussir !

C’est aussi un domaine dans lequel nous sommes ravis d’aider la communauté. Demandez sur le canal Slack si un chemin de log ou un filtre a déjà été fait par la communauté, ou si un exemple similaire peut être adapté. Si vous développez un chemin de log personnalisé ou un filtre pour un dispositif répondant à un besoin général, nous vous encourageons à soumettre l’amélioration via le dépôt github en tant que PR pour qu’elle soit incluse dans une version future de SC4S.  

Communauté Splunk Connect for Syslog

Splunk Connect for Syslog est entièrement pris en charge par Splunk et publié comme logiciel open-source. Nous espérons motiver une communauté vivante qui nous apportera ses commentaires et des idées d’amélioration, et nous aidera à communiquer et surtout à créer des chemins de log (filtres) ! Nous encourageons une participation active via les dépôts git, où vous pourrez faire des requêtes formelles d’inclusion de fonctionnalités (en particulier de chemin de log/filtres), de suivi de bug, etc. Au fil du temps, il devrait y avoir de moins en moins de « filtres locaux » car les efforts de la communauté seront encapsulés dans les configurations prêtes à l’emploi des conteneurs.

Ressources Splunk Connect for Syslog

De nombreuses ressources sont à votre disposition pour vous aider à réussir avec SC4S ! En plus du dépôt principal et de la documentation, vous pouvez également consulter :

• Partie 1 : histoire, objectifs de conception et architecture
• Assistance et discussions de la communauté : https://splunk-usergroups.slack.com, #splunk-connect-for-syslog
• Problèmes et améliorations : https://github.com/splunk/splunk-connect-for-syslog/issues

Tous nos vœux de réussite avec SC4S. Impliquez-vous, essayez, posez des questions, proposez de nouvelles sources de données et rencontrez de nouvelles personnes !

_{*Cet article est une traduction de celui initialement publié sur le blog Splunk anglais.}