Résumé

  • New Relic offre un chemin cohérent depuis les agents et les données OpenTelemetry, en passant par NRDB, les conditions d'alerte NRQL, les modèles d'anomalie, la corrélation et les flux de notification. Cela peut remplacer la surveillance manuelle des tableaux de bord et raccourcir les investigations, mais seuls les signaux correctement collectés, nommés, conservés et interrogés peuvent être détectés.
  • La propre documentation de la plateforme identifie les conditions qui compliquent le fonctionnement ordinaire: les requêtes de télémétrie acceptées peuvent encore échouer à la validation ultérieure, les traces échantillonnées peuvent omettre des spans, les données éparses ou tardives peuvent être évaluées de manière incorrecte, la modification d'une condition peut réinitialiser son évaluation et son historique d'anomalie, et les choix de mise en sourdine ou de routage peuvent supprimer l'alerte qu'un opérateur attendait.
  • Les études de cas des clients du fournisseur font état de réductions importantes du volume d'alertes et du temps de résolution, tandis que l'analyse 2026 de New Relic associe les comptes basés sur l'IA à une réduction du bruit et à une clôture plus rapide des incidents. Ce sont des signes crédibles d'une utilisation en production, pas des estimations contrôlées de l'effet qu'un nouveau client obtiendra; la qualité de l'instrumentation, la maturité de l'équipe et la sélection de fonctionnalités avancées restent des facteurs de confusion.
  • Un argumentaire d'achat solide utilise le coût par alerte actionnable: les frais de plateforme et de télémétrie, l'instrumentation, la gouvernance des requêtes, le réglage, le triage, la revue des incidents et le coût de migration divisés par les alertes qui identifient une condition réelle, atteignent le bon propriétaire à temps et soutiennent une action utile. Les défaillances ayant un impact sur le client restent au dénominateur comme des échecs, même si elles n'ont généré aucune alerte.

L'alerte est la fin d'une chaîne, pas le début

La démonstration la plus simple de New Relic commence par un graphique. Un agent applicatif rapporte les temps de réponse et les erreurs; une courbe monte; une condition NRQL franchit un seuil; Slack ou PagerDuty reçoit un message. Il est facile de décrire cette séquence comme une détection automatisée. Il est plus difficile de décrire ce qui a dû rester vrai pour que le message mérite une action.

L'application devait émettre des preuves de la défaillance. Un agent ou un collecteur devait préserver les champs utiles et les transmettre. Les noms de service et autres attributs devaient identifier le bon composant de production. NRDB devait conserver et exposer les enregistrements attendus par la requête. La requête devait représenter un préjudice pour l'utilisateur plutôt qu'un état interne simplement inhabituel. Sa fenêtre d'agrégation et le traitement des données tardives ou absentes devaient correspondre à la source. Un seuil statique ou une ligne de base apprise devait distinguer la variation ordinaire d'un problème. La corrélation devait regrouper les symptômes sans fusionner des défaillances non liées. Un flux de travail devait correspondre à l'incident résultant, et les informations d'identification de destination et la propriété d'astreinte devaient être à jour. Enfin, un ingénieur avait besoin d'un contexte et d'une autorité suffisants pour agir.

New Relic fournit des mécanismes importants à presque chaque étape. Il ne maîtrise pas la vérité à chaque étape. Le code client, les intégrations cloud, les composants OpenTelemetry, la livraison réseau, les outils d'incident tiers et la connaissance humaine des services restent des éléments du système de production. Un signal manqué en amont ne peut pas être récupéré par un meilleur modèle d'alerte en aval. Un seuil correctement détecté ne peut pas réparer une étiquette de routage obsolète. Un résumé d'incident convaincant ne peut pas rendre un service sans propriétaire actionnable.

C'est pourquoi le dénominateur utile n'est pas le nombre d'alertes créées. Ce sont les alertes actionnables: des notifications qui correspondent à une condition réelle nécessitant une attention, arrivent suffisamment tôt pour améliorer le résultat, atteignent un propriétaire approprié, contiennent suffisamment de preuves pour commencer le diagnostic et conduisent à une action justifiée. Cette définition est délibérément exigeante. Elle n'accorde du crédit à l'automatisation que lorsque l'automatisation change le travail.

Elle expose également deux types d'erreurs différents. Une fausse alerte ou une alerte de faible valeur consomme de l'attention sans améliorer le service. Une alerte manquée laisse le préjudice se poursuivre jusqu'à ce qu'un utilisateur, un autre système de surveillance ou un ingénieur le remarque. Le réglage de la sensibilité fait généralement un compromis entre les deux. Augmenter la durée ou le délai peut supprimer le bruit transitoire tout en allongeant le temps de détection. Resserrer une bande d'anomalie peut exposer des déviations plus petites tout en augmentant les notifications. Aucun réglage universel ne peut résoudre cet échange, car le coût d'un échec de paiement manqué est différent du coût d'un bref ralentissement d'une tâche de fond.

New Relic possède la plateforme, pas le modèle de service du client

New Relic est une entreprise d'observabilité bien établie, et non un simple habillage d'alerte. Sondernier rapport annuel en tant que société publiquedécrivait une plateforme combinant métriques, événements, journaux et traces avec des outils analytiques, déclarait un chiffre d'affaires de 925,6 millions de dollars pour l'exercice 2023 et indiquait servir plus de 16 000 clients payants. Le document mentionnait également Datadog et Dynatrace comme concurrents directs en observabilité unifiée et reconnaissait que les grandes organisations pouvaient développer leurs propres capacités. En novembre 2023,Francisco Partners et TPG ont finalisé une acquisition de 6,5 milliards de dollars, après quoi les actions de New Relic ont cessé d'être cotées en bourse.

Le périmètre du produit est large mais reste définissable. New Relic exploite la plateforme de données et d'analyse hébergée, NRDB, NRQL, ses propres agents, les alertes, les tableaux de bord, l'intelligence des incidents et la configuration des notifications. Elle accepte la télémétrie produite par l'écosystème OpenTelemetry, neutre vis-à-vis des fournisseurs, ainsi que d'autres intégrations. OpenTelemetry est un projet de la CNCF avec des API, des SDK, des conventions sémantiques, le protocole OTLP et un Collector; ce n'est pas un produit New Relic. PagerDuty, Slack, ServiceNow, Jira, les services cloud et les runbooks des clients restent également des systèmes distincts, même lorsque New Relic leur envoie des données.

