-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[exporter/clickhouse] ServiceName
as column in Clickhouse metrics tables
#31670
Comments
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
since the table scheme change is unpredictable, maybe we can introduce a table schema migration tools to the exporter. migrate looks good, it can use in code. /cc @hanjm @SpencerTorres |
As for a temporary method for speed up the query with update table schema:
after insert data:
|
@Frapschen migration tool looks heavy and complex, may be block on alter clickhouse table. the status of current component is beta so made break change is ok, just notice it in changelog. |
…cs (#31803) resolve: #31670 it's a breaking change. users who upgrade to the latest version need to alter the Clickhouse table: ``` ALTER TABLE otel_metrics_exponential_histogram ADD COLUMN ServiceName LowCardinality(String) CODEC(ZSTD(1)); ALTER TABLE otel_metrics_gauge ADD COLUMN ServiceName LowCardinality(String) CODEC(ZSTD(1)); ALTER TABLE otel_metrics_histogram ADD COLUMN ServiceName LowCardinality(String) CODEC(ZSTD(1)); ALTER TABLE otel_metrics_sum ADD COLUMN ServiceName LowCardinality(String) CODEC(ZSTD(1)); ALTER TABLE otel_metrics_summary ADD COLUMN ServiceName LowCardinality(String) CODEC(ZSTD(1)); ```
Component(s)
exporter/clickhouse
Is your feature request related to a problem? Please describe.
I currently use the
clickhouseexporter
for exporting traces, which follow a table schema withServiceName
as a column available for query. This column is indexed in the traces table, allowing for good performance on queries whereServiceName
is used as a filter, which is a vast majority of queries in my experience.When looking at benchmarking the metrics exporting against our current solution, I realized that
ServiceName
is not a column in the metrics tables. As someone comfortable with querying the traces table, this came as a surprise to me.Given that the OpenTelemetry semantic conventions spec specifically calls out that SDKs are required to set service.name and that
ServiceName
is already a column in the Clickhouse spans table, I was wondering if there is a specific design decision behind not including this column in the metrics tables?Describe the solution you'd like
I propose two possible solutions:
ServiceName
added as a column for all metrics tables. This would require some migration for users already using the clickhouse exporter, but to be honest, the migration shouldn't be that hard (just add a string column to the already existing tables). In fact, logic could probably be written to update the tables without any user intervention required by checking if the table exists in the old format and creating the new column if necessary.If there is a specific reason that
ServiceName
should not be a column in these tables, I would suggest automatically creating materialized views that would make it easier and more performant for users to query byServiceName
and including explicit documentation on how to do so.Last possible solution (less favorable, in my opinion):
Describe alternatives you've considered
Possible solutions provided above.
Additional context
n/a
The text was updated successfully, but these errors were encountered: