https://signoz.io logo
#support
Title
# support
r

Robert Winter

09/13/2023, 10:15 AM
Hey guys, great work! We are running ClickHouse in our K8s cluster already using the ClickHouse operator and are looking to run SigNoz as well. What's the recommended approach? 1. Install a ClickHouse instance through the SigNoz helm chart without installing the ClickHouse operator (which we have installed already) - is this possible? That feels like it would be ideal? 2. Run both operators in parallel - not sure if that has any other consequences? 3. Set up a separate ClickHouse cluster for SigNoz (trying to replicate the settings from the clickhouse/values.yaml and following the external clickhouse guide) and setting the following values in the SigNoz values.yaml when installing the helm chart:
Copy code
clickhouse:
    enabled: false # use an "external" clickhouse instance instead
  externalClickhouse:
    host: name_of_the_new_signoz_clickhouse_instance
a

Ankit Nayan

09/13/2023, 2:11 PM
@Prashant Shahi can you help here?
p

Prashant Shahi

09/13/2023, 7:40 PM
Hi @Robert Winter 👋
What'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.
r

Robert Winter

09/13/2023, 7:42 PM
Hey thanks a lot!
I think I'll try to run 2x clickhouse operators and 2x clickhouse clusters (our original + signoz) in the same k8s cluster . When I quickly tried just installing the signoz helm chart with the default settings it at least managed to install both the operator and clickhouse cluster in the platform namespace without any obvious problems - not sure how it could affect our other workloads that uses the other clickhouse cluster though.
p

Prashant Shahi

09/13/2023, 8:16 PM
not 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.
r

Robert Winter

09/14/2023, 6:28 AM
Thanks @Prashant Shahi, I'll give it a go. Just a follow-up question on your answer below to clarify if option (1) is possible:
Install 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?
p

Prashant Shahi

09/14/2023, 7:06 AM
Setting
clickhouse.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.
r

Robert Winter

09/14/2023, 7:09 AM
Ok thanks! Then option (1) is out the window I guess as I can't use the signoz chart to install just the clickhouse cluster but not the operator
Hey @Prashant Shahi thanks for your help. I run the altinity-clickhouse-operator 0.21.3 in my cluster. I started to look into this again and I couldn't find a setting where I could make the operator run with just a cluster role. I think it always provisions this clusterrolebinding:
Copy code
❯ 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?
Copy code
# Concurrently running operators should watch on different namespaces.
        namespaces: ["myexistingnamespacewithclickhouse"]
p

Prashant Shahi

09/20/2023, 5:44 AM
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"]```
seems like it. However, I cannot say for certain without testing out the complete set up with two different operators and respective CHIs.
2 Views