QTap DevTools - Interactive Traffic Inspection

What if you had Chrome DevTools... but for your server?

We're excited to introduce QTap DevTools - a browser-based interface that brings the familiar Chrome DevTools experience to server-side HTTP/S traffic debugging. See exactly what your applications are sending and receiving in production, without code changes, proxies, or certificate management.

DevTools is designed for single-host emergency troubleshooting - when you need to debug a specific server right now. It runs locally on localhost:10001, requires no service restarts, and keeps all captured data on your infrastructure.

Available Now: DevTools is included in the latest qtap release. Enable it with --enable-dev-tools or ENABLE_DEV_TOOLS=true. No application restarts required.

The Problem We Solved

Production API debugging has always been painful:

  • Third-party API failing? Your logs don't show the full request/response context

  • Integration broke overnight? Need to add logging, deploy, and wait for the issue to reproduce

  • Which service made that call? Multiple containers on the same host, impossible to tell

  • HTTPS traffic is encrypted - tcpdump and Wireshark only show encrypted packets

Traditional solutions require proxies, certificate installation, application restarts, and code changes. DevTools eliminates all of that.

What It Does

DevTools gives you a real-time, browser-based view of all HTTP/S traffic on a single host - ingress and egress, plaintext and TLS.

This is emergency troubleshooting, not monitoring. DevTools runs locally on the server you're debugging. When you need to see what's happening on a specific host right now, enable DevTools and watch traffic flow in real-time. No service restarts. No code deployments. No waiting.

Key Capabilities

1. See Inside HTTPS Without Proxies

DevTools uses eBPF to hook into TLS libraries (OpenSSL, Go crypto, Java SSL, Node.js) before encryption happens. You see the plaintext HTTP request/response even though the wire traffic is encrypted.

No certificate management. No proxy configuration. No application changes.

2. Process & Container Attribution

Every HTTP request shows:

  • Exact binary path (/usr/local/bin/python3.11)

  • Container name and image (payment-service:latest)

  • Process ID and user

When you see a failing API call, you instantly know which container made it.

3. Complete HTTP Transaction Details

Click any request to see:

  • Request: Method, URL, all headers (including Authorization), full body

  • Response: Status code, content-type, all headers, full body

  • Timing: Duration in milliseconds, exact timestamps

  • Network: Bytes sent/received, TLS version, connection ID

4. Real-Time Streaming

New requests appear instantly as they happen via Server-Sent Events (SSE). Watch traffic flow in real-time, filter by domain, status code, or process.

Use Cases

API Integration Debugging

Problem: Stripe API returning 401 errors. Your logs show "authentication failed" but not what header was sent.

DevTools Solution: Open DevTools, trigger the request, click on the failed call. See the exact Authorization: Bearer sk_test_... header that was sent. Discover you're sending a test key in production.

Time to resolution: 30 seconds instead of hours.

Production Incident Response

Problem: Customer reports sync failing in production. You need visibility NOW. Can't wait for a deploy cycle to add debug logging.

DevTools Solution:

  1. SSH into the production server: ssh user@prod-server

  2. Enable DevTools: sudo qtap --enable-dev-tools (takes 2 seconds, no app restarts)

  3. Reproduce the sync failure

  4. Watch it happen in real-time in DevTools at http://localhost:10001/devtools

  5. See the actual error: "404 Not Found - endpoint was moved"

Time to diagnosis: 30 seconds. No code deployment. No service restarts. No waiting for issues to reproduce in logs.

Multi-Container Attribution

Problem: Payment service logs show API calls to Twilio. But the payment service shouldn't be calling Twilio directly - that should go through the notification service.

DevTools Solution: Filter by process/container. See that the payment-worker container is indeed making direct Twilio calls. Unexpected dependency discovered.

Third-Party Service Changes

Problem: Integration that worked yesterday is broken today. Did the provider change their API?

DevTools Solution: Compare current requests against historical captures. See the provider now requires a new X-API-Version: 2 header that wasn't required before.

How It Works

DevTools combines three powerful technologies:

1. eBPF Syscall Hooking

Qtap uses eBPF to hook into system calls (read, write, recvfrom, sendto) at the Linux kernel level. This captures network traffic before it leaves the application.

2. TLS Library Introspection

When TLS is detected, Qtap hooks into the TLS library (OpenSSL, Go crypto, Java SSL, Node.js TLS) before encryption happens. This is why you see plaintext HTTP/S even though the network traffic is encrypted.

3. Browser-Based UI

DevTools runs a local web server on localhost:10001 that streams captured traffic to your browser via Server-Sent Events (SSE). The familiar interface makes it easy to inspect requests, filter traffic, and drill into transaction details.

Application → TLS Library → [Qtap eBPF Hook] → Encrypted Network Traffic
                            ↓
                     DevTools Web UI (localhost:10001/devtools)

Result: See plaintext HTTP/S in your browser, with process/container attribution, in real-time.

Event Stream Architecture

DevTools streams 5 types of events in real-time:

Event Type
What It Shows
Use Case

system.connected

DevTools connection established

Confirm UI is connected

process.started / process.stopped

Process lifecycle

Track which processes are active

connection.opened / connection.closed

TCP connection events

Network-level visibility

request.http_transaction

Complete HTTP transaction

