Observability Middleware in Bun.js: Logs, Request ID, Tracing und Latency Budgets
Ein praktischer Deep Dive zu Observability Middleware in Bun.js: Request ID, Structured Logs, traceparent, OpenTelemetry, Latency Budgets, Timing Headers, Error Correlation, Redaction, Sampling und schlechte Logging-Praktiken.
Bun.js Middleware Production Guide 2026
Eine Serie über Production Middleware in Bun.js: Überblick, Security, Performance, Observability, Rate Limiting, Body Parsing, WebSocket/SSE und Tests für die Request Pipeline.
Alle Artikel in diesem Guide
01
Bun.js Middleware 2026: Overview, Best Practices und Anti-Patterns
Das grundlegende mentale Modell für Middleware in nativem Bun, Hono und Elysia, mit Beispielen, Optimierung und Roadmap für die nächsten Deep-Dive-Artikel.
02
Auth Middleware in Bun.js: JWT, Sessions, API Keys und Multi-Tenant Context
Wie man Auth Middleware in Bun richtig baut: Reihenfolge der Prüfungen, Cache, Token Rotation, Tenant Context, 401/403-Fehler und Tests.
03
Rate Limiting in Bun.js: in-memory, Redis, Sliding Window und Edge Cases
Ein detaillierter Blick auf Rate Limiting für Bun APIs: Algorithmen, Redis, distributed limits, abuse protection und graceful degradation.
04
Observability Middleware in Bun.js: Logs, Request ID, Tracing und Latency Budgets
Wie man request id, structured logs, timing headers, einen OpenTelemetry-ähnlichen Flow hinzufügt und Logging nicht zum Bottleneck macht.
05
Body Parsing und Validation in Bun.js: JSON, Uploads, Streams und Payload Limits
Wie man Request Bodies in Bun sicher liest, wo Limits hingehören und wie man Streams, Uploads, Idempotency und Schema Validation nicht kaputtmacht.
Logs ohne Request ID, Traces ohne Sampling Policy, Errors ohne Tenant/User Context, Metrics ohne Route Group und Debug Body in Production sind keine Observability. Das ist nur Rauschen, das manchmal zufällig hilft.
Observability Middleware sollte praktische Fragen beantworten: welcher Request, welche Route, welcher Tenant, welcher User/API Key, wie lange auth, rate limit, handler, database und downstream dauerten, welche Error Class auftrat und wo man das in Logs findet.
In Bun sollte man das besser als dünnen request-scoped Layer designen, nicht als zufällige console.log Calls in Handlers.
karte
Das ist das vierte Chapter der Serie über Bun Middleware. Nach Auth und Rate Limiting muss Production-Verhalten sichtbar werden, nicht nur „lokal schnell“ wirken.
console.log(req), Body Logs, unterschiedliche Request IDs in unterschiedlichen Schichten, Tracing ohne Context Propagation.Observability sollte nicht auf „wir haben einen Logger hinzugefügt“ reduziert werden. Logs, Metrics und Traces haben unterschiedliche Rollen, und Middleware sollte den minimalen Context für alle drei sammeln.
| Signal | Was es beantwortet | Was schreiben | Risiko |
|---|---|---|---|
| Logs | Was mit einem konkreten Request oder Error passiert ist | requestId, traceId, route, status, duration, error class, tenant/user ids | Rauschen, PII, Secrets, Body Dumps, teure Serialisierung |
| Metrics | Was im System aggregiert passiert | latency percentiles, error rate, request count, limiter decisions | Zu hohe Cardinality durch userId/path params |
| Traces | Wo der Request in einem distributed flow Zeit verbraucht hat | spans, parent/child relationship, downstream calls, timings | Kein Nutzen ohne Propagation und Sampling Policy |
Logs, Metrics und Traces duplizieren sich nicht. Sie geben verschiedene Blickwinkel auf denselben Request Flow.
Screenshot des Abschnitts observability-modelKurz gesagt
Für Bun Middleware ist die beste Baseline: Request ID in Logs, Latenz in Metrics, Trace Context in Downstream Calls.
Eine Request ID sollte am Eingang erstellt oder von einem trusted Edge/Proxy akzeptiert werden. Danach sollte sie durch Logs, Response Headers, Error Reports und Downstream Calls laufen. Wenn unterschiedliche Middleware-Schichten unterschiedliche IDs generieren, geht Correlation verloren.
Ein minimaler nativer Bun Pattern:
type Context = { requestId: string; startedAt: number };
type Handler = (req: Request, ctx: Context) => Promise<Response> | Response;
type Middleware = (next: Handler) => Handler;
const withRequestId: Middleware = (next) => async (req, ctx) => {
const incoming = req.headers.get("x-request-id");
const requestId = incoming && incoming.length <= 128 ? incoming : crypto.randomUUID();
const res = await next(req, { ...ctx, requestId });
res.headers.set("x-request-id", requestId);
return res;
};
Bun.serve({
fetch: withRequestId(async (_req, ctx) => {
return Response.json({ ok: true, requestId: ctx.requestId });
}),
});In Production sollte die Trust Boundary klar definiert sein. Wenn x-request-id von einem öffentlichen Client kommt, sollte er validiert oder ersetzt werden. Wenn er von deinem Gateway kommt, kann er als Upstream Correlation ID akzeptiert werden.
Request ID sollte eine ID für den gesamten Request Flow sein: Response, Logs, Errors und Downstream Calls sollten dieselbe ID referenzieren.
Screenshot des Abschnitts request-idPraktische Regel
Generiere Request ID einmal am Edge oder am Eingang der Bun API und gib sie danach nur weiter.
Structured Logging bedeutet, dass ein Log Entry ein JSON-ähnliches Event mit filterbaren Feldern ist: requestId, traceId, route, method, status, durationMs, tenantId, subjectId, errorClass. Ein String wie user failed skaliert nicht, wenn ein Incident 200.000 Events hat.
Pino ist im Node Ecosystem beliebt, weil es ein schneller JSON Logger ist und einen Redaction-Mechanismus für sensitive Fields hat. Selbst wenn du Pino in Bun nicht direkt nutzt, sind die Prinzipien dieselben: structured fields, low overhead, redaction, sampling und keine Secrets im Payload. [4]
Typischer Shape eines Log Entry für eine Bun API:
logger.info({
event: "request.completed",
requestId: ctx.requestId,
traceId: ctx.traceId,
method: req.method,
route: ctx.routePattern,
status,
durationMs,
tenantId: ctx.auth?.tenantId,
subjectId: ctx.auth?.subjectId,
});Was nicht geloggt werden sollte
Logge keine Authorization Headers, Cookies, Refresh Tokens, vollständigen API Keys, Raw Request Body, Passwörter, Payment Data oder große Payloads ohne explizites Security Review.
W3C Trace Context standardisiert die Headers traceparent und tracestate, damit verschiedene Systeme Trace Identity zwischen Services weitergeben können. OpenTelemetry nutzt Context Propagation, damit Spans Teil eines Distributed Trace werden. [2][3]
Für eine Bun API bedeutet das: Wenn ein Request mit traceparent kommt, solltest du ihn entweder von einem trusted upstream akzeptieren oder einen neuen Trace erstellen. Wenn dein Handler einen anderen Service, eine Queue, einen Worker oder ein AI Gateway aufruft, sollte Trace Context weitergegeben werden.
Verwechsle Request ID und Trace ID nicht. Request ID ist praktisch für Support/Debugging einer einzelnen Response. Trace ID wird für den Distributed Path gebraucht. Sie können unterschiedlich sein, sollten aber gemeinsam in Logs stehen.
Trace Context ist nötig, wenn ein Request durch mehrere Services läuft. Ohne Propagation zerfällt der Trace in nicht verbundene Fragmente.
Screenshot des Abschnitts trace-contextKurz gesagt
Request ID hilft, einen Request zu finden. Trace Context zeigt den gesamten Weg des Requests durch das System.
Wenn du nur total duration siehst, weißt du, dass die API langsam ist, aber nicht warum. Observability Middleware sollte einen Request in wichtige Phasen aufteilen.
Wie viel Credential Verification kostet
JWT Verify, Session Lookup, API Key Lookup, Tenant Resolution und Permissions Cache sollten jeweils eigenes Timing haben. Sonst wird Auth unbemerkt zum Bottleneck.
Wie viel Limiter Storage kostet
Redis Latency oder Local Limiter Overhead sollte sichtbar sein. Wenn der Limiter 15ms zu jedem Request hinzufügt, ist das bereits eine Product Decision.
Wie lange Business Logic dauert
Handler Timing sollte von Middleware Timing getrennt werden, damit nicht die falsche Schicht optimiert wird.
Wie viel Zeit in DB, APIs und Queues geht
DB und externe Services sollten separate Spans oder Timing Events haben. Sonst sieht eine slow query wie ein slow Bun server aus.
Kurz gesagt
Latency ohne Breakdown wird zu Raten. Breakdown ohne Budget wird zu endlosem Rauschen.
In einer High-Traffic Bun API kann vollständiges Logging jedes Requests teurer sein als der Handler selbst. Sampling sollte Teil des Designs sein, kein Not-Aus-Schalter.
Gut: vollständige Logs für Errors und Slow Requests
Errors, 5xx, 429 Spikes, Auth Failures und Slow Requests sollten detaillierter geloggt werden, aber weiterhin ohne Secrets.
Vorsicht: Debug Logs für gesamten Traffic
In Production erzeugt das Storage Bill, Latency, Noise und Security Exposure. Debug Sampling sollte eng und temporär sein.
Gut: route-aware Sampling
Critical Flows, Checkout, Login, Exports und Webhooks können eine andere Sampling Policy haben als günstige public GET Routes.
Vorsicht: Sampling ohne Incident Override
Während eines Incidents sollte das Team eine kontrollierte Möglichkeit haben, Detailgrad temporär für Route, Tenant oder Request Class zu erhöhen.
Observability kann leicht selbst zum Problem werden: langsame Logs, Secret Leaks, Rauschen und Trace Data, die niemand verbinden kann.
console.log(req) oder Logging des rohen Request Object.
Logging von Authorization, Cookies, Refresh Tokens, vollständigen API Keys oder Request Body.
Neue Request ID in jeder Middleware generieren.
Trace ID existiert, wird aber nicht in Logs geschrieben.
Downstream Calls erhalten keinen Trace Context.
Metrics haben hohe Cardinality durch Raw URLs mit IDs oder userId Labels.
Error Logs enthalten keine Route, Status, RequestId oder Error Class.
Debug Logging ist global in Production aktiviert.
Observability Middleware steht nach dem Handler und sieht Early Rejects nicht.
Keine Sampling Policy und kein Storage Budget.
Review-Regel
Observability sollte Fragen während eines Incidents schneller beantworten, als sie neue Performance- und Security-Risiken erzeugt.
Diese Checklist sollte vor dem Launch einer Bun API in Staging oder Production durchgegangen werden, besonders wenn die API Auth, Rate Limiting und Downstream Calls hat.
Eine Request ID für den ganzen Flow
Wird von trusted upstream akzeptiert oder am Eingang generiert, in Response und alle Logs geschrieben.
Trace Context propagiert
traceparent und tracestate werden gemäß Policy akzeptiert/erstellt und an Downstream Calls weitergegeben.
Structured Logs haben ein stabiles Schema
event, requestId, traceId, route, method, status, durationMs, tenant/subject ids, error class.
Secrets sind redacted
Authorization, Cookies, API Keys, Tokens, Passwörter, PII und Raw Body gelangen nicht in Logs.
Latency Breakdown existiert
Auth, Rate Limit, Handler, DB/Downstream haben separate Timings oder Spans.
Sampling Policy ist definiert
Errors und Slow Requests werden detaillierter geloggt; High-Volume Success Logs nutzen Sampling oder Aggregation.
Route Labels sind normalisiert
Metrics nutzen Route Pattern, zum Beispiel /users/:id, nicht Raw /users/123.
Incident Override ist kontrolliert
Es gibt eine temporäre Möglichkeit, Detailgrad für route/tenant/request class zu erhöhen, ohne globales Debug Chaos.
Eine Bun API kann schnell antworten, aber ohne Observability verliert das Team während Incidents trotzdem Zeit. Request ID, Structured Logs, Trace Context und Latency Breakdown ermöglichen schnell zu verstehen, was passiert ist, wo es passiert ist und wer betroffen war.
Der wichtigste Kompromiss: Observability darf kein neues Bottleneck und kein neuer Datenleck-Kanal werden. Deshalb sollte Middleware dünn sein, Redaction default sein, Sampling bewusst gewählt werden und Timings genau die Schichten messen, die wirklich wehtun können.
In Production ist nicht der Log nützlich, der alles enthält. Nützlich ist der Log, der das richtige Minimum enthält und sich stabil mit Request, Trace, Route, Tenant und Error verbinden lässt.
Nicht für Production. `console.log` kann lokal helfen, aber eine Production API braucht Structured Logs mit requestId, route, status, duration, error class und redaction. Sonst sind Logs schwer zu durchsuchen, zu aggregieren und sicher zu speichern.
Nein. Request ID wird meistens für Support/Debug Correlation eines einzelnen HTTP Requests genutzt. Trace ID zeigt den Distributed Path über mehrere Services. In Logs sollte man am besten beides haben.
Authorization Headers, Cookies, Refresh Tokens, vollständige API Keys, Passwörter, PII, Payment Data und Raw Request Body ohne explizites Security Review. Redaction sollte default sein.
Nicht immer ab dem ersten Tag. Für eine kleine API reichen Request ID, Structured Logs und Latency Breakdown oft aus. Wenn Downstream Services, Queues oder Distributed Flows dazukommen, werden Trace Context und OpenTelemetry deutlich nützlicher.
Middleware dünn halten, keine großen Objekte serialisieren, Bodies nicht loggen, Sampling für High-Volume Success Traffic nutzen, Logger Overhead messen und Route Labels ohne High-Cardinality Values schreiben.
Ganz am Anfang, damit sie Early Rejects von auth/rate limit/body validation sieht. Aber Redaction und Context Enrichment müssen vorsichtig sein, damit keine Bodies oder Secrets unnötig gelesen werden.
Diese Quellen bestätigen Trace-Context-Standards, den OpenTelemetry-Propagation-Ansatz, das Bun Server Model und Praktiken für Structured Logging/Redaction.
PAS7 Studio kann helfen, Observability Middleware für Bun, Hono oder Elysia zu entwerfen: Request ID, Structured Logs, Trace Context, Latency Budgets, Redaction, Sampling und Dashboards für Production APIs.
Das ist besonders nützlich für SaaS, Internal Platforms, Integration APIs und High-Traffic-Produkte, bei denen Incidents schnell erklärt werden müssen, statt tausende zufällige Log Lines zu lesen.
Observability Middleware in Bun.js: Logs, Request ID, Tracing und Latency Budgets
Verwandte Artikel
AI Assistant Entwicklung Kosten 2026: RAG, Knowledge Base, Integrationen und Support
Praktischer Leitfaden zu Kosten fuer AI Assistants: RAG, Knowledge Base, Channels, Tool Use, Guardrails, Evaluations, Monitoring und Support.
KI fur Landingpage-Entwicklung: wo sie Launches beschleunigt und wo sie Conversion schadet
Eine praxisnahe Analyse zur Nutzung von KI fur Landingpages: v0, Webflow AI, Builder.io, Framer-ahnliche Builder, UX-Generierung, Copy, SEO, Personalisierung, A/B-Tests, Template-Risiken, Accessibility, Security und technischer Schuldenaufbau.
AI SEO / GEO im Jahr 2026: Ihre nächsten Kunden sind nicht Menschen — sondern Agents
Suche verschiebt sich von Klicks zu Antworten. Bots und AI-Agents crawlen, zitieren, empfehlen — und kaufen zunehmend. Erfahren Sie, was AI SEO / GEO bedeutet, warum klassisches SEO nicht mehr reicht und wie PAS7 Studio Marken im agentischen Web sichtbar macht.
Der leistungsstärkste Chip von Apple? M5 Pro und M5 Max brechen Rekorde
Eine Analyse zu Apple M5 Pro und M5 Max im März 2026. Wir zeigen, warum diese Chips als die stärksten professionellen Laptop-SoCs von Apple gelten können, wie sie sich gegen M4 Pro, M4 Max, M1 Pro, M1 Max schlagen und was der Vergleich mit aktuellen Intel- und AMD-Chips zeigt.
Professionelle Entwicklung für Ihr Geschäft
Wir erstellen moderne Web-Lösungen und Bots für Unternehmen. Erfahren Sie, wie wir Ihnen helfen können, Ihre Ziele zu erreichen.