Cette traduction automatique est fournie pour votre commodité.
En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.
L'onglet Data ingestion est situé dans l' UIde gestion des données. L'UI d'ingestion de données affiche un résumé de votre utilisation par source de données. Pour les organisations avec plusieurs comptes, vous pouvez également afficher l'utilisation de comptes spécifiques.
Pour voir la requête NRQL sous-jacente utilisée pour créer ce graphique, cliquez sur View NRQL.
Pour une vidéo montrant une brève visite de cette interface utilisateur d'administration et d'autres, voir Paramètres du compte.
Obtenez plus de détails
Pour obtenir plus de détails sur une source de données spécifique affichée dans le graphique, passez la souris sur la bande dans le graphique et cliquez dessus. Une fenêtre modale s'ouvrira, comme indiqué dans l'image ci-dessous.
Lorsque vous cliquez sur une bande dans le graphique d'ingestion, vous obtenez plus de détails sur ces données.
Pour quelques détails techniques sur la façon dont le graphique affiche les données et le message d'erreur, voir Détails du graphique.
La manière dont vous gérez vos données New Relic dépendra de nombreux facteurs spécifiques à votre organisation et à vos besoins. Cela dit, voici quelques conseils généraux pour gérer l’ingestion de données et éviter les pics inattendus :
Assign team members. Désignez des membres de l'équipe qui seront chargés de vérifier votre ingestion à une cadence donnée et de la gérer. Assurez-vous qu'ils comprennent les facteurs de facturation liés aux données, y compris ce qui est et n'est pas comptabilisé dans la facturation.
Get to know your data. Prenez le temps de vous familiariser avec vos données. Apprenez à connaître ses flux et reflux et à comprendre d’où il vient.
Monitor when you make significant changes. Lorsque vous activez pour la première fois un nouvel outil de reporting de données, ou lorsque vous mettez à niveau un agent ou une intégration, ou lorsque vous apportez une modification importante à votre système, vous devez monitorer votre ingestion pour vous assurer qu'il n'y a pas de pic inattendu de données.
Set up alerts. Si vous êtes préoccupé par des scénarios spécifiques provoquant des pics soudains dans l'ensemble de données, créez une condition d'alerte pour vous avertir si cela se produit. Pour obtenir des conseils à ce sujet, consultez Utilisation requête.
Réduire l'ingestion
Vous trouverez ci-dessous quelques conseils sur les approches courantes adoptées par les clients New Relic pour réduire l'ingestion de données qui ne leur sont pas utiles.
Toutes les solutions New Relic disposent de différentes options de configuration qui vous permettent de contrôler la manière dont les données sont signalées à New Relic. Ci-dessous, nous avons quelques méthodes populaires pour réduire l'ingestion de données, mais pour en savoir plus sur toutes les options disponibles, nous vous recommandons de lire la documentation des outils spécifiques que vous utilisez.
Les options permettant d’ajuster les données incluent :
Configurer le taux d'échantillonnage pour l'événement de transaction. Voir les configurations d'agent pour Java, .Net, Go, NodeJS, PHP, Python ou Ruby.
Les options de réglage de l’ingestion des données log incluent :
Logs automatiques en contexte: Désactivez ou activez via l'UI ou l'API, ou ajustez les paramètres configuration côté client.
Transfert de données de log: un log non filtré peut parfois entraîner le signalement d'une grande quantité de données log . Vous pouvez ajuster log configuration la du redirecteur de pour filtrer les événements de log du logcôté de l'envoi .
Lors de l'ingestion, nous appliquons des règles de suppression des données afin que vous ne soyez pas facturé pour des données inutiles. Mais vous pouvez également définir vos propres règles de suppression des données.
Pour des augmentations inattendues des données du réseaumonitoring , vous pouvez envisager d'ajuster l'intervalle d'interrogation.
Si vous avez des agents ou des intégrations dont vous ne voulez pas du tout, vous pouvez désinstaller/supprimer ces outils. Pour obtenir des instructions, consultez la documentation spécifique à cet outil. Gardez à l’esprit que si vous pensez qu’il y a une chance que vous utilisiez cet outil à l’avenir, le désactiver simplement peut être une meilleure solution que le désinstaller complètement.
Sources d'ingestion de données
Le graphique UId'ingestion de données vous montre une répartition de haut niveau de votre utilisation de données facturables. Le tableau ci-dessous explique ces sources. Dans ce tableau, « groupe métrique d'utilisation » fait référence à la valeur de l'attribut usageMetric de cette source sur l'événement NrConsumption .
les données d'intervalle de temps métrique sont en moyenne par périodes d'une heure après huit jours. Après 90 jours, les données métriques permanentes continuent d'être stockées par périodes d'une heure. Nous stockons actuellement les données métriques brutes pendant 30 jours.
Vous êtes uniquement facturé pour le volume d’ingestion initial. Vous n'êtes pas facturé pour les cumuls ultérieurs.
Ces données sont signalées via les événements SystemSample, NetworkSample et StorageSample .
Le groupe métrique d'utilisation est InfraHostBytes.
Informations relatives à vos serveurs et machines virtuelles provenant des agents d'infrastructure, y compris les données de stockage et de réseau.
Processus d'infrastructure
Ces données sont stockées dans l'événement ProcessSample .
Le groupe métrique d'utilisation est InfraProcessBytes.
Données relatives à chaque processus exécuté sur les hôtes exécutant l'agent d'infrastructure. Cette fonctionnalité est désactivée par défaut. Pour plus d'informations, voir Processus métriques.
Intégration des infrastructures
Groupe métrique d'utilisation : InfraIntegrationBytes.
Données de performances liées aux applications et aux services, généralement gérées par les clients, y compris les données liées au conteneur Docker, aux services Windows, aux contrôles Nagios et à l'intégration cloud tels que les services gérés dans AWS, Azure et GCP.
Inclut le log et toute partition de données personnalisée Log_<value> existante.
Le groupe métrique d'utilisation est LoggingBytes.
Les enregistrements de log sont stockés sur le type de donnéesLogpar défaut. Des partitions de données personnalisées supplémentaires créeront de nouveaux types de données, qui sont toujours préfixés par Log_ et sont comptabilisés comme faisant partie de l'ensemble global des données log stockées.
Avec LogExtendedRecord, les messages de log de plus de 4 Ko sont divisés en plusieurs événements qui, si nécessaire, sont assemblés pour afficher le message d'origine ; cela réduit la taille des données du message. Pour en savoir plus sur la manière dont ces données sont stockées, consultez notre documentation sur les blobs de logs.
Le groupe métrique d'utilisation est CustomEventsBytes.
Événement mobile, y compris l'événement général Mobile, MobileRequestError, MobileBreadcrumb, MobileSession, MobileHandledException, MobileCrash, MobileRequest et MobileJavaScriptError.
Groupe métrique d'utilisation : MobileEventsBytes.
Le groupe métrique d'utilisation est ServerlessBytes.
L'activité de suivi des changements est stockée dans l'espace de nommage Deployment . Les modifications individuelles que vous suivez représentent en moyenne environ 200 à 250 octets par rapport à votre ingestion.
Les événements signalés par la fonctionnalité de sécurité de New Relic sont stockés dans l'espace de nommage Security . Il s'agit principalement de rapports de vulnérabilités fournis par la gestion des vulnérabilités fonctionnalité, mais qui pourront être étendus pour inclure des produits supplémentaires à l'avenir.
Les volumes d'événements attendus de ce type sont très faibles, car les occurrences de rapports de vulnérabilités sont rares.
Les fonctionnalités de sécurité toujours en préversion publique utilisent un espace de nommage Security:Preview distinct et ne sont pas facturables.
Le groupe métrique d'utilisation est SecurityBytes.
Quelques détails techniques sur l'UI d'ingestion :
Displays are estimates. La valeur d'ingestion affichée sur le graphique d'ingestion peut varier légèrement du montant réel que vous pouvez voir lors de l'exécution de votre propre requête. Ceci est dû au fait que le calcul utilisé pour le graphique est une estimation.
No chart data available. Le graphique d'ingestion de données peut afficher une période légèrement plus longue que celle couverte par vos paramètres de conservation des données. Pour cette raison, vous pouvez recevoir un message indiquant qu'aucune donnée graphique n'est disponible.
Chart time buckets. Si un compte possède moins d'un téraoctet de données, nous calculons le volume sur une période de 24 heures ; sinon, nous le calculons sur une période d'une heure.
