Install an Obcerv instance

To install an Obcerv instance, perform the following tasks:

  1. Create a configuration file.
  2. Configure TLS.
  3. Install Obcerv.
  4. Check the installation status.

You can also install multiple instances on one cluster.

Create a configuration file


It is possible to install using only the default parameters. However, this will result in containers with no resource limits that may consume all cluster resources. As a result, the default disk sizes may not be adequate depending on the expected volume. Consult your ITRS representative for more information.

Immutable parameters

A number of installation parameters are immutable, which means that an Obcerv instance cannot be reconfigured if you change any of these parameters. To check the full list, run helm show values.

Some of these immutable parameters differ between the ITRS-provided sample configuration files, such as those for replicas and storage classes.

Configure TLS

TLS is used to secure network traffic inside the cluster (service to service) and outside the cluster (clients connecting via an Ingress).

Internal TLS configuration

TLS inside the cluster is optional and enabled by default. To disable in the config:

    enabled: false


Internal (service to service) TLS requires Linkerd to be installed.

External (Ingress) TLS configuration

Ingress TLS is always enabled and cannot be disabled. However, self-signed certificates can be automatically generated for quickly bootstrapping non-production environments. To enable:

    selfSigned: true


Self-signed certificates for Ingress are not suitable for production and should only be used for testing purposes.

If self-signed certificates are not enabled, then you must do one of the following:


When the TLS certificate expires, note the following certificate expiration and renewal scenarios:

  • If cert-manager is used, it will automatically renew the certificate before its expiration.
  • If the certificate is manually configured, the Kubernetes Secret holding the certificate (as outlined in step 5 of Manually create TLS certificates) needs to be manually updated.
  • If either of the above applies and the cluster’s ingress controller happens to be NGINX (see NGINX ingress controller for details), then NGINX will automatically pick up the new certificate without having to be restarted. Manual intervention may otherwise be required depending on the chosen ingress controller implementation.

Install Obcerv

Each instance of Obcerv must be assigned a unique name, for example demo.

helm install -f obcerv.yaml demo itrs/obcerv --version 1.3.2 -n itrs

Check the installation status

Check the progress of the installation:

kubectl describe obcerv <instanceName> -n <namespace>

Refer to the Status section. While the installation is in progress, the status will be DEPLOYING. After a successful installation, the status will be DEPLOYED. If any installation errors occur, the status will be FAILED and a reason will be given.

During and after the installation, check that all pods are in running or ready state. If any pods fail to start or crash, try to determine the cause. You can describe the pod (by looking at the container state and events) and inspect the pod log for any errors.

The Collection Agent DaemonSet, which collects metrics and logs for all Obcerv components, will attempt to schedule pods on all selected nodes. However, in cases such as when there are resource constraints on some nodes, not all pods may successfully start.

Identify the cause and resolve if possible, either by eliminating the resource constraint or by setting collection.daemonSet.nodeSelector in the Obcerv config to target specific nodes. If left unresolved, Obcerv will be unable to collect logs and metrics from that node.

Multiple instances on one cluster

Multiple Obcerv instances can be installed on the same cluster. Each instance must be installed in its own namespace.

Obcerv includes a Collection Agent DaemonSet that is deployed on each node. This may lead to clashes with other Obcerv instances on the same cluster. The agent listens on the statsd port (8125 by default) and collects logs for all pods running on that node. To avoid clashing ports and collecting duplicate logs from each instance, set the following parameters uniquely for each instance:

    statsdPort: 8126
    # Only collect kube metrics for these namespace(s)
    - "my-namespace"
    # Only collect kube logs for these namespace(s)
    - "my-namespace"
["Obcerv"] ["User Guide", "Technical Reference"]

Was this topic helpful?