Deno Integration
Instrument Deno applications with a single JSR import. HTTP server tracing, V8 isolate metrics, Deno KV spans, fetch client instrumentation, and Deno Deploy edge runtime support.
How It Works
Import from JSR or deno.land
Import the TigerOps Deno module: import { TigerOps } from "jsr:@tigerops/[email protected]". The module is available on JSR (JavaScript Registry) and deno.land/x. No install step needed — Deno fetches and caches the module on first run.
Initialize Before Serving
Call await TigerOps.init() at the top of your entry file before starting the HTTP server. The init function sets up the OTLP/HTTP exporter, Deno runtime metric collector, and installs the unhandled rejection handler for error tracking.
Set Environment Variables
Set TIGEROPS_API_KEY, TIGEROPS_SERVICE_NAME, and TIGEROPS_ENVIRONMENT. Grant the necessary Deno permissions: --allow-net (for OTLP export), --allow-env (for config), and optionally --allow-sys (for system metrics). Deploy.land environments support these automatically.
HTTP Spans, V8 Metrics & KV Traces
TigerOps begins capturing Deno.serve() request spans, outbound fetch() client traces, Deno KV get/set/delete spans, V8 heap used/total metrics, GC event timings, worker creation latency, and WebSocket connection lifecycle events.
What You Get Out of the Box
Deno.serve() HTTP Request Tracing
The TigerOps Deno middleware wraps Deno.serve() handlers to create root spans per request with URL pattern, HTTP method, response status, and handler execution time. Route patterns from URLPattern matching are used instead of raw URLs to prevent high cardinality.
fetch() Client Span Injection
Outbound fetch() calls are auto-instrumented by patching the global fetch with a TigerOps wrapper. Each call creates a child span with target URL, method, response status, and duration. W3C traceparent headers are injected into all outgoing requests.
V8 Isolate Performance Metrics
TigerOps collects V8 heap statistics via Deno.memoryUsage(): heap used, heap total, external memory, and array buffer bytes. V8 GC events reported via the PerformanceObserver "gc" entry type are captured as span events with GC kind and duration.
Deno KV Store Operation Spans
All Deno KV operations (kv.get, kv.set, kv.delete, kv.list, kv.atomic) are traced as child spans with key prefix, operation type, and execution time. Atomic transaction commit attempts and retry counts are recorded as span attributes.
Worker & Subprocess Tracing
new Worker() creation and message-passing latency are tracked. Workers receive trace context via Worker options and create child spans visible in the parent trace. Deno.Command subprocess execution time and exit code are captured as spans.
Deno Deploy & Edge Runtime Metrics
TigerOps is optimized for Deno Deploy with a sub-3KB OTLP exporter using fetch. Isolate cold start time, CPU time per request (Deno.cpuTime()), and memory limit utilization are tracked as metrics per deploy region.
Install & Initialize
One JSR import and one init() call. Full Deno observability with no package manager.
// deno.json
{
"imports": {
"@tigerops/deno": "jsr:@tigerops/[email protected]"
}
}
// main.ts
import { TigerOps, tigeropsHandler } from "@tigerops/deno";
// Initialize before serving
await TigerOps.init({
apiKey: Deno.env.get("TIGEROPS_API_KEY")!,
serviceName: "my-deno-app",
environment: Deno.env.get("DENO_ENV") ?? "production",
v8Metrics: true,
kvTracing: true,
});
const kv = await Deno.openKv();
// Wrap your handler with TigerOps middleware
Deno.serve(
tigeropsHandler(async (req: Request) => {
const url = new URL(req.url);
if (url.pathname.startsWith("/api/orders/")) {
const id = url.pathname.split("/").pop()!;
// Custom span
return await TigerOps.span("order.fetch", async (span) => {
span.setAttribute("order.id", id);
const entry = await kv.get(["orders", id]); // auto-traced KV op
if (!entry.value) return new Response("Not found", { status: 404 });
return Response.json(entry.value);
});
}
return new Response("OK");
})
);
// Run with required permissions
// deno run --allow-net --allow-env --allow-sys main.tsCommon Questions
Which Deno versions are supported?
Deno 1.40+ and Deno 2.x are fully supported. The module uses Web-standard APIs (fetch, PerformanceObserver, ReadableStream) and Deno-specific APIs (Deno.serve, Deno.memoryUsage, Deno.KV). All features except worker tracing work on Deno Deploy.
What Deno permissions does TigerOps require?
The minimum required permissions are --allow-net=otelcol.tigerops.net (for OTLP export) and --allow-env=TIGEROPS_API_KEY,TIGEROPS_SERVICE_NAME. For system metrics, add --allow-sys. Worker tracing also requires --allow-read for worker file access.
How does TigerOps work with Hono on Deno?
Use the TigerOps Hono middleware from the same JSR module: import { tigeropsMiddleware } from "jsr:@tigerops/deno/hono". Add app.use("*", tigeropsMiddleware()) to your Hono app before route definitions. All Hono routes are auto-traced.
Does TigerOps support Deno Fresh framework tracing?
Yes. TigerOps provides a Fresh middleware plugin. Add tigeropsPlugin() to your plugins array in fresh.config.ts. Route handler spans, island hydration events, and Partial rendering timings are all captured automatically.
How are spans exported from Deno Deploy edge isolates?
TigerOps uses a non-blocking fetch-based OTLP exporter. On Deno Deploy, spans are batched and exported using fetch() to the TigerOps OTLP endpoint. The export call is wrapped in a background promise that does not add to response latency.
Full Deno Observability in One JSR Import
HTTP server traces, V8 metrics, Deno KV spans, fetch client instrumentation, and Deno Deploy support — no package manager required.