Cette distinction est importante lorsqu'il s'agit d'attribuer les succès et les échecs. Si un agent New Relic instrumente automatiquement un framework pris en charge et expose une erreur que l'équipe ne pouvait pas voir auparavant, l'agent et la plateforme méritent un réel crédit. Si un Collector OpenTelemetry abandonne des données parce que sa file d'attente est sous-dimensionnée, l'échec de la détection ne peut pas être attribué uniquement à NRDB. Si New Relic crée un incident mais qu'un secret de webhook expiré empêche la livraison, le calcul d'alerte hébergé a fonctionné alors que le résultat opérationnel a échoué. Les achats doivent néanmoins prendre en compte le résultat, car le client a acheté une capacité de bout en bout, mais l'ingénierie doit localiser précisément la couche défaillante.

La limite juridique et commerciale est également importante. L'engagement de niveau de servicede New Relic pour les contrats Pro et Enterprise éligibles définit la disponibilité comme la capacité à se connecter et à consulter les données clients, vise une disponibilité mensuelle de 99,8 % sur la base d'efforts commercialement raisonnables, et exclut les causes telles que la technologie du client, les services tiers et la transmission sur l'Internet public. Les forfaits Standard et certaines offres basées sur l'utilisation ne bénéficient pas du même engagement. C'est une promesse plus étroite que « chaque alerte importante arrivera correctement et à temps ». Les acheteurs doivent lire leur contrat réel, leur plan de support et leurs accords de notification externes plutôt que de déduire une garantie de résultat d'alerte de la disponibilité de la plateforme.

L'instrumentation décide de ce qui peut être connu

New Relic peut ingérer de la télémétrie à partir de ses agents de langage et d'infrastructure, de composants navigateur et mobiles, d'intégrations cloud, d'API, de Prometheus et d'OpenTelemetry. Cette étendue est précieuse car de nombreux incidents traversent les couches. Un taux d'erreur HTTP en hausse est plus utile lorsqu'il peut être relié à un déploiement, une attente de base de données, un hôte saturé ou une dépendance défaillante. La même étendue crée un travail de gouvernance: plus de sources produisent plus d'attributs, plus de conventions de nommage, plus de coûts et plus de possibilités pour que deux signaux qui semblent comparables signifient des choses différentes.

OpenTelemetry réduit le verrouillage propriétaire de l'instrumentation, mais il ne supprime pas la conception de l'instrumentation. Leguide des ressources OpenTelemetryde New Relic explique que les attributs de ressource sont utilisés pour synthétiser des entités, avecservice.nameobligatoire pour un service et des champs tels queservice.instance.idrecommandés pour distinguer les instances. Un nom de service manquant ou instable modifie ce qui apparaît dans l'interface et ce sur quoi une alerte est facettée. Une étiquette d'environnement absente d'un déploiement peut acheminer les données de production vers une requête destinée au pré-production, ou les laisser en dehors des deux.

Même une réponse de transport réussie ne prouve pas que des données utilisables sont arrivées. Ladocumentation du point de terminaison OTLPde New Relic indique que les charges utiles doivent rester inférieures à un mégaoctet, que les exportateurs doivent grouper les données de manière appropriée, activer la compression et réessayer les échecs transitoires, et tenir compte des limites de débit. Plus subtilement, le point de terminaison répond après avoir vérifié l'authentification, la taille de la charge utile et la limite de débit, tandis que la validation du contenu se produit de manière asynchrone. Un statut de réussite peut donc précéder un échec d'ingestion enregistré ultérieurement comme uneNrIntegrationError. Un opérateur qui ne vérifie que la réussite HTTP a validé la livraison à la porte d'entrée, pas la télémétrie interrogeable.

Les agents New Relic introduisent leurs propres choix. Les plafonds d'événements et l'échantillonnage existent pour contrôler la surcharge applicative et de la plateforme. Ladocumentation sur l'échantillonnage des événementsavertit que les données d'événements échantillonnés peuvent ne pas correspondre aux métriques non échantillonnées et que des déconnexions plus longues entraînent davantage d'échantillonnage à partir des données stockées localement. Le tracing distribué utilise un échantillonnage adaptatif dans les configurations courantes; leguide des traces manquantesénumère l'absence d'exportateurs, l'échantillonnage, les limites de spans, les spans tardives, la dérive d'horloge et les autorisations entre comptes parmi les raisons pour lesquelles une trace peut sembler incomplète.

Cela ne rend pas l'observabilité échantillonnée non fiable. L'échantillonnage est souvent le moyen rationnel de contrôler la surcharge et les coûts. Cela signifie que les concepteurs de requêtes doivent savoir quelles preuves sont complètes, lesquelles sont estimées et lesquelles sont sélectionnées. Une alerte de taux d'erreur basée sur une métrique correctement agrégée peut être robuste même si une trace individuelle est absente. Une requête d'investigation qui suppose que chaque transaction échouée a une trace complète ne le peut pas. La capacité sous-jacente de la plateforme est de stocker et d'évaluer les données fournies; la fiabilité du produit inclut la clarté avec laquelle il expose les échecs de collecte; la fiabilité du déploiement dépend de la surveillance de ces échecs par le client et de la conception autour d'eux.

L'instrumentation est aussi un logiciel qui évolue. Les versions d'agents ajoutent la prise en charge de frameworks, modifient les valeurs par défaut et corrigent les défauts. Les conventions sémantiques d'OpenTelemetry évoluent. New Relic note que le passage de l'instrumentation native aux API OpenTelemetry peut produire des noms de spans ou de métriques différents pour des systèmes tels qu'Elasticsearch et RabbitMQ, ce qui peut casser les tableaux de bord et les alertes qui dépendent de noms exacts. Un programme de mise à niveau nécessite donc des tests de contrat de télémétrie: déployer une transaction, une erreur et un appel de dépendance connus; vérifier les attributs attendus et l'association d'entité; et comparer la requête d'alerte avant de promouvoir la nouvelle configuration d'agent ou de collecteur.

Le travail récurrent ne consiste pas seulement à installer un agent. Quelqu'un doit maintenir les versions, inspecter les erreurs des exportateurs et des agents, contrôler les champs sensibles, préserver les règles de nommage, identifier les services non instrumentés, décider de l'échantillonnage et tester la télémétrie après les changements. L'instrumentation automatique peut rendre la première semaine rapide. Elle ne peut pas rendre les trois années suivantes sans propriétaire.

