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

Les précédents épisodes de cette série vous ont donné la vue d’ensemble et les détails de configuration dont vous avez besoin pour importer une source prise en charge par Splunk Connect for Syslog et configurer les personnalisations et les remplacements nécessaires à votre entreprise. Il reste donc une capacité clé de SC4S que nous n’avons pas encore couverte, et qui permet d’étendre la plateforme elle-même.

Dans cet article, nous allons aborder la configuration d’une toute nouvelle source de données, une source que SC4S ne prend pas en charge au départ. Voyons maintenant comment ajouter la prise en charge d’une nouvelle source de données à SC4S !

Vue d’ensemble du développement SC4S

Tâches préalables

Avant de vous lancer dans la création d’un chemin de log (filtre) pour un nouveau périphérique, vous aurez besoin de répondre à certaines questions clés :

• Le périphérique est-il entièrement nouveau ou est-il apparenté à un périphérique existant (comme un nouveau périphérique Cisco basé sur iOS) ? Dans le deuxième cas, il est préférable de le signaler sur Github afin que l’équipe de développement Splunk puisse ajouter ce périphérique/format au support existant du fournisseur ou de la famille de périphériques. Le SC4S est développé rapidement : en quelques semaines seulement, de nouveaux dispositifs peuvent être pris en charge.
• L’appareil ou la source de données que vous utilisez est courant dans l’industrie ? Bien que nous prenions maintenant en charge la plupart des sources de données courantes, le support de SC4S est loin d’être exhaustif. Si le périphérique est couramment utilisé (s’il s’agit par exemple d’un pare-feu d’un fournisseur connu, et non d’une application développée en interne), il peut être préférable de signaler le problème (et peut-être de contribuer au code ou faire une PR) plutôt que de se lancer dans un effort totalement personnalisé.
• La communauté a-t-elle développé une solution pour la source de données ? Commencez toujours par poser la question sur les canaux Slack concernés.
• Existe-t-il une application Splunk et/ou une TA pour cet appareil ? C’est une question essentielle, car il faut que le format de sortie (vers Splunk) corresponde aux attentes de la TA. Consultez Splunkbase et la documentation du fournisseur pour obtenir confirmation.
• Le format de sortie utilisé par le périphérique est-il bien documenté ? La plupart des fournisseurs ne documentent pas correctement (voire pas du tout) les messages syslog bruts « sur le fil » : vous devrez donc le collecter par vous-même (et nous allons voir comment faire dans cette section).

Les réponses aux questions ci-dessus vous guideront dans la création d’un nouveau chemin de log pour étendre la plateforme. Commençons par un peu de contexte sur la structure globale d’une configuration syslog-ng, car il faut la comprendre pour créer un chemin de log.

Structure du fichier de configuration de syslog-ng

Voici la structure globale d’un fichier de configuration syslog-ng. La syntaxe du fichier de configuration syslog-ng, qui est elle-même un langage de programmation, offre une myriade de façons de parvenir à vos fins. Mais toutes suivent le même schéma de base :

Dans SC4S, la plupart de ces éléments sont abstraits via les mécanismes de configuration décrits dans la partie 3, ce qui évite à l’administrateur d’avoir à comprendre les nuances de la syntaxe syslog-ng. Mais la structure d’un chemin de log devient immédiatement apparente lorsqu’on doit en développer un nouveau, et il est essentiel de comprendre comment les pièces s’assemblent.

Flux d’événements syslog-ng

Dans une configuration syslog-ng type, ce qui vaut également pour SC4S, il y aura autant de chemins de log que de "variantes" d’événement (périphérique). Ces formats d’événement sont généralement définis par les fournisseurs eux-mêmes et doivent être conformes aux normes syslog publiées (RFC 3164 ou RFC 5424), mais beaucoup présentent des écarts par rapport à ces normes, et vous devez les prendre en compte dans les chemins de log.

