OBI Service Discovery

The executable_name, open_port, service_name, and service_namespace fields are key settings that help you configure OBI to instrument either a single service or a group of related services.

In some deployments, such as running Coralogix as a Kubernetes DaemonSet, you may need to monitor a broad range of services. The discovery section in the YAML configuration provides fine-grained control over which services Coralogix instruments.

For example, you can override service names and namespaces for different types of services.

Services selection

Specify different selection rules for different services. You can also override metadata such as service name or namespace.

See the Discovery services example section for more details.

Exclude services

Define services to exclude from instrumentation. This uses the same format as the services selection. Useful for skipping services like Prometheus.

Default excluded services

Skip Go-specific tracers

Turns off detection of Go-specific telemetry. Coralogix falls back to generic instrumentation in this case.

Language selection

Restrict OBI to instrument only applications written in a specific programming language. When set, OBI skips processes that do not match the selected language. Supported values: go, java, dotnet, python, ruby, nodejs, c, cpp, rust.

Use this to reduce overhead or limit instrumentation scope in mixed-language environments.

Filter by PID

Restrict OBI to instrument only specific processes by their process IDs (PIDs). This is useful for targeted debugging or when you want to instrument a single process without broader service discovery.

Filter by command-line argument

Filter processes by their command-line arguments. Use this selector to distinguish between multiple instances of the same binary running with different arguments.

Exclude OpenTelemetry-instrumented services

Prevents Coralogix from monitoring services that already use OpenTelemetry SDKs to avoid duplicated telemetry. Turn this off if dual telemetry is acceptable.

Discovery services example

Example YAML selecting two service groups:

discovery:
  instrument:
    - exe_path: {worker,backend,frontend}
      namespace: MyApplication
    - exe_path: loadgen
      namespace: testing
      name: "TestLoadGenerator"

Service name and namespace overrides

Each service entry accepts properties grouped by purpose:

1. Name and namespace overrides: name, namespace
2. Selection criteria (selectors): everything else

Name override

Sets the service name in telemetry. Deprecated in favor of automatic metadata extraction.

Namespace override

Sets the service namespace in telemetry. Deprecated.

Selector properties

Selectors can be combined within a service entry. All conditions must match for a process to be instrumented.

Selectors support numeric comparison operators for fields like open_ports. For example, you can use >8000 to match ports greater than 8000.

Example using labels:

discovery:
  services:
    - k8s_namespace: frontend
      k8s_pod_labels:
        instrument: obi

Kubernetes-specific name and namespace resolution

Coralogix automatically sets service name and namespace using Kubernetes metadata in this priority order:

1. OTEL_RESOURCE_ATTRIBUTES or OTEL_SERVICE_NAME environment variables
2. Pod annotations:
   • resource.opentelemetry.io/service.name
   • resource.opentelemetry.io/service.namespace
3. Pod labels:
   • app.kubernetes.io/name
   • app.kubernetes.io/part-of
4. Pod owner metadata (Deployment, ReplicaSet, StatefulSet, etc.)
5. Executable name

You can override default labels with YAML:

kubernetes:
  resource_labels:
    service.name:
      - override-svc-name
      - app.kubernetes.io/name
    service.namespace:
      - override-svc-ns
      - app.kubernetes.io/part-of