# OpenTelemetry Demo with Instana

[OpenTelemetry (OTel)](https://opentelemetry.io/) is a rapidly growing open-source project that aims to provide a set of standardized vendor-agnostic SDKs, APIs, and [tools](https://opentelemetry.io/docs/collector) for ingesting, transforming, and delivering application and infrastructure observability data ([traces](https://opentelemetry.io/docs/concepts/observability-primer/#distributed-traces), [metrics](https://opentelemetry.io/docs/concepts/observability-primer/#reliability--metrics), [logs](https://opentelemetry.io/docs/concepts/observability-primer/#logs)) to various open-source and vendor backends.

Instana fully [embraces OpenTelemetry](https://www.instana.com/blog/instana-autotrace-fully-embracing-opentelemetry/) based on the following predicates:

* Native support within the Instana agent for OpenTelemetry’s OTLP protocol used to transfer data
* Seamless integration with OpenTelemetry applications in Instana’s *Dynamic Graph*
* Upstream support for native Instana data export via OTel Collector and language-specific SDKs
* Seamless tracing context interoperability between Instana's proprietary format and OTel's default W3C Trace-Context

To bring OpenTelemetry closer to users and help them get started, the community has created a [showcase demo application](https://github.com/open-telemetry/opentelemetry-demo) that illustrates the implementation of the OpenTelemetry instrumentation and observability in a realistic environment. The demo is a collaborative effort of many individual and vendor contributors including Instana and IBM.

### Introducing the OpenTelemetry Demo webstore



The demo application is a sample webshop with a space exploration theme. Build as a distributed micro-services application, it consists of a set of interconnected services with built-in OpenTelemetry instrumentation. The services are written in [11 programming languages](https://github.com/open-telemetry/opentelemetry-demo/blob/main/docs/service_table.md) in order to represent the whole breadth of available language SDKs.


The demo includes idiomatic examples of using various OpenTelemetry features such as manual and automatic instrumentation, manual and automatic context propagation, custom attributes, trace events, baggage, metrics and logs. It provides developers with a convenient sandbox to learn and experiment with OpenTelemetry or to customize it for specific use-cases, such as coupling Instana-native and OpenTelemetry spans via Instana's W3C context propagation support. The demo can be run in either Docker or Kubernetes. It also comes with extensible feature-flag framework that implements several [failure injection scenarios](https://github.com/open-telemetry/opentelemetry-demo/blob/main/docs/README.md#scenarios).

Let's look at how the demo can be used with Instana. We'll describe two alternative ways to ingest the generated OpenTelemetry traces/metrics and we'll highlight the unique capabilities Instana adds though the host agent monitoring.

### Using OTel Collector


Let's start with the simplest way to connect the demo application to Instana, using the bundled [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/). The collector is pre-configured as the default receiver of the OpenTelemetry signals coming from the demo services. To forward the tracing data to the Instana backend, we can just enable the OTel Collector's built-in Instana exporter and point it at the serverless endpoint of your SaaS or on-prem Instana instance. The configuration is as simple as adding a few lines to the Collector [configuration file](https://github.com/open-telemetry/opentelemetry-demo/blob/main/src/otelcollector/otelcol-config.yml), as shown below:

[...]

exporters:
instana:
  endpoint: ${INSTANA_ENDPOINT_URL}
  agent_key: ${INSTANA_AGENT_KEY}

[...]

service:
pipelines:
  traces:
    exporters: [instana]

[...]

Details about the configuration parameters and an example can be found in the [OpenTelemetry Collector Contrib repository](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/instanaexporter).

The quick and simple approach described above is suitable for the case when you only want to receive and analyze OpenTelemetry traces without needing a deeper APM insight, or whenever you want to split and route the telemetry data to multiple backends (e.g. Prometheus, Jaeger) or perform [additional data handling](https://opentelemetry.io/docs/collector/) (batching, encryption, retries) and transformations.

#### Using Instana host agent


Compared to the previous basic method, Instana offers a more advanced way of supporting OpenTelemetry with a user experience and convenience similar to the native [Instana Autotrace](https://www.instana.com/supported-technologies/instana-autotrace/) technology. Instead of using the OTel Collector, we can forward the OpenTelemetry data to a local Instana host agent that provides a native OTLP receiver listening on standard ports 4317 (gRPC) and 4318 (HTTP). The key value of the agent is that it can link the received telemetry to the underlying application resources and host infrastructure that it continuously discovers and monitors. Because the agent is able to determine which process on the host is sending the OTel traces and metrics, Instana can use this mapping to extend the correlation to all related physical and logical dependencies (host, cluster, container, application runtimes) modeled by the Dynamic Graph. The infrastructure context is available to you via the omnipresent [Context Guide](https://www.instana.com/blog/context-guide-instanas-gps-for-your-applications-and-infrastructure/) and within the [Unbounded Analytics](https://www.instana.com/blog/unbounded-analytics-provides-even-easier-query-data-heres-how/) workspace for individual calls.

Details on configuring the host agent, customizing the demo services and redirecting the OTLP output are beyond the scope of this report. However, the configuration and deployment of the agent is almost identical to the standard Instana monitoring, except that we need to make sure to disable the Instana-native auto-instrumentation for each demo technology/service so that it doesn't interfere with the OTel instrumentation.

Below are some example Instana screens showing the OpenTelemetry demo in action:

**Application services** - notice how the individual demo services are linked with the corresponding language runtimes.


**Service dependencies** - showing the gRPC and REST services interaction including downstream databases


**Unbounded Analytics** - the end-to-end trace view with child spans. A closer look inside the Instana interface would reveal the seamless Instana-to-W3C context propagation between the Frontend-proxy service (Instana-instrumented) and the rest of the demo services (OTel-instrumented)


**Context Guide** - you can drill down the infrastructure layers all the way to the process level


**OpenTelemetry metrics** - received metrics are linked to the respective application process that generated the telemetry data


---

>**Note**
>If you don't yet have an Instana instance to play with you can quickly get one by signing up for a [free 14 day full trial](https://www.instana.com/trial/).

---

### ==References==
- Previous Instana blogs about OpenTelemetry
- https://www.instana.com/blog/instana-autotrace-fully-embracing-opentelemetry/
- https://www.instana.com/blog/what-is-opentelemetry/
- https://www.instana.com/blog/the-rise-of-distributed-tracing-with-opentelemetry/
- private references
- The drawings: https://excalidraw.com/#token=MkhsZzTWYLykkzBOuZ8ar
- An apt explanation of the difference between otel collector and Instana host-agent: https://stackoverflow.com/a/73635164
- https://www.ibm.com/docs/en/instana-observability/current?topic=apis-opentelemetry