📡 New Relic – APM, Observability & Infrastructure Monitoring

Qu'est-ce que New Relic ?

New Relic est une plateforme d'observabilité "Full-Stack", fournie en mode SaaS. Son objectif est de collecter, stocker et analyser toutes les données de télémétrie d'une application et de l'infrastructure qui la supporte.

Historiquement, c'était un pur outil d'APM (Application Performance Monitoring), mais il couvre maintenant l'ensemble du spectre de la supervision.

Les 3 Piliers de l'Observabilité (MELT)

L'observabilité repose sur la corrélation de 3 (parfois 4) types de données :

La force de New Relic est de stocker ces 4 types de données dans une base unique (NRDB) et de permettre de les interroger (NRQL).

Ces deux termes sont souvent confondus, mais décrivent deux approches complémentaires.

New Relic est une plateforme SaaS. La collecte des données (Télémétrie) se fait via des Agents (logiciels légers) que vous installez sur vos hôtes ou dans votre application.

[ VOTRE INFRASTRUCTURE ]
  ├─ [ Serveur 1 (Agent Infra) ]
  ├─ [ Serveur 2 (Agent Infra) ]
  ├─ [ App PHP (Agent APM) ]
  ├─ [ App Java (Agent APM) ]
  └─ [ Navigateur User (Agent Browser) ]
            │
            │ (Télémétrie (Metrics, Logs, Traces)
            │  envoyée via HTTPS / TLS)
            ▼
