Sonda
Sonda is a synthetic telemetry generator written in Rust. It produces realistic observability signals — metrics, logs, traces, and flows — for use in lab environments, pipeline validation, load testing, and incident simulation.
Its purpose is not to produce perfectly regular data or pure random noise, but to model the kinds of failure patterns that actually break real observability pipelines: gaps, micro-bursts, cardinality changes, and pattern-driven value sequences.
The core library (sonda-core) is the product. The CLI is a delivery mechanism built on top of it.
Features
- Multiple value generators — constant, uniform random (seeded for deterministic replay), sine wave, sawtooth ramp.
- Intentional gap windows — recurring silent periods that test alert flap detection, gap-fill logic, and buffer sizing.
- Burst windows — recurring high-rate periods that simulate micro-bursts and traffic spikes.
- Prometheus text exposition format — output is valid
text/plain 0.0.4ready for scraping or piping. - Static binary — statically linked for maximum portability: runs on bare metal, Docker, and CI without a runtime installation.
- YAML scenario files — all runtime behavior is defined in YAML; CLI flags override any value.
- Zero C dependencies — pure Rust throughout; compatible with
x86_64-unknown-linux-musl.
Installation
Install script (recommended)
Download and install the latest release for your platform:
|
Pin a specific version:
SONDA_VERSION=v0.1.0 |
Install to a custom directory:
SONDA_INSTALL_DIR=/.local/bin |
GitHub Releases
Download pre-built binaries for Linux (x86_64, aarch64) and macOS (x86_64, aarch64) from the GitHub Releases page. Each release includes SHA256 checksums for verification.
Docker
See the Docker Deployment section for usage details.
Helm
See the Kubernetes Deployment section for configuration options.
Cargo install
Library usage
Add sonda-core as a dependency to use the engine programmatically:
[]
= "0.1"
Example -- create a generator and encode a metric:
use ;
use ;
use MetricEvent;
// Create a sine wave generator
let gen_config = Sine ;
let generator = create_generator;
// Generate a value at tick 0
let value = generator.value;
// Encode a metric event
let encoder = create_encoder;
let event = MetricEvent ;
let mut buf = Vecnew;
encoder.encode_metric.unwrap;
Build from source
# Debug build (for development)
# Release build
# Fully static musl binary (requires musl target)
The resulting binary is at target/release/sonda (or target/x86_64-unknown-linux-musl/release/sonda
for the musl build).
Quick Start
Generate 10 Prometheus metric lines per second for 5 seconds:
Example output:
up 1 1742500000123
up 1 1742500000223
up 1 1742500000323
...
Generate a sine wave with labels:
Example output:
cpu_usage{hostname="t0-a1",zone="eu1"} 50 1742500000100
cpu_usage{hostname="t0-a1",zone="eu1"} 50.1045 1742500000110
...
Run from a YAML scenario file:
CLI Reference
sonda <COMMAND>
Commands:
metrics Generate synthetic metrics and write them to the configured sink
logs Generate synthetic log events and write them to the configured sink
run Run multiple scenarios concurrently from a multi-scenario YAML file
help Print help information
Options:
-h, --help Print help
-V, --version Print version
sonda metrics
Usage: sonda metrics [OPTIONS]
Options:
--scenario <SCENARIO>
Path to a YAML scenario file.
When provided, loaded first; CLI flags override file values.
--name <NAME>
Metric name emitted by this scenario.
Must match [a-zA-Z_:][a-zA-Z0-9_:]*.
Required when no --scenario file is provided.
--rate <RATE>
Target event rate in events per second.
Must be strictly positive. Supports fractional values (e.g. 0.5).
Required when no --scenario file is provided.
--duration <DURATION>
Total run duration (e.g. "30s", "5m", "1h", "100ms").
When absent the scenario runs indefinitely until Ctrl+C.
--value-mode <VALUE_MODE>
Value generator mode.
Accepted values: constant, uniform, sine, sawtooth.
Default: constant.
--amplitude <AMPLITUDE>
Sine wave amplitude (half the peak-to-peak swing).
Used with --value-mode sine. Default: 1.0.
--period-secs <PERIOD_SECS>
Sine wave or sawtooth period in seconds.
Used with --value-mode sine or sawtooth. Default: 60.0.
--offset <OFFSET>
Sine wave midpoint, or the constant value for --value-mode constant.
Default: 0.0.
--min <MIN>
Minimum value for the uniform generator.
Used with --value-mode uniform. Default: 0.0.
--max <MAX>
Maximum value for the uniform generator.
Used with --value-mode uniform. Default: 1.0.
--seed <SEED>
RNG seed for the uniform generator (enables deterministic replay).
When absent a seed of 0 is used.
--gap-every <GAP_EVERY>
Gap recurrence interval (e.g. "2m").
Together with --gap-for, defines a recurring silent period.
Both --gap-every and --gap-for must be provided together.
--gap-for <GAP_FOR>
Gap duration within each cycle (e.g. "20s").
Must be strictly less than --gap-every.
--burst-every <BURST_EVERY>
Burst recurrence interval (e.g. "10s").
Together with --burst-for and --burst-multiplier, defines a recurring
high-rate period. All three --burst-* flags must be provided together.
--burst-for <BURST_FOR>
Burst duration within each cycle (e.g. "2s").
Must be strictly less than --burst-every.
--burst-multiplier <BURST_MULTIPLIER>
Rate multiplier applied during each burst window (e.g. "5.0").
Effective rate during burst = base rate × multiplier.
Must be strictly positive.
--label <key=value>
Static label attached to every emitted event (repeatable).
Format: key=value. Keys must match [a-zA-Z_][a-zA-Z0-9_]*.
Example: --label hostname=t0-a1 --label zone=eu1
--encoder <ENCODER>
Output encoder format.
Accepted values: prometheus_text, influx_lp, json_lines.
Default: prometheus_text.
--output <OUTPUT>
Write output to a file at this path instead of stdout.
Shorthand for sink: file in a YAML scenario.
-h, --help
Print help
sonda logs
Usage: sonda logs [OPTIONS]
Options:
--scenario <SCENARIO>
Path to a YAML log scenario file.
When provided, loaded first; CLI flags override file values.
--mode <MODE>
Log generator mode.
Accepted values: template, replay.
Required when no --scenario file is provided.
--file <FILE>
Path to a log file for use with --mode replay.
Lines are replayed in order, cycling back to the start when exhausted.
--rate <RATE>
Target event rate in events per second.
Must be strictly positive. Defaults to 10.0 when no scenario file is provided.
--duration <DURATION>
Total run duration (e.g. "30s", "5m", "1h", "100ms").
When absent the scenario runs indefinitely until Ctrl+C.
--encoder <ENCODER>
Output encoder format.
Accepted values: json_lines, syslog. Default: json_lines.
--output <OUTPUT>
Write output to a file at this path instead of stdout.
Shorthand for sink: file in a YAML scenario.
--label <key=value>
Static label attached to every emitted event (repeatable).
Format: key=value.
Example: --label hostname=t0-a1 --label zone=eu1
--message <MESSAGE>
A single static message template for use with --mode template.
Overrides any templates in the scenario file.
--severity-weights <WEIGHTS>
Comma-separated severity=weight pairs (e.g. "info=0.7,warn=0.2,error=0.1").
Used with --mode template.
--seed <SEED>
RNG seed for deterministic template resolution.
When absent a seed of 0 is used.
--replay-file <REPLAY_FILE>
Alias for --file. Path to the log file for --mode replay.
--gap-every <GAP_EVERY>
Gap recurrence interval (e.g. "2m").
Together with --gap-for, defines a recurring silent period.
--gap-for <GAP_FOR>
Gap duration within each cycle (e.g. "20s").
Must be strictly less than --gap-every.
--burst-every <BURST_EVERY>
Burst recurrence interval (e.g. "5s").
Together with --burst-for and --burst-multiplier, defines a recurring high-rate period.
--burst-for <BURST_FOR>
Burst duration within each cycle (e.g. "1s").
Must be strictly less than --burst-every.
--burst-multiplier <BURST_MULTIPLIER>
Rate multiplier during burst periods (e.g. 10.0 for 10x the base rate).
-h, --help
Print help
sonda run
Usage: sonda run --scenario <SCENARIO>
Options:
--scenario <SCENARIO>
Path to a multi-scenario YAML file.
Each entry in the `scenarios:` list specifies a `signal_type` key
(`metrics` or `logs`) and the full scenario configuration for that signal.
All scenarios start concurrently on separate threads and run independently
until they complete or until Ctrl+C is received.
-h, --help
Print help
Run multiple scenarios concurrently from a single YAML file:
The multi-scenario YAML uses a scenarios: list. Each entry specifies a signal_type of
either metrics or logs, followed by the full scenario configuration:
scenarios:
- signal_type: metrics
name: cpu_usage
rate: 100
duration: 30s
generator:
type: sine
amplitude: 50
period_secs: 60
offset: 50
encoder:
type: prometheus_text
sink:
type: stdout
- signal_type: logs
name: app_logs
rate: 10
duration: 30s
generator:
type: template
templates:
- message: "Request from {ip} to {endpoint}"
field_pools:
ip:
- "10.0.0.1"
- "10.0.0.2"
endpoint:
- "/api/v1/health"
- "/api/v1/metrics"
severity_weights:
info: 0.7
warn: 0.2
error: 0.1
seed: 42
encoder:
type: json_lines
sink:
type: file
path: /tmp/sonda-logs.json
See examples/multi-scenario.yaml for a complete example.
YAML Scenario Files
All flags can be expressed in a YAML file. CLI flags override any value in the file.
name: interface_oper_state
rate: 1000
duration: 30s
generator:
type: sine
amplitude: 5.0
period_secs: 30
offset: 10.0
gaps:
every: 2m
for: 20s
bursts:
every: 10s
for: 2s
multiplier: 5.0
labels:
hostname: t0-a1
zone: eu1
encoder:
type: prometheus_text
sink:
type: stdout
Run it with:
Override the rate from the CLI:
Metric generator types
type |
Parameters | Description |
|---|---|---|
constant |
value: f64 |
Emits a fixed value every tick. |
uniform |
min: f64, max: f64, seed: u64 (optional) |
Uniformly distributed random value in [min, max]. Seeded for deterministic replay. |
sine |
amplitude: f64, period_secs: f64, offset: f64 |
Sine wave: offset + amplitude * sin(2π * tick / period_ticks). |
sawtooth |
min: f64, max: f64, period_secs: f64 |
Linear ramp from min to max that resets at the period boundary. |
Encoder types
The encoder field selects the wire format. Use a mapping with a type key:
type |
Parameters | Description |
|---|---|---|
prometheus_text |
(none) | Prometheus text exposition format 0.0.4. |
influx_lp |
field_key: string (optional, default "value") |
InfluxDB line protocol. |
json_lines |
(none) | JSON Lines (NDJSON), one object per line. |
syslog |
hostname: string (optional), app_name: string (optional) |
RFC 5424 syslog format. Log events only — not supported for metrics. |
encoder:
type: influx_lp
field_key: requests
Sink types
The sink field selects the output destination. Use a mapping with a type key:
type |
Parameters | Description |
|---|---|---|
stdout |
(none) | Write to standard output (buffered). Default. |
file |
path: string |
Write to a file. Parent directories are created automatically. |
tcp |
address: string |
Write over a persistent TCP connection (e.g. "127.0.0.1:9999"). |
udp |
address: string |
Send each event as a UDP datagram (e.g. "127.0.0.1:9999"). |
http_push |
url: string, content_type: string (optional), batch_size: usize (optional) |
POST batches of encoded events to an HTTP endpoint. Retries once on 5xx. |
kafka |
brokers: string, topic: string |
Publish batches of encoded events to a Kafka topic (requires kafka feature). brokers is a comma-separated list of host:port addresses. |
loki |
url: string, labels: map (optional), batch_size: usize (optional) |
POST log streams to the Loki push API (/loki/api/v1/push). labels are static key-value pairs attached to the log stream. Log events only — not supported for metrics. |
# Write to a file
sink:
type: file
path: /tmp/sonda-output.txt
# Send over TCP
sink:
type: tcp
address: "127.0.0.1:9999"
# Send over UDP
sink:
type: udp
address: "127.0.0.1:9999"
# POST batches to an HTTP endpoint
sink:
type: http_push
url: "http://localhost:9090/api/v1/otlp/metrics"
content_type: "text/plain; version=0.0.4"
batch_size: 65536
# Publish batches to a Kafka topic (requires the `kafka` feature)
sink:
type: kafka
brokers: "127.0.0.1:9092"
topic: sonda-metrics
Gap windows
A gap window defines a recurring silent period. No events are emitted during the gap; the scheduler sleeps to avoid busy-waiting.
gaps:
every: 2m # one gap every 2 minutes
for: 20s # each gap lasts 20 seconds
for must be strictly less than every.
Burst windows
A burst window defines a recurring high-rate period. During a burst the effective event rate is
rate × multiplier, which increases the emission frequency for the burst duration. Bursts are useful
for simulating traffic spikes, micro-burst patterns, and ingest pipeline stress.
bursts:
every: 10s # one burst every 10 seconds
for: 2s # each burst lasts 2 seconds
multiplier: 5.0 # 5x the base rate during the burst
for must be strictly less than every. multiplier must be strictly positive.
When a gap and a burst would overlap, the gap takes priority and no events are emitted.
Log Scenario Files
Log scenarios use a different config structure from metric scenarios. Run with sonda logs --scenario <file.yaml>.
name: app_logs_template
rate: 10
duration: 60s
generator:
type: template
templates:
- message: "Request from {ip} to {endpoint} returned {status}"
field_pools:
ip:
- "10.0.0.1"
- "10.0.0.2"
- "10.0.0.3"
endpoint:
- "/api/v1/health"
- "/api/v1/metrics"
status:
- "200"
- "404"
- "500"
severity_weights:
info: 0.7
warn: 0.2
error: 0.1
seed: 42
gaps:
every: 2m
for: 20s
bursts:
every: 5s
for: 1s
multiplier: 10.0
encoder:
type: json_lines
sink:
type: stdout
Run it with:
Log generator types
type |
Parameters | Description |
|---|---|---|
template |
templates: list, severity_weights: map (optional), seed: u64 (optional) |
Generates structured log events from message templates with field pools. Placeholders like {ip} are resolved from the matching pool entry using a deterministic hash of the seed and tick. |
replay |
file: string |
Replays lines from a file at the configured rate, cycling back to the start when exhausted. Each line becomes a log event with severity info. |
LogScenarioConfig YAML schema
| Field | Type | Default | Description |
|---|---|---|---|
name |
string |
required | Scenario name (used for identification). |
rate |
f64 |
required | Target event rate in events per second. Must be strictly positive. |
duration |
string |
none (indefinite) | Total run duration (e.g. "30s", "5m"). |
generator |
object |
required | Log generator configuration. See log generator types above. |
gaps |
object |
none | Optional gap window: every and for duration strings. |
bursts |
object |
none | Optional burst window: every, for, and multiplier. |
encoder |
object |
{type: json_lines} |
Output encoder. Accepted values: json_lines, syslog. |
sink |
object |
{type: stdout} |
Output sink. Any sink type supported by metric scenarios. |
Example Scenarios
Example scenario files are included in the examples/ directory.
examples/basic-metrics.yaml
A 30-second sine wave at 1000 events/sec with labels and a recurring gap:
examples/simple-constant.yaml
A 10-second constant up=1 metric at 10 events/sec:
examples/tcp-sink.yaml
Sine wave sent over TCP (start a listener first with nc -l 9999):
&
examples/udp-sink.yaml
Constant metric sent as UDP datagrams in JSON Lines format (listen with nc -u -l 9998):
&
examples/file-sink.yaml
Sawtooth wave written to a file in InfluxDB line protocol:
examples/http-push-sink.yaml
Sine wave POSTed in batches to an HTTP endpoint (start a local receiver first):
# Listen with netcat (for testing)
&
examples/kafka-sink.yaml
Constant metric published in batches to a local Kafka broker (requires kafka feature):
# Start a local Kafka broker first (e.g. via Docker)
examples/influx-file.yaml
Sawtooth ramp in InfluxDB line protocol written to /tmp/sonda-influx-output.txt:
Output looks like:
disk_io_bytes,device=sda,host=storage-01 bytes=0.0 1742500000000000000
disk_io_bytes,device=sda,host=storage-01 bytes=20000.0 1742500000020000000
...
examples/burst-metrics.yaml
A sine wave at 100 events/sec that bursts to 500 events/sec for 2 seconds out of every 10 seconds:
Count lines during a burst second to see the rate spike:
|
examples/json-tcp.yaml
HTTP request duration sine wave streamed as JSON Lines over TCP (start a listener first):
&
Output looks like:
examples/prometheus-http-push.yaml
Prometheus text exposition format POSTed in batches to an HTTP endpoint. Compatible with VictoriaMetrics, vmagent, and any endpoint that accepts the Prometheus text format over HTTP:
# Quick test with netcat
&
# Against VictoriaMetrics
# Edit the url in the YAML to: http://localhost:8428/api/v1/import/prometheus
examples/log-template.yaml
Template-based log generation at 10 events/sec for 60 seconds. Emits JSON Lines to stdout with varied messages, field values, and severity levels (70% info, 20% warn, 10% error):
Output looks like:
examples/log-replay.yaml
Replay lines from an existing log file at 5 events/sec for 30 seconds. Lines cycle when the file
is exhausted. Update the file: path in the YAML to point to a real log file:
examples/loki-json-lines.yaml
Push JSON Lines log events to a Loki instance at 10 events/sec for 60 seconds. Logs are batched
(batch size 50) and pushed via Loki's HTTP API. Requires the e2e stack (task stack:up):
examples/kafka-json-logs.yaml
Send JSON Lines log events to a Kafka topic (sonda-logs) at 10 events/sec for 60 seconds.
Requires the e2e stack with Kafka running (task stack:up):
examples/docker-metrics.yaml
CPU usage sine wave (30-70%) at 10 events/sec for 120 seconds with a recurring 5-second gap. Designed for the Docker Compose stack:
examples/docker-alerts.yaml
Sine wave (0-100) that crosses alert thresholds with burst windows. Useful for testing Prometheus/Alertmanager alert rules:
Output Format
Output is Prometheus text exposition format
(text/plain 0.0.4). Each line is one sample:
metric_name{label1="val1",label2="val2"} value timestamp_ms
- Labels are sorted alphabetically by key.
- Timestamp is milliseconds since Unix epoch.
- Label values are escaped (
\,", and newlines). - When there are no labels, the
{}is omitted.
Example:
cpu_usage{hostname="t0-a1",zone="eu1"} 50.523 1742500001000
up 1 1742500001000
Piping and Integration
Count lines produced in 5 seconds at 100 events/sec:
|
# expect ~500
Feed into a pipeline:
|
Workspace Layout
sonda/
├── sonda-core/ library crate: all engine logic (generators, encoder, scheduler, sinks)
├── sonda/ binary crate: CLI (thin wrapper over sonda-core)
├── sonda-server/ binary crate: HTTP API control plane (post-MVP)
├── examples/ example YAML scenario files
└── docs/ architecture doc, phase plans
sonda-core is the primary product and is designed to be reusable as a library dependency.
sonda-server — HTTP Control Plane
sonda-server exposes a REST API for starting, inspecting, and stopping scenarios over HTTP.
It is useful for integrating Sonda into CI pipelines, test harnesses, or dashboards without shell
access.
Starting the server
# Build and run on the default port (8080)
# Specify a custom port and bind address
The server logs bind address and status to stderr using structured tracing output. The log
level can be controlled via the RUST_LOG environment variable (default: info):
RUST_LOG=debug
Press Ctrl+C for a graceful shutdown — the server signals all running scenarios to stop before exiting.
Health check
# {"status":"ok"}
Start a scenario (POST /scenarios)
Post a YAML scenario body to start a running scenario. The server accepts both
application/x-yaml (text/yaml) and application/json content types.
Bare metrics or logs YAML (without signal_type) is also supported.
# Start a metrics scenario from an example file
# {"id":"550e8400-e29b-41d4-a716-446655440000","name":"interface_oper_state","status":"running"}
# Start a logs scenario
# {"id":"7c9e6679-7425-40de-944b-e07fc1f90ae7","name":"app_logs_template","status":"running"}
# Use the signal_type tag to specify metrics or logs explicitly
Error responses:
400 Bad Request— body cannot be parsed as YAML or JSON.422 Unprocessable Entity— body is valid YAML/JSON but fails validation (e.g.rate: 0).500 Internal Server Error— scenario thread could not be spawned.
API endpoints (implemented by slice)
| Method | Path | Slice | Description |
|---|---|---|---|
| GET | /health |
3.1 | Health check |
| POST | /scenarios |
3.2 | Start a new scenario from YAML/JSON body |
| GET | /scenarios |
3.3 | List all running scenarios |
| GET | /scenarios/:id |
3.3 | Inspect a scenario: config, stats, elapsed |
| DELETE | /scenarios/:id |
3.4 | Stop and remove a running scenario |
| GET | /scenarios/:id/stats |
3.5 | Live stats: rate, events, gap/burst state |
Docker Deployment
Sonda ships as a minimal Docker image built from scratch with statically linked musl binaries.
Both the sonda CLI and sonda-server HTTP API are included in the image.
Building the image
The multi-stage Dockerfile builds static musl binaries and copies them into a scratch base
image. The final image contains only the two binaries and is typically under 20 MB.
Multi-arch images are available for linux/amd64 and linux/arm64. To build a multi-arch image locally using Docker Buildx:
Pre-built multi-arch images are published to GitHub Container Registry on each tagged release. Docker automatically pulls the correct architecture for your host.
Running with Docker
# Run the server on port 8080
# Run the CLI instead
# Mount scenario files from the host
Docker Compose stack
A docker-compose.yml is included with a realistic observability stack for demos and testing:
| Service | Port | Description |
|---|---|---|
sonda-server |
8080 | Sonda HTTP API (built from the Dockerfile) |
prometheus |
9090 | Prometheus (scrape or receive remote-write) |
alertmanager |
9093 | Alertmanager for alert routing |
grafana |
3000 | Grafana dashboards (admin password: admin) |
Start the stack:
Verify the server is running:
# {"status":"ok"}
Post a scenario to the running server:
# Start a metrics scenario
# Start an alert-testing scenario
# List running scenarios
# View live stats for a scenario
# Stop a scenario
Open Grafana at http://localhost:3000 to explore metrics. Prometheus is available at http://localhost:9090 for querying.
Tear down the stack:
Docker scenario examples
Two scenario files are provided specifically for the Docker stack:
-
examples/docker-metrics.yaml-- CPU usage sine wave (30-70%) with recurring gaps. Useful for testing metric pipelines and gap-fill behavior. -
examples/docker-alerts.yaml-- Sine wave (0-100) that crosses typical warning (70) and critical (90) thresholds. Includes bursts for spike simulation. Useful for testing alert rules in Prometheus or Alertmanager.
Kubernetes Deployment (Helm)
Sonda includes a Helm chart for deploying sonda-server to Kubernetes clusters. The chart
configures liveness and readiness probes using the /health endpoint, supports scenario
injection via ConfigMap, and follows Helm best practices for labels and resource management.
Installing the chart
# Install with default values (port 8080, 1 replica)
# Install with a custom port
# Install with custom resource limits
Configuring scenarios
Scenarios are injected as a ConfigMap mounted at /scenarios inside the container. Define
them in values.yaml under the scenarios key:
scenarios:
cpu-metrics.yaml: |
name: cpu_usage
rate: 100
duration: 30s
generator:
type: sine
amplitude: 50
period_secs: 60
offset: 50
encoder:
type: prometheus_text
sink:
type: stdout
Or pass them at install time:
Health probes
The Deployment configures both liveness and readiness probes using GET /health on the
server port. This endpoint always returns {"status":"ok"} with HTTP 200 when the server
is running, so pods are automatically restarted if the server becomes unresponsive.
Accessing the server
After installation, use kubectl port-forward to access the API:
# Then use the API as normal
Uninstalling
Development
# Build everything
# Run all tests
# Lint
# Format check
# Run the CLI in development
End-to-End Integration Tests
The tests/e2e/ directory contains a docker-compose based test suite that validates sonda against
real observability backends and message brokers.
Prerequisites
- Docker with the Compose v2 plugin (
docker compose) - Task (optional — for convenient task runner commands)
curlandpython3in PATH- Rust toolchain (for
cargo build)
Services
| Service | Port | Purpose |
|---|---|---|
victoriametrics |
8428 | VictoriaMetrics single-node (push target and query endpoint) |
prometheus |
9090 | Prometheus with remote write receiver enabled |
vmagent |
8429 | vmagent that relays incoming pushes to VictoriaMetrics |
kafka |
9094 | Kafka broker (KRaft mode, no Zookeeper) |
kafka-ui |
8080 | Kafka UI for browsing topics and messages |
grafana |
3000 | Grafana with VictoriaMetrics, Prometheus, and Loki datasources pre-configured |
loki |
3100 | Loki log aggregation system (push target for sonda logs) |
Test scenarios
VictoriaMetrics scenarios (verified by querying /api/v1/series):
| Scenario file | Encoder | Sink target | Metric verified |
|---|---|---|---|
vm-prometheus-text.yaml |
prometheus_text |
VictoriaMetrics /api/v1/import/prometheus |
sonda_e2e_vm_prom_text |
vm-influx-lp.yaml |
influx_lp |
VictoriaMetrics /write |
sonda_e2e_vm_influx_lp_value |
Kafka scenarios (verified by consuming from topic):
| Scenario file | Encoder | Kafka topic | Metric verified |
|---|---|---|---|
kafka-prometheus-text.yaml |
prometheus_text |
sonda-e2e-metrics |
messages consumed > 0 |
kafka-json-lines.yaml |
json_lines |
sonda-e2e-json |
messages consumed > 0 |
Using the Taskfile
The project includes a Taskfile.yml for common operations:
Exploring metrics visually
Start the stack and send some data:
Then open the dashboards:
- Grafana — http://localhost:3000 (anonymous access, VictoriaMetrics datasource pre-configured). Go to Explore, select VictoriaMetrics, and query
demo_sine_wave. - Kafka UI — http://localhost:8080. Browse topics
sonda-e2e-metricsandsonda-e2e-jsonto see messages. - VictoriaMetrics — http://localhost:8428/vmui for the built-in query UI.
Running the automated tests
# Via Taskfile
# Or directly
The script starts the docker-compose stack, waits for all services to become healthy, builds sonda
in release mode, runs each scenario, verifies data arrived (VictoriaMetrics via series API, Kafka
via consumer), and tears everything down. Exits 0 if all pass, 1 if any fail.
Running scenarios manually
# Start the stack
# Run individual scenarios
# Verify VictoriaMetrics
# Verify Kafka (consume from topic)
# Tear down
License
Licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE)
- MIT license (LICENSE-MIT)
at your option.