Les événements circulent de haut en bas dans le fichier de configuration final ; chacun d’eux est testé par les filtres dans chaque chemin de log afin de déterminer si l’événement y a sa place. Bien que le diagramme ci-dessus montre les filtres comme une entité distincte, en réalité, toutes les étapes (sauf la directive de destination finale) agissent comme un même filtre (ou test). Cela signifie que le bloc source lui-même agit comme un filtre ; si le bloc source indique "Collecter sur le port UDP 5000" et que l’événement s’affiche sur le port UDP 514, ce chemin de log ne sera pas utilisé pour cet événement. De même, le parsage syntaxique des messages peut également agir comme un filtre (si vous le souhaitez) et exclure des événements de ce chemin de log si le parsage échoue. Si l’événement "survit" assez longtemps dans un chemin de log, il est finalement envoyé à une ou plusieurs destinations du choix de l’administrateur.

Rien n’empêche un événement de correspondre à plus d’un chemin de log, mais nous le déconseillons dans SC4S : nous intégrons en effet à la configuration de chaque chemin de log un indicateur qui met fin au traitement si l’événement est traité avec succès par un chemin de log donné. Dans ce cas, "le premier gagne", et c’est le seul endroit dans syslog-ng où le nom des fichiers de chemin de log ont de l’importance : les chemins de log sont traités dans l’ordre lexicographique (essentiellement par ordre alphabétique) des noms de fichier.  En interne, SC4S utilise des noms de fichier appropriés pour forcer certains chemins de log à se placer avant (ou après) tous les autres, de manière à imposer un "gagnant" si plusieurs chemins de log se déclenchent sur la seule base du filtrage. Cette technique n’est utilisée que pour les chemins de log de dernier recours (catchall) et de file d’attente "null", elle ne doit donc pas affecter les chemins de log développés localement.

Nous allons maintenant nous pencher sur une fonctionnalité clé de SC4S, fondamentale pour la création d’un chemin de log. Vous vous souvenez qu’au début de la partie 3, nous avons discuté des variables d’environnement dans env_file ? Si nous spécifions un jeton et une URL de point de terminaison HEC avec une variable d’environnement, comment cela se traduit-il dans la syntaxe syslog-ng, qui doit effectivement être "codée en dur" ? La réponse se trouve dans la création de modèles : un élément clé de l’abstraction de la syntaxe sous-jacente pour l’administrateur et un élément clé pour rendre les chemins de log beaucoup plus faciles à créer.

Modèles de chemin de log (gomplate)

La syntaxe syslog-ng est très stricte, et bien qu’elle se rapproche d’un langage de programmation complet, il lui manque certaines constructions clés, en particulier la possibilité d’interagir avec l’environnement en cours d’exécution et d’adapter sa configuration en fonction de tests conditionnels des variables d’environnement. Lorsque syslog-ng est instancié, la configuration doit être solidifiée lors de l’exécution. Par conséquent, SC4S a besoin d’un mécanisme pour construire dynamiquement cette configuration fixe juste avant le lancement de syslog-ng. C’est là qu’intervient "gomplate", ou "Go templates".  

Le processus de modélisation permet aux variables d’environnement de dicter la configuration syslog-ng finale utilisée par SC4S. Prenons cette variable d’environnement :

SC4S_SOURCE_UDP_SO_RCVBUFF=33554432

Comment la valeur de cette variable s’inscrit-elle dans la configuration finale ? La clé réside dans la modélisation ; la configuration source syslog-ng qui se trouve à l’intérieur du conteneur n’est pas codée en dur, mais ressemble plutôt à ceci pour le tampon de réception UDP :

so-rcvbuf({{getenv "SC4S_SOURCE_UDP_SO_RCVBUFF" "1703936"}})

Tout ce qui se trouve à l’intérieur des paires d’accolades doubles fait partie du modèle (qui est lui-même son propre langage) et est utilisé pour insérer, de façon conditionnelle, des éléments de configuration en fonction des paramètres des variables d’environnement. Le résultat est la configuration finale suivante, dans laquelle la valeur par défaut (1703936) est remplacée par la valeur de la variable :

so-rcvbuf(33554432)

L’exemple ci-dessus est une simple substitution, mais il est possible de réaliser des remplacements conditionnels plus complexes :

{{- if or (conv.ToBool (getenv "SC4S_ARCHIVE_GLOBAL" "no")) (conv.ToBool (getenv "SC4S_ARCHIVE_CISCO_ASA" "no")) }}
    destination(d_archive);
{{- end}}

