diff --git a/README.md b/README.md index 6fabc51..22b83bb 100644 --- a/README.md +++ b/README.md @@ -31,7 +31,7 @@ rerun it and check every figure a post cites. | [`clickstack-e2e/`](clickstack-e2e/) | Does the whole ClickHouse route work end to end, in containers? The released capture through a collector into the 10x receiver, the rows the receiver marked `offload` written to an object store and the rest inserted by ClickStack's own exporter, both sides read back as one table, the query shapes timed with their object-store requests, and a reconciliation of what left the receiver against what is stored. | Current. Behind [*Reading ClickHouse logs from the table and the bucket in one query*](https://www.log10x.com/blog/clickhouse-offload-merge-table/). | | [`clickstack-e2e-gaps/`](clickstack-e2e-gaps/) | The six questions the end to end run left open, each over the whole capture: what a day predicate prunes across thirty days of objects, whether Vector can write the cold branch, whether the Retriever indexes and queries that layout, what a container killed mid-stream costs line by line, which dashboard answers change when rows leave the hot table, and how the per-type policy compares with a collector-only policy on insert and merge CPU. Plus a second pass on four of them: Vector 0.58.0 writing Parquet beside JSON with the Parquet reader's own counters, a `GROUP BY` and an `ORDER BY ... LIMIT` through the Merge table, the collector configured as its code owners prescribe, the `TTL TO VOLUME 'cold'` alternative costed on the same capture, and ClickHouse issue 116888 demonstrated with its guard. | Current. Not behind a post. | | [`clickstack-rows-gate/`](clickstack-rows-gate/) | Which ClickHouse system table counts the rows written into the logs table to the row, with the Receiver regulating in lines with a service total: `system.part_log` NewPart rows equals the hot count in both runs, `system.query_log` written_rows drifts with the exporter's async-insert entries; the totals held to the row, a policy rewrite mid-window reset nothing, and the events unit takes effect only from the config or an engine option. | Current. The meter for the ClickHouse rows run. Not behind a post. | -| [`clickstack-rows/`](clickstack-rows/) | The ClickHouse rows run, metered: rows written into ClickStack held at a rate an hour while load grew 2.5x with a storm and a new service, read on ClickHouse's own `system.part_log`. FAIL as registered: the rate held at 0.99 to 1.04 of R in every complete 10-minute window but one, the floor has no allowance in the 10-minute test, one service's 1,422 new statements in a window passed their always-pass sample, and 33 rows were inserted twice. Rerun with the regulator's sample bound (config `baselineMaxOverTotal` 50): every 4-minute window under its bound, 10-minute windows 0.97 to 1.07 of R/6, every returned record stored once; fails as registered on the 10-minute sum alone. | Current. Not behind a post. | +| [`clickstack-rows/`](clickstack-rows/) | The ClickHouse rows run, metered: rows written into ClickStack held at a rate an hour while load grew 2.5x with a storm and a new service, read on ClickHouse's own `system.part_log`. FAIL as registered: the rate held at 0.99 to 1.04 of R in every complete 10-minute window but one, the floor has no allowance in the 10-minute test, one service's 1,422 new statements in a window passed their always-pass sample, and 33 rows were inserted twice. Rerun with the regulator's sample bound (config `baselineMaxOverTotal` 50): every 4-minute window under its bound, 10-minute windows 0.97 to 1.07 of R/6, every returned record stored once; fails as registered on the 10-minute sum alone. | Three runs. The first failed as registered (one 10-minute window at 1.36, 33 duplicates). With the sample bound, the rate held at 0.97 to 1.07 of R in every complete 10-minute window, none over, no duplicates. Beside a collector rule under the same 2.5x step, the hold read 0.91 to 1.13 (one window over the 1.10 bound, the storm's first) against the rule's 2.95 to 3.42; insert-plus-merge CPU did not separate the arms on this rig. | | [`splunk-license/`](splunk-license/) | Splunk bills on what its licence meter counts, not on a file size. What does the 10x Receiver in front of Splunk do to that number? The same capture through the same Universal Forwarder into the same instance, twice, raw and compact, measured from `license_usage.log` and from the Monitoring Console's own searches, with every compact event read back through the 10x Splunk app and compared to the text that went in. | Current. Not behind a post. | | [`datadog-flex-accounting/`](datadog-flex-accounting/) | Datadog bills Standard indexing per million events. When the 10x Receiver moves events from Standard to Flex Logs under the plan the 10x MCP writes, how many events and GB move, and what do they cost at Datadog's list prices? The released engine and MCP on one capture at three targets, counted two independent ways, priced per million events moved, with the custom metrics the Datadog metric output creates. Computed from the engine's counts at list price; no Datadog account needed. | Current. Not behind a post. | | [`datadog-service-control/`](datadog-service-control/) | Inside one service a Datadog service filter cannot split the volume, so the rules a person writes are filters on the service's logger names. On the kafka container of two public captures of the same code, what does the per-pattern plan the 10x MCP writes move against the fewest `@logger.name` filters that move as many events, and what does each do on the second capture with nothing re-tuned? Computed from the engine's counts; no Datadog account needed. | Current. Not behind a post. | diff --git a/clickstack-e2e/README.md b/clickstack-e2e/README.md index 55377e2..ed05a98 100644 --- a/clickstack-e2e/README.md +++ b/clickstack-e2e/README.md @@ -48,7 +48,7 @@ The run writes `results/clickstack-e2e-.md` and `results/results.json`. +--> Merge table over both <--+ ``` -The receiver reads two files: `conf/caps.csv` gives a byte cap per service, and +The receiver reads two files: `conf/caps.csv` gives a byte cap per service (this run counted bytes; the rows run counts events), and `conf/actions.csv` gives that service's disposition for the excess. Both must exist and neither may be empty, and a service with no row in the cap file is not regulated at all, which is what makes an uncapped service a control.