# Visibility and Logs > Octelium documentation. Canonical page: . As a zero trust architecture, one of the main goals of Octelium's architecture and its reliance on identity-aware proxies is to provide clear, structured, identity-based, application-layer aware visibility and auditing. Octelium is built to be [OpenTelemetry](https://opentelemetry.io/)-native and emits all logs and metrics in real-time, which not only clearly identify the subject (i.e. the *User*, their *Session* and *Device* if available) and the resource represented by the *Service* and its *Namespace*, but can also provide you with application-layer specific details of the request (e.g. paths, methods, user agent, query parameters, and even optionally body content in the case of HTTP-based *Services*, database queries in the case of PostgreSQL and MySQL-based *Services*, session recording in the case of SSH-based *Services*, DNS queries and answers in the case of DNS-based *Services*, etc...). *Diagram: Visibility.* [View the diagram on the canonical HTML page](https://octelium.com/docs/octelium/latest/management/core/visibility). ## OpenTelemetry All logs and metrics produced by the different Octelium components including *Services* are compatible with [OpenTelemetry](https://opentelemetry.io/). OpenTelemetry is a modern framework that is designed to standardize observability including logs, metrics, and traces. Each *Service*, or more specifically, the identity-aware proxy (IaP) component that implements the *Service*, [*Vigil*](https://octelium.com/docs/octelium/latest/reference/components.md#vigil), emits its access logs in real time to an OpenTelemetry Protocol (OTLP) gRPC receiver that must be listening on the address `octelium-collector.octelium.svc:8080` (i.e. the receiver must be deployed as a Kubernetes service with the name `octelium-collector` in the Kubernetes namespace `octelium`). While you can write and deploy your own custom OTLP receiver fairly easily, it is much simpler for most use cases to simply deploy the official OTLP collector (read more [here](https://opentelemetry.io/docs/collector/)) inside the Kubernetes cluster as a Kubernetes service. You can also use the [opentelemetry-collector-contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib) as it already includes many exporters to various major log management and SIEM vendors. And you can also use the official OpenTelemetry Helm chart as shown [here](https://opentelemetry.io/docs/platforms/kubernetes/helm/collector/). > **Note:** > > Octelium provides a commercial, scalable OpenTelemetry collector that integrates with Grafana, Splunk, Elastic, Logz.io as well as any OTLP and OTLP-HTTP based providers on demand. You can see the list of our offerings [here](https://octelium.com/enterprise). This is an example on how to deploy the contrib OTEL collector via Helm to show all the *Cluster* logs and metrics to the collector pod stdout via a `debug` exporter: ```bash helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts helm repo update helm install my-otel open-telemetry/opentelemetry-collector -n octelium -f - <