Problème
Pour nos fonctionnalités , et , il peut y avoir des cas où un compte ou une application envoie de nombreux points de données métriques d'intervalle de temps individuels qui pourraient être mieux gérés en les regroupant. Nous utilisons le terme metric grouping issue ou MGI pour décrire cette situation. Lorsque cela se produit, l'agent envoie des quantités de données inutilement importantes à New Relic, ce qui réduit l'efficacité des graphiques, des tableaux et des rapports New Relic.
Les problèmes de regroupement métrique se produisent le plus souvent avec les transactions Web, en particulier si le nom est basé sur des URL. Ils peuvent également se produire avec d’autres métriques signalées par votre application. Par exemple:
- Si votre application explore Internet et que chaque appel externe est dirigé vers un domaine différent
- Si votre logiciel génère dynamiquement des tables de base de données temporaires chaque fois que vous recevez une demande
- Si vous utilisez une instrumentation personnalisée qui inclut des UUID, des noms d'articles ou des composants uniques similaires
Toute situation dans laquelle une liste potentiellement infinie de métriques peut être créée, plutôt que de regrouper efficacement les métriques (comme avec les contrôleurs, les tables de base de données permanentes ou les services externes spécifiques) peut devenir un problème de regroupement de métriques.
Solution
En comprenant ce qu'est le regroupement métrique et comment des problèmes peuvent survenir, vous pouvez mieux comprendre comment New Relic fonctionne avec votre application pour regrouper efficacement les métriques et aider à éviter que des problèmes de regroupement métrique ne se produisent.
Voici un exemple « avant » et « après » de la manière dont le regroupement métrique peut aider à organiser les transactions, pour vous aider à identifier plus facilement les modèles présentant des problèmes de performances.
Pour éviter que des problèmes de regroupement métrique ne se produisent dans votre application :
- Consultez les notes de sortie de New Relic pour vérifier que vous exécutez la dernière version de l'agent New Relic.
- Si nécessaire, mettez à jour votre agent APM/mobile/navigateur vers la dernière version.
- Attendez quelques minutes, puis regardez les nouvelles données dans l'interface utilisateur de New Relic.
- Vérifiez/demandez
NrIntegrationErrorpour l'événement portant le nomMetricCardinalityNearLimit. La création de ces événements se produit lorsque votre application se rapproche de la limite de cardinalité.
Si le problème persiste, suivez les procédures de votre agent :
Agent | Prévenir les MGI |
|---|---|
Tous les agents | Consultez les informations sur les causes des problèmes de regroupement métrique. |
Navigateur | |
Go | Renommez vos transactions Go. |
Java | |
.NET | Renommer les métriques avec |
Node.js | Renommer les transactions avec Request appel d'API. |
PHP | |
Python | Renommez vos transactions Python avec |
Ruby |
Vous pouvez également modifier et créer des règles de normalisation métrique dans l'interface utilisateur. Pour plus de détails, voir Normalisation métrique.
Cause
Les problèmes de regroupement métrique se produisent lorsque la granularité des noms métriques (le plus souvent des noms Web de transaction) est trop fine, ce qui entraîne des centaines ou des milliers de noms Web de transaction différents pour un petit nombre de chemins de code. Quelques chemins de code majeurs peuvent générer de nombreux chemins d'URL complets différents vers des documents, articles ou pages uniques, etc., et si l'élément unique du chemin d'URL est inclus dans le nom de la transaction, chacun de ces chemins communs aura son propre nom unique.
Pour monitorer et améliorer les performances de vos applications, il est beaucoup plus utile de connaître les performances moyennes d'une fonction (par exemple, l'affichage des articles sur votre site) que la rapidité d'affichage de chaque article individuel. Pour éviter les problèmes de regroupement métrique, New Relic affichera normalement une seule entrée pour cette fonction (par exemple, /article/view/*) sur la page APM Transactions .
Ce regroupement vous donne une bien meilleure idée du temps passé à consulter les articles et vous permet de repérer facilement tout problème de performance lié à la consultation des articles. Si ces statistiques étaient réparties sur des centaines ou des milliers de transactions, il serait extrêmement difficile de détecter des tendances, des régressions ou des améliorations de performances.
Chaque agent APM dispose de méthodes distinctes pour détecter les contrôleurs et le framework. La plupart sont automatiques, mais quelques-unes nécessitent que vous activiez ou désactiviez des options dans un fichier de configuration. Vous pouvez également suivre nos recommandations pour éviter les problèmes de regroupement métrique .