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

Cela fait plus de 8 ans que je travaille chez Splunk, et certaines questions des clients et de la communauté des professionnels de Splunk reviennent systématiquement chaque année, en particulier au sujet des données syslog et de la meilleure façon de les importer. S’il y a bien une question essentielle qui revient sans cesse, c’est :

en tant qu’administrateur, comment puis-je facilement importer les données syslog à grande échelle sans avoir à fournir de gros efforts de conception au départ ni à faire appel au « syslog-fu » ?

Nous avons le plaisir d’annoncer que nous pouvons maintenant apporter une réponse appropriée à cette question, grâce à Splunk Connect for Syslog ! Splunk Connect for Syslog a été développé pour soulager les administrateurs de la tâche de la collecte des données syslog et leur fournir une approche clé en main, évolutive et reproductible pour l’incorporation des données syslog.

Spécifiquement, Splunk Connect for Syslog (SC4S) a été conçu pour :

• transporter les données syslog dans Splunk à une très grande échelle (plus de 5 To par jours depuis une seule instance vers plusieurs indexeurs) ;
• catégoriser correctement (selon le sourcetype) les sources de données les plus courantes, avec peu ou pas de configuration personnalisée ;
• apporter un enrichissement amélioré des données, au-delà des métadonnées standard de Splunk que sont l’horodatage, l’hôte, la source et le sourcetype ;
• fournir des « filtres » personnalisés supplémentaires pour d’autres sourcetypes que ceux qui sont pris en charge dès le départ.
  

Dans la suite de cet article, nous allons analyser le raisonnement sur lequel s’appuie la conception de SC4S, qui fait suite au blog de 2017 « Syslog-ng et HEC : approche évolutive de la collecte des données agrégées dans Splunk » et puiser dans les enseignements que nous avons tirés depuis. Nous allons également proposer une vue d’ensemble du processus employé pour configurer ce nouveau produit, mais pas sous la forme d’un « livre de recettes ». Pour des détails complets, la documentation est disponible dans notre dépôt (et sera référencée dans les sections concernées ci-dessous).

Mais avant tout chose, un peu d’histoire...

Il y a plus de deux ans, Ryan Faircloth et moi avons commencé à étudier une nouvelle architecture pour l’importation des données syslog, utilisant le collecteur d’événements HTTP (HEC) pour transporter les données d’un serveur syslog directement dans Splunk. Nous avions entrevu la nécessité de trouver une alternative à l’approche traditionnelle, qui consiste à écrire les messages de log sur un disque puis à les envoyer à Splunk via un UF, pour des questions d’échelle et de simplicité d’utilisation. Depuis la publication du premier article « Syslog et HEC », les tendances que nous voyions apparaître à l’époque n’ont fait que s’accélérer.

Plus spécifiquement, nous avons observé ce qui suit :

• Syslog n’est PAS devenu « obsolète » et n’est PAS considéré comme une technologie « héritée » par la plupart des fournisseurs. Au contraire, un grand fournisseur de dispositifs de sécurité est revenu à syslog après un long départ.
• Le volume des données syslog a considérablement augmenté en raison de la croissance des entreprises et du rendement des machines, ce qui impose de formaliser les techniques étudiées dans les articles précédents.
• Syslog reste un type de données majoritaire en termes de volume pour presque 100 % de la clientèle de Splunk.
• Les deux grands types de serveurs syslog (syslog-ng et rsyslog) ont répondu en apportant des améliorations critiques à la prise en charge de destination de http (HEC) et de Kafka.
• Les clients demandent de plus en plus une solution clé en main et évolutive à ce problème.
  

Face à cette situation, il est devenu clair qu’un projet formel visant à commercialiser une solution évolutive, cohérente et facile à configurer était justifié, puis SC4S est né.

Les défis GDI de syslog

Bien que syslog soit manifestement la première source de données de Splunk, les défis uniques de l’importation des données syslog dans Splunk n’ont pas beaucoup changé au fil du temps. 

Ces défis sont bien connus :

• manque de documentation et de prise en charge des bonnes pratiques ;
• pénurie d’expertise approfondie sur syslog dans la communauté ;
• hétérogénéité des déploiements de serveurs syslog, qui crée un défi de prise en charge ;
• les événements de nombreuses sources de données portent la balise générique « sourcetype=syslog » qui limite l’utilité des analyses de Splunk ;
• distribution inégale des données entre les indexeurs Splunk, ce qui affecte la performance des recherches.
  