NRQL transforme le jugement opérationnel en conditions exécutables

NRQL est l'une des fonctionnalités les plus puissantes de New Relic car elle permet aux équipes d'exprimer une logique de détection sur un magasin de données commun. Une condition peut surveiller un pourcentage d'erreur, un percentile de latence, une profondeur de file d'attente, le nombre d'un événement métier ou presque tout résultat numérique dérivé de la télémétrie. Le facettage peut appliquer une même condition à de nombreux services, hôtes ou locataires. C'est plus flexible qu'un catalogue d'alarmes d'infrastructure fixes et peut relier le comportement technique à une transaction métier.

La flexibilité transfère la responsabilité dans la conception des requêtes. Une moyenne peut masquer un petit groupe d'utilisateurs gravement affectés. Un percentile peut devenir instable à faible trafic. Un compteur peut chuter parce que la demande a disparu plutôt que parce qu'un service s'est amélioré. Diviser les erreurs par toutes les transactions peut sous-estimer la défaillance si le dénominateur inclut les vérifications de santé. Le facettage par un identifiant de pod éphémère peut créer un flux de signaux de courte durée alors que la véritable unité opérationnelle est le déploiement. Un filtre copié d'un tableau de bord peut omettre un environnement récemment renommé.

Une alerte NRQL n'est pas non plus simplement un graphique qui s'exécute toutes les minutes. Ladocumentation sur les alertes en streamingde New Relic décrit trois méthodes d'agrégation. Le flux d'événements, la valeur par défaut, convient aux données fréquentes et principalement ordonnées. Le minuteur d'événements convient aux données qui arrivent irrégulièrement ou par lots. La cadence utilise l'horloge murale de New Relic et est décrite par l'entreprise comme l'option la plus ancienne et inférieure. Les données sont filtrées, collectées dans une fenêtre d'agrégation, autorisées avec un délai ou un minuteur supplémentaire, réduites à une valeur, puis testées pendant une durée de seuil.

Chaque paramètre modifie le détecteur. Une fenêtre plus longue lisse un pic mais peut masquer une défaillance brève et sévère. Un délai plus long donne à la télémétrie tardive le temps d'arriver, mais prolonge l'intervalle avant une notification. Le minuteur d'événements peut attendre une période calme dans un lot, tandis que le flux d'événements a besoin d'horodatages ultérieurs pour fermer une fenêtre précédente. Si un minuteur est trop court pour des données incohérentes, New Relic avertit que la fenêtre peut être évaluée avant que tous les points n'arrivent et produire une notification incorrecte.

Les fenêtres vides nécessitent une autre décision. Laisser un vide peut réinitialiser le minuteur de durée de seuil. Le remplir avec zéro peut transformer des données manquantes en une santé apparente pour une requête et en un désastre apparent pour une autre. Reporter la dernière valeur peut préserver un échec ou un succès obsolète. La détection de perte de signal aide, mais elle ne s'active qu'après que le signal a existé; une condition activée alors qu'une source est déjà absente ne peut pas découvrir cette absence rétrospectivement. Dans une condition avec facettes, chaque facette est son propre signal, ce qui est puissant jusqu'à ce que des entités éphémères disparaissent dans le cadre d'une mise à l'échelle normale.

Le langage de requête a des limites explicites.LIMITn'est pas compatible avec les alertes NRQL car l'ensemble complet des résultats est évalué. Les sous-requêtes et les jointures de sous-requêtes sont incompatibles avec les alertes en streaming car elles nécessitent plusieurs passages de données. Les limites de compte et de condition sont également importantes: la documentation actuelle indique 4 000 conditions d'alerte par compte, 20 000 facettes par condition NRQL, 300 millions de points de données correspondants par minute et 2,5 milliards d'opérations d'analyse de requête par minute. Les fenêtres glissantes peuvent augmenter considérablement les points correspondants et, sur certains plans de calcul, ajouter des frais de consommation.

Ce sont des plafonds généreux pour de nombreuses organisations, mais l'implication de conception arrive plus tôt que la limite stricte. Une condition facettée sur des milliers de dimensions volatiles est plus difficile à posséder, tester et router qu'une alerte de niveau service délibérément cadrée. La gouvernance des requêtes doit donc se demander non seulement si NRQL accepte l'expression, mais quelle population elle représente, comment son dénominateur se comporte, que se passe-t-il en l'absence de trafic, combien de signaux distincts elle crée et quelle équipe possède chacun d'eux.

La détection d'anomalies apprend de l'historique et en hérite les ambiguïtés

Les seuils statiques sont faciles à expliquer et difficiles à généraliser. Un seuil de latence de cinq secondes peut être intolérable pour le paiement et normal pour un rapport nocturne. Le trafic à midi diffère du trafic à minuit. Les conditions d'anomalie de New Relic y répondent en prédisant la valeur suivante à partir du comportement antérieur et en déclenchant une alerte lorsque les observations restent suffisamment éloignées de la prédiction. La sensibilité est exprimée par la distance par rapport à la valeur prédite, tandis que la direction et la durée contrôlent les écarts qui comptent.

Ladocumentation sur les anomaliesest dûment nuancée. Les nouveaux signaux ont peu d'historique et des prédictions instables. Les signaux cohérents produisent des bandes plus étroites; les signaux irréguliers produisent des bandes plus larges. Le système peut automatiquement déduire la saisonnalité ou utiliser une saisonnalité horaire, quotidienne, hebdomadaire ou aucune. Les modèles mensuels et annuels ne sont pas pris en charge. Un cycle de vente hebdomadaire peut donc être modélisé, tandis qu'un pic de renouvellement annuel ou un lot de fin de mois nécessite une autre conception.

Une anomalie n'est pas la même chose qu'une défaillance nuisible. Une promotion réussie peut produire un pic de trafic inhabituel. Un déploiement qui rend un point de terminaison inefficace uniformément lent peut devenir la nouvelle norme s'il persiste. Une erreur de sécurité ou de paiement à faible volume peut rester à l'intérieur d'une large bande même si chaque occurrence compte. À l'inverse, un lot attendu peut déclencher une alerte si la saisonnalité est incorrecte. Le modèle détecte un écart par rapport au comportement appris; le client décide si le comportement appris est acceptable et si l'écart nécessite une interruption.

