Skip to content

[exporter/clickhouse] ServiceName as column in Clickhouse metrics tables #31670

@jwafle

Description

@jwafle

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 with ServiceName as a column available for query. This column is indexed in the traces table, allowing for good performance on queries where ServiceName 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:

  1. 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.

  2. 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 by ServiceName and including explicit documentation on how to do so.

Last possible solution (less favorable, in my opinion):

  1. Including specific documentation that makes it easy for users to manually create and query the materialized views proposed in solution 2.

Describe alternatives you've considered

Possible solutions provided above.

Additional context

n/a

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions