Aperçu
Nous travaillons toujours sur cette fonctionnalité, mais nous aimerions que vous l'essayiez !
Cette fonctionnalité est actuellement fournie dans le cadre d'un aperçu conformément à nos politiques de pré-sortie.
Monitorez la santé et les performances de votre collecteur OpenTelemetry grâce à une expérience d'interface utilisateur APM dédiée. Lorsque votre collecteur tombe en panne ou fonctionne mal, cela peut entraîner une interruption des données d'observabilité, une perte définitive de données ou des analyses faussées. C'est pourquoi nous avons créé Collector Observability, une expérience APM adaptée au travail de streaming effectué par les collecteurs. Vous pouvez exploiter la télémétrie interne du collecteur pour voir d'un coup d'œil comment chaque composant de votre collecteur fonctionne, afin de repérer les problèmes avant qu'ils n'impactent votre pipeline d'observabilité.
Configurer le monitoring du collecteur
Facturation
Votre utilisation de Collector Observability est facturable pendant la version préliminaire conformément à votre Commande, selon le modèle de tarification associé à votre Compte et tel que défini ci-dessous.
Les coûts associés à cette fonctionnalité sont déterminés par les facteurs suivants, selon le modèle de tarification associé à votre Compte :
Core Compute: la page Résumé, mesurée en Core CCU, est facturable pendant la version préliminaire. La page Processus n'est pas facturable pendant la preview.
Ingestion de données: Les données supplémentaires issues de la télémétrie interne, mesurées en Go ingérés, sont facturables pendant la version préliminaire.
Si cette fonctionnalité devient disponible de manière générale, votre utilisation sera facturable conformément à votre Commande.
Activer la télémétrie interne pour votre collecteur
Par défaut, le collecteur n'émet pas sa télémétrie interne, vous devez donc d'abord l'activer.
Télécharger le fichier de configuration
$curl 'https://raw.githubusercontent.com/newrelic/nrdot-collector-releases/refs/heads/main/examples/internal-telemetry-config.yaml' \> --silent --output internal-telemetry-config.yamlDéfinir les variables d'environnement
INTERNAL_TELEMETRY_NEW_RELIC_LICENSE_KEY: Clé de licence d'ingestion pour le compte vers lequel la télémétrie interne doit être envoyée. Cette clé peut être différente de la clé que le collecteur utilise pour envoyer des données standard à New Relic, c'est-à-direNEW_RELIC_LICENSE_KEYdans l'exemple ci-dessous.INTERNAL_TELEMETRY_SERVICE_NAME: Par défautotel-collector, détermine le nom de l'entité dans New RelicINTERNAL_TELEMETRY_OTLP_ENDPOINT: Par défaut UShttps://otlp.nr-data.net; si vous êtes dans l'UE, définissez ceci surhttps://otlp.eu01.nr-data.net
Lancer le collecteur avec la configuration fusionnée
En plus de la configuration normale pour les composants et les pipelines (dans l'exemple suivant --config=/etc/nrdot-collector/config.yaml), ajoutez un second argument --config qui fusionnera les deux configurations :
$docker run \> -e INTERNAL_TELEMETRY_NEW_RELIC_LICENSE_KEY='...' \> -e NEW_RELIC_LICENSE_KEY='...' \> -e INTERNAL_TELEMETRY_SERVICE_NAME='demo-collector' \> -v './internal-telemetry-config.yaml:/etc/nrdot-collector/config-internal.yaml' \> newrelic/nrdot-collector:1.10.0 --config=/etc/nrdot-collector/config.yaml \> --config='/etc/nrdot-collector/config-internal.yaml'Important
L'ordre des arguments --config est important si vous avez une configuration préexistante sous le nœud service::telemetry. Le collecteur utilise une stratégie du « dernier arrivé gagne » au niveau du nœud lors de la fusion des configurations et de certaines parties de la config (par ex. les listes, les nœuds feuilles) ne peuvent pas être fusionnés, ils sont donc écrasés par le dernier argument --config.
Alternative (non recommandée pour la production)
Nous ne recommandons pas cette méthode pour des raisons de fiabilité, mais pour les tests, vous pouvez également référencer la configuration directement et le collecteur la récupérera au démarrage :
$docker run \> -e INTERNAL_TELEMETRY_NEW_RELIC_LICENSE_KEY='...' \> -e NEW_RELIC_LICENSE_KEY='...' \> -e INTERNAL_TELEMETRY_SERVICE_NAME='demo-collector' \> newrelic/nrdot-collector:1.10.0 --config=/etc/nrdot-collector/config.yaml \> --config='https://raw.githubusercontent.com/newrelic/nrdot-collector-releases/refs/tags/1.10.0/examples/internal-telemetry-config.yaml'Ajouter un tag d'entité
Le tag newrelic.service.type: otel_collector sert d'activation pour l'expérience au niveau de l'interface utilisateur. Choisissez l'une des options suivantes :
- Option 1: Utilisez l'exemple de configuration fourni ci-dessus qui contient la configuration de l'option 2.
- Option 2: Ajouter l'argument
--config=yaml:service::telemetry::resource::newrelic.service.type: otel_collectorau collecteur. Cela ajoute l'attribut en tant qu'attribut de ressource et New Relic effectue l'étiquetage pour vous lors de l'ingestion. Si vous supprimez cette option, il faudra un jour pour que le tag expire. - Option 3: Ajouter un tag via l'interface APM (en haut de la page, à côté du nom de l'entité). Vous pouvez également le supprimer via l'interface utilisateur pour revenir en arrière.
Personnalisation de la configuration
La configuration par défaut expose des variables d'environnement supplémentaires de la forme INTERNAL_TELEMETRY_... pour ajuster des options courantes telles que les niveaux de détail et l'échantillonnage. Consultez la configuration elle-même pour plus de détails.
Nous vous recommandons d'utiliser la configuration par défaut pour monitorer votre collecteur. Cependant, vous pouvez modifier l'exemple de configuration pour répondre à vos besoins, par exemple en réduisant le niveau de détail, l'échantillonnage ou les taux de collecte de données. Consultez la documentation officielle pour plus de détails. Gardez à l'esprit que les modifications de la configuration peuvent empêcher certaines parties de l'interface utilisateur d'afficher des données. Reportez-vous également aux Limitations. Les options de configuration de la télémétrie interne du collecteur changent à mesure que la communauté OTel évolue. Vous avez un contrôle total sur votre configuration, y compris le choix d'utiliser les valeurs par défaut fournies.
Considérations relatives au surcoût
Comme toute télémétrie, la télémétrie interne du collecteur augmente votre ingestion de données. La surcharge dépend de votre charge de travail et de votre configuration. Voici les facteurs clés à prendre en compte :
Métriques Génère une surcharge constante pour le collecteur et tous les composants actifs, quel que soit le débit. Les métriques sont émises à intervalle constant (60 secondes par défaut). Tout composant peut émettre des métriques personnalisées, comme indiqué par le metadata.yaml respectif, ce qui peut augmenter la surcharge.
Si vous devez réduire le volume de métriques émises par votre collecteur, nous vous recommandons de définir le niveau de métrique sur normal, par ex. via la variable d'environnement INTERNAL_TELEMETRY_METRICS_LEVEL dans l'exemple de configuration, car seul un sous-ensemble des métriques detailed est utilisé par l'interface utilisateur et ce sont généralement des métriques destinées à l'ajustement des performances ou aux problèmes réseau, vous pouvez donc les réactiver au besoin.
Logs A un impact minime lors du fonctionnement normal. Une surcharge plus importante peut survenir lorsque les logs d'erreur augmentent rapidement, mais elle est réduite car les logs sont échantillonnés par défaut. L'algorithme d'échantillonnage autorise un nombre constant de logs par intervalle défini, puis échantillonne à un taux statique. Reportez-vous à service::telemetry::logs::sampling.
Traces Désactivées par défaut en raison de :
- Maturité limitée des traces. Tous les composants ne sont pas instrumentés, voir ce ticket github.
- Surcharge imprévisible variant en fonction de la charge de travail et de la configuration du traitement par lots des agents et collecteurs en amont.
- Aucun algorithme d'échantillonnage adaptatif disponible. Cela rend impossible de fournir une recommandation d'échantillonnage universelle sans risquer d'entraîner des coûts imprévus pour certains cas d'utilisation.
Lorsque les traces seront plus matures, elles fourniront des informations précieuses sur le temps que le collecteur passe à traiter les données au niveau des composants. Pour expérimenter avec les traces en cours de développement, définissez INTERNAL_TELEMETRY_TRACE_LEVEL=info et commencez avec un taux d'échantillonnage faible tel que INTERNAL_TELEMETRY_TRACE_SAMPLE_RATIO=0.001 (0,1 %) tout en monitorant votre volume d'ingestion et en l'ajustant si nécessaire.
Afficher votre collecteur dans l'interface utilisateur
Explorer la télémétrie interne dans l'interface utilisateur APM
Pour consulter la télémétrie interne de votre collecteur, accédez à APM & Services > Services - OpenTelemetry > your_collector_name pour explorer l'entité du collecteur.
Selon les composants utilisés par votre collecteur, certains graphiques peuvent ne pas être alimentés. Par exemple, si vous ne traitez pas les logs dans votre collecteur, les graphiques associés à ce signal seront vides.
Page de résumé
La page Résumé vous donne un aperçu de la santé et des performances de votre collecteur :
- Métriques globales de santé du collecteur
- Graphiques pour le comportement des récepteurs, processeurs, exportateurs et du traitement par lots (nécessite batchprocessor)
- Graphique dédié pour memorylimiter en raison de son mode de défaillance unique
- Relations et métriques d'infrastructure (si configurées, voir les exemples de configuration)
Page des processus
Suivez la consommation de ressources au niveau du système avec la page Processus :
- Utilisation du CPU et tendances
- Utilisation de la mémoire et schémas
- Indicateurs de performance au niveau du processus
Exemples de configuration
Cette section contient des exemples de la façon dont le guide étape par étape ci-dessus s'applique à différents cas d'utilisation impliquant le collecteur.
Collecteur simple avec télémétrie interne activée
Exemple minimal d'un collecteur s'exécutant avec docker compose.
Peupler les relations d'infrastructure (facultatif, expérimental)
Comme indiqué ci-dessus, l'APM peut afficher des métriques d'infrastructure pour l'infrastructure sur laquelle le collecteur s'exécute, mais uniquement si votre infrastructure est instrumentée et qu'une relation peut être établie. La relation est pilotée par des attributs supplémentaires sur la télémétrie interne du collecteur. Vous pouvez en savoir plus sur ce sujet dans notre documentation OTel. Les étapes de configuration dépendent fortement de votre infrastructure exacte. Pour le choix courant de Kubernetes, nous avons créé un exemple qui présente comment obtenir des relations conteneur-service basées sur notre solution OTel pour Kubernetes.
Limites
La télémétrie du Collecteur n'est pas encore stable:
- La version prise en charge de la télémétrie interne est implicitement définie par la version du collecteur principal que nous utilisons pour construire NRDOT ; voir la version de l'otlpreceiver dans le manifeste du nrdot-collector.
- Si la télémétrie émise change au cours de la Public Preview, nous nous réservons le droit de ne prendre en charge que la version la plus récente.
Exigences de format d'exportation: L'interface utilisateur du collecteur attend la télémétrie au format exporté par le
otlpexporter. Il ne prend pas en charge les métriques exportées via Prometheus.Métriques de composants personnalisés: La télémétrie interne qui n'est pas répertoriée dans la documentation sur la télémétrie interne n'est pas encore prise en charge. Les composants personnalisés ou les composants contrib émettent des métriques standard mais peuvent également définir leurs propres métriques. Nous travaillons toujours sur un moyen de vous aider à en tirer des informations sans créer de dashboards personnalisés.
Métriques Golden pour les conteneurs OTel: Pas encore entièrement pris en charge, ce qui signifie que certaines colonnes du panneau d'infrastructure peuvent ne pas être renseignées pour les conteneurs.