Les pièges du temps dans Splunk : les fuseaux horaires

« Le temps est une chose mystérieuse, puissante, et quand on y touche, dangereuse. »                                  - Albus Dumbledore, JK Rowling

Voici une présentation de quelques comportements parfois déroutants de l’interface graphique de Splunk, relatifs à la gestion du temps (date et heure, horodatage, timestamp, _time). Au temps pour moi, autant en être informé.

Quel format de dates préférez-vous : « JJ/MM/AAAA » ou 
« MM/JJ/AA » ?

Si votre navigateur internet est configuré en français, toute connexion sur un Search Head  Splunk se fera en ajoutant automatiquement fr-FR après l’URL (syntaxe universelle du pays et de la langue). Votre interface Splunk sera donc en français.

Si votre système d’exploitation est en anglais, ou si votre navigateur est configuré en anglais, vous aurez la surprise de voir l’interface de Splunk en anglais américain en-US, ou en anglais britannique en-GB.

De fait, il est assez facile de basculer d’une langue vers l’autre, puisqu’il suffit de modifier cela dans l’URL et de rafraîchir l’interface. Vous pouvez aussi travailler en allemand, en italien, en japonais, en coréen …

Le changement de langue entraîne le changement de format de la date et de l’heure. On parle ici de la colonne « Time » ou « Heure » dans l’affichage des événements, et non pas du champ «_time ».

Voici comment est affiché le 5 septembre 2020 à 09h56 du matin selon différents formats :

en-US  9/5/20 9:56:57.000 AM   

en-GB  05/09/2020 09:56:25.000

fr-FR 05/09/2020 09:56:25,000

Comme vous pouvez le constater, pour l’interface en français ou en anglais britannique, on retrouve
« JJ/MM/AAAA HH:MM:SS » (avec une petite nuance au niveau du point ou d'une virgule entre les secondes et les millièmes de secondes). On appelle aussi ce format le format « européen ».

Quitte à choisir l’anglais dans son interface, autant utiliser le même format qu’en français, et donc opter pour en-GB plutôt que en-US.

Fuseau horaire et affichage de l’heure

Tout utilisateur de l’interface peut modifier dans ses préférences le fuseau horaire depuis lequel il observe les données.

Considérons que les données analysées ont été générées et indexées dans le même fuseau horaire que le Search Head, et que cela correspond aux préférences de l’observateur. On s’attend à ce qu’un événement horodaté présente l’heure exacte dans l’onglet des événements.

Par exemple, une donnée access_combined_wcookie d’un serveur apache commencerait ainsi : 217.132.169.69 - - [14/Sep/2020:16:23:24] …

La colonne « Heure » de l’onglet « Événement » en fr-FR indiquerait alors :

14/09/2020
16:23:24,000

Cependant, si l’utilisateur est sur la côte Est des États-Unis, alors que les données viennent de GMT+1, il a modifié ses préférences en GMT-05:00, soit un décalage de 6h.

L’interface fr-FR présenterait le même événement dans la colonne « Heure » :

14/09/2020
10:23:24,000

Ainsi, si l'on prend l'exemple d'un événement survenu à 16h23 à Paris, l'utilisateur basé à New-York verra que l'événement a eu lieu à 10h23 pour lui. L’affichage reste donc bien cohérent.

J'entends parfois : « Faut-il obliger les utilisateurs à travailler dans le même fuseau horaire que les données ? »

Certes non. Mais il faut les informer de ces décalages horaires pour qu'ils puissent évoquer des événements particuliers avec un utilisateur d’un autre fuseau horaire.

J'entends également : « Cela peut-il perturber l’affichage dans les graphiques ? »

En effet, et certaines précautions sont à prendre.

Quelle différence dans un timechart entre span=1d et span=24h ?

La commande timechart permet de regrouper les données en une série chronologique. On peut forcer la taille des périodes en utilisant l’option span dans la chaîne de recherche.

On peut alors se poser la question du regroupement par périodes de 24 heures plutôt qu’une journée.

Exemple :

index=network | timechart span=24h count 
index=network | timechart span=1d count 

a) Si l’observateur est dans le même fuseau horaire que le serveur Search Head, les deux paramètres donnent exactement le même résultat.

b) Depuis la Colombie, avec un décalage de 7 heures par rapport aux données, span=24h affiche l’heure locale quand il est minuit pour les données (soit ici la veille à 17h00, pour Bogotá).

c) span=1d considère minuit localement, ne montre pas de décalage dans le champ _time mais montre des valeurs différentes puisque décalées.

Selon que vous souhaitiez vous caler sur l’heure des données, ou sur votre fuseau horaire pour la limite de journée, vous utiliserez span=24h, ou span=1d.

Et maintenant ?

Une chose à retenir, c'est que le service Splunk Education se tient à votre disposition pour toute question supplémentaire et vous accompagne tout au long de votre progression dans l’apprentissage de la solution Splunk.

Pour vous entraîner, si vous n’avez pas de générateur de données, vous pouvez utiliser les données du tutoriel Splunk, identiques à celles des formations de base ici.

Et si vous ne maîtrisez pas encore les expressions régulières, indispensables à tout administrateur de Splunk, de nombreux sites indépendants proposent des leçons et des tutoriels :

Pour apprendre : https://regexone.com/

Pour tester : https://regex101.com/

Pour faire des mots croisés en regex : https://regexcrossword.com/

Quant à moi, je vous donne rendez-vous pour le deuxième volet des « Pièges du temps dans Splunk »  qui traitera des modificateurs du temps.