La maintenance des conditions crée une frontière de fiabilité particulièrement importante. New Relic indique que la modification d'une requête, d'une méthode d'agrégation, d'une fenêtre, d'un délai, du remplissage des vides, de la direction de l'anomalie, du seuil ou de l'intervalle glissant réinitialise l'évaluation de la condition NRQL. Pour les seuils basés sur la durée, cela crée au moins la période d'attente configurée avant qu'un nouvel événement puisse s'ouvrir. Pour les conditions d'anomalie, tout l'apprentissage est perdu et recommence. Une modification bien intentionnée effectuée avant une version risquée peut donc créer une période aveugle ou instable précisément au moment où la confiance est nécessaire.

Cela fait de la configuration des alertes un actif géré en contrôle des modifications. Les modifications doivent enregistrer la raison, les valeurs précédentes, l'effet attendu et le propriétaire. Une équipe doit prévisualiser le signal historique, appliquer les modifications en dehors des périodes critiques lorsque c'est possible, et exécuter un exercice de défaillance connue après que la condition soit devenue active. Pour les alertes d'anomalie, le propriétaire doit considérer l'intervalle de réapprentissage comme une confiance réduite, l'associer à une garde statique ou synthétique là où le risque le justifie, et éviter les modifications cosmétiques répétées qui réinitialisent le modèle.

New Relic a ajouté la détection des valeurs aberrantes, qui compare les entités avec leurs pairs plutôt que de comparer un signal avec son passé. Cela peut trouver un seul serveur surchargé dans un groupe autrement sain. Songuide sur les valeurs aberrantesfournit également un avertissement précieux: une entité rapportant des horodatages plus anciens peut être exclue de la comparaison. Les remèdes recommandés, diviser les conditions par comportement de rapport ou allonger la fenêtre, font à nouveau un compromis entre la couverture et le délai et la maintenance. Une détection plus sophistiquée n'élimine pas la nécessité de comprendre le temps.

La télémétrie manquante peut sembler saine, cassée ou simplement en retard

La perte de télémétrie est l'une des ambiguïtés les plus dangereuses de la surveillance. L'absence d'événements d'erreur peut signifier que rien n'a échoué, qu'aucune requête n'est arrivée, que le processus a cessé de rapporter, qu'un filtre a exclu les enregistrements ou que le transport a échoué. La réponse correcte dépend de l'absence qui s'est produite.

New Relic expose plusieurs outils pour cela. Les conditions de perte de signal peuvent ouvrir ou fermer un événement d'alerte après un minuteur. Le remplissage des vides peut insérer une valeur statique ou la dernière valeur connue. Les enregistrementsNrIntegrationErrorpeuvent révéler des données mal formées, des limites et des échecs de configuration. L'interface des limites de compte rapporte certains incidents d'ingestion et de requête. Ces contrôles permettent à une équipe de surveiller l'observabilité elle-même, mais ils nécessitent des conditions distinctes et une route indépendante. Une alerte sur les alertes manquantes qui utilise le même chemin de télémétrie défaillant n'est pas une protection complète.

La cardinalité complique le problème. Une série temporelle de métrique est définie par son nom et sa combinaison unique d'attributs. L'ajout de valeurs d'identifiant client, de requête, de conteneur ou non bornées peut multiplier le nombre de séries de façon spectaculaire. New Relic décrit actuellement un budget de cardinalité quotidien de 15 millions par compte et un budget par défaut de 100 000 par métrique, avec des contrôles d'expansion et d'élagage payants. Lorsque les limites sont atteintes, le comportement varie selon la limite; la documentation sur les limites de données indique que certains dépassements de taux de requêtes reçoivent des réponses 429, tandis qu'atteindre une limite de cardinalité de métrique peut désactiver les données agrégées pour le reste du jour UTC, même si les données brutes peuvent encore être stockées.

La cardinalité n'est pas seulement un sujet de coût. Elle modifie les populations d'alertes et les performances des requêtes. Une alerte facettée sur un champ à fort taux de rotation peut créer des milliers de signaux de courte durée, augmenter le travail d'évaluation des alertes et rendre le routage absurde. Élaguer le champ peut contrôler les coûts mais supprimer la dimension nécessaire pour isoler un locataire. La bonne unité est généralement un service, une région, une charge de travail ou un niveau de client opérationnellement possédé, et non l'identifiant le plus facile à attacher.

L'historique de statut 2026 de la plateforme montre pourquoi cette couche doit être mesurée plutôt que supposée. Leflux public d'incidentsde New Relic enregistre des épisodes impliquant des notifications d'alerte retardées ou manquantes, de fausses alertes, de fausses notifications de perte de signal et des irrégularités de télémétrie. Le20 mars 2026, par exemple, l'entreprise a déclaré que certains clients de la région des États-Unis utilisant des intégrations Azure pouvaient avoir reçu des erreurs, des notifications retardées ou manquantes et des données potentiellement irrécupérables. Le18 mai, elle a signalé qu'une interruption d'un fournisseur cloud tiers avait causé des données retardées et des notifications retardées, manquantes ou fausses pour certains clients des États-Unis et de l'UE. Le21 janvier, elle a enregistré plus de quatre heures pendant lesquelles un sous-ensemble de clients américains pouvait subir des notifications en temps réel retardées ou manquantes.

Ces divulgations sont la preuve d'incidents spécifiques, pas d'un taux de défaillance mesuré. Le flux ne divulgue pas le nombre de comptes affectés, toutes les conditions dégradées ou un dénominateur d'évaluations réussies. Il montre également New Relic détectant, communiquant et résolvant les problèmes de service. La conclusion opérationnelle correcte est plus étroite: le fournisseur d'observabilité est lui-même une dépendance cloud distribuée, et les clients ayant un risque sévère ont besoin d'une vérification externe pour son chemin de collecte et de notification.

Cette vérification externe pourrait être un moniteur synthétique léger acheminé indépendamment, une alarme cloud native pour la ressource la plus critique, un battement de cœur d'ingestion observé en dehors de New Relic, ou un signal de parcours utilisateur provenant d'un autre fournisseur. Dupliquer chaque alerte recréerait du bruit et des coûts. Protéger un petit ensemble de chemins existentiels crée un contrôle utile sans reconstruire toute la plateforme.

La corrélation réduit la duplication mais ne peut pas prouver une cause commune