Cette construction insère la destination de l’archive alternative dans la configuration si l’une des variables ARCHIVE est définie sur "yes". Si aucune des variables n’est définie dans env_file ou si les deux ont la valeur "no", le texte spécifié au sein de l’instruction conditionnelle "if/end" n’est pas inséré dans la configuration.

Nous allons maintenant nous intéresser au processus de création d’un chemin de log, qui utilise grandement le processus de modélisation décrit ci-dessus. Mais nous devons encore nous occuper de quelques aspects avant d’écrire le chemin de log, et cela nous facilitera la tâche. Une étape critique, après avoir déterminé qu’un chemin de log est effectivement nécessaire en vérifiant les "tâches préalables" au début de cette section, consiste à obtenir un événement brut avec lequel il sera possible de travailler.

Collecte des données brutes

Vous avez peut-être de l’expérience dans la collecte d’échantillons de données brutes lors de la configuration de SC4S, en particulier si les événements arrivent dans Splunk avec des métadonnées incorrectes (sourcetype, etc.). Cette tâche est essentielle pour le développement du chemin de log et elle doit être la première étape technique. Plusieurs options sont à votre disposition, les deux plus courantes étant tcpdump et l’utilisation de SC4S lui-même. Les détails sont documentés ici, ils sont brièvement résumés ci-dessous et seront examinés dans notre guide :

• exécutez tcpdump avec les options appropriées sur l’hôte SC4S et recherchez la chaîne indicatrice (par exemple <134>) et le texte qui suit. Le message apparaîtra probablement entre des caractères "parasites", mais il devrait être assez clair pour être visible, en particulier son en-tête, la partie la plus importante ;
• définissez la variable SC4S_SOURCE_STORE_RAWMSG=yes et recherchez le champ RAWMSG dans Splunk lorsqu’un échantillon d’événement est envoyé à SC4S Lorsque vous affichez l’événement dans Splunk (il devrait avoir l’un des deux types de sources de dernier recours, sc4s:Fallback ou nix:syslog), vous voyez également d’autres champs qui seront très utiles lors du développement de notre chemin de log ;
• pour "relire" un événement brut (collecté à partir du périphérique lui-même ou fourni out-of-band), exécutez simplement echo "" > /dev/udp//514.

Nous avons maintenant les données dont nous avons besoin pour créer pas à pas un exemple de chemin de log. Allons-y !

Guide de développement de chemin de log SC4S

Développement du chemin de log : processus initial

Il existe deux types de chemins de log dans SC4S: "simple" et "traditionnel".  Les chemins de log simples peuvent être utilisés lorsque le périphérique peut envoyer ses messages sur un port unique et qu’une interprétation minimale, reposant uniquement sur un protocole, suffit pour déterminer le sourcetype unique de l’événement. Ils peuvent être entièrement configurés via des variables d’environnement et ne nécessitent pas le développement d’un chemin de log dédié. Vous trouverez ici plus d’informations sur les chemins de log simples.  

D’autre part, si la famille d’appareils nécessite plusieurs sourcetypes (par exemple, Palo Alto), un chemin de log traditionnel intégrant une interprétation plus complète doit être développé.Dans le cadre de notre guide, nous déterminerons si notre nouveau périphérique peut être pris en charge par un chemin de log simple, ou s’il faut développer un chemin traditionnel.

Nous utiliserons le produit Stealthbits StealthINTERCEPT comme exemple pour notre nouveau chemin de log. La configuration de l’application et du périphérique pour le fonctionnement de syslog est typique dans la mesure où aucun échantillon brut "sur le fil" n’est fourni. Par conséquent, il faut utiliser tcpdump ou SC4S pour obtenir un échantillon brut comme indiqué ci-dessus.  

Les étapes permettant de créer un chemin de log qui prendra en charge la famille de périphériques StealthINTERCEPT sont décrites ci-dessous :

