telemetry: add cloud_region_latency table and carry cloud identity on records - #4319
Draft
thijsvanemmerik wants to merge 1 commit into
Conversation
… records The exporter record gains an optional Cloud field naming the origin and target cloud, their regions and the probe that produced the sample. It is nil-able, so Record.Validate is unchanged and the rewards-bearing ledger exporter never reads it; a consumer that needs it validates the field itself and treats nil as an error rather than dereferencing it. The ClickHouse table sorts by time first, matching the two production latency tables, because most reads filter on time only. probe_id is in the sort key so a sample stays attributable to its probe and ReplacingMergeTree does not merge it away. ClickHouse cannot reorder a sort key afterwards.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of measuring latency between AWS regions with the internet latency collector. Those samples
have nowhere to land and no way to say which cloud and which probe they came from.
This adds the ClickHouse table
cloud_region_latencyas a goose migration, and an optionalCloudfield on the exporter record holding source cloud, target cloud, probe ID, packets sent and packets
received.
The sort key is worth reading closely, because ClickHouse cannot reorder it once the table exists;
changing it later means a new table and a backfill. It is
(event_ts, origin_cloud, origin_region, target_cloud, target_region, data_provider, probe_id). It leads with time because reads filter ontime, matching the two latency tables already in production.
probe_idis in it so two probessampling the same region pair in the same second stay two rows instead of one being merged away by
the ReplacingMergeTree. A test inserts that pair, runs
OPTIMIZE TABLE ... FINALand asserts bothsurvive; another confirms a re-export of one probe's same sample still collapses to one row.
The record field is a pointer and is nil on every path that exists today, so
Record.Validate()ignores it and nothing behaves differently. Merging creates an empty table that nothing writes to
yet.
Test:
go test ./controlplane/internet-latency-collector/internal/exporter/ -run Recordandgo test ./telemetry/migrations/ -run TestCloudRegionLatency. The migration test starts a realClickHouse container, so it needs Docker.