[ NEW RELIC (SaaS) ]
  ├─ [ Data Collector (Ingestion) ]
  │    (Point d'entrée)
  │
  ├─ [ NRDB (Database) ]
  │    (Stockage Time-Series)
  │
  └─ [ New Relic One (UI) ]
       (NRQL, Dashboards, Alerts)

L'APM est le produit phare historique de New Relic. C'est un outil (Couche 7) qui analyse la performance de votre code de l'intérieur.

Objectif : Répondre à la question "Pourquoi cette page est-elle lente ?".

Fonctionnement (Auto-Instrumentation)

L'agent APM (ex: pour PHP, Java, Node.js, Python, .NET) s'attache au runtime de votre application. Il "observe" (instrumente) automatiquement les fonctions clés :

• Frameworks Web (Symfony, Laravel, Spring)
• Appels de Base de Données (MySQL, Postgres)
• Appels Externes (API REST, gRPC)
• Bibliothèques (Redis, Memcached)

Métriques Clés (Dashboard APM)

• Response Time (Temps de réponse) : (ex: 200ms) Le temps moyen d'une transaction.
• Throughput (Débit) : (ex: 1000 rpm) Requêtes par minute.
• Error Rate (Taux d'erreur) : (ex: 0.5%) Pourcentage de requêtes échouées (5xx, Exceptions).
• Apdex Score : (Voir 2.2).

Problème : Dans une architecture Microservices, une requête (ex: "Acheter Produit") ne touche pas 1 serveur, but 5 (Frontend -> API Gateway -> Service Commande -> Service Paiement -> Service Stock).

Distributed Tracing est la solution pour suivre le "trajet" complet de cette requête.

Trace vs. Span

• Trace : L'ensemble du "trajet" (l'ID de la requête globale).
• Span (Étendue) : Une "étape" (une opération) dans ce trajet (ex: l'appel à l'API Paiement).

Flux (W3C Trace Context)

L'agent APM 1 (API Gateway) injecte un en-tête HTTP (traceparent) dans sa requête vers le Service Commande. L'agent APM 2 (Commande) lit cet en-tête et "sait" qu'il fait partie de la même Trace.

Visualisation (Waterfall)

(Trace ID: abc-123. Temps Total: 800ms)

[API Gateway (Span 1 - 800ms)]
   │
   ├─ [Service Auth (Span 2 - 50ms)]
   │
   └─ [Service Commande (Span 3 - 750ms)]
         │
         ├── [DB Query (Span 4 - 300ms)]
         │
         └── [Service Paiement (Span 5 - 400ms)]

(Diagnostic : Le goulot d'étranglement est le Service Paiement)

L'une des causes les plus fréquentes de lenteur applicative est la base de données.

L'agent APM (ex: php_newrelic) instrumente les pilotes de BDD (PDO, MySQLi) pour chronométrer chaque requête.

Rapports Disponibles (APM -> Databases)

• Response Time : Temps moyen de réponse de la BDD.
• Throughput : Requêtes BDD par minute.
• Slowest Queries (Requêtes Lentes) : Le rapport le plus utile. Liste les requêtes (ex: SELECT * ...) qui prennent le plus de temps (ex: > 500ms).
• Problème N+1 : New Relic détecte les "N+1 Query Problems" (ex: une boucle foreach qui exécute 100 requêtes SELECT au lieu d'un seul JOIN).

L'agent APM capture automatiquement toutes les exceptions non gérées (Erreurs 500, Fatal Errors, Exceptions) de votre application.

Error Inbox

Plutôt que de chercher dans des fichiers logs (.log) sur 10 serveurs, New Relic agrège toutes les erreurs dans une interface unique ("Error Inbox").

Il groupe les erreurs similaires et vous montre :

• Le Message de l'exception (ex: NullPointerException).
• La Stack Trace complète (fichier, ligne de code).
• Le Nombre d'Occurrences (ex: "Vu 500 fois dans la dernière heure").
• Logs in Context : Les logs (niveau INFO/DEBUG) qui ont eu lieu juste avant l'exception.

Pour les langages managés (Java, .NET), l'agent APM fournit une visibilité "bas niveau" dans la Machine Virtuelle (VM) elle-même.

Métriques (Exemple JVM - Java)

• Heap Memory (Mémoire de Tas) : Utilisation (ex: 1.5 Go / 2 Go).
• Garbage Collection (GC) : Fréquence et durée des "stop-the-world" (pauses GC). (Une cause majeure de latence).
• Thread Pool : Nombre de threads actifs, bloqués (wait), ou en attente.

Le produit New Relic Infrastructure (NRI) supervise l'Hôte (Host) : le serveur (VM, bare-metal, ou conteneur) sur lequel tourne votre application.

Il utilise l'Agent Infrastructure (un service newrelic-infra) pour collecter les métriques système de base (Couche 3/4).

Métriques Collectées (Exemples)

• Système : Load Average (1, 5, 15 min), Uptime.
• CPU : % Utilisation (Total, User, System, I/O Wait).
• Mémoire : % Utilisation (RAM totale, utilisée, cache).
• Disque : % Utilisation (Espace disque), I/O (opérations/sec).
• Réseau : Trafic (Octets entrants/sortants), Erreurs.
• Processus : Liste des processus (ex: nginx) et leur consommation CPU/RAM.

Logs in Context

L'agent Infra est aussi (souvent) le composant qui collecte et transfère (Forward) les fichiers logs (ex: /var/log/syslog) vers New Relic Log Management.

La force de l'agent Infra est qu'il peut être étendu avec des Intégrations (On-Host Integrations - OHI) pour superviser des services tiers tournant sur le même hôte.

Le monitoring de Kubernetes est une brique essentielle de l'observabilité moderne. New Relic fournit une intégration K8s complète (généralement installée via un Helm Chart).

Composants

• Agent (DaemonSet) : Déploie l'agent Infra sur chaque Nœud (Node) du cluster.
• Intégration API K8s : Récupère les métriques du Control Plane (état des Deployments, Pods...).
• Pixie (eBPF) : (Optionnel, puissant) Utilise eBPF (au niveau Kernel Linux) pour tracer toutes les communications (Réseau, HTTP) entre les Pods, sans avoir besoin d'installer un agent APM dans chaque application (Auto-instrumentation).

Ce qui est monitoré

Permet de voir la performance au niveau de : Nœuds, Pods, Conteneurs, Deployments, Services, et Namespace.

RUM répond à la question : "Comment mes utilisateurs réels (Real Users) perçoivent-ils la performance (côté client) ?"

Fonctionnement (Agent Browser)

L'agent APM (back-end) injecte automatiquement un snippet JavaScript dans le <head> des pages HTML.

Ce JS s'exécute dans le navigateur du client et collecte des métriques (LCP, INP, Erreurs JS) puis les envoie aux Collectors New Relic.

Métriques Clés (Front-End)

• Core Web Vitals : (Voir 4.2) LCP, INP, CLS.
• Temps de chargement de page (Page Load Time) : Décomposé (Network, DOM Processing, Page Rendering).
• Erreurs JavaScript (JS Errors) : Agrégation des erreurs (ex: TypeError: 'null' is not an object) avec stack trace.
• Requêtes AJAX : Suivi des appels fetch() (Temps de réponse, Erreurs).
• Session Traces : (Détaillé) Capture (échantillonnée) de la chronologie complète (waterfall) du chargement d'une page pour un utilisateur lent.

Problème : L'APM et le RUM sont réactifs (ils attendent un utilisateur pour détecter une panne). Que se passe-t-il si votre site tombe à 3h du matin (zéro trafic) ?

Solution : Synthetics. C'est un monitoring proactif (robotisé). New Relic utilise des "minions" (robots) depuis des localisations mondiales (ex: Dublin, Tokyo, Ohio) pour tester votre site 24/7.

(Exemple de script)
1. Aller sur /login
2. Entrer "user@test.com"
3. Entrer "password"
4. Cliquer sur "Connexion"
5. Vérifier que le texte "Tableau de bord" est présent
6. Cliquer sur "Ajouter au Panier"
7. Vérifier que le panier contient "1"

(Si l'étape 5 échoue -> Alerte !)

C'est la solution de Log Aggregation (type ELK/Splunk) de New Relic.

Ingestion (Forwarding)

New Relic peut recevoir des logs de plusieurs façons :

• Agent Infrastructure : L'agent (via config YAML) "tail" (suit) les fichiers (ex: /var/log/nginx/access.log) et envoie les nouvelles lignes.
• Plugins (Fluentd, Logstash) : Vous pouvez configurer vos pipelines de logs existants pour "forwarder" les logs vers l'API d'ingestion New Relic.
• API : Envoyer des logs directement via l'API HTTP.

Logs in Context (La "Magie")

C'est la fonctionnalité la plus puissante. L'agent APM (ex: PHP) enrichit automatiquement les logs (ex: Monolog) en y injectant l'ID de la Trace et du Span actuels.

Log (Standard) :
[2025-11-08] ERROR: Failed to process payment.

Log (Enrichi par New Relic) :
[2025-11-08] ERROR: Failed to process payment.
(TraceID: abc-123, SpanID: def-456)

Résultat : Lorsque vous regardez une Trace APM lente (abc-123), l'interface vous montre automatiquement tous les logs (ERROR, INFO...) qui ont été générés pendant cette transaction spécifique.

NRDB est le "cerveau" de New Relic. C'est une base de données Time-Series (TSDB) massivement parallèle, conçue pour ingérer et requêter des pétaoctets de données de télémétrie en temps réel.

Toutes les données (APM, Infra, RUM, Logs, Synthetics) sont stockées ici.

Types de Données (Data Types)

NRDB stocke 3 types de données (MELT) :

C'est sur ces "Tables" (ex: Transaction) que l'on exécute les requêtes NRQL.

NRQL (prononcé "Nerkel") est le langage (similaire à SQL) utilisé pour interroger la base de données NRDB. C'est l'outil fondamental de l'Observabilité (exploration).

-- Syntaxe: SELECT fonction(attribut) FROM Table WHERE ... SINCE ...

-- Taux d'erreur des transactions (APM)
SELECT percentage(count(*), WHERE error IS true)
FROM Transaction
SINCE 1 day ago

-- 95e percentile du temps de chargement (RUM)
SELECT percentile(duration, 95)
FROM PageView
WHERE appName = 'MonApp-Production'

-- Compter les erreurs 500 par URL (APM)
SELECT count(*)
FROM Transaction
WHERE http.responseCode = '503'
FACET name  -- (FACET = GROUP BY)

-- Graphique du temps de réponse moyen
-- (par minute) des 6 dernières heures
SELECT average(duration)
FROM Transaction
SINCE 6 hours ago
TIMESERIES 1 minute

-- Graphique du CPU (Infra)
SELECT average(cpuPercent)
FROM SystemSample
TIMESERIES AUTO

-- Graphique du LCP (RUM)
SELECT percentile(largestContentfulPaint, 90)
FROM PageViewTiming
TIMESERIES

-- Top 10 des pays avec des erreurs JS (RUM)
SELECT count(*)
FROM JavaScriptError
FACET countryCode
LIMIT 10

-- Taux d'erreur (APM) par Nœud Kubernetes
SELECT percentage(count(*), WHERE error IS true)
FROM Transaction
FACET kubernetes.podName

-- Funnel (Tunnel de conversion)
SELECT funnel(
    session,
    WHERE name = 'Page A' as 'A',
    WHERE name = 'Page B' as 'B',
    WHERE name = 'Page C' as 'C'
)
FROM PageView
SINCE 1 day ago

Les Dashboards (Tableaux de bord) sont la composante Monitoring (les "Inconnus Connus") de New Relic. (Similaire à Grafana).

Un dashboard est une grille de "Widgets" (graphiques), où chaque widget est alimenté par une requête NRQL.

Types de Widgets

• Line Chart (Graphique linéaire) : (Utilise TIMESERIES) ex: CPU au fil du temps.
• Area Chart (Graphique en aires) : (Utilise TIMESERIES)
• Bar Chart (Barres) / Pie Chart (Camembert) : (Utilise FACET) ex: Répartition des erreurs par type.
• Billboard (Panneau) : Affiche un seul chiffre (ex: Taux d'erreur actuel).
• Table : (Utilise FACET) ex: Top 10 des requêtes les plus lentes.

Le système d'alertes de New Relic (Alerts & AI) est la composante "proactive".

Le SLM (gestion du niveau de service) est une fonctionnalité (basée sur NRQL) pour suivre la fiabilité de vos services par rapport à des objectifs business.

New Relic et Datadog sont les deux leaders incontestés de l'Observabilité (SaaS). Ils sont devenus très similaires ("convergence").