You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/agentpond-sync.md
+18-8Lines changed: 18 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,29 +2,39 @@
2
2
3
3
## Goal
4
4
5
-
AgentPond stores raw ingestion events in a remote object storage (e.g. S3) and uses DuckDB as a local query cache. Object storage is the durable source of truth; DuckDB is the materialized analysis layer.
5
+
AgentPond stores raw OTEL payloads and Langfuse-compatible score ingestion events in remote object storage (e.g. S3) and uses DuckDB as a local query cache. Object storage is the durable source of truth; DuckDB is the materialized analysis layer.
6
6
7
7
## Write Path
8
8
9
-
Ingestion validates incoming events before accepting them. Accepted events are grouped by entity, such as trace, observation, score, or event.
9
+
OTEL ingestion validates and decodes trace export requests, then stores raw `resourceSpans` under UTC minute buckets:
10
10
11
-
Each group is written as a JSON object under the configured object-store prefix and project ID. With `AGENTPOND_S3_PREFIX=archive/` and `AGENTPOND_PROJECT_ID=project-a`, trace objects are written under paths like `archive/project-a/trace/<trace-id>/<event-id>.json`.
A batch manifest is then written under the same prefix and project ID, in `archive/project-a/manifests/...`, and references all entity objects in the accepted batch.
15
+
Non-OTEL ingestion remains for Langfuse SDK scores. Accepted non-OTEL events are grouped by entity, written under the configured project prefix, and referenced by a UTC minute-bucketed manifest:
`agentpond sync` lists manifests for the configured object-store prefix and project ID.
24
+
`agentpond sync` scans UTC bucket windows for both sources:
25
+
26
+
- OTEL objects are read directly from `otel/<project-id>/...` and normalized during sync.
27
+
- Non-OTEL manifests are read from `<project-id>/manifests/...`; sync then reads their referenced event objects.
18
28
19
-
For each new manifest, sync reads the referenced event objects, writes every event to `events_raw`table in DuckDB, and projects typed rows into `traces`, `observations`, and `scores` tables.
29
+
Every normalized event is written to `events_raw` and projected into `traces`, `observations`, and `scores`.
20
30
21
31
The `sessions` relation is a DuckDB view derived from traces with session IDs.
22
32
23
33
## Idempotency
24
34
25
-
DuckDB tracks imported manifests in `processed_manifests`and imported event objects in `processed_objects`.
35
+
DuckDB tracks imported OTEL objects and non-OTEL event objects in `processed_objects`. Non-OTEL manifests are tracked in `processed_manifests`.
26
36
27
-
Running sync repeatedly is safe: already processed manifests and objects are skipped.
37
+
DuckDB also stores per-source UTC bucket watermarks. The first sync scans all current-layout source keys; later syncs rescan recent buckets for late writes and skip already processed object or manifest keys.
0 commit comments