Filtrage des métriques avec observIQ Distro pour OpenTelemetry Collector

Dans ce didacticiel, nous aborderons le cas d’utilisation courant de la surveillance des métriques de filtrage dans la distribution d’observaIQ du collecteur OpenTelemetry (OTEL). Que les métriques soient jugées inutiles ou qu’elles soient filtrées pour des raisons de sécurité, le processus est assez simple.

Pour notre exemple d’environnement, nous utiliserons MySQL sur Red Hat Enterprise Linux 8. L’exportateur de destination sera Google Cloud Operations, mais le processus est indépendant de l’exportateur. Nous utilisons cet exportateur pour fournir les graphiques visuels montrant la métrique avant et après le filtrage.

Prérequis de l’environnement

Système d’exploitation adapté
observIQ Distro pour OTEL Collector installé
MySQL installé
Configuration de l’utilisateur MySQL avec le moins de privilèges (LPU)
OTEL configuré pour collecter les métriques de MySQL

Ressources

Métriques initiales

Une fois configuré à l’aide du LPU que j’ai créé, les métriques MySQL devraient circuler. Pour nos besoins, nous nous concentrerons sur la métrique spécifique mysql.buffer_pool.limit. Actuellement, notre section config.yaml MySQL ressemble à ceci :

mysql:
    endpoint: localhost:3306
    username: otel
    password: otelPassword
    collection_interval: 60s

Après avoir attendu au moins cinq minutes pour obtenir une bonne quantité de données, les métriques ressembleront à ceci dans l’explorateur de métriques de Google :

Filtration

Maintenant que les métriques circulent, nous pouvons les filtrer. Tout d’abord, discutons des raisons de filtrer cette métrique spécifique. La réponse est simple : ce n’est pas vraiment utile ou important. Ce sera, à moins d’un changement de configuration par le DBA, une ligne plate. Même après un changement de configuration, cela ferait simplement monter ou descendre cette ligne plate.

Pour effectuer le filtrage, nous devons d’abord examiner le fichier de métadonnées du récepteur MySQL. Dans ce fichier, nous trouvons une liste des attributs et des métriques associés à ce récepteur. Si nous allons dans la section des métriques du fichier et trouvons notre métrique de limite de pool, nous apprenons qu’elle ressemble à ceci :

mysql.buffer_pool.limit:
	enabled: true
	description: The configured size of the InnoDB buffer pool.
	unit: By
	sum:
  	value_type: int
  	input_type: string
  	monotonic: false
  	aggregation: cumulative

Cela nous permet de savoir qu’il est activé par défaut, donne une description et quelques autres données importantes sur la métrique. Comme ce sont les valeurs par défaut, nous pouvons en déduire que si nous définissons le enabled paramètre à false, alors il devrait désactiver – alias filtre – cette métrique. Il ne sera pas collecté, et comme il n’est pas collecté, il ne sera pas non plus envoyé à l’exportateur.

Pour y parvenir dans notre fichier de configuration, nous apportons les modifications suivantes :

 mysql:
    endpoint: localhost:3306
    username: otel
    password: otelPassword
    collection_interval: 60s
    metrics:
      mysql.buffer_pool.limit:
        enabled: false

Cela reproduit la structure du fichier de métadonnées, mais avec tout le reste coupé autre que le nombre minimum de lignes nécessaires pour atteindre notre objectif.

Une fois que cela a été modifié et que le collecteur a redémarré, j’attends à nouveau au moins cinq minutes et vérifie l’explorateur de métriques de Google pour voir ce qui a changé :

Comme le montre la capture d’écran, les données ont été envoyées pour la dernière fois à Google à 10h48, et il est maintenant 11h13.

Conclusion

Alors que les informations nécessaires sont situées à quelques endroits différents, le filtrage est très facile à faire. N’oubliez pas que les métadonnées que nous avons examinées fournissent également d’autres informations qui peuvent être utiles pour comprendre vos données.