Observability Platform
Alopex OTel
Storage and dashboards in one product
Around OpenTelemetry, ingestion, storage, and visualization are usually separate products. The right composition differs by environment, with no fixed answer. Alopex OTel packages the whole set together. It scales from an embedded single process to multiple nodes while keeping the same screen and query language.
One package for the ingestion, storage, and visualization that otherwise surround OpenTelemetry.
- Processes to start
- 1
- Dashboard
- Built in
Key points
- Get ingestion, storage, and visualization together without selecting a combination
- The dashboard is embedded in the same process rather than built separately
- The UI and API stay the same as scale changes
Challenge
A change in scale means rebuilding observability
A one-machine setup and a multi-node setup are different things. Products, screens, and query languages are all replaced. Alopex OTel aims to use the same screen and queries from embedded deployments through clusters.
- Before starting, someone must decide what to combine and how
- When scale changes, the deployment and dashboards must be rebuilt
- Every migration also raises the question of what to do with stored data
Observability is usually built by combining ingestion, storage, and visualization. The composition differs by environment, and changing scale means choosing again.
Alopex OTel packages the entire set in one binary. Its dashboard is embedded in the same process. From an embedded single process to multiple nodes, the screen and query language remain the same.
Inside, Skulk handles metrics, Trail handles traces and logs, and Chirps acts as the logical router that absorbs differences in deployment scale. Chirps transparently routes in-process and network calls, so callers do not change when moving from embedded to distributed operation.
Add nodes while keeping one binary
Alopex OTel puts ingestion through visualization in one product. Start in an embedded single process, then move to a local server, two or three nodes, and multiple nodes without changing the screen, API, or query language.
- One process to start and no wiring configuration
- One location for retention policy
- Nothing new to learn when scale changes
- Processes to start
- 1
- UI changes when scaling
- None
Capabilities
Four scales
Change only the scale while keeping the same screen and query language.
Embedded
For single-process applications
- Ship it inside an application without an external process
- Keep observability entirely within the application
Local server
For development environments and small teams
- Run it on one machine and send data from multiple applications
- Keep the dashboard in the same process
Two or three nodes
For the point where redundancy becomes necessary
- Expand by adding nodes
- No need to reassemble the architecture
Multiple nodes
For production workloads
- The screen and API stay unchanged as scale changes
- No need to move stored data into another system
Features
Key features
What brings ingestion through visualization into one product.
Built-in dashboard
Visualization runs in the same process. There is no separate dashboard to construct and reconnect to each store.
Prometheus-compatible query API
Reuse existing queries and integrations, and keep the same language as requirements grow.
Metrics, traces, and logs in one place
Do not split storage by data type; follow them across the same interface.
One retention policy
Settings and retention periods live in one place. There is no separate configuration language per product.
Transparent from embedded to distributed
Move deployment scale without changing callers; in-process and network access work the same way.
Tech Stack
Technology stack
Combines components from the Alopex family.
Metrics
Alopex Skulk
Traces and logs
Alopex Trail
Routing
Chirps
Status
Development status
The metrics path is running in Skulk v0.3.0 and accepts Prometheus Remote Write. The dashboard, traces and logs through Trail, and scale-out are next.
Public Resources
The latest documents, code, and community links in one place.
Get Involved
What are you combining today?
Knowing where ingestion, storage, or visualization creates work in real deployments helps decide what to build first.