> ## Documentation Index
> Fetch the complete documentation index at: https://docs.odigos.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshooting

> If you selected a workload to auto-instrument and you don't see any data, use the checklist below to troubleshoot the issue.

<Tip>
  It is recommended to use the [`odigos describe`](../../cli/odigos_describe) command to get detailed information in one command.
</Tip>

## Check is Source Created?

A `Source` object is required for Odigos to instrument the workload or namespace, such as:

```yaml theme={null}
apiVersion: odigos.io/v1alpha1
kind: Source
metadata:
  name: example
  namespace: foo
spec:
  workload:
    name: myapp
    namespace: foo
    kind: StatefulSet
```

If you expect to see data from a workload but don't, check if the `Source` object exists:

<CodeGroup>
  ```shell get all in namespace theme={null}
  kubectl get sources -n <namespace>
  ```

  ```shell get by deployment name theme={null}
  kubectl get sources -n <namespace> -l odigos.io/workload-name=<deployment-name>
  ```

  ```shell get by deployment kind theme={null}
  kubectl get sources -n <namespace> -l odigos.io/workload-kind=<deployment-kind>
  ```
</CodeGroup>

## Check is Language Detected?

After a `Source` object is created, Odigos will attempt to detect the programming language of the containers in the workload pods, and write the detected language to an `InstrumentationConfig` object in the same namespace.

The resulting language is used to determine which instrumentation to apply.

If a `Source` object exists, verify that the `InstrumentationConfig` also exists:

<CodeGroup>
  ```shell get all in namespace theme={null}
  kubectl get instrumentationconfigs -n <namespace>
  ```

  ```shell get by crd name theme={null}
  kubectl get instrumentationconfigs -n <namespace> <crd-name> -o yaml
  ```
</CodeGroup>

If an `InstrumentationConfig` object exists, verify that the `status.runtimeDetailsByContainer` array contains the expected languages, for example:

```yaml theme={null}
apiVersion: odigos.io/v1alpha1
kind: InstrumentationConfig
metadata:
  name: example
  namespace: foo
spec:
  serviceName: example
status:
  runtimeDetailsByContainer:
  - containerName: example
    language: go
    runtimeVersion: 1.21.2
```

## Check is Device Instrumented?

Once an `InstrumentationConfig` object is created, and the supported language is detected, Odigos will wait until a [destination](../../backends-overview) is added, and OpenTelemetry Collectors are deployed to the cluster (which will receive the telemetry data).

To inject the instrumentation agents into the pods, Odigos will patch the workload template containers with a resource based on the detected language.

If an `InstrumentationConfig` object exists, and the languages are detected, verify that the `Deployment` object contains the expected instrumentation devices:

<CodeGroup>
  ```shell get all in namespace theme={null}
  kubectl get deployments -n <namespace>
  ```

  ```shell get by deployment name theme={null}
  kubectl get deployments -n <namespace> <deployment-name> -o yaml
  ```
</CodeGroup>

It should look something like this:

```yaml theme={null}
apiVersion: apps/v1
kind: Deployment
metadata:
  name: example
  namespace: foo
spec:
  template:
    spec:
      containers:
      - resources:
          limits:
            instrumentation.odigos.io/go-ebpf-community: "1"
```

The `instrumentation.odigos.io/go-ebpf-community` resource-limit instructs Odigos on how to mount the relevant OpenTelemetry agents and environment variables into the container, and which processes should be instrumented with eBPF.

## Getting Help

If you have any issues, or require our assistance, please open an issue in [GitHub](https://github.com/odigos-io/odigos), or reach out to us in [Odigos Slack](https://join.slack.com/t/odigos/shared_invite/zt-24u91yknm-0fLXu6qnqYfNHS_GSUgTJw)