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
Add a hosting_type tag distinguishing ClickHouse Cloud from self-hosted (DataDog#24736)
* Add a hosting_type tag distinguishing ClickHouse Cloud from self-hosted
DBM had no way to tell a ClickHouse Cloud service apart from a self-hosted
deployment. The only Cloud signal was single_endpoint_mode, a flag the operator
sets by hand, so slicing metrics, samples, or instance metadata by hosting model
was not possible even though the two behave differently: SharedMergeTree vs
ReplicatedMergeTree, clusterAllReplicas topology, per-node checkpointing, and
datetime vs integer types in system.query_log.
Resolves the hosting model from two independent server-side signals and attaches
it as an instance-level tag, following the same shape as clickhouse_cluster:
resolved once per check instance, set on the tag manager before the query manager
is built, so it flows through the existing payload tags/ddtags plumbing to query
metrics, samples, completions, errors, parts and merges, FQT and instance
metadata. The tag key and value vocabulary follow the mongo integration, the
other DBM check that reports a hosting model.
Both signals must agree before reporting cloud. cloud_mode is read from
system.settings rather than via getSetting('cloud_mode'), which raises on the
versions predating the setting and would increment FailedQuery/FailedSelectQuery.
SharedMergeTree is looked up in system.table_engines rather than system.tables so
a freshly provisioned Cloud service with no user tables still resolves, and both
filter with exact equality rather than LIKE, which makes ClickHouse compile a re2
regex and bump RegexpCreated. Both lessons come from the clickhouse_cluster work.
A probe that succeeds without finding its marker is a definite negative and
settles the conjunction on its own. A probe that raises is indeterminate and
yields 'unknown' rather than a self-hosted verdict built on nothing more than a
permission error or a system table the server is too old to have.
Verified against a live ClickHouse Cloud service, which resolves to
clickhouse-cloud, and against self-hosted 18 and 24.8, which resolve to
self-hosted through the setting-absent and setting-disabled paths respectively.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Add changelog entry
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Apply ruff format to the hosting type test
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Describe the hosting type probes as unconditional
The docstring said a negative signal 'short-circuits to self-hosted', which reads as
control flow that does not exist: both probes are always issued and the conjunction is
evaluated afterwards. Say so, and record why neither probe is skipped.
Also correct the stated failure mode. A lack of privileges was listed as a reason a probe
might raise, but neither system.settings nor system.table_engines is gated behind grants:
a user granted only SELECT on one database still reads all 1091 settings rows and all 64
table engines, verified against a live 24.8 cluster. The indeterminate case is a transport
error or a server too old to have the table, not a permissions gap.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Trim verbose comments and docstrings on the hosting_type change
* Remove two more redundant comments on the hosting_type change
* Drop redundant _hosting_type_resolved flag
hosting_type always resolves to a non-empty string, so None alone
distinguishes "not yet resolved" without a second boolean.
* Move hosting_type tag into the expected_tags literal
It's unconditional, unlike the cluster tag, so it belongs with the
other always-present tags rather than as a trailing append.
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments