Attention à l’écart

Récemment, j’ai publié un tutoriel sur la façon dont j’ai surveillé mon serveur « pihole » basé sur Raspberry-pi en utilisant New Relic et Flex.

Comme beaucoup de tutoriels, ce que vous y lisez est le résultat final, un récit de l’exécution parfaite d’une idée bien conçue où toutes les étapes et variables sont prévues à l’avance.

Ceci, mes amis, n’est pas la façon dont une journée en informatique se déroule généralement.

La vérité est que j’ai eu beaucoup de faux départs et quelques nuits blanches à essayer de tout mettre en place comme je le voulais. Certains aspects du pihole lui-même et de New Relic n’ont pas fonctionné comme je m’y attendais initialement, et j’ai dû trouver des solutions de contournement. Au final, s’il n’y avait pas l’aide de plusieurs collègues – dont Zameer Fouzan, Kav Pather, Haihong Ren,

Avant que vous n’appeliez votre canapé évanoui et que vous sentiez des sels, aussi choqué que je vous sache de m’entendre dire que New Relic n’est pas une pure perfection et une exécution élégante, je veux être clair : bien qu’aucun outil ne soit parfait ou ne fasse tout pour tous personnes, les problèmes que j’ai rencontrés étaient tout à fait normaux et les solutions ultimes étaient à la fois simples à comprendre et faciles à exécuter.

Ce avec quoi j’ai d’abord eu du mal, c’était d’essayer de faire fonctionner New Relic en fonction de mes préjugés sur la façon dont je pensais que les choses devraient fonctionner, plutôt que de comprendre et d’accepter comment elles fonctionnaient.

Le problème en bref

Mais je suis inutilement vague. Permettez-moi d’entrer dans les détails :

Sur le pihole, vous pouvez interroger l’API pour obtenir des données comme celle-ci :
http://pi.hole/admin/api.php?summary

Et cela vous donnera une sortie comme ceci:

{
    "domains_being_blocked": "177,888",
    "dns_queries_today": "41,240",
    "ads_blocked_today": "2,802",
    "ads_percentage_today": "6.8",
    "unique_domains": "8,001",
    "queries_forwarded": "18,912",
    "queries_cached": "19,266",
    "clients_ever_seen": "34",
    "unique_clients": "28",
    "dns_queries_all_types": "41,240",
    "reply_UNKNOWN": "258",
    "reply_NODATA": "1,155",
    "reply_NXDOMAIN": "11,989",
    "reply_CNAME": "12,296",
    "reply_IP": "15,436",
    "reply_DOMAIN": "48",
    "reply_RRNAME": "0",
    "reply_SERVFAIL": "2",
    "reply_REFUSED": "0",
    "reply_NOTIMP": "0",
    "reply_OTHER": "0",
    "reply_DNSSEC": "0",
    "reply_NONE": "0",
    "reply_BLOB": "56",
    "dns_queries_all_replies": "41,240",
    "privacy_level": "0",
    "status": "enabled",
    "gravity_last_updated": {
        "file_exists": true,
        "absolute": 1676309149,
        "relative": {
            "days": 4,
            "hours": 0,
            "minutes": 27
        }
    }
}

Bien que cela ne soit pas immédiatement évident, permettez-moi d’attirer votre attention sur le problème :
"domains_being_blocked":"177,888"

Étant entouré de guillemets, New Relic traitera le nombre « 177 888 » comme une chaîne (texte) plutôt que comme un nombre.

NRQL à la rescousse !

Ma première tentative pour résoudre ce problème a tiré parti de l’approche évidente (et finalement incomplète) consistant à modifier le type d’entrée à l’aide d’une fonction. Dans ce cas numeric() est spécialement conçu pour faire exactement cela – prendre des données « tapées » comme une chaîne et les traiter comme un nombre. Facile, n’est-ce pas ?

Si vous avez travaillé dans l’informatique pendant plus de 15 minutes, vous savez que la réponse est « bien sûr que non ». Cette technique ne fonctionnait que pour les nombres inférieurs à 1 000

La raison en est que numeric() ne peut pas gérer les nombres formatés – c’est-à-dire les chaînes avec des symboles pour la devise, le pourcentage ou – à mon grand regret – les virgules.

À ce moment-là, mon collègue et collègue DevRel Advocate Zameer Fouzan est venu à la rescousse. Il m’a aidé à tirer parti de l’une des nouvelles fonctionnalités de NRQL – la capacité d’analyser les sous-éléments d’un tableau.

La fonction est nommée aparse() qui signifie « analyse d’ancre » Vous pouvez trouver plus d’informations à ce sujet ici, mais en bref, cela vous permet de nommer un champ, de décrire comment vous voulez le séparer, puis de renommer les parties séparées. Comme ça:

aparse(unique_domains ,'*,*' ) As (n1,n2)

En clair, cela dit, « prenez les données dans le champ unique_domains, mettez tout ce qui précède la virgule dans une variable (appelée n1) et tout ce qui suit la virgule dans une autre variable (appelée n2). »

Maintenant j’ai les deux moitiés de mon numéro et je peux les recombiner :

numeric(concat(n1,n2))

Le résultat ressemble à ceci :

Ce qui aurait pu être la fin de mes problèmes, sauf si les chiffres se chiffrent en millions.

Une approche plus flexible

L’avant-dernière étape pour résoudre ce problème consistait à le ramener à la source – dans ce cas, l’intégration de New Relic Flex, pour voir si je ne pouvais pas reformater les chiffres avant de les envoyer dans New Relic. Ce qui est tout à fait possible.