• Utilisez l’échantillon brut pour voir à quoi ressemble l’événement dans Splunk, avec un traitement minimal et sans aucun chemin de log dédié, en consultant la documentation du fournisseur et celle de l’application ou la TA Splunk
• Déterminez si les champs minimaux fournis par la phase initiale de décodage du protocole syslog permettent d’utiliser un chemin de log simple ou s’il faut développer un chemin de log traditionnel
• Si un chemin de log simple suffit, configurez le port unique et les entrées de métadonnées de manière appropriée. Le chemin de log sera alors créé automatiquement au démarrage de SC4S, sinon
• Créez un chemin de log personnalisé pour le nouveau périphérique, en suivant l’exemple de modèle fourni.

Commençons par examiner l’échantillon brut dans Splunk (en écoutant un appareil réel ou en utilisant la commande "echo" décrite ci-dessus) :

Envoyez l’événement à SC4S (ici raccourci pour plus de lisibilité) :

echo "<37>`date +\"%b %d %H:%M:%S\"`"’.986 stealth-host StealthINTERCEPT - Authentication Auth failed - PolicyName="StealthDEFEND for AD" Domain="TDOMAIN" Server="TDOMAIN-DC" ServerAddress="10.2.8.55" Perpetrator="MarkB" ClientHost="AP34.TEST.COM" ClientAddress="10.2.8.55" TargetHost="TDOMAN-DC.TEST.COM" TargetHostIP="10.135.33.7"’ > /dev/udp/sc4s.test.com/514

Voici l’événement dans Splunk; vous pouvez voir que RAWMSG est activé :

On peut observer plusieurs choses :

• le message présente une chaîne valide, un horodatage et ce qui semble être un nom d’hôte dans l’en-tête. C’est de bon augure pour l’événement, qui affiche un minimum de conformité à la RFC ;
• Pour le vérifier, vous pouvez consulter les champs indexés dans Splunk. En effet, cet événement est conforme à la norme RFC 3164, il existe un autre champ ("macro" syslog-ng) appelé PROGRAM qui pourrait être très utile dans un filtre – ou pourquoi pas comme sourcetype de l’événement ? Une consultation rapide de la documentation de Stealthbits montre que ce champ peut en effet varier – il pourrait donc être utile pour affecter un sourcetype à l’événement. Une autre vérification rapide du TA montre que SC4S devra fournir plus d’un sourcetype. Le chemin de log simple est donc exclu, et il faut développer un chemin de log traditionnel. Poursuivons :

Guide de développement de chemin de log

Maintenant que nous savons que nous devons développer un chemin de log traditionnel, par où commencer ? Rappelez la structure de répertoire décrite plus haut. Vous verrez le répertoire

/opt/sc4s/local/config/log-paths 

Il contient deux fichiers :

lp-example.conf 

lp-example.conf.tmpl

Le répertoire log-path (et les autres du répertoire config) sont tous des fichiers de configuration syslog-ng "actifs" et sont inclus dans la configuration globale lorsque le conteneur et le processus syslog-ng sous-jacent sont exécutés. La syntaxe doit donc être parfaite, sans quoi tout cela ne pourra pas démarrer. Pour cette raison, de nombreux fichiers .conf ne sont pas édités directement, mais plutôt via leurs variantes .tmpl. En plus de la substitution de variables et des substitutions conditionnelles abordées dans la partie 3, le processus de modélisation nous permet d’abstraire certaines parties complexes du chemin de log qui n’ont pas besoin d’être exposées (et configurées) par l’administrateur.

Examinons maintenant le fichier lp-example.conf.tmpl. Ne vous inquiétez pas si le fichier d’exemple spécifique de votre version SC4S diffère de celui utilisé pour ces captures d’écran. Le fichier d’exemple change régulièrement au fur et à mesure que SC4S est amélioré et affiné, et aura certainement subi des modifications pour simplifier sa structure lorsque vous lirez ceci. Concentrez-vous sur la structure globale tout en passant en revue les étapes ci-dessous, elles resteront cohérentes, quelles que soient les spécificités du fichier.

Avant tout, vous verrez que le fichier est parsemé de commentaires d’instructions. Le nombre de lignes exécutables sera au final assez réduit. Ensuite, il est peu probable que vous ayez un éditeur de texte orienté contexte (comme Sublime en mode de langage "C") sur votre serveur SC4S, il peut s’avérer utile lors de la création initiale de votre fichier de modèle à partir du fichier d’exemple ci-dessus, pour faciliter la vérification de la syntaxe.