Full request/response details

Each HTTP transaction includes:

  • Summary (lightweight): Status, method, host, duration, process - for list views

  • Full transaction: Complete headers, bodies, metadata - for detail views

This dual-level structure enables fast UI rendering with drill-down capabilities.

Getting Started

Quickest Way (30 seconds)

# Download and run qtap with DevTools enabled
curl -s https://get.qpoint.io/demo | sudo sh -s -- --enable-dev-tools

# Access DevTools in your browser
open http://localhost:10001/devtools

That's it! DevTools is now showing all HTTP/S traffic on your server.

Production Usage

Binary Installation:

# Install qtap
curl -s https://get.qpoint.io/install | sudo sh

# Run with DevTools enabled
sudo qtap --enable-dev-tools --log-level=warn

Docker:

docker run -d --name qtap \
  --user 0:0 --privileged \
  --cap-add CAP_BPF --cap-add CAP_SYS_ADMIN \
  --pid=host --network=host \
  -v /sys:/sys \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e TINI_SUBREAPER=1 \
  -e ENABLE_DEV_TOOLS=true \
  --ulimit=memlock=-1 \
  us-docker.pkg.dev/qpoint-edge/public/qtap:v0 \
  --log-level=warn

Kubernetes:

Add the environment variable to your Pod spec:

env:
  - name: ENABLE_DEV_TOOLS
    value: "true"

Then port-forward to access:

kubectl port-forward pod/qtap-xxxxx 10001:10001
open http://localhost:10001/devtools

Remote Access via SSH Tunnel

For remote servers, use SSH port forwarding to access DevTools from your laptop:

# Create SSH tunnel
ssh -L 10001:localhost:10001 -N user@production-server &

# Access DevTools locally
open http://localhost:10001/devtools

What Makes DevTools Different

vs. tcpdump / Wireshark

  • Wireshark shows encrypted packets and requires TLS keys to decrypt

  • DevTools shows plaintext HTTP/S automatically by hooking TLS libraries

vs. Proxy Tools (Charles, mitmproxy)

  • Proxies require certificate installation, proxy configuration, and application restarts

  • DevTools requires no configuration and no restarts - just the --enable-dev-tools flag

vs. Application Logging

  • Logs only show what developers explicitly logged, require code changes and redeployment

  • DevTools captures complete HTTP/S traffic automatically, no code changes needed

vs. Qplane

  • Qplane is for centralized, multi-host, long-term visibility across your entire fleet

  • DevTools is for single-host emergency troubleshooting - when you need to debug one specific server right now

Think of DevTools as your emergency diagnostic tool. When a specific server is having issues, SSH in, enable DevTools, and see what's happening locally in real-time. For ongoing monitoring across your fleet, use Qplane.

Use both together: DevTools for emergency debugging + S3 storage for permanent archives + Qplane for fleet-wide visibility.

Key Features

✅ No Service Restarts Required

Enable DevTools while your applications are running. No restarts, no downtime, no waiting.

✅ Single-Host Local Operation

Runs on localhost:10001 for emergency troubleshooting on a specific server. All data stays local.

✅ Process-Aware Traffic Capture

Not just IP:port - see the actual binary, container name, and image that made each request.

✅ Passive Observation

Out-of-band operation. Qtap observes traffic but doesn't route, proxy, or modify it.

✅ Plaintext TLS Inspection

See inside HTTPS by hooking TLS libraries before encryption, without certificates or proxies.

✅ Real-Time Streaming

Server-Sent Events (SSE) provide instant updates - no polling, no lag.

✅ Ring Buffer Storage

Finite, browser-based storage for ephemeral troubleshooting sessions. Perfect for emergency diagnostics.

Data Sovereignty

This is a key reason to use DevTools with local storage instead of sending everything to the cloud.

Captured HTTP traffic often contains sensitive information:

  • API keys and tokens in Authorization headers

  • Customer PII in request/response bodies

  • Internal service credentials

  • Business-critical data

DevTools keeps all of this data:

  • ✅ On your server (localhost:10001)

  • ✅ In your browser's memory (ring buffer)

  • ✅ Never sent to external services

  • ✅ Ephemeral - cleared on page refresh

For permanent storage, configure S3-compatible object storage (MinIO, AWS S3, GCS) to keep captured data entirely within your infrastructure.

System Requirements

DevTools has the same requirements as qtap:

  • Linux kernel 5.10+ with eBPF support

  • Privileged container or root access (for eBPF programs)

  • CAP_BPF and CAP_SYS_ADMIN capabilities

  • Access to /sys filesystem

  • Docker socket (for container attribution)

See System Requirements for details.

Learn More

What's Next

We're actively developing DevTools with more features coming soon:

  • RED Metrics Dashboard - Request rate, Error rate, Duration metrics for all captured traffic

  • Advanced Filters - Filter by request/response body content, header values, and custom expressions

  • Search - Full-text search across all captured requests

Feedback

We'd love to hear how you're using DevTools! Share your use cases, feature requests, or bug reports:

Ready to try it? Enable DevTools in 30 seconds:

curl -s https://get.qpoint.io/demo | sudo sh -s -- --enable-dev-tools
open http://localhost:10001/devtools

Happy debugging! 🔍

PreviousRelease NotesNextFAQ

Last updated