Nous avons ajouté de nouvelles méthodes d'analyse et de transformation de vos données !

Nous sommes ravis d'annoncer aujourd'hui l'arrivée de quelques fonctions d'analyse et de transformation qui vous aideront à trouver plus facilement les données dont vous avez besoin lors des requêtes. Vous pourrez ainsi créer des dashboards et des alertes plus rapidement, même avec des données non structurées. 

Il faut bien l'avouer, les données ne sont pas toujours très belles à voir. La manière dont elles sont stockées empêche souvent leur utilisation immédiate, ce qui signifie que l'horodatage, un guid d'entité ou un identifiant de magasin peut être caché au plus profond d'un dataset. L'une des méthodes de résolution de ce problème consiste à nettoyer les données avant leur ingestion, mais les équipes qui traitent et analysent ces données (les DevOps, par exemple) ne sont pas toujours responsables de la manière dont elles sont arrivées là. C'est pourquoi nous vous simplifions la vie. Nous avons ajouté les fonctions suivantes au langage de requête New Relic (NRQL). Et toute personne ayant accès à New Relic peut les utiliser :

• Analyse du code JSON au moment de la requête : jparse(), mapKeys(), mapValues()
• Conversion de l'horodatage : toTimestamp(), toDatetime()
• Mappage des adresses IP : cidrAddress()
• Encodage et décodage de Base64 : encode(), decode()
• Conversion d'une unité à une autre : convert()

Voir les procédures détaillées et des exemples de chacune de ses fonctions.

Analyse du code JSON au moment de la requête

Les données se présentent sous de nombreux formats, et l'un des plus courants est JSON. Pour analyser/parser ces données, vous devez généralement utiliser une formule d'extraction compliquée pour les expressions régulières (regex) ou les ancrages, ce qui n'est pas drôle du tout. Désormais, avec jparse(), un parseur est adapté spécifiquement à ce type de données :

jparse(attribute, [chemin])

Supposons que nous ayons un message de log contenant du code JSON après le texte « Order responses: », comme dans l'exemple suivant : 

