Changer le sourcetype après un Universal Forwarder

Splunk Logo

Bonjour à tous, aujourd’hui, je veux vous parler d’une configuration possible dans une infra Splunk pour changer le sourcetype après un Universal Forwarder. En effet dans une infra Splunk, lorsque vous utilisez un UFW (Universal Forwarder), dans votre fichier Inputs.conf vous devez définir le sourcetype des logs.

Par exemple :

[monitor:///splunk-inputs-dir/PROXY/*/*.log]
disabled = 0
index = proxy
host_segment = 3
sourcetype = editor:proxy

Comme on le voit le sourcetype est affecté pour le dossier surveillé. Et il n’est pas possible de placer des règles pour définir des sourcetypes custom en fonction du host ou du format de la ligne de log par exemple. En lisant sur les forums Splunk, la plupart des postes que j’ai vu disent qu’il faut remplacer l’UFW par un heavy forwarder, sauf… qu’en regardant bien la doc, on a une option pour faire faire le travail à nos indexeur.

En effet, il est possible de jouer avec les fichiers props.conf (et transforms.conf) pour lui faire appliquer un TRANSFORMS sur les logs. Par exemple, le props.conf qui défini vos extractions du champs pour votre sourcetype devrait ressembler à quelques chose comme :

[editor:proxy]
EVAL-bytes = bytes_out+bytes_in
EXTRACT-proxy = ^une méchante regex
TIME_FORMAT = %s%3N
TIME_PREFIX = une autre regex

Dans ce fichier et ce « stanza » vous pouvez rajouter la ligne suivante qui défini une transformation à appliquer sur les logs.

TRANSFORMS-changeproxysourcetypeB = sourcetype_B

Et dans le fichier transforms.conf adjacent au props.conf, vous avez

[sourcetype_B]
REGEX = ^[^\s]+\s[^\s]+(\smwg:)?\s(?!MARK\:)
DEST_KEY = MetaData:Sourcetype
FORMAT = sourcetype::editor:proxy_typeB

Et voilà, déployez la conf et les sources type de vos logs qui matchent la regex ci-dessus. Ils vont se retrouver modifié avec l’autre sourcetype ! L’avantage de passer par un transforms c’est que l’opération est réalisée à « l’index-time » et pas au search-time. Effectivement le champs sourcetype fait partie des champs indexés par défaut à la réception (et pas au moment de la recherche donc). Du coup les recherches sur ces champs vont plus vite déjà. Elles permettent aussi d’avoir des extractions de champs spécifiques en fonction du sourcetype. Bref, tout bénef.

Remarque : Regex avec un negative lookeahead

Je profite de ce petit tuto, pour vous parlez du cas pratique que j’ai eu. En effet, on voulait affecter un sourcetype spécifique à nos log d’administrations pour ce sourcetype (qui sont « vomis » avec le reste des logs). Sauf que dans c’est logs d’administration il n’y avait pas de marqueurs textuel fixe à faire matcher avec une regex (genre admin ou toto). En gros, c’est quasiment le même format qu’un log normal, qui arrivent par le même chemin. Le seul trucs qui changeait c’est la présence d’un marqueur dans les logs normaux (soit 99,9999% des logs) qui n’était pas présent dans le logs d’admin. Alors une option aurait pu être de changer le logs source par défaut pour celui d’admin, et de rechercher ce marqueur pour remetttre le sourcetype ensuite au log (et laisser celui au logs d’administration).

Néanmoins je ne trouvais pas ça élégant et je m’en sortie avec un negative-lookahead en regex qui match « si le marqueurs n’est pas présent ». Dans la regex, le negative lookahead c’est ça :

Changer le sourcetype après un Universal Forwarder - negative lookahead
negative lookahead

Comme vous voyez ça « match » ce qui ne correspond pas à la chaine demandée. Pour les anciens du blog, c’est un truc dont je m’étais déjà servis pour les logs let’s encrypt/certbot et qui a le défaut de ne pas être du tout performant (mais alors pas du tout). Du coup ici je le protège en forçant l’extraction à un endroit fixé à partir du début de la ligne (le ^[^\s]+\s[^\s]+(\smwg:)?\s) ce qui lui évite de chercher le marqueurs sur l’ensemble de la chaine et réduit la complexité à du linéaire.

Conclusion

Et voilà vous savez maintenant comment changer le sourcetype après un Universal Forwarder pour certains logs correspondant à une regex dans votre infra Splunk. Sans déployer un Heavy Forwarder ou vous lancer dans des découpages de logs compliqué à la réception ou l’émission. Comme d’hab avec Splunk, c’est quand même pas si compliqué à faire. J’espère que vous aurez appris 2-3 trucs, moi j’ai documenté ça par là pour ne pas l’oublier, vous me direz dans les commentaires si ça vous a servis. Geekez bien !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.