Passons en revue les étapes nécessaires pour convertir ce fichier "exemple" en chemin de log fonctionnant avec un appareil réel, "Stealthbits" dans notre cas. Les étapes suivantes prépareront le nouveau chemin de log pour la personnalisation spécifique au périphérique :

1. La première chose à faire (et non des moindres) : dupliquez le fichier d’exemple et donnez-lui un nouveau nom de fichier modèle, qui sera utilisé dans le chemin de log (par exemple). Ne modifiez pas directement le fichier d’exemple !
2. Notez la différence entre les commentaires "gomplate" (modélisation) et les commentaires syslog-ng normaux (signalés par des hashtags traditionnels de style bash). Dans la plupart des cas, vous conserverez les commentaires syslog-ng, mais les commentaires de modélisation seront rarement utilisés.
3. La première section (lignes 1 à 26) est en grande partie un bloc de commentaires d’instructions axés sur un aspect clé de l’utilisation du fichier d’exemple : dans ce fichier, des expressions clés (comme LOCAL_EXAMPLE) seront remplacées par une expression représentant le fournisseur et le produit qui nous intéresse. Conformément à la convention "Fournisseur_produit" utilisée dans SC4S, nous utiliserons la formulation STEALTHBITS_INTERCEPT.
4. De même, remplacez toutes les occurrences de la version minuscule de cette chaîne (local_example) par stealthbits_intercept.

Après ces substitutions de chaînes, nous allons maintenant examiner chaque section à tour de rôle. Un examen attentif des fragments présentés dans les sections ci-dessous révèle les substitutions de chaînes par rapport à la capture d’écran complète du fichier d’exemple non modifié ci-dessus.  

Conformément à la marche à suivre que nous avons annoncée, nous allons maintenant disséquer ce fichier en quatre sections principales:

• Source
• Filtre
• Parsage/métadonnées
• Destination.

Source

Commençons par la partie "Source" du chemin de log. À partir de la ligne 28, nous voyons :

Ces deux lignes modélisées font l’essentiel du travail pour vous, grâce au processus de modélisation. Il vous suffit de la chaîne STEALTHBITS_INTERCEPT principale, qui forme la "racine" des variables d’environnement utilisées pour définir des ports d’écoute uniques, et d’une valeur "parser" (définie pour correspondre à la structure de haut niveau des événements, en cas de doute, utilisez "common") pour créer une déclaration de source personnalisée pour votre appareil. Gardez à l’esprit que cette section va créer la déclaration de source, c’est-à-dire la fonction appelée depuis le chemin de log, comme nous le verrons plus bas.

Filtre

Ensuite, nous allons examiner le début du chemin de log lui-même, en commençant à la ligne 32 (ligne 34 tronquée):

Vous verrez que chaque événement prend deux chemins parallèles à travers un filtre "junction", qui "fusionnent" après la traversée de tous les éléments "channel".  Dans le canal supérieur, la nouvelle source appelée s_STEALTHBITS_INTERCEPT est vérifiée. Si des événements arrivent sur cette source (port unique), ils sont transmis au reste du chemin de log sans filtrage supplémentaire. Si, en revanche, l’événement arrive sur le port par défaut s_DEFAULT (généralement UDP ou TCP 514), vous pouvez voir qu’un filtre supplémentaire (f_stealthbits_intercept) doit également être validé, sans quoi l’événement ne sera pas "autorisé à entrer" dans ce chemin de log. Ce filtre peut être déclaré (tout comme la source personnalisée) immédiatement au-dessus de la section log{} du fichier de chemin de log, ou inclus dans un fichier séparé comme indiqué ci-dessous. Comme dans le cas de la source, il s’agit simplement d’une fonction nommée f_stealthbits_intercept :

Examinons les lignes 2 et 3. Vous vous souvenez de la capture d’écran du message brut dans Splunk (ci-dessus) ? Recherchez le champ PROGRAM. C’est un exemple de la façon dont l’interprétation initiale de syslog-ng peut être extrêmement utile pour créer des filtres dans les chemins de log, et les lignes 2 et 3 montrent comment ce champ ("macro" dans le langage syslog-ng) est vérifié pour déterminer s’il correspond aux deux valeurs affichées. Vous verrez également dans la section ci-dessous comment la même macro peut être très utile pour attribuer les sourcetypes attendus par la TA.

