Custom tags allow you to attach metadata to captured connections based on process environment variables, container labels, or Kubernetes labels and annotations. This is especially useful for:
Multi-tenant environments: Tag traffic by team, customer, or tenant
Environment identification: Distinguish between production, staging, and development traffic
Cost allocation: Track usage by department, project, or business unit
Service organization: Identify traffic by service name, version, or component
Qplane filtering: Filter and organize captured traffic in the Qplane UI by custom dimensions
Custom tags appear in the tags object of Connection events (event store) alongside default tags like bin, host, ip, protocol, and strategy. Tags are connection-level metadata and do not appear in HTTP transaction objects (object store).
Configuration
Custom tags are defined in the tags section of your qtap configuration:
All tag values from all sources are preserved in the array.
Use Cases
Multi-Tenant SaaS Platform
Tag traffic by tenant and tier for cost allocation:
Run application:
Microservices Environment
Identify traffic by service, version, and team:
Cost Tracking by Department
Tag traffic for cost allocation across departments:
Run application:
Environment-Specific Tagging
Distinguish between production, staging, and development:
Run in production:
Run in staging:
Viewing Tags in Qplane
When qtap is connected to Qplane, custom tags appear in the Qplane UI and can be used for:
Filtering connections: Filter by team, environment, service, etc.
Grouping traffic: Group connections by custom dimensions
Creating dashboards: Visualize traffic patterns by custom tags
Setting alerts: Alert on traffic patterns for specific tags
Custom tags make it easy to organize and filter large volumes of captured traffic across multiple teams, services, and environments.
Best Practices
Security Considerations
Avoid tagging sensitive data: Don't extract environment variables or labels that contain secrets, credentials, or personally identifiable information (PII).
Use Static Tags for Infrastructure
Use the --tags CLI flag for infrastructure-level tags that don't change per process:
Use YAML tags for application-level tags that vary per process:
Complete Example
Here's a complete configuration combining multiple tag sources:
Start qtap with static infrastructure tags:
Run your application with environment variables:
The resulting Connection events will include all tags:
apiVersion: v1
kind: Pod
metadata:
name: api-server
annotations:
app.version: "2.1.0"
owner: "platform-team"
spec:
containers:
- name: api
image: myapp:latest
tags:
# From environment variables
- key: environment
source: env
location: ENVIRONMENT
# From container labels
- key: service
source: container.label
location: service
# From Kubernetes labels
- key: team
source: k8s.label
location: team
# From Kubernetes annotations
- key: version
source: k8s.annotation
location: version
tags:
- key: service
source: k8s.label
location: app
- key: version
source: k8s.annotation
location: version
- key: team
source: k8s.label
location: team
# AVOID - these could contain sensitive data
tags:
- key: api_key
source: env
location: API_KEY # ❌ Never tag secrets
- key: user_email
source: env
location: USER_EMAIL # ❌ Avoid PII
# Good - safe metadata
tags:
- key: service
source: env
location: SERVICE_NAME # ✅ Safe
- key: team
source: env
location: TEAM # ✅ Safe
# Tag by region and cluster
qtap --tags='region:us-west-2,cluster:production,zone:a'
# Tag by datacenter and rack
qtap --tags='datacenter:dc1,rack:r42'
# Tag by application attributes
tags:
- key: service
source: env
location: SERVICE_NAME
- key: version
source: env
location: APP_VERSION