Un incident majeur peut créer une alerte par hôte, service, région et symptôme. Notifier chaque événement séparément transforme une défaillance technique en une défaillance d'attention. L'intelligence des incidents de New Relic regroupe les événements d'alerte en problèmes et peut appliquer des décisions de corrélation intégrées, suggérées ou définies par le client en fonction du temps, des attributs, de la similarité textuelle et des relations entre entités. Elle peut simuler une décision suggérée par rapport aux données récentes avant l'activation.

Cela répond à un besoin réel. Leguide SRE de Googlerecommande que les alertes bruyantes tendent vers une relation un-à-un avec les incidents et avertit que des notifications répétées de faible priorité peuvent faire en sorte que les alertes sérieuses reçoivent moins d'attention. Uneétude industrielle de deux ans portant sur plus de quatre millions d'alertes de Huawei Clouda également constaté des descriptions peu claires, des gravités trompeuses, des stratégies obsolètes, des basculements et des tempêtes collectives; ses ingénieurs devaient encore reconfigurer le blocage, l'agrégation et la corrélation après des changements de services ou de stratégies d'alerte.

Le mécanisme de corrélation de New Relic peut effectuer cette agrégation à l'échelle de la plateforme. Ses décisions documentées incluent le regroupement d'événements provenant du même déploiement Kubernetes, de la même application ou du même moniteur synthétique, ainsi que des règles basées sur la similarité et des relations topologiques. Un délai de grâce allant jusqu'à 20 minutes donne au système le temps de collecter et de corréler l'activité avant la notification. L'avantage est un nombre réduit d'éléments de travail fragmentés et plus de contexte sur une page d'incident unique.

Le compromis est le temps et un possible sur-regroupement. Deux alertes proches dans le temps et la topologie peuvent partager un déploiement, ou représenter des défaillances indépendantes. Des titres similaires peuvent être générés par un modèle commun plutôt que par une cause commune. Un délai de grâce plus long donne à la corrélation plus de preuves tout en différant la première notification. Une règle suffisamment large pour supprimer une tempête peut fusionner un deuxième problème dans un incident dont le propriétaire poursuit déjà la mauvaise hypothèse.

Le produit doit donc être évalué sur la précision et le rappel au niveau des incidents, pas seulement sur le taux de corrélation. La précision demande à quelle fréquence les événements regroupés appartiennent réellement au même problème opérationnel. Le rappel demande combien d'événements d'un même problème ont été regroupés avec succès. Un taux de corrélation élevé seul peut être fabriqué en regroupant de manière agressive. Le résultat pour le client est de savoir si le regroupement réduit le travail en double sans masquer des actions ou des propriétaires distincts.

Les décisions suggérées et les simulations aident, mais elles utilisent des données passées. Les nouvelles architectures, les changements de nom et les incidents composés rares restent en dehors de cet historique. La revue post-incident doit inspecter à la fois les événements qui ont été regroupés et ceux qui ont été exclus. Les décisions nécessitent des propriétaires et des revues d'expiration, tout comme les seuils.

Le routage fait partie de la fiabilité de la détection

Une fois qu'une condition ouvre un événement d'alerte et que la corrélation forme un incident, les flux de travail de New Relic filtrent les événements d'incident et envoient les déclencheurs sélectionnés vers les destinations. Ils peuvent enrichir une notification avec des résultats NRQL et cibler les e-mails, Slack, PagerDuty, ServiceNow, Jira, les webhooks ou d'autres intégrations. Les étiquettes peuvent diriger un service vers son équipe. Les déclencheurs de notification peuvent différer pour l'activation, l'accusé de réception, l'investigation, la clôture, le changement de priorité et les mises à jour ultérieures.

C'est puissant car la détection sans propriétaire n'est qu'un enregistrement. C'est aussi une autre surface de configuration. Un filtre de flux de travail peut ne plus correspondre après un changement de politique ou d'étiquette. Une information d'identification de destination peut expirer. Un destinataire d'e-mail peut ne pas vérifier une adresse. Une charge utile de webhook peut changer. Une requête d'enrichissement peut renvoyer des données vides. Le test de flux de travail de New Relic utilise un incident correspondant existant, donc une configuration sans historique pertinent peut afficher qu'elle n'a trouvé aucune correspondance sans prouver si la future route fonctionnera.

Les règles de mise en sourdine ajoutent un contrôle nécessaire autour de la maintenance et des perturbations connues. Elles s'appliquent vers la fin du cycle de vie de l'alerte: l'évaluation continue et les événements d'alerte existent toujours, mais les notifications peuvent être supprimées. Ladocumentation sur la mise en sourdinedistingue le fait de notifier lorsqu'un problème actif persiste après la fin d'une sourdine et la suppression de cette notification ultérieure. Une sourdine récurrente avec un fuseau horaire, un filtre ou un comportement de fin incorrect peut donc créer un silence qui semble intentionnel dans la configuration mais qui est nuisible en opération.

Les équipes doivent tester la route, pas seulement la condition. Une violation synthétique dans un environnement sûr doit vérifier l'ouverture de la condition, le regroupement des incidents, la correspondance du flux de travail, la livraison à la destination, l'accusé de réception de l'astreinte et la clôture. Les routes critiques nécessitent des vérifications périodiques car l'absence de notifications récentes ne prouve pas un chemin sain. La vérification doit enregistrer le temps de bout en bout plutôt que le seul horodatage d'évaluation de New Relic. La documentation de l'entreprise indique que l'heure de l'événement d'alerte affiché et l'heure de notification initiale peuvent différer jusqu'à trois minutes en raison du traitement des données, avant que les fenêtres, délais, périodes de grâce configurés par le client et la livraison externe ne soient ajoutés.

Les résultats des clients sont encourageants et sélectionnés

New Relic publie des exemples détaillés et nommés d'équipes ayant réduit la charge des alertes. Lecompte client de PicPayindique qu'il a réduit le volume d'incidents de 65 %, le temps moyen de résolution de 30 % et le temps d'arrêt annuel de 51 % après avoir défini des normes d'alerte et centralisé les journaux.Viewpointdit avoir réduit le bruit hebdomadaire des alertes de plus de 3 500 à moins de 600 et économisé 57 % par rapport à sa solution de surveillance précédente.The Access Grouprapporte une réduction de 99 % du bruit des alertes, à environ neuf alertes par jour, et décrit des investigations prenant environ dix minutes après le réglage et la consolidation.

