Meilleures pratiques pour l' Instana de la journalisation OpenTelemetry
Pour appliquer l'ingestion de journaux généraux pour le collecteur OTEL ( OpenTelemetry ), utilisez les meilleures pratiques suivantes basées sur les capacités et les limitations connues.
Journaux d'application
La valeur d'une plateforme de surveillance et d'analyse des journaux dépend de la qualité des journaux qui y sont ingérés. Par conséquent, la structure des journaux peut fortement influencer l'utilité des messages de journalisation dans le diagnostic des problèmes.
Utilisez une sémantique de journalisation bien définie qui fournit un format cohérent pour les horodatages, les niveaux de journalisation, les codes d'erreur et les informations contextuelles. Cette approche permet de mieux comprendre le comportement des applications et facilite l'analyse des causes profondes.
Les fonctionnalités de journalisation standard peuvent fournir une journalisation structurée. On peut citer, par exemple, divers frameworks de journalisation d' Java s qui utilisent la « Simple Logging Facade » pour l' Java ( SLF4J ) API ainsi que le slog paquet disponible sur Golang qui prend en charge la journalisation structurée en paires clé-valeur.
Enregistrez uniquement les informations essentielles et évitez de générer des journaux excessifs qui n'apportent aucune valeur ajoutée aux applications. Un nombre trop important de journaux peut nuire aux performances, augmenter la pression sur la mémoire et le réseau, et entraîner une conservation et une analyse inutiles des données de journalisation par Instana.
OpenTelemetry Collecte des journaux du collecteur
Avant d'installer et de configurer OTEL Collector, familiarisez-vous avec la documentation suivante sur OTEL Collector fournie par la communauté OTEL :
- Capacités d'enregistrement
- Meilleures pratiques en matière de sécurité
- Vulnérabilités et expositions courantes
Une fois que vous comprenez le journalisation d' OpenTelemetry, familiarisez-vous avec les plug-ins intégrés receiver, processor et exporter. Découvrez également les divers plug-ins tiers pour les récepteurs, les processeurs et les exportateurs. Chaque plug-in dispose de ses propres bonnes pratiques et directives d'utilisation concernant ses capacités et ses limites.
Extraction d'attributs
OTEL Collector prend en charge les attributs de journal généraux qui capturent les informations de base liées aux journaux, telles que log.file.name et log.iostream.
Pour enrichir les contextes de journalisation, ajoutez les attributs Ressource et Enregistrement de journal. Ces attributs appartiennent à l'un des deux contextes suivants :
- Contexte du journal des ressources : contient des métadonnées sur le journal, telles que le
hostname. - Contexte de l'enregistrement du journal : contient des données spécifiques pour chaque entrée du journal, telles que le
log file path.
Utilisez les processeurs de ressources et d'attributs pour ajouter des champs codés en dur. Utilisez le processeur de transformation pour définir des attributs dynamiques avec des valeurs variables grâce à une approche basée sur la configuration.
Si vous n'êtes pas certain qu'il faille ajouter ou modifier certains attributs, évitez de le faire. L'ajout d'attributs inutiles peut augmenter le temps de traitement de chaque message de journal dans OTEL Collector.
Corrélation des messages de journalisation
Instana utilise suffisamment de ressources contextuelles et d'attributs d'enregistrement de journal pour corréler les messages de journal avec leurs entités émettrices, générant ainsi un lien entre les deux. Instana suit une stratégie optimale pour établir la liaison en utilisant les attributs fournis dans la charge utile. Le lien le plus direct utilise l'identifiant de processus (PID) et le lien le moins direct utilise la machine hôte.
Configurez OTEL Collector pour envoyer les données de journalisation directement à l'agent Instana qui s'exécute sur le même hôte que OTEL Collector. Cette configuration définit automatiquement l'hôte de l'agent Instana comme l'hôte sur lequel se trouve l'application surveillée, ce qui fournit le lien le moins direct pour les journaux.
Ne configurez pas les collecteurs OTEL à partir de plusieurs hôtes pour envoyer des journaux au même agent d' Instana. Cela peut entraîner une attribution incorrecte de l'hôte pour les journaux. En conséquence, Instana ne peut pas corréler les messages du journal comme prévu.
Corrélation entre conteneurs et clusters
Les scénarios d'application conteneurisés sont directement pris en charge pour la liaison d'entités pour les attributs d' Kubernetes s capturés par le processeur K8sattributes, tels que container.id. L'attribut container.id est utilisé pour faire correspondre les journaux avec les entités Container qui sont surveillées par les capteurs natifs [ DockerLog et ContainerD d' Instana. De même, k8s.pod.uid l'attribut est utilisé pour relier les journaux aux entités de pod d' Kubernetes s correspondantes qui sont enregistrées par le capteur Kubernetes. La capture du PID n'est pas utile dans les applications conteneurisées. Chaque conteneur dispose de son propre espace de noms PID, et dans cet espace, les processus se voient attribuer des PID commençant à 1. En conséquence, container.id fournit le lien le plus direct pour les applications conteneurisées.
Pour plus d'informations sur les environnements en cluster, consultez la documentation sur la surveillance des clusters.
Instana prend en charge les champs de corrélation de conteneurs ou de clusters suivants qui peuvent être capturés en tant qu'attributs :
container.idk8s.pod.uidk8s.job.uidk8s.cronjob.uidk8s.node.uidservice.instance.id
Pour les déploiements d' AWS, les attributs suivants peuvent être capturés :
aws.ecs.container.arnfaas.id
Exportation des données du journal
Un exemple de charge utile de journalisation OTEL est disponible dans la documentation officielle OTEL, où les attributs sont divisés en deux catégories distinctes : les attributs de ressource et les attributs d'enregistrement de journal. Pour plus d'informations, consultez la section Extraction d'attributs.
Les charges utiles de ce type sont générées par les HTTP exportateurs gRPC et. L'agent Instana et le backend Instana ( OTLP -Acceptor) prennent en charge ces types d'entrée via les exportateurs otlphttp et otlp. L'envoi direct des journaux à l'agent Instana améliore la prise en charge de la corrélation des messages de journal avec leurs entités émettrices, telles que les conteneurs, les pods et les hôtes. Pour plus d'informations, consultez la section Corrélation entre conteneurs et clusters.
Filtrage des charges utiles des journaux
En raison de la nature même de la génération des journaux d'application, les applications peuvent accidentellement exposer des données sensibles d'identification personnelle (PII) dans les journaux, telles que les numéros de carte de crédit et les identifiants. Pour éviter d'inclure des informations sensibles dans les charges utiles de journalisation envoyées à Instana, utilisez le processeur de filtre. Le fait de placer ce processeur au début de la configuration du pipeline de journalisation OTEL empêche les autres processeurs du pipeline de traiter inutilement les messages de journalisation qui sont supprimés et n'atteignent jamais l' Instana e.
Regroupement des messages de journalisation
Le processeur par lots met en file d'attente les messages du journal et les envoie en masse à Instana. Utilisez le processeur par lots pour réduire la charge réseau en diminuant le nombre de connexions sortantes nécessaires à la transmission des données et pour améliorer la compression des données sortantes. Placez ce processeur à la fin du pipeline du processeur de journalisation. Ce placement permet de garantir que les processeurs qui traitent le contenu des enregistrements de journaux, le filtrage ou les opérations d'échantillonnage interviennent avant la construction de la charge utile du lot.
Les performances des processeurs par lots dépendent de la taille des lots configurée. Si la taille du lot est trop faible, cela augmente le nombre de requêtes sortantes et alourdit le trafic réseau. À l'inverse, si la taille du lot est trop importante, cela augmente la pression sur la mémoire et augmente le risque d'erreurs de mémoire insuffisante (OOM).
Choisissez des valeurs pour send_batch_size (par exemple, 5000) et send_batch_max_size (par exemple, 10000) qui sont suffisamment éloignées les unes des autres. Cela augmente la probabilité que, si des lignes correspondantes de traces d'exception sont ajoutées à un fichier journal, elles soient toutes ajoutées au même lot avant son envoi. Si les lignes de journal provenant d'une trace de pile d'exceptions sont ajoutées à différents lots (ou même envoyées individuellement, sans aucun regroupement), elles peuvent ne pas apparaître dans leur ordre d'origine dans Unbounded Analytics.
Choisissez une timeout valeur pour le lot qui permet aux lots de s'étendre dans les conditions normales, send_batch_size tout en garantissant que les messages du journal sont envoyés dans les délais nécessaires à votre cas d'utilisation, même lorsque le flux de données est inférieur à la normale.
Pour plus d'informations sur la configuration batch du processeur, consultez le collecteur OpenTelemetry.
Les configurations par défaut du processeur par lots fonctionnent bien dans de nombreux scénarios côté client. Cependant, il est recommandé de se familiariser avec les options de configuration afin de prendre en compte les impacts spécifiques à chaque scénario en termes d'utilisation de la mémoire et du réseau, en particulier pour les scénarios à haut débit. Vous pouvez également utiliser le plug-in exporterhelper pour optimiser les performances de vos exportateurs.
Réduire la capture inutile de journaux
Si votre application génère des journaux redondants ou de faible valeur et les envoie à Instana, utilisez le processeur de filtrage pour les supprimer avant qu'ils n'atteignent Instana. Vous pouvez supprimer complètement des catégories entières de journaux ou utiliser le processeur probabilisticsampler pour capturer un échantillon des journaux générés. Cette action réduit la charge réseau, améliore la qualité des journaux ingérés en réduisant le bruit et permet de réaliser des économies sur les coûts de traitement et de stockage.
Compression des données
Envisagez la compression de la charge utile en fonction de votre scénario de collecte des journaux. Tous les scénarios de collecte de journaux ne tirent pas nécessairement profit des taux et ratios de compression.
Si votre collecteur OTEL est limité par le CPU (le CPU est le facteur limitant, tandis que le disque, la mémoire et le réseau sont variables) et fonctionne sur un réseau rapide, désactivez la compression des données pour améliorer les performances. Dans de tels cas, la compression n'offre que des avantages limités. Pour les réseaux plus lents, activez la compression afin de réduire la quantité de données à transmettre. Des lots de journaux plus petits réduisent les chances pour les algorithmes de compression d'identifier des modèles. En conséquence, les taux de compression diminuent par rapport aux charges utiles de lots plus importants et augmentent l'utilisation du processeur, car l'algorithme de compression travaille plus dur mais trouve moins de structures compressibles.
Le taux de compression dépend de l'entropie des données du journal, qui est une mesure de la quantité d'informations ou du caractère aléatoire des données. Par conséquent, les journaux présentant une « entropie plus faible » comportent davantage de répétitions et permettent une meilleure compression. Les journaux présentant une « entropie plus élevée » comportent moins de modèles et permettent une compression moins efficace.
Pour plus d'informations sur les options de compression, consultez HTTP payload compression et gRPC payload compression en fonction de la méthode de transmission de données préférée.
gzip de compression pour l'envoi de charges utiles OTEL à Instana.Chiffrement des données
Activez toujours le chiffrement dans les environnements de production. Si OTEL Collector envoie des données à un agent d' Instana local, procédez comme suit pour activer les communications cryptées TLS entre l'agent d' Instana et le backend.
Utilisation de la mémoire
Le processeur de limitation de mémoire définit les limites d'utilisation de la mémoire pour le collecteur OTEL. Suivez les meilleures pratiques et veillez à ajouter ce processeur en tant que premier processeur dans le pipeline. De plus, n'utilisez pas ce processeur pour remplacer le dimensionnement et la configuration appropriés de l'empreinte mémoire du collecteur OTEL.