feat(clickhouse): add service_logs migration for internal service logs - #3455
Draft
rguliyev wants to merge 2 commits into
Draft
feat(clickhouse): add service_logs migration for internal service logs#3455rguliyev wants to merge 2 commits into
rguliyev wants to merge 2 commits into
Conversation
❌ 1 Tests Failed:
View the top 3 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
rguliyev
force-pushed
the
feat/internal-loki-clickhouse
branch
from
July 30, 2026 04:05
f3b00e2 to
6040cc3
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6040cc39f0
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
rguliyev
force-pushed
the
feat/internal-loki-clickhouse
branch
from
July 30, 2026 17:29
edffbde to
7facb3b
Compare
Owns the schema the OTel collectors' clickhouse exporter previously created itself (create_schema) when exporting internal service logs: same column set, indexes and sort key as the upstream v0.146.0 DDL, so the exporter's fixed INSERT list keeps working, plus what create_schema never set - a 30-day TTL and the Distributed wrapper (cluster name rewritten by the migrator job where deployments use a different one). service_logs (platform-internal, engineer-facing, 30d, random sharding) is deliberately separate from the customer-facing sandbox_logs table. Statements are individually re-runnable (no transactional DDL in ClickHouse); the initial DROPs discard the exporter-created otel_logs staging table.
rguliyev
force-pushed
the
feat/internal-loki-clickhouse
branch
from
July 30, 2026 17:57
7facb3b to
23d328e
Compare
tvi
approved these changes
Jul 30, 2026
rguliyev
marked this pull request as draft
July 30, 2026 18:29
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.
Summary
service_logstable used by the OTel collectors' ClickHouse log export of internal (platform service) logs, replacing the exporter'screate_schemaauto-DDLlogs_table.sqlexactly, so the exporter's fixed INSERT column list keeps working withcreate_schema: false(the exporter introspects optional columns likeEventNameat startup)create_schemanever set: a 30-day TTL and aDistributed('cluster', ...)wrapper (cluster name rewritten by the migrator job on deployments that use a different cluster name)service_logs(platform-internal, engineer-facing, 30-day retention, random sharding) is deliberately separate from the customer-facingsandbox_logstable: different tenancy, retention, sharding and exposure boundariesotel_logsstaging validation tableTesting
clusterdefinition: all migrations apply cleanly including this oneotel_logsMergeTree (simulating the exporter-created staging table): dropped correctly, no leftovers insystem.tablesTimestampTime/EventName) through the Distributedservice_logstable: succeeds,TimestampTimeDEFAULT materializesDistributed('cluster', 'default', 'service_logs_local', rand())andTTL TimestampTime + toIntervalDay(30)insystem.tablesRollout
Merge and promote the migrator image before (or with) the collectors switching to
create_schema: falseandlogs_table_name: service_logs. The exporters' retry queue covers the brief window while the migration runs.