Node.js-Monitoring und APM
Laden Sie @opentelemetry/auto-instrumentations-node, und Obseria zeigt Traces, Event-Loop-Delay, V8-Heap und Garbage Collection jedes Node.js-Service, verknüpft mit Logs und Infrastruktur.
Warum Node.js mit Obseria überwachen
Ein einziges Require-Flag
Das Paket mit den OpenTelemetry-Autoinstrumentierungen deckt HTTP, Express, Fastify, NestJS, gRPC, Datenbanktreiber und AWS-SDK-Aufrufe über NODE_OPTIONS ab.
Einblick in die Event Loop
Event-Loop-Delay und -Auslastung decken blockierenden Code auf, den CPU-Diagramme allein nicht zeigen.
Zusammenhängende asynchrone Traces
Kontext-Propagation über Promises und async/await hält jeden nachgelagerten Aufruf im richtigen Trace.
Node.js-Frameworks und Bibliotheken, die Obseria überwacht
- Express, Fastify, Koa und Hapi. Routen und Middleware erscheinen als Spans mit Routen-Template und Statuscode.
- NestJS. Controller und Provider werden über die Instrumentierung des zugrunde liegenden HTTP-Frameworks getract.
- HTTP-, fetch- und gRPC-Clients. Ausgehende Aufrufe tragen den W3C-Trace-Kontext zu Services in jeder Sprache.
- Treiber für PostgreSQL, MySQL, MongoDB und Redis. Queries und Befehle werden zu Client-Spans mit Dauer und Ziel.
- Kafka- und AMQP-Clients. Producer und Consumer von kafkajs und amqplib tragen den Trace-Kontext über Queues.
- Logging-Bibliotheken. Logs aus Pino, Winston und Bunyan werden um Trace- und Span-IDs ergänzt.
Die Node.js-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Tempo der Antworten
Zeigt, wie schnell Ihre Node.js-Dienste Nutzern antworten, das direkteste Maß dafür, wie sich Ihr Produkt anfühlt.
Tempo externer Dienste
Zeigt, wie lange Ihre Anwendung auf andere Dienste und Partner wartet, und deckt langsame externe Abhängigkeiten auf.
Reaktionsfähigkeit der Anwendung
Macht sichtbar, wann die Anwendung zu beschäftigt ist, um sofort zu reagieren, sodass jede Anfrage warten muss.
Zustand des Speichers
Zeigt, wie viel Speicher die Anwendung nutzt, wie nah sie ihrer Grenze ist und wie lange das Aufräumen dauert.
Alle 8 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
http.server.request.duration | s | Latenz eingehender HTTP-Requests je Route und Statuscode. |
http.client.request.duration | s | Latenz ausgehender HTTP-Aufrufe, um langsame Abhängigkeiten zu finden. |
nodejs.eventloop.delay.p99 | s | 99. Perzentil des Event-Loop-Delays; hohe Werte bedeuten blockierenden Code. |
nodejs.eventloop.delay.max | s | Längste gemessene Verzögerung der Event Loop im Intervall. |
nodejs.eventloop.utilization | 1 | Anteil der Zeit, in der die Event Loop beschäftigt war; nahe 1 heißt Sättigung. |
v8js.memory.heap.used | By | Genutzter V8-Heap je Heap-Space; stetiges Wachstum deutet auf ein Leak. |
v8js.memory.heap.limit | By | Heap-Limit, um die Auslastung gegenüber --max-old-space-size zu berechnen. |
v8js.gc.duration | s | Dauer der Garbage Collection je Typ (minor, major, incremental). |
Node.js-Monitoring in wenigen Minuten einrichten
- Schritt 1
Paket installieren
Fügen Sie @opentelemetry/api und @opentelemetry/auto-instrumentations-node hinzu oder überlassen Sie Kubernetes-Workloads dem Obseria Agent.
- Schritt 2
Per Umgebung konfigurieren
Setzen Sie OTEL_SERVICE_NAME, den OTLP-Endpoint von Obseria, Ihr Token und die Exporter als Umgebungsvariablen.
- Schritt 3
Mit --require starten
Registrieren Sie die Instrumentierung über NODE_OPTIONS, bevor Ihr Code lädt, und starten Sie Node.js wie gewohnt.
npm install --save @opentelemetry/api @opentelemetry/auto-instrumentations-node
export OTEL_SERVICE_NAME="storefront-api"
export OTEL_RESOURCE_ATTRIBUTES="deployment.environment.name=production"
export OTEL_TRACES_EXPORTER="otlp"
export OTEL_METRICS_EXPORTER="otlp"
export OTEL_LOGS_EXPORTER="otlp"
export OTEL_EXPORTER_OTLP_ENDPOINT="${OBSERIA_OTLP_ENDPOINT}"
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer%20${OBSERIA_TOKEN}"
export OTEL_NODE_RESOURCE_DETECTORS="env,host,os,container"
export NODE_OPTIONS="--require @opentelemetry/auto-instrumentations-node/register"
node server.jsSofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- Node.js-Runtime: Event Loop, Heap, GC
- Service-Health mit RED-Metriken je Route
- Alert auf Event-Loop-Delay p99
- Alert bei Heap nahe am Limit
- Langsamste ausgehende Abhängigkeiten
Node.js-Monitoring: Darauf kommt es an
Warum Node.js-Monitoring anders ist
Node.js führt JavaScript auf einem einzigen Haupt-Thread mit Event Loop aus. Dieses Modell verarbeitet Tausende gleichzeitige Verbindungen effizient, solange kein Callback die Loop blockiert. Ein langsames JSON-Parsing, ein synchroner Krypto-Aufruf oder ein aufwendiger regulärer Ausdruck verzögert jeden anderen Request im selben Prozess. Node.js-Monitoring braucht deshalb mehr als CPU- und Speicherdiagramme: Es muss den Zustand der Event Loop direkt neben den Request-Traces zeigen.
Die zweite Herausforderung ist der asynchrone Kontext. Ein einzelner Request verzweigt in Promises, Callbacks und Timer. OpenTelemetry nutzt AsyncLocalStorage, um den aktiven Span über diese Grenzen hinweg zu halten, sodass ausgehende HTTP-Aufrufe und Datenbankabfragen im richtigen Trace landen. Das Paket @opentelemetry/auto-instrumentations-node bündelt Instrumentierungen für die gängigsten Bibliotheken und macht Node.js APM zu einer Frage eines einzigen Flags.
Signale für das Node.js Performance Monitoring
- Event-Loop-Delay:
nodejs.eventloop.delay.p99undnodejs.eventloop.delay.maxmessen, wie verspätet Timer feuern. Werte über wenigen Millisekunden bedeuten, dass etwas die Loop blockiert. - Event-Loop-Auslastung:
nodejs.eventloop.utilizationzeigt, wie beschäftigt die Loop ist. Nahe 1 kann der Prozess keine weitere Arbeit annehmen, selbst wenn die Host-CPU unauffällig wirkt. - V8-Heap:
v8js.memory.heap.usedje Heap-Space im Vergleich zuv8js.memory.heap.limit. Wird das Limit erreicht, endet der Prozess mit einem fatalen Out-of-Memory-Fehler. - Garbage Collection:
v8js.gc.durationje Typ. Major Collections pausieren die JavaScript-Ausführung. - Requests und Abhängigkeiten:
http.server.request.durationundhttp.client.request.durationliefern Latenz, Durchsatz und Fehler je Route und je nachgelagertem Service.
Typische Node.js-Probleme erkennen
Blockierte Event Loop
Synchroner Dateizugriff, aufwendige JSON-Serialisierung oder CPU-lastige Schleifen halten jeden parallelen Request auf. Das Muster ist eindeutig: Der Event-Loop-Delay springt nach oben, die Latenz steigt für alle Routen gleichzeitig, und ein CPU-Kern ist voll ausgelastet. CPU-Profile zeigen die verantwortliche Funktion.
Memory Leaks
Closures, die große Objekte festhalten, wachsende In-Memory-Caches und nie entfernte Listener lassen den Heap wachsen, bis der Prozess abstürzt und neu startet. Beobachten Sie den genutzten Heap über mehrere Tage und korrelieren Sie Neustarts mit dem Erreichen des Heap-Limits.
Unbehandelte Promise Rejections
Abgelehnte Promises ohne Handler können den Prozess beenden oder Arbeit stillschweigend verwerfen. Error Tracking gruppiert diese Exceptions nach Stacktrace, sodass neue Fehlertypen direkt nach einem Deployment auffallen.
Langsame oder ausgelastete Abhängigkeiten
Zu kleine Connection Pools für PostgreSQL oder Redis lassen Requests warten. Client-Spans zeigen Wartezeit und Abfragedauer getrennt, damit Sie wissen, ob der Pool oder die Query optimiert werden muss.
Crash-Loops in Containern
Läuft ein Node.js-Prozess aus dem Heap oder wirft eine nicht abgefangene Exception, startet der Orchestrator ihn neu. Kurzlebige Pods verbergen den Fehler, wenn Logs und Traces nicht vor dem Prozessende verschickt werden. Restart-Zähler aus Kubernetes neben Heap-Nutzung und Fehler-Spans machen das Muster sichtbar.
Ungleich verteilte Last im Cluster-Modus
Mit dem Cluster-Modul oder PM2 laufen mehrere Prozesse pro Host. Ist ein einzelner Prozess blockiert, leidet nur ein Teil der Requests, und Durchschnittswerte wirken unauffällig. Metriken je Prozess und Perzentile statt Mittelwerte decken solche Ausreißer zuverlässig auf.
Best Practices für Node.js APM
- Laden Sie die Instrumentierung vor allen anderen Modulen, idealerweise mit
--requireoder--importüberNODE_OPTIONS. - Deaktivieren Sie nicht benötigte Instrumentierungen, etwa Dateisystem-Spans, um Rauschen und Overhead zu reduzieren.
- Alarmieren Sie auf Event-Loop-Delay p99 und Heap-Auslastung, nicht nur auf die Antwortzeit.
- Setzen Sie
--max-old-space-sizein Containern explizit, damit das Heap-Limit zum Memory-Limit passt. - Schreiben Sie Trace-IDs in Pino- oder Winston-Logs, um von einer Logzeile direkt zum vollständigen Trace zu springen.
So unterstützt Obseria das Node.js-Monitoring
Obseria verarbeitet die OpenTelemetry-Daten Ihrer Node.js-Services per OTLP; die Instrumentierung bleibt herstellerneutral und portabel. Der Obseria Agent ergänzt Host- und Container-Kontext und läuft auf Kubernetes als DaemonSet. TopoGraph ordnet jeden Service seinen Datenbanken, Caches, Queues und Aufrufern zu. Continuous Profiling mit unter 1 % Overhead zeigt die Funktion, die die Event Loop blockiert. Steigt die Latenz nach einem Release, korreliert Obseria Intelligence Deployment, Event-Loop-Delay und langsame Abhängigkeiten und präsentiert die Ursache mit nachvollziehbarer Beweiskette. Dashboards, Alerts und SLOs sind ohne Aufpreis enthalten.
Verwandte Integrationen
Passende Funktionen
Distributed Tracing
Verfolgen Sie jeden Request über Services, Queues und Datenbanken hinweg und finden Sie den langsamen Span oder die fehlerhafte Abhängigkeit in Sekunden.
Mehr erfahrenFehler-Tracking
Die Errors Inbox gruppiert Exceptions aus Backend, Frontend und Mobile Apps zu Issues, zeigt deren Auswirkung und bündelt Zuweisung und Lösung in einem Workflow.
Mehr erfahrenContinuous Profiling
Dauerhaftes Continuous Profiling zeigt, welche Funktionen in Produktion CPU, Speicher und Locks beanspruchen, mit unter 1 % Overhead und Verknüpfung zu Traces.
Mehr erfahrenMehr erfahren
Was ist APM (Application Performance Monitoring)?
Was ist APM? Wie Application Performance Monitoring Latenz, Durchsatz und Fehler misst, wie Distributed Tracing funktioniert und welche Kennzahlen zählen.
Die vier Golden Signals: Latenz, Traffic, Fehler und Sättigung
Die vier Golden Signals erklärt: Latenz, Traffic, Fehler und Sättigung, der Bezug zu RED- und USE-Methode und die Messung mit OpenTelemetry.
Häufige Fragen zum Node.js-Monitoring
Nein. Wird @opentelemetry/auto-instrumentations-node über NODE_OPTIONS registriert, werden unterstützte Bibliotheken automatisch instrumentiert. Eigene Spans über die OpenTelemetry API sind optional.
Ja, mit aktuellen Node.js-Versionen. Für ESM wird der Loader-Hook von OpenTelemetry benötigt; die Dokumentation des OpenTelemetry-JavaScript-Projekts beschreibt das passende --import-Setup.
Express, Fastify, Koa, Hapi, NestJS sowie zahlreiche Datenbank-, Messaging- und Cloud-SDK-Clients werden von den offiziellen Instrumentierungspaketen abgedeckt.
Die im Autoinstrumentierungspaket enthaltene Runtime-Instrumentierung meldet Event-Loop-Delay und -Auslastung sowie V8-Heap- und GC-Metriken. Obseria zeigt sie im Node.js-Runtime-Dashboard.
Ja. Nutzen Sie den OpenTelemetry Lambda Layer für Node.js; Traces und Metriken gelangen per OTLP zu Obseria, ergänzt um CloudWatch-Metriken aus der agentenlosen AWS-Integration.
Starten Sie heute mit dem Node.js-Monitoring
Binden Sie Node.js in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.