La plupart de ces défis proviennent de deux problèmes fondamentaux touchant les données syslog en général :

1. Syslog est un protocole, et non un sourcetype. Les clients comme les Splunkers ont souvent groupé toutes ces données dans un sourcetype (sourcetype=syslog, par exemple), ce qui rend difficile de réaliser des analyses supplémentaires avec SPL et l’application d’un « schéma à la lecture », car le protocole transporte souvent de multiples formats de données provenant de différents fournisseurs.
   
   
2. L’interprétation efficace du protocole et le « préconditionnement » approprié des données avant leur importation dans Splunk nécessite l’utilisation d’un serveur syslog, pour lequel Splunk ne fournit aucune recommandation.
    

Objectifs de conception de SC4S

Au cours de nos recherches, il est devenu clair qu’en matière d’ingestion des données syslog dans Splunk, le statu quo n’était pas acceptable pour des questions de complexité et d’échelle, et les retours des clients témoignaient de problèmes réguliers. C’est comme cela qu’est né Splunk Connect for Syslog, et lorsque le produit a pris forme au cours de l’été, deux questions transversales ont orienté tout le processus de développement :

• Quelle solution permettrait d’améliorer significativement nos pratiques actuelles en matière de syslog ?
• Comment répondre aux besoins d’au moins 80 % de nos clients dès le départ ?
   

Nous avions le sentiment qu’en apportant les avantages ci-dessous à la communauté des utilisateurs de Splunk, la solution serait viable. Ces avantages sont les suivants :

• réduire la charge, pour les clients comme pour les Splunkers, liée à l’importation des données syslog dans la plateforme Splunk ;
• fournir une infrastructure cohérente, documentée et reproductible pour la collecte des données syslog ;
• permettre l’importation clé en main des 15 sourcetypes les plus courants dès la première version ;
• améliorer « l’hygiène » des données syslog entrantes en appliquant un sourcetype correct et des métadonnées enrichies ;
• réduire la charge de Splunk associée au traitement des données syslog ;
• améliorer considérablement la capacité et la distribution des données.
  

Examinons chacun de ces aspects dans le détail.

Réduire la charge « GDI »

D’abord et avant tout, nous voulions réduire la charge associée à l’importation des données syslog pour l’ensemble de la communauté. Malheureusement, Splunk n’a jamais proposé de méthode efficace pour envoyer simplement et directement ces données à la plateforme ; en effet, une telle approche serait source d’une myriade de problèmes que nous n’aborderons pas ici. Disons simplement ceci : nous décourageons fortement cette pratique, et pour d’excellentes raisons. Mais que doit donc faire le client ? La pratique recommandée, qui consiste à utiliser un serveur syslog (syslog-ng ou rsyslog), exige de posséder une expertise dans la configuration de ce serveur. Il était clair qu’il fallait éliminer et/ou réduire significativement l’exposition du client aux rouages internes des serveurs syslog.

Documenté, cohérent et reproductible

Au fil des ans, nous avons vu apparaître autant d’architectures de collecte des données syslog que de flocons de neige en décembre ! L’un des objectifs clés était de rendre la configuration suffisamment flexible pour la plupart des utilisateurs, mais aussi cohérente et reproductible pour ceux qui souhaitent simplement « copier » ce qui est déjà là. Pour cette raison, nous avons choisi syslog-ng comme serveur syslog à la base de SC4S, pour sa robustesse et sa syntaxe claire (à défaut d’être simple).

Clé en main pour les principales sources de données

L’un des grands défis associés à l’élaboration de configurations de serveur syslog dans différentes entreprises réside dans la création de « filtres », qui sont les éléments uniques de la configuration qui interprètent les types de périphériques (pour ensuite les catégoriser en un ou plusieurs sourcetypes connexes). SC4S avait donc pour objectif de créer des filtres pour les systèmes que nous voyons le plus dans l’environnement d’entreprise. Nous avons ainsi pu atteindre l’objectif essentiel « clé en main » pour la plupart (mais certainement pas l’intégralité) de nos clients.

Une meilleure hygiène des données

