Envoy Traffic Capture
This guide shows you how to use Qtap to capture HTTP traffic flowing through Envoy, the modern cloud-native proxy designed for service meshes. You'll learn how to observe both incoming and outgoing connections in a microservices architecture.
What You'll Learn
Capture Envoy ingress traffic (incoming requests)
Capture Envoy egress traffic (upstream service requests)
Monitor service mesh traffic patterns
Configure Envoy listeners, routes, and clusters
Apply conditional capture rules
Set up Envoy + Qtap in Docker for testing
Deploy production-ready configurations
Use Cases
Why capture Envoy traffic?
Service Mesh Visibility: Monitor all service-to-service communication
Istio/Consul Integration: Observe traffic in service mesh deployments
gRPC Traffic Inspection: See gRPC calls between microservices
Debugging Routing: Verify Envoy routes traffic correctly
Observability: Deep insights into request/response patterns
Security Auditing: Monitor for suspicious traffic patterns
Performance Analysis: Measure latency and identify bottlenecks
Prerequisites
Linux system with kernel 5.10+ and eBPF support
Docker installed (for this guide's examples)
Root/sudo access
Basic understanding of Envoy configuration concepts
Part 1: Basic Envoy Proxy Setup
Envoy uses YAML configuration with a specific structure: listeners, routes, and clusters.
Step 1: Create Project Directory
Step 2: Create Envoy Configuration
Create envoy.yaml:
Step 3: Create Backend Service
Create backend-service.py:
Step 4: Create Qtap Configuration
Create qtap.yaml:
Step 5: Create Docker Compose Setup
Create docker-compose.yaml:
Key Envoy Concepts:
Listeners: Accept incoming connections
Routes: Map requests to clusters
Clusters: Groups of upstream endpoints
Filters: Process requests (router, logging, etc.)
Part 2: Running and Testing
Step 1: Start the Services
Step 2: Generate Test Traffic
Step 3: View Captured Traffic
What you should see:
Key indicators:
✅
"exe"containsenvoy✅
Direction: INGRESS- Client → Envoy✅
Direction: EGRESS- Envoy → Backend✅ Path transformation visible
✅ Cluster routing working
Part 3: Advanced Configurations
Configuration 1: Service Mesh Monitoring
Capture service-to-service traffic:
Configuration 2: Selective Capture by Service
Configuration 3: Production with S3
Real-World Use Cases
Use Case 1: Istio Service Mesh
Monitor Envoy sidecars in Istio:
Use Case 2: API Gateway
Envoy as edge proxy:
Troubleshooting
Not Seeing Envoy Traffic?
Check 1: Is Envoy running?
Check 2: Qtap running before traffic?
Check 3: Envoy routing correctly?
Seeing "l7Protocol": "other"?
"l7Protocol": "other"?Envoy might be using HTTP/2 or HTTP/3
Wait longer after starting Qtap
Check if TLS is involved
Performance Considerations
Envoy + Qtap:
CPU: ~1-3% overhead
Memory: ~50-200MB
Latency: Zero additional (passive)
Best practices:
Use
summaryfor high volumeApply conditional rules
Filter admin traffic
Send to S3 with batching
Next Steps
Learn More:
Related Guides:
Cleanup
This guide uses validated configurations for Envoy and Qtap.
Last updated