Installation Overview
Causely agents are lightweight components that can be installed on your servers in minutes to provide real-time root cause analysis. This page covers what gets deployed when you install Causely, the key benefits of its distributed architecture, and how to get started with the installation.
Causely works alongside your existing observability tools, processing telemetry data locally while keeping your raw data secure in your datacenter. The platform automatically discovers service dependencies, builds topology maps, and identifies root causes without requiring you to send terabytes of telemetry data to the cloud - resulting in dramatically lower costs and stronger privacy compared to traditional observability platforms.
Installation Options
You can install the Causely agent using either:
While the default installation deploys into a Kubernetes cluster, telemetry data can be ingested from any source. Causely's mediator listens for OpenTelemetry Protocol (OTLP) data on port 4317, making it easy to send data from existing OpenTelemetry Collectors or any OTLP-compatible source.
What Gets Deployed
When you install Causely, the following components are deployed in your infrastructure:
To learn more about how causely works, see How Causely Works.
The relevant documentation for your security considerations can be found in the Security section.
Mediator
The core component that runs locally in your environment and serves as the data processing layer:
- Symptom Detection: Converts telemetry from various sources into binary symptom states
- Topology Discovery: Automatically discovers services, infrastructure, and dependencies
- Local Processing: Keeps all raw telemetry local - no raw data leaves your datacenter
- OTLP Endpoint: Listens on port 4317 for OpenTelemetry Protocol data
The mediator handles secure communication with Causely's cloud-based causal reasoning engine, sending only distilled insights, never raw data.
eBPF Instrumentation (Default)
Causely leverages OpenTelemetry eBPF instrumentation, powered by Grafana Beyla, to automatically collect the following telemetry data:
- Service dependencies and communication patterns
- Synchronous and asynchronous communication signals
- Performance metrics without code changes
eBPF instrumentation can be disabled if you already have comprehensive telemetry coverage. However, we recommend keeping it enabled as it serves as telemetry quality assurance, ensuring you have complete visibility into service dependencies and communication patterns.
If your existing OpenTelemetry, Prometheus, or other telemetry sources already provide excellent coverage, you can disable eBPF to reduce overhead.
Executor
The Executor is an optional component and can be enabled as part of the deployment process. The Executor is responsible for executing remediation actions.
VictoriaMetrics
VictoriaMetrics is a timeseries database used by the agents and mediator to store additional timeseries data.
Data Sources and Integration
While the components are deployed via Helm or CLI, data can be sent to the Causely mediator from multiple sources. See all available telemetry sources for a complete list, but make sure you have at least one source providing traces for the platform to be most effective. Without traces, Causely's ability to discover service dependencies and perform root cause analysis is severely limited.
Any source that generates OpenTelemetry traces is perfect - Causely comes with auto-instrumentation for that, but if you already have another solution like groundcover, Odigos, Grafana Beyla, an existing OpenTelemetry Collector, you can use those as well.
Additionally, Causely can leverage data from datadog and dynatrace to discover service dependencies.
Key Benefits of Causely's Architecture
Causely's distributed architecture provides significant advantages over traditional observability approaches:
Cost of Ownership
Minimal Egress Costs
- Only distilled insights are sent to the cloud, not raw telemetry data
- Dramatically reduces data transfer costs compared to sending 100% of traces/metrics/logs
- Especially impactful for high-volume environments generating terabytes of telemetry
Lightweight Footprint
- Mediator doesn't retain weeks, months, or years of historical data
- Focuses on real-time analysis rather than long-term storage
- Minimal resource consumption in your infrastructure
Zero Instrumentation Overhead
- No need for engineers to spend time instrumenting traces in application code
- Leverages eBPF for automatic, zero-code instrumentation
- Starts providing value immediately upon deployment
Security & Privacy
Your Data Stays Local
- All raw telemetry data remains in your datacenter
- No sensitive application data, logs, or metrics are transmitted
- Only anonymized, distilled insights are sent to Causely's cloud engine
Distributed Processing
- Mediator can be deployed at the edge of your infrastructure
- No need to send data across regions or clouds
- Maintains data sovereignty and compliance requirements
Data Efficiency
Intelligent Data Processing
- Processes only the signals needed for causal reasoning
- Eliminates the need to store and analyze 100% of your telemetry data
- Focuses on actionable insights rather than data hoarding
Comparison to Traditional Approaches
- Traditional observability platforms require ingesting and storing all telemetry data
- Causely's approach processes only what's needed for root cause analysis
- Results in orders of magnitude less data transmission and storage
Next Steps
After installation, we recommend:
- Connect Additional Data Sources: Visit Telemetry Sources to learn about supported integrations
- Configure Workflows: Set up notifications in Workflow Integrations for Slack, PagerDuty, and more
- Customize Your Setup: Learn about advanced configuration options in Customize Installation
For a detailed explanation of how Causely works, see How Causely Works.