Ces témoignages sont importants. Ils identifient des clients, des charges de travail, des chiffres avant-après et des praticiens. Ils montrent que New Relic peut être intégré dans des opérations de production substantielles et que la rationalisation des alertes peut produire des gains importants. Ils montrent également que le résultat n'a pas été un interrupteur actionné par un modèle d'anomalie. PicPay a défini des normes d'alerte de plateforme et centralisé les journaux. Viewpoint a instrumenté des applications Kubernetes et élargi l'accès entre les fonctions. The Access Group a affiné les alertes, utilisé la mise en sourdine et ajouté de l'instrumentation métier. Le travail organisationnel fait partie du résultat.

Les preuves sont sélectionnées par le fournisseur et manquent de dénominateurs importants. Les pages ne fournissent pas les prix contractuels, les heures d'implémentation d'ingénierie, un groupe témoin apparié, des intervalles de confiance, les incidents échappés, le nombre de faux négatifs ou la part d'amélioration due à New Relic plutôt qu'à la consolidation et à la refonte des processus. Le « bruit des alertes » peut également être défini différemment par chaque client. Une baisse de 3 500 à 600 notifications peut être excellente, mais elle est incomplète sans savoir si les défaillances détectées par les clients ont également diminué.

Lerapport d'impact IA 2026de New Relic offre une vue observationnelle beaucoup plus large. Il indique que l'analyse couvre une utilisation agrégée et anonymisée d'environ 6,6 millions d'utilisateurs actifs en 2025. Les comptes avec IA activée avaient environ 46 % d'alertes bruyantes contre 63 % pour les comptes non activés, un taux de corrélation des incidents environ deux fois plus élevé et un temps moyen de clôture inférieur d'environ 25 %. En mai, les moyennes rapportées étaient de 26,75 minutes et 50,23 minutes respectivement.

L'échelle rend l'association intéressante, mais pas causale. Le rapport regroupe les fonctionnalités génératives, d'apprentissage automatique et déterministes sous l'appellation « New Relic AI ». Il ne publie pas d'assignation aléatoire, le nombre de comptes dans chaque cohorte, les méthodes d'appariement, la complexité des services, la maturité des équipes, la composition des gravités, les conventions de clôture ou les résultats de faux négatifs. Les équipes qui activent les fonctionnalités avancées peuvent également investir davantage dans l'instrumentation et les pratiques de gestion des incidents. Le temps moyen de clôture n'est pas nécessairement le temps de récupération; un incident peut être fermé automatiquement, manuellement ou par politique sans prouver que les utilisateurs ont récupéré.

L'interprétation correcte est que la corrélation intégrée et l'assistance sont des contributeurs plausibles à un effort opérationnel réduit, et que New Relic observe une association durable dans son propre parc. Un acheteur ne doit pas mettre 25 % dans un modèle de retour sur investissement comme une économie garantie. Il doit mesurer localement les mêmes étapes: début du signal, ouverture de l'événement, livraison de la notification, accusé de réception, début de l'investigation, atténuation, récupération du service et clôture de l'incident. Ce n'est qu'alors qu'il pourra déterminer quelles minutes New Relic a supprimées.

Le coût par alerte actionnable révèle où le travail s'est déplacé

Le modèle commercial de New Relic rend visibles le volume de télémétrie et l'accès des utilisateurs. Lesconditions tarifaires publiques actuellesincluent 100 Go d'ingestion mensuelle gratuite, puis facturent les Données Originales à 0,40 $ par Go et Data Plus à 0,60 $ par Go, en plus des frais d'utilisateur et de calcul avancé. Les prix publics peuvent changer et les engagements d'entreprise diffèrent, ces chiffres sont donc des points de référence plutôt que des devis. Data Plus modifie également la rétention et les limites de requêtes, ce qui signifie que le coût est lié à la quantité d'historique qu'une investigation peut examiner.

La facture directe n'est qu'une partie de l'économie des alertes. Une équation mensuelle utile est:

coût par alerte actionnable = (plateforme + ingestion + rétention + calcul + instrumentation + opérations de collecte + gouvernance des requêtes + réglage des alertes + maintenance du routage + triage + revue des incidents + formation + amortissement de la migration) / alertes actionnables

Ce dénominateur ne doit inclure que les alertes qui ont satisfait la règle d'acceptation opérationnelle. Une notification qui a atteint la mauvaise équipe n'est pas actionnable pour cette route. Une alerte correcte arrivée après que les utilisateurs ont déjà signalé la panne n'a pas amélioré la détection, bien qu'elle puisse encore aider au diagnostic. Une notification en double n'est pas une autre unité de valeur. Un événement automatiquement fermé avant examen peut être une preuve utile, mais il ne doit pas être compté comme une action humaine évitée à moins que l'équipe ne vérifie que la suppression était sûre.

Les défaillances manquées nécessitent une métrique complémentaire car elles ne produisent aucun élément dans le dénominateur. Suivez les incidents ayant un impact sur le client détectés en premier par New Relic, par un autre moniteur, par un employé et par les clients. Suivez les incidents couverts qui n'ont produit aucune notification New Relic utile. Calculez ensuite la précision des alertes, la couverture actionnable et la part de premier détecteur en même temps que le coût. Un système d'alerte moins cher qui manque l'incident coûteux n'est pas moins cher.

Le numérateur doit être mesuré à la fois en argent et en temps d'ingénieur. L'instrumentation inclut l'ajout d'attributs de service et métier, le test des mises à niveau et la maintenance des collecteurs. Les opérations de collecte incluent les contrôles de file d'attente, de nouvelle tentative et de cardinalité. La gouvernance des requêtes inclut la révision, le versionnage et la propriété. Le réglage inclut la sensibilité, les fenêtres, la saisonnalité, la gestion des vides et la mise en sourdine. Le triage inclut chaque destinataire qui a regardé une notification, pas seulement le résolveur final. La revue des incidents inclut la réparation de l'alerte après la réparation du service.

