Synthetic Logs and Metrics: What the Files Contain
Logs explain discrete events; metrics describe numeric behavior over time. I generated both for anomaly-detection experiments, but inspecting the published files exposes an important limitation: they are internally trace-structured, yet they cannot currently be joined to each other.
The published artifacts are synthetic. They do not contain customer or internal production data.
The two files contain 600 traces, not 300 shared traces
The files have the same shape but were generated as separate datasets:
| File | Records | Unique traces | Spans per trace | Anomalous records | Anomalous traces |
|---|---|---|---|---|---|
application_logs.jsonl |
1,500 | 300 | 5 | 125 (8.33%) | 25 (8.33%) |
apm_metrics.jsonl |
1,500 | 300 | 5 | 95 (6.33%) | 19 (6.33%) |
Every trace is internally consistent: all five spans in a trace share the same synthetic anomaly label. However, the two files have zero shared trace IDs and zero shared span IDs. The identifiers connect records inside each file, but do not connect a log record to a metric record in the other file.
Application logs describe what happened
A log is a timestamped record emitted by an application, server, or device. Logs can support debugging, performance monitoring, progress tracking, security audits, and pattern analysis because each record carries event context.
The downloadable application_logs.jsonl contains 1,500 records with:
timestamptrace_id,span_id, andparent_span_idservicelevelpathmessagestatuslatency_msis_anomaly
The sample contains services such as payment-service, log levels such as WARN, endpoint paths, HTTP-like status values, and latency measurements.
APM metrics describe how the system behaved
The downloadable apm_metrics.jsonl also contains 1,500 records. Each record includes:
timestamptrace_id,span_id, andparent_span_idservicecpumemorylatencythroughputis_anomaly
The metric values in the published file range from 20.04 to 99.99 for CPU, 30.02 to 99.94 for memory, 20.01 to 899.59 for latency, and 50 to 200 for throughput. These ranges describe this synthetic artifact, not production operating limits.
The is_anomaly field is synthetic ground truth for evaluating a detector; it must not be used as an input feature. Because five rows share one trace and one label, train/test splitting should also happen by trace_id. A row-level random split could place sibling spans from the same synthetic request on both sides of the evaluation.
The generators model anomalies at trace-chain level
The two scripts reference the same trace-chain design. For each request, they create spans across services and assign one anomaly state to the generated chain. Normal and anomalous values are sampled from different configured ranges.
generate_logs.pywrites the application-log records.generate_metrics.pywrites the APM-metric records.
The current scripts reference trace_chain.py, topology.json, config_logs.yaml, and config_metrics.yaml, which are not present in this repository. The JSONL artifacts can be downloaded and inspected, but the datasets cannot currently be regenerated from the two published scripts alone. This is a reproducibility gap, not merely a documentation gap.
The current artifacts support separate experiments
The metric file can support numeric anomaly-detection experiments using CPU, memory, latency, and throughput. The log file can support experiments using level, service, path, message, status, and latency. Within either file, trace-level aggregation can preserve the five-span request structure.
The current files cannot support a valid claim that a metric anomaly was explained by the log messages from the same request. Similar timestamps or service names are not a safe substitute for a shared trace ID.
Cross-signal RCA requires one shared generation pass
To create a genuinely linked dataset, one generated trace chain should be passed to both writers in the same run. The log and metric records for each span must reuse the same trace_id, span_id, parent_span_id, timestamp, service, and anomaly state; only the signal-specific fields should differ.
That design would make the intended analysis possible: a latency or CPU anomaly could be joined to the exact log events from the same request. Until the missing generator files are published and the identifiers are shared, the honest boundary is two separate synthetic experiments rather than one combined root-cause-analysis dataset.
Reference: Splunk — What is log data?