Dans le fichier Flex YAML, il existe de nombreuses possibilités d’analyse, de réorganisation et de reformatage des données avant de les transmettre au magasin de données. L’un des plus puissants d’entre eux est jq. Vous pouvez trouver la documentation de New Relic sur jq ici. Mais pour une plongée plus profonde dans l’utilitaire lui-même, vous devriez aller à la source.

Je ne peux pas décrire comment jq fonctionne mieux que l’auteur:

« Un programme jq est un « filtre »: il prend une entrée et produit une sortie. Il existe de nombreux filtres intégrés pour extraire un champ particulier d’un objet, ou convertir un nombre en une chaîne, ou diverses autres tâches standard. «

En étant un peu plus précis, jq prendra l’entrée JSON, et pour chaque clé qui correspond à vos paramètres de recherche, il affichera la valeur de cette clé et la reformatera dans le processus si vous le lui dites.

Par conséquent, je pourrais créer le filtre de recherche le plus basique comme celui-ci :
jq > .domains_being_blocked

… et il afficherait « 177 888 ». Mais cela ne résoudrait pas mon problème. CEPENDANT, en utilisant des filtres supplémentaires, vous pouvez diviser la sortie par sa virgule, réunir les deux parties, définir la sortie sous forme de nombre et sortir de l’autre côté avec un ensemble de sortie magnifique (et correct).

Mais je ne veux pas que vous pensiez que cette solution m’est venue d’elle-même, ou que j’ai été capable de tout mettre en place avec un minimum d’effort. Tout cela était aussi nouveau pour moi que pour vous, et ce que vous lisez ci-dessous vient de l’esprit incroyable et généreux de Kav Pather (qui a essentiellement inventé l’intégration Flex) et de l’architecte principal des solutions Haihong Ren.

Dérouler la plénitude de la chaîne jq ci-dessous est bien au-delà de la portée de ce blog. Mais Kav et Haihong m’ont aidé à comprendre suffisamment pour le résumer ainsi :

Retirez la clé « status : » et toute la section « gravity_last_updated » et conservez-la telle quelle.
Pour tout le reste,
- diviser la valeur par la virgule
- remonter les éléments constitutifs (sans la virgule)
- le sortir sous la forme d’un nombre plutôt que d’une chaîne
Enfin, affichez tout (status, gravity_last_updated et toutes les autres valeurs) sous la forme d’un bloc de données unique que Flex emballera et enverra à New Relic.

Le fichier YAML complet ressemble à ceci ::

integrations:
  - name: nri-flex
    config:
      name: pihole_test
      apis:
        - name: pihole_test
          url: http://pi.hole/admin/api.php?summary&auth=a11049ddbf38fc1b678f4c4b17b87999a35a1d56617a9e2dcc36f1cc176ab7ce
          jq: >
            .[]|with_entries( select(.key | test("^gravity_last_updated|status|api"))) as $xx | with_entries( select(.key | test("^gravity_last_updated|status|api")|not)) |to_entries|map({(.key):(.value|split(",")|join("")|tonumber)})|add+$xx
          headers:
            accept: application/json
      remove_keys:
        - timestamp

Ce qui donne des données qui ressemblent à ceci :

"domains_being_blocked": 182113
"dns_queries_today": 41258
"ads_blocked_today": 3152
(and so on)

C’est une solution merveilleusement efficace à l’ensemble du problème!

Un résumé, avec un rebondissement

Pour tout résumer :

Nous avons appris à convertir des chaînes en nombres dans NRQL en utilisant numeric().
Nous avons appris à diviser des chaînes dans NRQL en fonction d’un délimiteur (ou même de texte) en utilisant aparse().
Nous avons appris à reconstituer les parties séparées dans NRQL en utilisant concat().
Nous avons appris à utiliser jq dans Flex pour effectuer des manipulations de chaînes et de données assez complexes.
Mais surtout, nous avons appris que demander de l’aide à des collègues n’est pas un signe de faiblesse, c’est un signe de maturité et que, comme l’a dit l’auteur et conférencier Ken Blanchard, « Aucun d’entre nous n’est aussi intelligent que nous tous. »

Mais… après toutes mes recherches, toutes mes questions à mes collègues, tous mes tests et dépannages ; et après toutes les larmes, la rage et la frustration associées – j’ai découvert que je n’en avais pas besoin.

Vous souvenez-vous de ce que j’ai dit au début de ce blog ?

Ce avec quoi j’ai d’abord eu du mal, c’était d’essayer de faire fonctionner New Relic en fonction de mes préjugés sur la façon dont je pensais que les choses devraient fonctionner, plutôt que de comprendre et d’accepter comment elles fonctionnaient.

Dans ma course pour forcer New Relic à faire tout le gros du travail; dans mon besoin égocentrique de forcer New Relic à accepter tout type de données que je lui soumettais, j’ignorais la solution la plus simple et la plus élégante de toutes : Pihole a la possibilité de produire des données brutes et non formatées.

A la place de l’URL standard :
http://pi.hole/admin/api.php?summary

Si à la place j’avais utilisé :
http://pi.hole/admin/api.php?summaryRaw

… tous les chiffres sortent d’une manière que New Relic peut prendre et utiliser sans aucune manipulation supplémentaire.

{
    "domains_being_blocked": 182113,
    "dns_queries_today": 42825,
    "ads_blocked_today": 1846,
    "ads_percentage_today": 4.310566,
    "unique_domains": 9228,
    "queries_forwarded": 25224,
    "queries_cached": 15547,
    "clients_ever_seen": 36,
    (and so on)

Ce qui montre simplement que les solutions à nos problèmes existent, tant que nous avons la patience et la persévérance pour les trouver.

Attention à l’écart – DZone

Leave A Reply Cancel Reply