Parsage/Métadonnées

Dans cette phase du développement, tout le langage de programmation syslog-ng config peut être mis en œuvre. Bien que vous puissiez analyser en profondeur la charge utile de l’événement et même aller jusqu’à l’extraction complète des champs comme dans Splunk, il est préférable de limiter l’interprétation aux métadonnées Splunk qui devront être envoyées avec l’événement à indexer. Ces métadonnées comprennent l’index normal, l’heure, l’hôte, la source et le sourcetype. Notez que le temps est inclus dans cette liste, nous voulons nous assurer qu’il est correctement interpréter avant d’atteindre Splunk, car le traitement de l’horodatage est ignoré (par défaut) avec le point de terminaison /event HEC utilisé par SC4S.

Voici les "entrailles" du chemin de log, où cette attribution de métadonnées a lieu :

Plusieurs fonctions de réécriture sont mises à la disposition du développeur, comme illustré, de sorte que même cette section peut être "plug and play" pour la plupart des chemins de log. Les valeurs par défaut de toutes les métadonnées Splunk sont définies à l’aide des réécritures aux lignes 56 et 61, et la réécriture utilisée dépend de la valeur de la macro PROGRAM. Encore une fois, l’interprétation syslog-ng initiale a été mise à profit. Vous pouvez voir que le sourcetype est défini lorsque ces fonctions sont appelées, mais aucune autre métadonnée ne l’est. En effet, les autres métadonnées (hôte, heure et source) sont généralement définies au moment de l’acquisition (dans la déclaration de source) et n’ont pas besoin d’être définies (ou remplacées) spécifiquement ici.

Mais qu’en est-il de l’index ? Il est rare qu’on puisse lui appliquer une valeur par défaut. Où pouvons-nous le définir ? À la ligne 66 : c’est celle du parseur qui consulte le fichier splunk_metadata.csv dont nous avons parlé dans la partie 3. Le seul argument passé dans cette fonction est la clé que le développeur attribue (à nouveau, en utilisant la convention fournisseur_produit). De la même façon, les fichiers compliance_meta_by_source.* sont référencés dans l’interpréteur appelé à la ligne 70 et constituent la dernière lookup consultée avant que l’événement ne soit envoyé à une ou plusieurs destinations, comme décrit ci-après.

Destination

Une fois toutes les variables définies (y compris plusieurs champs indexés dérivés du parsage syslog-ng initiale), l’événement est prêt à être envoyé à une ou plusieurs destinations. Ces destinations sont fortement contrôlées par des variables d’environnement, ce qui implique plusieurs constructions de modélisation. Cette section du fichier est illustrée ci-dessous :

La dernière étape de la préparation de l’envoi est le réglage du modèle de sortie, illustré à la ligne 75. Un modèle par défaut approprié (basé en grande partie sur ce qu’attend la TA) est sélectionné. Ces modèles sont tous documentés et sont construits à partir des différentes macros syslog-ng (PROGRAM, MESSAGE, etc.). Cette valeur par défaut peut être remplacée via splunk_metadata.csv si vous le souhaitez.

Enfin, aux lignes 81 à 102, les variables d’environnement sont consultées et les destinations appropriées sont ajoutées au fichier de configuration final. Le chemin de log se termine ensuite par deux indicateurs : l’un indique à syslog-ng de contrôler le flux du trafic TCP si nécessaire (le flux UDP ne peut pas être contrôlé), et l’autre empêche l’événement d’emprunter un autre chemin de log et met fin à toute poursuite du traitement.

Résultat final

Qu’obtenons-nous une fois que le fichier modèle est passé par le moteur de modélisation gomplate ? Voici la sortie après la modélisation de l’exemple ci-dessus, avec les variables suivantes

SC4S_LISTEN_STEALTHBITS_INTERCEPT_TCP_PORT=5015 

SC4S_DEST_GLOBAL_ALTERNATES=d_hec_debug

définies dans le fichier env_file:

