Altinity / Altinity/clickhouse-operator
Feature: Support HA setup for ClickHouse metrics exporter
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 2.6k
- Forks
- 574
- Avg merge
- 8d 6h
- Merged PRs (30d)
- 6
Description
Assuming we want to run the ClickHouse metrics exporter with HA (Highly Availability), one would need to deploy it separately from the ClickHouse operator, which can only run with a single replica.
Currently, state is propagated from the ClickHouse operator to the ClickHouse metrics exporter running within the same pod, but in case the ClickHouse operator is down so will the metrics exporter service.
A possible solution would be to change/extend the ClickHouse metrics exporter logic to do polling or periodically check for updates reusing the logic in DiscoveryWatchedCHIs.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the single-replica operator Deployment and the state propagation in pkg/apis/metrics/rest_machinery.go. Read the DiscoveryWatchedCHIs logic in pkg/apis/metrics/exporter.go to understand how exporter updates currently work. Done means the metrics exporter can be deployed separately and remains operational when the ClickHouse operator is unavailable, while still receiving updates.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- clickhouse, go, kubernetes
- Domain
- databases, infrastructure, observability
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100