Skip to main content

Customize your installation

After you have installed the Causely agent, you can customize your installation to meet your needs.

Use a Custom Values File​

To specify additional configurations - like a specific image tag, integrations, webhook notifications, etc - you can do this by creating a causely-values.yaml file. Below is an example of common values used for installation.

global:
  cluster_name: <my_cluster_name>
image:
  tag: <version> # Locate latest version in the Causely Portal > Gear Icon > Integrations > Agents
mediator:
  gateway:
    token: <my_token> # Locate your token in the Causely Portal > Gear Icon > Integrations > Details

Now add the --values parameter to the command you used to install the Causely agent.

helm upgrade --install causely \
  --create-namespace oci://us-docker.pkg.dev/public-causely/public/causely \
  --version <version> \
  --namespace=causely \
  --values </path/to/causely-values.yaml>

Custom Labels​

You can scope the Causely interface to specific components out-of-the-box (clusters, namespaces, services). Causely can also use labels to provide users with additional scopes - this can be accomplished by adding the following to your causely-values.yaml.

label_semconv:
  scopes:
    geography:
      - 'app.kubernetes.io/geography'
    environment:
      - 'app.kubernetes.io/environment'
    customer:
      - 'app.kubernetes.io/customer'
    team:
      - 'app.kubernetes.io/team'
    product:
      - 'app.kubernetes.io/product'
    project:
      - 'app.kubernetes.io/project'
    service:
      - 'app.kubernetes.io/service'

Connect Additional Telemetry Sources​

You can add additional data sources to Causely which expands Causely's causality map to help identify root causes. Some data sources require you to update your causely-values.yaml file. For more details on Telemetry Sources, see Telemetry Sources.

Push Insights into Your Workflows​

Causely can automatically send identified root causes to your existing notification and observability tools. To explore integrations with Slack, Grafana, Opsgenie, and more, visit our Workflow Integrations page. You'll find setup instructions for webhooks (via causely-values.yaml) and details on our Grafana plugin, with additional native integrations coming soon.

Per-Service Threshold Configuration (via CLI)​

Causely supports custom latency and error rate thresholds on a per-service basis, giving teams more control over how symptoms are detected and when SLO violations are flagged.

By default, Causely uses machine-learned thresholds to detect anomalies in latency and error rate. While effective in many environments, these learned thresholds may not always reflect service-specific expectations or the team's own definitions of what constitutes an issue.

To address this, you can now override learned thresholds via Kubernetes service labels, enabling fine-grained control without modifying code or dashboards.

Use Cases

  • Define stricter or looser thresholds for sensitive or noisy services.
  • Align Causely's detection logic with your own SLO definitions.
  • Improve trust and reduce false positives by tuning detection thresholds explicitly.

How to Configure Thresholds

Apply the appropriate labels to your Kubernetes service resources using kubectl. You can configure both latency and error rate thresholds:

kubectl label svc -n <namespace> <service-name> causely.ai/latency-threshold=<value-in-ms>
kubectl label svc -n <namespace> <service-name> causely.ai/error-rate-threshold=<value-between-0-and-1>

Example

kubectl label svc -n causely victoriametrics causely.ai/latency-threshold=500.0
kubectl label svc -n causely victoriametrics causely.ai/error-rate-threshold=0.01

Notes

  • Latency thresholds are specified in milliseconds.
  • Error rate thresholds are decimals between 0.0 and 1.0 (representing 0% to 100%).
  • Thresholds override the default learned values.
  • You can remove a label to revert back to learned behavior.

Suggest Additional Thresholds

We're currently exploring ways to make threshold configuration more flexible via the Causely UI and support for additional metrics such as CPU and memory. If there are other thresholds you'd like to configure, please let us know.

Deploying on Openshift​

If you are deploying on Openshift, you need to use the group id from the uid-range assigned to the project:

oc new-project causely
oc get ns causely -o yaml|grep uid-range
    openshift.io/sa.scc.uid-range: 1000630000/10000

and include in the causely-values.yaml file:

global:
  securityContext:
    fsGroup: 1000630000

telemetry:
  otel:
    enabled: false

Or you can change the security context of the project to the 'anyuid' SCC

oc adm policy add-scc-to-group anyuid system:serviceaccounts:causely

In both cases, you need to assign the privileged SCC to the causely-agent service account used by the Causely agents:

oc adm policy add-scc-to-user privileged -z causely-agent -n causely

Using a custom StorageClass instead of the default one​

If you are deploying into a cluster, where there is no default StorageClass defined, you can specify the StorageClass to use for persistent volumes:

global:
  storageClass: ocs-storagecluster-ceph-rbd

Alternatively you can annotate a default StorageClass:

kubectl patch storageclass ocs-storagecluster-ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'