Tout d’abord, vous voyez que tout le code gomplate entre accolades a maintenant disparu. Le fichier commence par la déclaration de source (seulement 3 lignes de code "gomplate") qui s’étend maintenant sur plusieurs lignes (11–48) dans la sortie finale. La déclaration de source gère la plupart des métadonnées initiales et la préparation des champs indexés, ainsi que la configuration de la socket d’écoute sur le port TCP 5015 d’après le paramètre du fichier env_file. Les sections de filtrage et de parsage (lignes 50 à 87) traversent le moteur de modélisation en subissant relativement peu de modifications, tandis que la section de destination (qui couvrait plusieurs lignes de code gomplate) se trouve réduite à 3 lignes de code dans la sortie finale (lignes 91-93) et inclut la destination d_hec_debug, encore une fois à cause du paramètre contenu dans env_file.

Résultat final dans Splunk

Voici le résultat final tel qu’il apparaît dans Splunk. Notez que le format de sortie n’est plus JSON (comme c’est le cas avec les événements de "dernier recours") : il s’agit simplement de l’événement d’origine sans l’en-tête (chaîne, hôte et horodatage). C’est ce à quoi s’attendent la plupart des TA.

Conseils de développement

Voici quelques conseils utiles au cours du développement : 

• Assurez-vous de configurer le périphérique source (ou les logs de capture) au format recommandé par le fournisseur et/ou l’auteur de la TA. C’est essentiel avant de commencer tout travail de développement, car cela peut même affecter le parsage initial du protocole syslog. En outre, les paramètres du périphérique source doivent être documentés dans le document de source SC4S correspondant (s’il est adopté comme source prise en charge).
  
  
• Si vous prévoyez d’écrire des chemins de log pour plusieurs sources personnalisées et souhaitez contribuer à la communauté, pensez à utiliser un IDE complet avec la suite pytest fournie sur github. Il est recommandé d’écrire le test avant le code, afin de savoir si votre chemin de log est correct sur le plan fonctionnel et n’a pas d’impact sur le reste de la base de code.
  
  
• Testez votre nouveau chemin de log dès que possible. Après avoir simplement remplacé les chaînes LOCAL_EXAMPLE initiales et créé votre filtre, testez avec quelques événements pour voir s’ils entrent dans le chemin de log et s’ils reçoivent au moins un sourcetype.
  
  
• Pour envoyer un événement brut à sc4s, exécutez cette commande simple sur n’importe quelle machine linux : echo "" > /dev/udp//514
  • Il est essentiel d’avoir l’événement brut : l’intégralité du chemin de log/filtre en dépend. Ne faites pas de suppositions, collectez les événements à partir d’un dispositif réel!
     
• Lorsque le développement n’en est plus qu’à quelques détails, il est souvent utile de lancer une exécution vers le conteneur puis simplement de mettre fin au processus syslog par un HUP pour voir les effets de vos modifications. Dans ce cas (et c’est le seul cas), vous allez éditer les fichiers de conf directement et, une fois satisfait, intégrer les modifications dans les fichiers tmpl. L’exécution vous permet également de voir à quoi ressemblent les chemins de log pris en charge. Vous pouvez copier des éléments très utiles pour vos propres chemins de log : analyseurs de date, analyseurs csv/kv, etc.
  
  
• Si vous êtes sûr d’avoir fait une modification et que rien ne se passe au redémarrage de sc4s, il est quasiment certain que vous avez édité le fichier de configuration directement et non le fichier tmpl. N’oubliez pas que les fichiers de configuration sont éphémères et sont reconstruits à chaque redémarrage.

Nous sommes conscients que ce qui précède n’est qu’un rapide tour d’horizon et que de nombreux détails ont été survolés, en particulier les nuances de la syntaxe de configuration syslog-ng elle-même. La communauté est là pour vous aider à répondre à vos questions ou à relever vos défis de conception ! Bonne chance !

Communauté Splunk Connect for SyslogSplunk 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
• Partie 2 : vue d’ensemble de la configuration de Splunk Connect for Syslog
• Partie 3 : la configuration de Splunk Connect for Syslog dans le détail
• Support 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 !

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
• Partie 2 : Vue d’ensemble de la configuration de Splunk Connect for Syslog
• Partie 3 : La configuration de Splunk Connect for Syslog dans le détail
• Support 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.}