La tarification de l'ingestion crée une incitation importante. Plus de télémétrie peut améliorer le diagnostic et la couverture, mais une grande partie peut ne jamais contribuer à une décision utile. L'abandon ou l'échantillonnage agressif permet d'économiser de l'argent mais peut supprimer la trace rare qui explique un incident. L'objectif économique n'est pas le minimum de Go. C'est l'ensemble de preuves le moins coûteux qui préserve la détection et le diagnostic pour les risques convenus. Cela signifie généralement des signaux de niveau de service et métier de haute qualité, des détails sélectifs pour l'investigation, et une rétention explicite par cas d'usage plutôt que de tout collecter indéfiniment.

Les licences et l'accès façonnent également le travail. Donner aux développeurs un contexte direct peut supprimer les transferts, tandis qu'un accès complet coûteux peut concentrer l'investigation dans une petite équipe de plateforme. L'acheteur doit cartographier les capacités dont chaque rôle a réellement besoin, si un accès de base est suffisant, et si un destinataire de notification peut inspecter les preuves liées sans attendre quelqu'un avec une licence ou une permission de compte différente.

Le coût de la migration fait partie du calcul même lorsqu'OpenTelemetry améliore la portabilité. L'instrumentation écrite sur des API ouvertes peut envoyer des données à un autre backend, mais les conditions NRQL, les tableaux de bord, les décisions d'incident, les règles de mise en sourdine, les filtres de flux de travail, les lignes de base historiques et les habitudes d'investigation sont des actifs spécifiques à New Relic. La télémétrie exportée ne traduit pas automatiquement le sens opérationnel qui y est intégré. Une sortie future nécessite une exécution en parallèle, une traduction des règles, une reconversion et la preuve que le remplacement détecte les mêmes défaillances.

Une évaluation sérieuse utilise des défaillances ordinaires et conserve chaque tentative

Une démonstration ne doit pas être le test d'acceptation. L'évaluation doit couvrir des services et déploiements ordinaires répétés, y compris les cas peu glamour qui consomment du temps d'astreinte. Sélectionnez un ensemble de services représentatifs: trafic élevé constant, faible trafic, travail par lots planifié, un service avec mise à l'échelle automatique, une métrique interrogée dans le cloud, un service OpenTelemetry et un service avec agent natif. Définissez le symptôme métier et le propriétaire attendu avant de configurer l'alerte.

Injectez uniquement des défauts autorisés et réversibles dans un exercice de pré-production ou de production contrôlée. Les exemples incluent une augmentation connue du taux d'erreur, de la latence ajoutée à une dépendance de test, un exportateur de télémétrie arrêté, un lot retardé, un déploiement qui change un nom de service, un webhook de test expiré et une terminaison attendue de mise à l'échelle automatique. Incluez des événements normaux mais inhabituels tels qu'une promotion de trafic et une maintenance planifiée. L'objectif n'est pas de maximiser les détections; c'est de distinguer les changements nuisibles des changements inoffensifs.

Enregistrez chaque cas prévu, y compris ceux qui ne produisent jamais d'événement. Pour chaque répétition, capturez l'heure d'émission de la télémétrie, l'heure interrogeable, l'heure de l'événement d'alerte, l'heure de l'incident, la livraison de la notification, l'accusé de réception, l'arrivée au bon propriétaire, le diagnostic, l'atténuation et la récupération du service. Classez le résultat comme vrai actionnable, vrai mais tardif, en double, mauvais propriétaire, non actionnable, faux, manqué ou non résolu. Conservez les premières tentatives; ne transformez pas une notification manquée en réussite parce qu'une condition a été modifiée et le test réexécuté.

Exécutez suffisamment de répétitions pour couvrir les changements de routine: une mise à niveau d'agent, un déploiement, une limite de cycle de trafic, un week-end, un redémarrage de collecteur et une modification de condition. Les conditions d'anomalie ont besoin de temps pour apprendre, donc le test doit comparer les périodes froides et matures. Répétez avec une télémétrie retardée ou partiellement absente. Pour la corrélation, créez une défaillance avec plusieurs symptômes et deux défaillances simultanées non liées; mesurez à la fois le regroupement et la fusion nuisible. Pour le routage, testez l'accusé de réception et les mises à jour de clôture ainsi que l'activation initiale.

Comparez avec un substitut réel. Cela peut être la plateforme précédente, une alarme cloud native, une route Prometheus et Alertmanager, ou un processus manuel de tableau de bord. Maintenez le service et le défaut constants. Comparez la détection de bout en bout, le contexte utile, les minutes d'ingénieur, les cas manqués et le coût mensuel. Une page d'incident soignée n'a de valeur que si elle améliore l'un de ces résultats.

Le tableau de bord opérationnel doit continuer après l'achat. Les mesures utiles incluent le taux d'alertes actionnables; le rappel des incidents couverts; le taux de détection en premier par le client; les notifications en double par incident; le taux de mauvais propriétaire; le temps de notification médian et extrême; les minutes d'ingénieur médianes jusqu'au diagnostic; les alertes sans propriétaire ni runbook; les conditions non révisées depuis six mois; les conditions d'anomalie récemment réinitialisées; le taux d'erreur de télémétrie; les événements de limite de cardinalité; et le coût par alerte actionnable par service. Un score global unique masquera les services qui ont besoin de réparation.

Les alternatives clarifient ce pour quoi New Relic est payé

New Relic est en concurrence avec des plateformes commerciales intégrées telles que Datadog, Dynatrace, Splunk Observability et Elastic, ainsi qu'avec des services cloud natifs et des composants open source. La comparaison pertinente n'est pas un inventaire de fonctionnalités. C'est qui exploite le magasin de données, les intégrations, les mises à niveau, la mise à l'échelle, le système de requêtes, l'évaluation des alertes, la corrélation et le support, et combien de contexte parvient à un ingénieur.

Prometheus sépare l'évaluation des alertes d'Alertmanager, qui regroupe, route, inhibe et met en sourdine les alertes. Grafana peut fournir des tableaux de bord et des alertes à travers les sources de données; Loki et Tempo couvrent les journaux et les traces; OpenTelemetry peut standardiser la collecte. Cette pile peut être efficace, transparente et portable. Elle laisse également le client responsable de la capacité, de la haute disponibilité, de la rétention, des mises à niveau, de la corrélation entre signaux et des interfaces entre les composants, à moins qu'un fournisseur géré ne les prenne en charge.

