Robert Winter
09/13/2023, 10:15 AMclickhouse:
enabled: false # use an "external" clickhouse instance instead
externalClickhouse:
host: name_of_the_new_signoz_clickhouse_instance
Ankit Nayan
Prashant Shahi
09/13/2023, 7:40 PMWhat's the recommended approach?If possible, it would be best to keep SigNoz and ClickHouse isolated in a separate K8s cluster.
without installing the ClickHouse operator (which we have installed already) - is this possible? That feels like it would be ideal?yes, it is possible. However, there are multiple changes that you would need to do to your existing cluster as stated in the external clickhouse guide. You will also need to version match the operator and the clickhouse server.
Run both operators in parallel - not sure if that has any other consequences?Your existing clickhouse operator might be using
ClusterRole
and ClusterRoleBinding
, you will need to use Role
and RoleBinding
instead.Robert Winter
09/13/2023, 7:42 PMPrashant Shahi
09/13/2023, 8:16 PMnot sure how it could affect our other workloads that uses the other clickhouse cluster though.As stated in previous message, you will need to use
Role
and RoleBinding
instead for your clickhouse operator. That will keep the scope of your clickhouse operator to its own namespace.
Otherwise, your existing clickhouse operator might make multiple periodic attempts to communicate to SigNoz-managed CHI pods.Robert Winter
09/14/2023, 6:28 AMInstall a ClickHouse instance through the SigNoz helm chart without installing the ClickHouse operator (which we have installed already) - is this possible?
yes, it is possible. However, there are multiple changes that you would need to do to your existing cluster as stated in the external clickhouse guide. You will also need to version match the operator and the clickhouse server.Is there a setting in the signoz or clickhouse values.yaml files allows me to disable installing the clickhouse operator but still install ClickHouse using my existing clickhouse-operator? I see I can disable installing clickhouse but I didn't find a similar setting for skipping installing the operator?
Prashant Shahi
09/14/2023, 7:06 AMclickhouse.enabled
to false
should disable the clickhouse dependency chart i.e both operator and clickhouse installation.Otherwise, your existing clickhouse operator might make multiple periodic attempts to communicate to SigNoz-managed CHI pods.also, this is not a major issue, when it comes to functionality-wise. But it makes many unnecessary network calls and you will see lots of error logs in your existing operator pod.
Robert Winter
09/14/2023, 7:09 AM❯ kubectl get <http://clusterrolebindings.rbac.authorization.k8s.io|clusterrolebindings.rbac.authorization.k8s.io> | grep altinity
clickhouse-operator-altinity-clickhouse-operator ClusterRole/clickhouse-operator-altinity-clickhouse-operator
I'm not sure that blocks the SigNoz clickhouse-operator though as it seems to work fine anyways?
Based on this comment would it be enough you think to set my existing ClickHouse operator to only look in my existing namespaces?
# Concurrently running operators should watch on different namespaces.
namespaces: ["myexistingnamespacewithclickhouse"]
Prashant Shahi
09/20/2023, 5:44 AMBased on this comment would it be enough you think to set my existing ClickHouse operator to only look in my existing namespaces?
``` # Concurrently running operators should watch on different namespaces.
namespaces: ["myexistingnamespacewithclickhouse"]```seems like it. However, I cannot say for certain without testing out the complete set up with two different operators and respective CHIs.