Lors du développement de filtres pour les différents systèmes, nous voulions avant tout identifier correctement les données de l’appareil et les affecter à un sourcetype fonctionnant avec les TA (existants) de Splunkbase. Il fallait donc qu’elles soient correctement « sourcetypées » en envoyant des métadonnées appropriées (horodatage, hôte, source et index de destination) avec le message à Splunk. Outre les métadonnées de base ci-dessus, nous avons découvert très tôt dans le processus de conception qu’il était possible d’apporter un enrichissement plus approfondi des données, sous la forme de champs indexés. Ces champs peuvent indiquer si le système fait partie du champ PCI, d’une unité commerciale ou d’une région particulière, ou de bien d’autres catégories selon le scénario d’utilisation. Cette capacité dépasse largement ce que permettait auparavant le transport par UF traditionnel.

Réduction de la charge de Splunk

La réduction de la charge de Splunk a été un effet collatéral majeur des travaux effectués dès le départ sur le transport. Lorsque nous avons commencé à explorer HEC comme méthode de transport, seul le point de terminaison « raw » était mis à disposition. Par la suite, lorsque le serveur syslog-ng a reçu d’importantes améliorations, le point de terminaison « event » est devenu accessible, ainsi que le mode « batch » pour le transport de données par lot. La combinaison du point de terminaison event et du transport en mode batch a produit une assimilation des données à la fois évolutive et légère.

Volume et distribution des données

Le volume et la distribution des données étaient dès le départ des motivations pour la création de SC4S, car les clients utilisant l’approche traditionnelle par UF rencontraient des difficultés en termes de distribution des données (les données n’étaient pas uniformément réparties sur un grand nombre d’indexeurs) et d’échelle en général. C’est dans ce contexte que des alternatives à l’UF comme mécanisme de transport ont été étudiées. Les premiers articles de blog et sessions .conf mettent en évidence le travail accompli (et validé par les clients actuels) pour faire de HEC une alternative de transport viable qui, une fois bien configurée, répond aux besoins des très gros volumes. D’après les tests effectués avec SC4S, on peut obtenir le traitement de 5 To/jour sur une seule instance de SC4S avec 5 indexeurs ou plus. Les premières sessions .conf montrent également la distribution exemplaire des données sur les indexeurs, qui permet une recherche bien plus rapide, en particulier avec l’accélération des modèles de données massivement employée dans ES et d’autres contextes.

Architecture de Splunk Connect for Syslog

Pour obtenir les avantages ci-dessus, SC4S se présente sous deux formes : un conteneur conforme à OCI pour un déploiement simplifié et une fonctionnalité prête à l’emploi, et une option « Bring Your own Environment » (BYOE) pour un maximum de flexibilité, aux dépens de certaines fonctionnalités clé en main. Les deux environnements reposent sur un logiciel de serveur syslog-ng et encapsulent le même ensemble de configurations de serveur syslog-ng, mais ils se distinguent par la façon dont syslog-ng lui-même est instancié. Les deux utilisent la même architecture de haut niveau décrite ci-dessous :

Voici les points clés de chaque distribution :

Conteneur

• Le « bouton facile » de SC4S
• La dernière branche stable du serveur syslog-ng
• Tous les programmes de création de modèles sont inclus et automatiquement invoqués au démarrage
• Tampon sur disque local pour la résilience des données
• Hébergé sur l’image de base universelle (UBI) de Red Hat Linux, une distribution ultra légère de Linux conçue pour être utilisée dans des conteneurs (la norme dans tous les projets Splunk basés sur des conteneurs)
• Conformité à OCI et compatibilité avec l’environnement d’exécution de votre choix (Docker, Podman, k8s, etc.)
   

BYOE

• Pour les clients aux besoins spécifiques
• Pour les clients qui ne peuvent pas utiliser les conteneurs, quelle qu’en soit la raison
• Offre un accès complet aux fichiers de configuration de syslog-ng sous-jacents
• Configuration requise
      o CentOS, RHEL 7.0 ou autre distribution Linux ultérieure
      o Dernière version de syslog-ng ; 3.24.1 au moment de cette publication
      o Dernière version du logiciel de création de modèles gomplate ; version 3.5 ou ultérieure (n’est pas nécessaire au moment de l’exécution)
   

Dans chaque distribution, la configuration syslog-ng sous-jacente est identique, le choix entre la version conteneur et la version BYOE résident uniquement dans la préférence (et les éventuelles limitations) du client concernant l’environnement d’exécution. De plus, un client utilisant un environnement BYOE peut créer un conteneur personnalisé incluant des éléments de configuration locale, qui conviendraient ensuite à une distribution en périphérie par orchestration automatisée.

Dans la partie 2 de cet article, nous nous pencherons sur la configuration de pointe de Splunk Connect for Syslog, entièrement documentée dans les ressources ci-dessous.

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 :

• 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.}