Les alarmes cloud natives peuvent être plus simples pour une charge de travail concentrée dans AWS, Azure ou Google Cloud. Elles peuvent voir les métriques de la plateforme sans autre agent et fournir une solution de repli indépendante. Elles deviennent moins cohérentes à travers plusieurs clouds, applications et événements métier. Un traqueur d'erreurs spécialisé peut surpasser une plateforme large pour les flux de travail d'exception des développeurs, tout en laissant les preuves d'infrastructure et de niveau de service ailleurs.

L'architecture rationnelle peut être hybride. Utilisez New Relic pour une analyse large des applications et inter-pile, OpenTelemetry là où la portabilité et le contrôle importent, et une alarme indépendante pour quelques chemins critiques. Gardez les vérifications synthétiques de niveau métier séparées des alertes de symptômes internes. Utilisez des métriques locales ou cloud natives lorsque l'exportation de chaque détail à haut volume a peu de valeur incrémentale. L'objectif n'est pas la pureté de l'outil; c'est une détection fiable avec une propriété et un coût compréhensibles.

New Relic est le plus attractif lorsqu'une équipe a suffisamment de services hétérogènes pour qu'une seule couche de données et de requêtes hébergée supprime un véritable travail d'intégration, mais pas si peu de discipline d'observabilité que la plateforme devienne un entrepôt de signaux sans propriétaire. Il est moins convaincant lorsqu'un petit périmètre est bien servi par des alarmes cloud natives, lorsque des contraintes de sortie de données ou de résidence dominent, lorsque l'équipe ne peut pas financer la propriété de l'instrumentation, ou lorsqu'une opération open source existante fournit déjà des résultats fiables à un coût durable.

Quelles preuves changeraient le jugement

La preuve manquante la plus forte est la fiabilité au niveau des conditions sur des tâches répétées et divulguées. New Relic pourrait considérablement renforcer son argumentaire en publiant des distributions de précision, de rappel et de temps de détection pour les conditions statiques, d'anomalie et de valeurs aberrantes sur des ensembles de données versionnés, avec les périodes de démarrage à froid, les données tardives, les données manquantes, les changements de saisonnalité et les modifications inclus. Les résultats de corrélation devraient signaler les fusions nuisibles et les groupes manqués, pas seulement la proportion d'événements corrélés.

Les preuves clients seraient plus transférables avec des comptes de conditions avant-après, des dénominateurs d'incidents, la détection en premier par le client, les heures d'ingénierie, les fourchettes contractuelles et d'ingestion, la durée de mise en œuvre, les faux négatifs et les définitions du bruit. Une réduction des notifications est convaincante lorsque la couverture des incidents nuisibles reste stable ou s'améliore. Sans cette mesure, le silence peut être de l'efficacité ou de la cécité.

Les rapports de fiabilité de la plateforme bénéficieraient de proportions de comptes affectés et de taux de succès spécifiques aux composants pour l'ingestion, l'évaluation et la notification. Le flux de statut public est utile, mais il ne peut pas produire un taux de livraison des alertes. Les acheteurs devraient demander leurs propres rapports de service historiques, les engagements de réponse du support et la définition exacte de la disponibilité dans leur contrat.

Pour New Relic AI, un travail de cohorte contrôlé ou soigneusement apparié aiderait à séparer l'effet du produit de la maturité du client. Publiez le nombre de comptes, les critères d'adoption, les contrôles de gravité et d'architecture, les mécanismes de clôture et les intervalles de confiance. Liez le temps moyen de clôture à des horodatages de récupération de service indépendants. Divulguez la fréquence à laquelle les causes racines suggérées ou les requêtes ont été acceptées, corrigées ou ignorées. Ces mesures transformeraient une large association en preuve qu'une équipe pourrait utiliser dans la planification de capacité.

Le jugement deviendrait plus positif si de telles preuves montraient une couverture actionnable élevée, de faibles taux de corrélation nuisible et des réductions durables des minutes d'ingénieur après inclusion du travail d'instrumentation et de réglage. Il deviendrait moins positif si les gains dépendaient de grandes équipes spécialisées, si le réapprentissage des anomalies produisait des périodes aveugles significatives, si les défaillances de routage étaient courantes, ou si le contrôle des coûts supprimait à plusieurs reprises les preuves nécessaires au diagnostic.

Le verdict: achetez le système de détection, budgétez pour ses gardiens

New Relic offre une plateforme d'observabilité techniquement substantielle. Sa couche de données partagée, son NRQL expressif, sa large instrumentation, son évaluation en streaming, sa détection d'anomalies, sa corrélation d'incidents et ses flux de travail peuvent remplacer la surveillance manuelle et les recherches d'outils fragmentés. Des clients nommés rapportent des réductions importantes du bruit et du temps de résolution. La prise en charge d'OpenTelemetry réduit une source importante de verrouillage, et la documentation est inhabituellement franche sur les données tardives, les réinitialisations, les limites et les signaux manquants.

La plateforme ne peut pas décider ce qu'une entreprise considère comme nuisible, garantir que l'instrumentation du client l'exprime, ou maintenir chaque requête et route correctes à mesure que les services changent. Des modèles plus avancés améliorent le mécanisme entre la télémétrie et l'attention; ils ne suppriment pas la nécessité de superviser le mécanisme. Le travail humain récurrent passe de la contemplation des tableaux de bord à la conception des signaux, à la gouvernance des requêtes, à l'examen des exceptions, au test des routes et à la réparation des conditions après les incidents.

Cela peut être un excellent compromis. Quelques heures d'ingénierie disciplinée des alertes peuvent économiser beaucoup plus d'heures de triage en double et réduire le préjudice pour les clients. Cela peut aussi être un mauvais compromis lorsque les équipes ne mesurent que les données ingérées et le nombre de notifications, laissent les conditions s'accumuler sans propriétaires, ou traitent un volume d'alertes plus faible comme une preuve de fiabilité accrue.

New Relic doit donc être acheté et exploité comme un système de détection, pas comme un oracle. Mesurez le chemin complet depuis la preuve émise jusqu'à l'action justifiée. Gardez visibles les défaillances manquées. Attribuez le coût de l'instrumentation et du réglage à l'alerte qui en dépend. Protégez les chemins les plus critiques avec une vérification indépendante. Le nombre décisif n'est pas combien de signaux NRDB peut contenir ou combien d'événements un algorithme peut regrouper. C'est à quelle fréquence le système dit à la bonne personne quelque chose de vrai, assez tôt pour avoir de l'importance, à un coût total inférieur à la défaillance et au travail qu'il prévient.