Component Overview
Internal Architecture
Protocol Modules
Each distribution includes modules for specific protocols:
Modules are stateless. They parse incoming requests, evaluate policies, and
forward results. All state lives in the policy registry.
Policy Registry
The registry holds all loaded policies and provides lock-free read access during request processing. Key properties:- Atomic snapshots: Writers create new snapshots; readers use existing ones
- Lock-free reads: No contention during policy evaluation
- Hot reload: New policies take effect without restart
Policy Engine
The engine evaluates policies against telemetry using Vectorscan (a Hyperscan fork) for regex matching. Evaluation flow:- Index lookup: Find policies that might match based on field keys
- Regex scan: Evaluate regex patterns against field values
- Action merge: Combine keep/transform actions from matching policies
- Apply: Execute the merged actions
Policy Providers
Providers load policies from external sources:
Multiple sources can be configured. Policies from all sources merge together.
The policy ID acts as a unique key. If two providers emit a policy with the same
ID, the one from the higher-priority source (HTTP > file) wins. Same-priority
sources will have the later update win. This structure allows you to create a
set of default policies that can be overridden remotely.
Design Principles
Data-Oriented Design
Edge optimizes for memory access patterns and cache coherency. It lays out data structures for sequential access to minimize cache misses during high-throughput processing.Lock-Free Reads
Policy evaluation reads policies on each request, while updates stay rare. Edge uses atomic pointers to policy snapshots, eliminating read-side synchronization.Fail-Open
Edge prioritizes availability. If policy evaluation fails, Edge forwards the telemetry unchanged. A filter may not apply, and no data is dropped.Stateless Modules
Protocol modules are stateless. Each module:- Parses the request
- Reads policies from the registry
- Applies policies to the data
- Forwards to upstream
Performance Characteristics
Performance depends on:
- Number of regex patterns (more patterns = more evaluation time)
- Request body size (larger bodies take longer to parse)
Deployment Patterns
Gateway
Deploy Edge as a shared gateway for multiple services: Use Case: Tero Edge sits at the egress point after your telemetry pipeline. It acts as a final gateway before data leaves your network and applies cost-focused policies that reduce egress to SaaS vendors. Drop redundant health checks and sample high-cardinality metrics before your provider bills for them. Best for:- Centralized policy management
- Environments with many services
- When you want a single point of control
Sidecar
Deploy Edge alongside each service: Use Case: Tero Edge runs as a lightweight sidecar next to each application. It applies policies at the source by dropping noisy debug logs, redacting PII, or sampling high-volume metrics before data reaches the telemetry pipeline. This reduces load on collectors and network bandwidth within your infrastructure. Best for:- Service-specific policies
- Isolation between services
- Kubernetes environments with sidecar injection
Next Steps
Quickstart
Get Edge running in 5 minutes
Reference
Full configuration reference