Order response: {"timestamp":1709938901291,"status":500...

Nous pouvons tout d’abord utiliser anchor parse pour retirer le code JSON, puis utiliser la fonction jparse() pour extraire les champs souhaités :

WITH aparse(message, 'Order response: *') AS json

FROM Log 

SELECT  jparse(json, 'timestamp'), jparse(json, 'status'), message

WHERE message LIKE 'Order response: {%'

Vous pouvez voir que l'extraction de l'horodatage et du code d'état du code JSON est beaucoup plus simple avec cette nouvelle fonctionnalité.

Il existe deux fonctions supplémentaires qui fonctionnent bien avec l'analyse du code JSON et que nous avons également publiées récemment :

• mapKeys() extrait une liste de toutes les clés lorsqu'une carte est transmise en tant qu'entrée. 
  • Dans l'exemple ci-dessus, il s'agit de ['timestamp', 'status', etc.]
• mapValues() extrait une liste de toutes les valeurs lorsqu'une carte est fournie en tant qu'entrée/input.
  •  ['1709938901291', '500', etc.]

Pour en savoir plus, consultez la documentation de chacune de ces fonctions ici : jparse(), mapKeys(), mapValues()

Conversion de l'horodatage

Supposons que vous ayez analysé un horodatage de votre code JSON (finalement), mais que vous disposiez maintenant d'une heure Unix (ou Epoch time) « 1709938901291 » qui n'est pas lisible. L'inverse peut également se produire : vous extrayez une date sous la forme d'une chaîne de caractères, comme « 08 mars 2024 23:01:41 », et vous n'avez aucun moyen de comparer cet horodatage à d'autres horodatages.

Pour résoudre ce problème, utilisez les nouvelles fonctions de conversion de l'horodatage pour le formater comme bon vous semble.

toTimestamp(datestring [, pattern [, timezone]])

toTimestamp() - également connu sous le nom de fromDateTime() - prend une chaîne datetime et la traduit en un horodatage représenté en temps Unix millisecondes. 

Exemple : 

FROM Log
SELECT toTimestamp('2023-10-18 15:27', 'yyyy-MM-dd HH:mm', timezone: 'America/Los_Angeles') 

Cela donne l'heure Unix : 1697668020000.

Remarque : l'interface utilisateur de New Relic traduit cela en une date lisible.

toDatetime(timestamp [, pattern [, timezone]])

toDatetime() – également connu sous le nom fromTimestamp() – prend l'horodatage au format numérique et le traduit en une chaîne datetime de votre choix. Notez que le format par défaut est : aaaa-MM-jj'T'HH:mm:ss[.SSS][XXX].

Une valeur de fuseau horaire facultative peut être utilisée pour interpréter le paramètre de chaîne de date.

Exemple : 

FROM Log

SELECT toDatetime(1697668020000, 'yyyy-MM-dd HH:mm', timezone: 'America/Los_Angeles')

La requête ci-dessus renvoie « 2023-10-18 15:27 ». 

Pour en savoir plus, consultez la documentation de chacune de ces fonctions ici : toTimestamp(), toDatetime().

Mappage des adresses IP

Les adresses IP peuvent être un point de données crucial dans votre système, et leur regroupement par réseau de base vous permet d'avoir une vue d'ensemble de la provenance des données. Jusqu'à présent, la conversion d'une adresse IP vers son réseau de base était très compliquée, mais avec cidrAddress ce problème est désormais résolu :

cidrAddress(<attribute>[, <number> [ ,cidrFormat:true|false]])

cidrAddress() prend une adresse IP CIDR et génère l'adresse réseau de base correspondante. L'attribut peut être une adresse IP seule ou avec une longueur de préfixe en notation CIDR. Le nombre représente la longueur du préfixe et si l'attribut est en notation CIDR, il est prioritaire sur la longueur du préfixe fournie par la chaîne CIDR.

Supposons que nous ayons un message de log avec une adresse IP et un port intégrés dans le message :

...{id:"etcd-events-a" endpoints:"172.20.44.143:3997" }...

Nous utilisons à nouveau l'analyse d'ancrage pour extraire l'adresse IP, puis en utilisant notre nouvelle fonction, nous pouvons trouver son adresse de base.

WITH aparse(message, '%endpoints:"*:*"%') AS (IP, Port)

FROM Log SELECT  count(*) 

FACET cidrAddress(IP, 24)

WHERE message LIKE '%etcdClusterPeerInfo%'

Pour en savoir plus, consultez la documentation de cette fonction ici : cidrAddress()

Codage et décodage Base64

Les données peuvent également arriver au format Base64, ce qui peut entraîner des problèmes si vous ne parvenez pas à les décoder. Pour résoudre ce problème, utilisez encode() et decode() pour reformater vos données quand vous le souhaitez :

encode(input, encoding)

encode() effectue des conversions Base64 sur une chaîne fournie, en suivant la norme Base64 spécifiée dans le deuxième paramètre. encode() prend en charge 'base64', 'base64mime' et 'base64url' comme paramètres d'encodage. encode() n'est pas pris en charge pour les blobs.

Exemple : 

FROM Event SELECT encode('Hello World', 'base64')

La requête ci-dessus renvoie « SGVsbG8gV29ybGQ= ».

decode()

decode() effectue des conversions Base64 sur les chaînes et les blobs, en suivant la norme Base64 spécifiée dans le deuxième paramètre. decode() prend en charge base64, base64mime et base64url comme paramètres de décodage.

Exemple : 

FROM Event SELECT decode(‘SGVsbG8gV29ybGQ=', ‘base64’)

La requête ci-dessus renvoie « Hello World ».

Pour en savoir plus, consultez la documentation de chacune de ces fonctions ici : encode(), decode()

Conversion d'une unité à une autre

C'est aussi simple que cela en a l'air. Si vous avez des données stockées, par exemple en millisecondes, et que vous souhaitez les convertir en secondes, cette fonction est faite pour vous :

convert(attribute, fromUnits, toUnits)

Exemple 1 : 

FROM Transaction 

SELECT  duration, convert(duration, 's', 'ms')

Cette fonction sera particulièrement utile si vos métriques OpenTelemetry (OTel) ont une unité spécifiée, ce qui rend la conversion dynamique.

Exemple 2 : 

FROM FROM Metric

SELECT average(convert(apm.service.transaction.duration, unit, 'ms')) AS 'Response time'

Pour en savoir plus, consultez la documentation de cette fonction ici : convert()

Conclusion

Avec toutes les fonctions d'analyse et de transformation que nous avons ajoutées, vous pouvez mieux comprendre beaucoup plus facilement vos données, peu importe à quel point elles sont cachées ou codées. Des tâches autrefois ardues peuvent désormais être accomplies avec une seule fonction. Nous sommes impatients de voir comment vous utiliserez ces nouvelles fonctions pour mieux visualiser et obtenir des informations détaillées sur vos données.