Repository: SigNoz/signoz
Pull request #7358: docs: for setting up otel demo app and sending data to signoz
Author: login: Elizabeth-Mathew1
Labels: name: safe-to-test
description: Run CI tests for dependabot and external contributors
Created: 2025-03-19T05:12:06Z | Merged: 2025-03-24T11:40:51Z

### Summary

<!-- ✍️ A clear and concise description...-->

#### Related Issues / PR's

<!-- ✍️ Add the issues being resolved here and related PR's where applicable  -->

#### Screenshots

NA

<!-- ✍️ Add screenshots of before and after changes where applicable-->

#### Affected Areas and Manually Tested Areas

<!-- ✍️ Add details of blast radius and dev testing areas where applicable-->

<!-- ELLIPSIS_HIDDEN -->

----

> [!IMPORTANT]
> Adds documentation for setting up OpenTelemetry Demo App with SigNoz using Docker, Kubernetes, and cloud deployments.
> 
>   - **New Documentation**:
>     - Adds `otel-demo-docs.md` for setting up OpenTelemetry Demo App with SigNoz.
>     - Covers deployment with Docker, Kubernetes (Helm), and SigNoz Cloud.
>   - **Configuration**:
>     - Details modifying `otelcol-config-extras.yml` for Docker and cloud setups.
>     - Provides `values.yaml` configuration for Kubernetes Helm deployment.
>   - **Monitoring**:
>     - Instructions for accessing SigNoz UI to verify telemetry data reception.
>   - **Misc**:
>     - Includes prerequisites and step-by-step setup instructions.
>     - Notes on configuration merging behavior and potential errors.
> 
> <sup>This description was created by </sup>[<img alt="Ellipsis" src="https://img.shields.io/badge/Ellipsis-blue?color=175173">](https://www.ellipsis.dev?ref=SigNoz%2Fsignoz&utm_source=github&utm_medium=referral)<sup> for 8a9502d48051799d2d11ded9587deb1fd7500001. It will automatically update as commits are pushed.</sup>

<!-- ELLIPSIS_HIDDEN -->


Diff:
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index f08980fc264..879b371a73a 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -77,3 +77,4 @@ Need assistance? Join our Slack community:
 ## Where do I go from here?
 
 - Set up your [development environment](docs/contributing/development.md)
+- Deploy and observe [SigNoz in action with OpenTelemetry Demo Application](docs/otel-demo/otel-demo-docs.md)
diff --git a/docs/img/otel-demo-docker-containers.png b/docs/img/otel-demo-docker-containers.png
new file mode 100644
index 00000000000..0e5527cf07d
Binary files /dev/null and b/docs/img/otel-demo-docker-containers.png differ
diff --git a/docs/img/otel-demo-helm.png b/docs/img/otel-demo-helm.png
new file mode 100644
index 00000000000..00aaf0e367a
Binary files /dev/null and b/docs/img/otel-demo-helm.png differ
diff --git a/docs/img/otel-demo-pods.png b/docs/img/otel-demo-pods.png
new file mode 100644
index 00000000000..986d4bad0bb
Binary files /dev/null and b/docs/img/otel-demo-pods.png differ
diff --git a/docs/img/otel-demo-services.png b/docs/img/otel-demo-services.png
new file mode 100644
index 00000000000..eb6abbc23d1
Binary files /dev/null and b/docs/img/otel-demo-services.png differ
diff --git a/docs/otel-demo-docs.md b/docs/otel-demo-docs.md
new file mode 100644
index 00000000000..af989efbfdc
--- /dev/null
+++ b/docs/otel-demo-docs.md
@@ -0,0 +1,246 @@
+# Configuring OpenTelemetry Demo App with SigNoz
+
+[The OpenTelemetry Astronomy Shop](https://github.com/open-telemetry/opentelemetry-demo) is an e-commerce web application, with **15 core microservices** in a **distributed system** which communicate over gRPC. Designed as a **polyglot** environment, it leverages a diverse set of programming languages, including Go, Python, .NET, Java, and others, showcasing cross-language instrumentation with OpenTelemetry. The intention is to get a quickstart application to send data and experience SigNoz firsthand.
+
+This guide provides a step-by-step walkthrough for setting up the **OpenTelemetry Demo App** with **SigNoz** as backend for observability. It outlines steps to export telemetry data to **SigNoz self-hosted with Docker**, **SigNoz self-hosted with Kubernetes** and **SigNoz cloud**. 
+<br/>
+
+__Table of Contents__
+- [Send data to SigNoz Self-hosted with Docker](#send-data-to-signoz-self-hosted-with-docker)
+  - [Prerequisites](#prerequisites)
+  - [Clone the OpenTelemetry Demo App Repository](#clone-the-opentelemetry-demo-app-repository)
+  - [Modify OpenTelemetry Collector Config](#modify-opentelemetry-collector-config)
+  - [Start the OpenTelemetry Demo App](#start-the-opentelemetry-demo-app)
+  - [Monitor with SigNoz (Docker)](#monitor-with-signoz-docker)
+- [Send data to SigNoz Self-hosted with Kubernetes](#send-data-to-signoz-self-hosted-with-kubernetes)
+  - [Prerequisites](#prerequisites-1)
+  - [Install Helm Repo and Charts](#install-helm-repo-and-charts)
+  - [Start the OpenTelemetry Demo App](#start-the-opentelemetry-demo-app-1)
+  - [Moniitor with SigNoz (Kubernetes)](#monitor-with-signoz-kubernetes)
+- [What's next](#whats-next)
+
+
+# Send data to SigNoz Self-hosted with Docker
+
+In this guide you will install the OTel demo application using Docker and send telemetry data to SigNoz hosted with Docker, referred as SigNoz [Docker] from now.
+
+
+## Prerequisites
+- Docker and Docker Compose installed
+- 6 GB of RAM for the application [as per OpenTelemetry documentation]
+- Nice to have Docker Desktop, for easy monitoring
+
+
+## Clone the OpenTelemetry Demo App Repository
+Clone the OTel demo app to any folder of your choice.
+```sh
+# Clone the OpenTelemetry Demo repository
+git clone https://github.com/open-telemetry/opentelemetry-demo.git
+cd opentelemetry-demo
+```
+
+## Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz [Docker] as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "http://host.docker.internal:4317"
+    tls:
+      insecure: true
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+
+The SigNoz OTel collector [sigNoz's otel-collector service] listens at 4317 port on localhost. When the OTel demo app is running within a Docker container and needs to transmit telemetry data to SigNoz, it cannot directly reference 'localhost' as this would refer to the container's own internal network. Instead, Docker provides a special DNS name, `host.docker.internal`, which resolves to the host machine's IP address from within containers. By configuring the OpenTelemetry Demo application to send data to `host.docker.internal:4317`, we establish a network path that allows the containerized application to transmit telemetry data across the container boundary to the SigNoz OTel collector running on the host machine's port 4317.
+
+>
+> Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overridden.
+ The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+>
+<br>
+<u>To send data to SigNoz Cloud</u>
+
+If you want to send data to cloud instead, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "https://ingest.{your-region}.signoz.cloud:443"
+    tls:
+      insecure: false
+    headers:
+      signoz-access-token: <SIGNOZ-KEY>
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+Remember to replace the region and ingestion key with proper values as obtained from your account.
+
+
+## Start the OpenTelemetry Demo App
+
+Both SigNoz and OTel demo app [frontend-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/otel-demo-docker-containers.png)
+
+
+
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Docker].
+
+## Monitor with SigNoz [Docker]
+Signoz exposes its UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/otel-demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
+
+
+# Send data to SigNoz Self-hosted with Kubernetes
+
+In this guide you will install the OTel demo application using Helm and send telemetry data to SigNoz hosted with Kubernetes, referred as SigNoz [Kubernetes] from now.
+
+## Prerequisites
+
+- Helm charts installed
+- 6 GB of free RAM for the application [as per OpenTelemetry documentation]
+- A kubernetes cluster (EKS, GKE, Minikube)
+- kubectl [CLI for Kubernetes]
+
+>Note: We will be installing OTel demo app using Helm charts, since it is recommended by OpenTelemetry. If you wish to install using kubectl, follow [this](https://opentelemetry.io/docs/demo/kubernetes-deployment/#install-using-kubectl).
+
+
+## Install Helm Repo and Charts
+You’ll need to **install the Helm repository** to start sending data to SigNoz cloud.
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+```
+The OpenTelemetry Collector’s configuration is exposed in the Helm chart. All additions made will be merged into the default configuration. We use this capability to add SigNoz as an exporter, and make pipelines as desired.
+
+For this we have to create a `values.yaml` which will override the existing configurations that comes with the Helm chart.
+
+```yaml
+default:
+  env:
+    - name: OTEL_SERVICE_NAME
+      valueFrom:
+        fieldRef:
+          apiVersion: v1
+          fieldPath: "metadata.labels['app.kubernetes.io/component']"
+    - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE
+      value: cumulative
+    - name: OTEL_RESOURCE_ATTRIBUTES
+      value: 'service.name=$(OTEL_SERVICE_NAME),service.namespace=opentelemetry-demo'
+    - name: OTEL_COLLECTOR_NAME
+      value: signoz-otel-collector.<namespace>.svc.cluster.local
+```
+Replace namespace with your appropriate namespace. This file will replace the chart’s existing settings with our new ones, ensuring telemetry data is sent to SigNoz [Kubernetes].
+
+> Note: When merging YAML values with Helm, objects are merged and arrays are replaced. The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+
+<br>
+<u>To send data to SigNoz cloud</u>
+
+If you wish to send data to cloud instance of SigNoz, we have to create a `values.yaml` which will override the existing configurations that comes with the Helm chart.
+
+```sh
+opentelemetry-collector:
+  config:
+    exporters:
+      otlp:
+        endpoint: "https://ingest.{your-region}.signoz.cloud:443"
+        tls:
+          insecure: false
+        headers:
+          signoz-access-token: <SIGNOZ-KEY>
+      debug:
+        verbosity: detailed
+    service:
+      pipelines:
+        traces:
+          exporters: [spanmetrics, otlp] 
+        metrics:
+          exporters: [otlp]
+        logs:
+          exporters: [otlp]
+```
+Make sure to replace the region and key with values obtained from the account
+
+Now **install the helm chart** with a release name and namespace of your choice. Let's take *my-otel-demo* as the release name and *otel-demo* as the namespace for the context of the code snippet below,
+
+```sh
+# Create a new Kubernetes namespace called "otel-demo"
+kubectl create namespace otel-demo
+# Install the OpenTelemetry Demo Helm chart with the release name "my-otel-demo"
+helm install my-otel-demo open-telemetry/opentelemetry-demo --namespace otel-demo -f values.yaml
+```
+You should see a similar output on your terminal,
+![](/docs/img/otel-demo-helm.png)
+
+To verify if all the pods are running,
+```sh
+kubectl get pods -n otel-demo 
+```
+The output should look similar to this,
+
+![](/docs/img/otel-demo-pods.png)
+
+## Start the OpenTelemetry Demo App
+
+To expose the OTel demo app UI [frontend-proxy service] use the following command (replace my-otel-demo with your Helm chart release name):
+
+```sh
+kubectl port-forward svc/my-otel-demo-frontend-proxy 8080:8081
+```
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Kubernetes].
+
+
+
+## Monitor with SigNoz [Kubernetes]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/otel-demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Kubernetes] as expected. 
+
+
+
+# What's next?
+
+
+
+Don't forget to check our OpenTelemetry [track](https://signoz.io/resource-center/opentelemetry/), guaranteed to take you from a newbie to sensei in no time!
+
+Also from a fellow OTel fan to another, we at [SigNoz](https://signoz.io/) are building an open-source, OTel native, observability platform (one of its kind). So, show us love - star us on [GitHub](https://github.com/SigNoz/signoz), nitpick our [docs](https://signoz.io/docs/introduction/), or just tell your app we’re the ones who’ll catch its crashes mid-flight and finally shush all the 3am panic calls!


Reviews:
user: login: ellipsis-dev[bot]
body: :x: Changes requested. Reviewed everything up to 8a9502d48051799d2d11ded9587deb1fd7500001 in <ellipsistime>3 minutes and 0 seconds</ellipsistime>

<details>
<summary>More details</summary>

 - Looked at `314` lines of code in `1` files
 - Skipped `4` files when reviewing.
 - Skipped posting `8` drafted comments based on config settings.


<details>
<summary>1. <code>docs/otel-demo/otel-demo-docs.md:78</code></summary>

- **Draft comment:** 
Typo: use 'its UI' instead of 'it's UI'.
- **Reason this comment was not posted:** 
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50%
While this is a valid grammatical correction, the review rules emphasize focusing on code changes and logic rather than documentation typos. The rules don't explicitly mention handling grammar in documentation, but they emphasize focusing on substantive issues rather than minor corrections.
The comment is technically correct, but may be too minor to warrant a PR comment. Documentation readability could be considered important enough to fix.
However, the rules emphasize focusing on substantive issues that affect functionality and code quality. Grammar fixes in documentation, while nice to have, don't align with the core review priorities.
The comment should be deleted as it focuses on a minor documentation grammar issue rather than substantive code or functionality concerns.

</details>

<details>
<summary>2. <code>docs/otel-demo/otel-demo-docs.md:214</code></summary>

- **Draft comment:** 
Typo: 'frontent-proxy' should be 'frontend-proxy'.
- **Reason this comment was not posted:** 
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50%
While this is a real typo, the review rules emphasize focusing on substantive issues and avoiding purely informative comments. Typo fixes, while helpful, are not critical to the functionality or understanding of the documentation. The meaning is still clear despite the typo.
The typo is real and fixing it would improve documentation quality. Documentation accuracy could be considered important for user experience.
However, the review rules explicitly state to avoid making purely informative comments and to focus on issues that require code changes. This is a minor documentation typo that doesn't impact functionality.
Based on the review rules emphasizing substantive issues over minor corrections, this typo comment should be removed despite being accurate.

</details>

<details>
<summary>3. <code>docs/otel-demo/otel-demo-docs.md:62</code></summary>

- **Draft comment:** 
Typo: 'frontent-proxy' should be 'frontend-proxy'.
- **Reason this comment was not posted:** 
Marked as duplicate.

</details>

<details>
<summary>4. <code>docs/otel-demo/otel-demo-docs.md:62</code></summary>

- **Draft comment:** 
Typo: 'frontent-proxy service' should be 'frontend-proxy service'.
- **Reason this comment was not posted:** 
Marked as duplicate.

</details>

<details>
<summary>5. <code>docs/otel-demo/otel-demo-docs.md:80</code></summary>

- **Draft comment:** 
Typo: "Signoz exposes it's UI" should use the correct possessive form, i.e., "SigNoz exposes its UI".
- **Reason this comment was not posted:** 
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
While this is technically correct - "its" is the possessive form and "it's" means "it is" - the review rules emphasize focusing on code changes and logic rather than minor text issues. This is a documentation file, but the rules don't make an exception for documentation. The rules emphasize removing comments that are obvious or unimportant.
Documentation quality and correctness is important for user experience. Grammar errors could reflect poorly on the project's professionalism.
While documentation quality matters, this is a very minor grammatical issue that doesn't impact understanding. The rules clearly state to avoid obvious or unimportant comments.
Delete this comment as it addresses a minor grammatical issue that falls under "obvious or unimportant" according to the review rules.

</details>

<details>
<summary>6. <code>docs/otel-demo/otel-demo-docs.md:172</code></summary>

- **Draft comment:** 
Grammar correction: 'The most easiest way' should be changed to 'The easiest way'.
- **Reason this comment was not posted:** 
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
While the grammar correction is technically correct, the review rules emphasize focusing on code changes and logic issues rather than documentation style or grammar. The meaning is still clear despite the minor grammatical error. This seems like a nitpick that doesn't materially improve the content.
The grammar error does make the documentation look less professional. Poor grammar could reflect badly on the project's quality.
While professionalism matters, the review rules explicitly prioritize code quality and logic issues. Grammar fixes in documentation are a lower priority and can be handled in dedicated documentation reviews.
Delete this comment as it focuses on documentation grammar rather than substantive code or logic issues.

</details>

<details>
<summary>7. <code>docs/otel-demo/otel-demo-docs.md:250</code></summary>

- **Draft comment:** 
Typo: 'signoz-acess-token' should be 'signoz-access-token'.
- **Reason this comment was not posted:** 
Marked as duplicate.

</details>

<details>
<summary>8. <code>docs/otel-demo/otel-demo-docs.md:126</code></summary>

- **Draft comment:** 
Typo: In the comment, 'can u please add' should be 'Can you please add'.
- **Reason this comment was not posted:** 
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50%
This is a comment about fixing informal language in what appears to be a temporary developer note/TODO comment. The informal language is not customer-facing and is just communication between developers. The comment itself will likely be removed once the actual implementation details are added. Nitpicking informal language in temporary developer notes is not valuable.
The informal language could be seen as unprofessional if this comment somehow made it into production documentation. However, this appears to be a temporary note that will be removed.
Since this is clearly a temporary developer note that will be replaced with actual implementation details, the informal language style is not important enough to warrant a comment.
Delete this comment as it's nitpicking informal language in a temporary developer note that will be removed anyway.

</details>


Workflow ID: <workflowid>`wflow_q8mM9WDF3PFC1wVQ`</workflowid>

</details>


----
**Want Ellipsis to fix these issues?** Tag `@ellipsis-dev` in a comment. You can customize Ellipsis with :+1: / :-1: [feedback](https://docs.ellipsis.dev/review), review rules, user-specific overrides, `quiet` mode, and [more](https://docs.ellipsis.dev/config).

state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-19T05:15:14Z
user: login: therealpandey
state: CHANGES_REQUESTED
author_association: MEMBER
submitted_at: 2025-03-21T07:47:35Z
user: login: therealpandey
state: APPROVED
author_association: MEMBER
submitted_at: 2025-03-24T09:15:57Z

Review comments:
diff_hunk: @@ -0,0 +1,308 @@
+# Configuring OpenTelemetry Demo App with SigNoz
+
+[The OpenTelemetry Astronomy Shop](https://github.com/open-telemetry/opentelemetry-demo) is an e-commerce web application, with **15 core microservices** in a **distributed system**. Designed as a **polyglot** environment, it leverages a diverse set of programming languages, including Go, Python, .NET, Java, and others, showcasing cross-language instrumentation with OpenTelemetry.
+
+This guide provides a step-by-step walkthrough for setting up the **OpenTelemetry Demo App** with **SigNoz** as backend for observability. It outlines steps to export telemetry data to **SigNoz self-hosted with Docker**, **SigNoz self-hosted with Kubernetes** and **SigNoz cloud**.
+
+# Send data to SigNoz Self-hosted with Docker
+
+In this guide you will install the OTel demo application using Docker and send telemetry data to SigNoz hosted with Docker, referred as SigNoz [Docker] from now.
+
+
+## Prerequisites
+- Docker and Docker Compose installed
+- 6 GB of RAM for the application [as per Opentelemetry documentation]
+- Nice to have Docker Desktop, for easy monitoring
+
+
+## Clone the OpenTelemetry Demo App Repository
+Clone the OTel demo app to any folder of your choice.
+```sh
+# Clone the OpenTelemetry Demo repository
+git clone https://github.com/open-telemetry/opentelemetry-demo.git
+cd opentelemetry-demo
+```
+
+## Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz [Docker] as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "http://host.docker.internal:4317"
+    tls:
+      insecure: true
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+
+The SigNoz OTel collector [sigNoz's otel-collector service] listens at 4317 port on localhost. When the OTel demo app is running within a Docker container and needs to transmit telemetry data to SigNoz, it cannot directly reference 'localhost' as this would refer to the container's own internal network. Instead, Docker provides a special DNS name, `host.docker.internal`, which resolves to the host machine's IP address from within containers. By configuring the OpenTelemetry Demo application to send data to `host.docker.internal:4317`, we establish a network path that allows the containerized application to transmit telemetry data across the container boundary to the SigNoz OTel collector running on the host machine's port 4317.
+
+>
+> Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden.
+ The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+>
+
+## Start the OpenTelemetry Demo App
+
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
path: docs/otel-demo/otel-demo-docs.md
user: login: ellipsis-dev[bot]
body: Typo: 'frontent-proxy' should be 'frontend-proxy'.
```suggestion
Both SigNoz and OTel demo app [frontend-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
```
created_at: 2025-03-19T05:15:13Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,308 @@
+# Configuring OpenTelemetry Demo App with SigNoz
+
+[The OpenTelemetry Astronomy Shop](https://github.com/open-telemetry/opentelemetry-demo) is an e-commerce web application, with **15 core microservices** in a **distributed system**. Designed as a **polyglot** environment, it leverages a diverse set of programming languages, including Go, Python, .NET, Java, and others, showcasing cross-language instrumentation with OpenTelemetry.
+
+This guide provides a step-by-step walkthrough for setting up the **OpenTelemetry Demo App** with **SigNoz** as backend for observability. It outlines steps to export telemetry data to **SigNoz self-hosted with Docker**, **SigNoz self-hosted with Kubernetes** and **SigNoz cloud**.
+
+# Send data to SigNoz Self-hosted with Docker
+
+In this guide you will install the OTel demo application using Docker and send telemetry data to SigNoz hosted with Docker, referred as SigNoz [Docker] from now.
+
+
+## Prerequisites
+- Docker and Docker Compose installed
+- 6 GB of RAM for the application [as per Opentelemetry documentation]
+- Nice to have Docker Desktop, for easy monitoring
+
+
+## Clone the OpenTelemetry Demo App Repository
+Clone the OTel demo app to any folder of your choice.
+```sh
+# Clone the OpenTelemetry Demo repository
+git clone https://github.com/open-telemetry/opentelemetry-demo.git
+cd opentelemetry-demo
+```
+
+## Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz [Docker] as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "http://host.docker.internal:4317"
+    tls:
+      insecure: true
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+
+The SigNoz OTel collector [sigNoz's otel-collector service] listens at 4317 port on localhost. When the OTel demo app is running within a Docker container and needs to transmit telemetry data to SigNoz, it cannot directly reference 'localhost' as this would refer to the container's own internal network. Instead, Docker provides a special DNS name, `host.docker.internal`, which resolves to the host machine's IP address from within containers. By configuring the OpenTelemetry Demo application to send data to `host.docker.internal:4317`, we establish a network path that allows the containerized application to transmit telemetry data across the container boundary to the SigNoz OTel collector running on the host machine's port 4317.
+
+>
+> Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden.
+ The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+>
+
+## Start the OpenTelemetry Demo App
+
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/docker-containers.png)
+
+
+
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Docker].
+
+## Monitor with SigNoz [Docker]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
+
+
+# Send data to SigNoz Self-hosted with Kubernetes
+
+In this guide you will install the OTel demo application using Helm and send telemetry data to SigNoz hosted with Kubernetes, referred as SigNoz [Kubernetes] from now.
+
+## Prerequisites
+
+- Helm charts installed
+- 6 GB of free RAM for the application [as per OpenTelemetry documentation]
+- A kubernetes cluster (EKS, GKE, Minikube)
+- kubectl [CLI for Kubernetes]
+
+>Note: We will be installing OTel demo app using Helm charts, since it is recommended by OpenTelemetry. If you wish to install using kubectl, follow [this](https://opentelemetry.io/docs/demo/kubernetes-deployment/#install-using-kubectl).
+
+
+## Install Helm Repo and Charts
+You’ll need to **install the Helm repository** to start sending data to SigNoz cloud.
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+```
+The OpenTelemetry Collector’s configuration is exposed in the Helm chart. All additions made will be merged into the default configuration. We use this capability to add SigNoz as an exporter, and make pipelines as desired.
+
+For this we have to create a `values.yaml` which will override the existing configurations that comes with the Helm chart.
+
+```yaml
+default:
+  env:
+    - name: OTEL_SERVICE_NAME
+      valueFrom:
+        fieldRef:
+          apiVersion: v1
+          fieldPath: "metadata.labels['app.kubernetes.io/component']"
+    - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE
+      value: cumulative
+    - name: OTEL_RESOURCE_ATTRIBUTES
+      value: 'service.name=$(OTEL_SERVICE_NAME),service.namespace=opentelemetry-demo,service.version={{ .Values.appVersion }}'
+    - name: OTEL_COLLECTOR_NAME
+      value: signoz-otel-collector.<namespace>.svc.cluster.local
+```
+<!-- @Pandey can u please add how to form collector name for different configs + I couldn't get this working on my local - OTel Collector pod was crash looping, so I'm blindly trusting the docs here, From what I tried -  service.version={{ .Values.appVersion }} was throwing an error-->
+
+Replace namespace with your appropriate namespace. This file will replace the chart’s existing settings with our new ones, ensuring telemetry data is sent to SigNoz [Kubernetes].
+
+> Note: When merging YAML values with Helm, objects are merged and arrays are replaced. The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+
+Now **install the helm chart** with a release name and namespace of your choice. Let's take *my-otel-demo* as the release name and *otel-demo* as the namespace for the context of the code snippet below,
+
+```sh
+# Create a new Kubernetes namespace called "otel-demo"
+kubectl create namespace otel-demo
+# Install the OpenTelemetry Demo Helm chart with the release name "my-otel-demo"
+helm install my-otel-demo open-telemetry/opentelemetry-demo --namespace otel-demo -f values.yaml
+```
+You should see a similar output on your terminal,
+![](/docs/img/otel-demo-helm.png)
+
+To verify if all the pods are running,
+```sh
+kubectl get pods -n otel-demo 
+```
+The output should look similar to this,
+
+![](/docs/img/otel-demo-pods.png)
+
+## Start the OpenTelemetry Demo App
+
+To expose the OTel demo app UI [frontend-proxy service] use the following command (replace my-otel-demo with your Helm chart release name):
+
+```sh
+kubectl port-forward svc/my-otel-demo-frontend-proxy 8080:8081
+```
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Kubernetes].
+
+
+
+## Monitor with SigNoz [Kubernetes]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
+
+
+# Send data to SigNoz Cloud
+The most easiest way to send data to SigNoz is via the cloud. This is a quick guide to send data to SigNoz cloud, for both docker and Kubernetes (Helm) deployments.
+
+## 1. Get your SigNoz cloud endpoint
+1. Sign up or log in to [SigNoz Cloud](https://signoz.io/)
+2. Generate a new access token within the ingestion settings. This token will serve as your authentication method for transmitting telemetry data.
+
+## 2. Docker based deployment of OTel demo app
+
+If you have installed the OTel demo application using docker, follow the steps below to send data to SigNoz Cloud.
+
+### Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "https://ingest.{your-region}.signoz.cloud:443"
+    tls:
+      insecure: false
+    headers:
+      signoz-access-token: <SIGNOZ-KEY>
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+Remember to replace the region and ingestion key with proper values as obtained from your account.
+
+>Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden. The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+
+### Start the OpenTelemetry Demo App
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/docker-containers.png)
+
+
+## 2. Kubernetes [Helm] based deployment of OTel demo app
+
+If you have installed the OTel demo application using Helm charts, follow the steps below to send data to SigNoz Cloud.
+
+### Install Helm Repo and Charts
+You’ll need to **install the Helm repository** to start sending data to SigNoz cloud.
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+```
+The OpenTelemetry Collector’s configuration is exposed in the Helm chart. All additions made will be merged into the default configuration. We use this capability to add SigNoz as an exporter, and make pipelines as desired.
+
+For this we have to create a `values.yml` which will override the existing configurations that comes with the Helm chart.
path: docs/otel-demo/otel-demo-docs.md
user: login: ellipsis-dev[bot]
body: Inconsistent file extension: Prefer using a consistent extension (e.g. `.yaml`) for the Helm override values file.
```suggestion
For this we have to create a `values.yaml` which will override the existing configurations that comes with the Helm chart.
```
created_at: 2025-03-19T05:15:13Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,308 @@
+# Configuring OpenTelemetry Demo App with SigNoz
+
+[The OpenTelemetry Astronomy Shop](https://github.com/open-telemetry/opentelemetry-demo) is an e-commerce web application, with **15 core microservices** in a **distributed system**. Designed as a **polyglot** environment, it leverages a diverse set of programming languages, including Go, Python, .NET, Java, and others, showcasing cross-language instrumentation with OpenTelemetry.
+
+This guide provides a step-by-step walkthrough for setting up the **OpenTelemetry Demo App** with **SigNoz** as backend for observability. It outlines steps to export telemetry data to **SigNoz self-hosted with Docker**, **SigNoz self-hosted with Kubernetes** and **SigNoz cloud**.
+
+# Send data to SigNoz Self-hosted with Docker
+
+In this guide you will install the OTel demo application using Docker and send telemetry data to SigNoz hosted with Docker, referred as SigNoz [Docker] from now.
+
+
+## Prerequisites
+- Docker and Docker Compose installed
+- 6 GB of RAM for the application [as per Opentelemetry documentation]
+- Nice to have Docker Desktop, for easy monitoring
+
+
+## Clone the OpenTelemetry Demo App Repository
+Clone the OTel demo app to any folder of your choice.
+```sh
+# Clone the OpenTelemetry Demo repository
+git clone https://github.com/open-telemetry/opentelemetry-demo.git
+cd opentelemetry-demo
+```
+
+## Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz [Docker] as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "http://host.docker.internal:4317"
+    tls:
+      insecure: true
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+
+The SigNoz OTel collector [sigNoz's otel-collector service] listens at 4317 port on localhost. When the OTel demo app is running within a Docker container and needs to transmit telemetry data to SigNoz, it cannot directly reference 'localhost' as this would refer to the container's own internal network. Instead, Docker provides a special DNS name, `host.docker.internal`, which resolves to the host machine's IP address from within containers. By configuring the OpenTelemetry Demo application to send data to `host.docker.internal:4317`, we establish a network path that allows the containerized application to transmit telemetry data across the container boundary to the SigNoz OTel collector running on the host machine's port 4317.
+
+>
+> Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden.
+ The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+>
+
+## Start the OpenTelemetry Demo App
+
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/docker-containers.png)
+
+
+
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Docker].
+
+## Monitor with SigNoz [Docker]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
+
+
+# Send data to SigNoz Self-hosted with Kubernetes
+
+In this guide you will install the OTel demo application using Helm and send telemetry data to SigNoz hosted with Kubernetes, referred as SigNoz [Kubernetes] from now.
+
+## Prerequisites
+
+- Helm charts installed
+- 6 GB of free RAM for the application [as per OpenTelemetry documentation]
+- A kubernetes cluster (EKS, GKE, Minikube)
+- kubectl [CLI for Kubernetes]
+
+>Note: We will be installing OTel demo app using Helm charts, since it is recommended by OpenTelemetry. If you wish to install using kubectl, follow [this](https://opentelemetry.io/docs/demo/kubernetes-deployment/#install-using-kubectl).
+
+
+## Install Helm Repo and Charts
+You’ll need to **install the Helm repository** to start sending data to SigNoz cloud.
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+```
+The OpenTelemetry Collector’s configuration is exposed in the Helm chart. All additions made will be merged into the default configuration. We use this capability to add SigNoz as an exporter, and make pipelines as desired.
+
+For this we have to create a `values.yaml` which will override the existing configurations that comes with the Helm chart.
+
+```yaml
+default:
+  env:
+    - name: OTEL_SERVICE_NAME
+      valueFrom:
+        fieldRef:
+          apiVersion: v1
+          fieldPath: "metadata.labels['app.kubernetes.io/component']"
+    - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE
+      value: cumulative
+    - name: OTEL_RESOURCE_ATTRIBUTES
+      value: 'service.name=$(OTEL_SERVICE_NAME),service.namespace=opentelemetry-demo,service.version={{ .Values.appVersion }}'
+    - name: OTEL_COLLECTOR_NAME
+      value: signoz-otel-collector.<namespace>.svc.cluster.local
+```
+<!-- @Pandey can u please add how to form collector name for different configs + I couldn't get this working on my local - OTel Collector pod was crash looping, so I'm blindly trusting the docs here, From what I tried -  service.version={{ .Values.appVersion }} was throwing an error-->
path: docs/otel-demo/otel-demo-docs.md
user: login: ellipsis-dev[bot]
body: Remove personal note from HTML comment; public docs should not include internal debugging notes.
```suggestion

```
created_at: 2025-03-19T05:15:13Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,308 @@
+# Configuring OpenTelemetry Demo App with SigNoz
+
+[The OpenTelemetry Astronomy Shop](https://github.com/open-telemetry/opentelemetry-demo) is an e-commerce web application, with **15 core microservices** in a **distributed system**. Designed as a **polyglot** environment, it leverages a diverse set of programming languages, including Go, Python, .NET, Java, and others, showcasing cross-language instrumentation with OpenTelemetry.
+
+This guide provides a step-by-step walkthrough for setting up the **OpenTelemetry Demo App** with **SigNoz** as backend for observability. It outlines steps to export telemetry data to **SigNoz self-hosted with Docker**, **SigNoz self-hosted with Kubernetes** and **SigNoz cloud**.
+
+# Send data to SigNoz Self-hosted with Docker
+
+In this guide you will install the OTel demo application using Docker and send telemetry data to SigNoz hosted with Docker, referred as SigNoz [Docker] from now.
+
+
+## Prerequisites
+- Docker and Docker Compose installed
+- 6 GB of RAM for the application [as per Opentelemetry documentation]
+- Nice to have Docker Desktop, for easy monitoring
+
+
+## Clone the OpenTelemetry Demo App Repository
+Clone the OTel demo app to any folder of your choice.
+```sh
+# Clone the OpenTelemetry Demo repository
+git clone https://github.com/open-telemetry/opentelemetry-demo.git
+cd opentelemetry-demo
+```
+
+## Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz [Docker] as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "http://host.docker.internal:4317"
+    tls:
+      insecure: true
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+
+The SigNoz OTel collector [sigNoz's otel-collector service] listens at 4317 port on localhost. When the OTel demo app is running within a Docker container and needs to transmit telemetry data to SigNoz, it cannot directly reference 'localhost' as this would refer to the container's own internal network. Instead, Docker provides a special DNS name, `host.docker.internal`, which resolves to the host machine's IP address from within containers. By configuring the OpenTelemetry Demo application to send data to `host.docker.internal:4317`, we establish a network path that allows the containerized application to transmit telemetry data across the container boundary to the SigNoz OTel collector running on the host machine's port 4317.
+
+>
+> Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden.
+ The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+>
+
+## Start the OpenTelemetry Demo App
+
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/docker-containers.png)
+
+
+
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Docker].
+
+## Monitor with SigNoz [Docker]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
path: docs/otel-demo/otel-demo-docs.md
user: login: ellipsis-dev[bot]
body: Typo and consistency: `'Signoz exposes it's UI'` should be `'SigNoz exposes its UI'`.
```suggestion
SigNoz exposes its UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
```
created_at: 2025-03-19T05:15:13Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,308 @@
+# Configuring OpenTelemetry Demo App with SigNoz
+
+[The OpenTelemetry Astronomy Shop](https://github.com/open-telemetry/opentelemetry-demo) is an e-commerce web application, with **15 core microservices** in a **distributed system**. Designed as a **polyglot** environment, it leverages a diverse set of programming languages, including Go, Python, .NET, Java, and others, showcasing cross-language instrumentation with OpenTelemetry.
+
+This guide provides a step-by-step walkthrough for setting up the **OpenTelemetry Demo App** with **SigNoz** as backend for observability. It outlines steps to export telemetry data to **SigNoz self-hosted with Docker**, **SigNoz self-hosted with Kubernetes** and **SigNoz cloud**.
+
+# Send data to SigNoz Self-hosted with Docker
+
+In this guide you will install the OTel demo application using Docker and send telemetry data to SigNoz hosted with Docker, referred as SigNoz [Docker] from now.
+
+
+## Prerequisites
+- Docker and Docker Compose installed
+- 6 GB of RAM for the application [as per Opentelemetry documentation]
+- Nice to have Docker Desktop, for easy monitoring
+
+
+## Clone the OpenTelemetry Demo App Repository
+Clone the OTel demo app to any folder of your choice.
+```sh
+# Clone the OpenTelemetry Demo repository
+git clone https://github.com/open-telemetry/opentelemetry-demo.git
+cd opentelemetry-demo
+```
+
+## Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz [Docker] as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "http://host.docker.internal:4317"
+    tls:
+      insecure: true
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+
+The SigNoz OTel collector [sigNoz's otel-collector service] listens at 4317 port on localhost. When the OTel demo app is running within a Docker container and needs to transmit telemetry data to SigNoz, it cannot directly reference 'localhost' as this would refer to the container's own internal network. Instead, Docker provides a special DNS name, `host.docker.internal`, which resolves to the host machine's IP address from within containers. By configuring the OpenTelemetry Demo application to send data to `host.docker.internal:4317`, we establish a network path that allows the containerized application to transmit telemetry data across the container boundary to the SigNoz OTel collector running on the host machine's port 4317.
+
+>
+> Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden.
+ The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+>
+
+## Start the OpenTelemetry Demo App
+
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/docker-containers.png)
+
+
+
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Docker].
+
+## Monitor with SigNoz [Docker]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
+
+
+# Send data to SigNoz Self-hosted with Kubernetes
+
+In this guide you will install the OTel demo application using Helm and send telemetry data to SigNoz hosted with Kubernetes, referred as SigNoz [Kubernetes] from now.
+
+## Prerequisites
+
+- Helm charts installed
+- 6 GB of free RAM for the application [as per OpenTelemetry documentation]
+- A kubernetes cluster (EKS, GKE, Minikube)
+- kubectl [CLI for Kubernetes]
+
+>Note: We will be installing OTel demo app using Helm charts, since it is recommended by OpenTelemetry. If you wish to install using kubectl, follow [this](https://opentelemetry.io/docs/demo/kubernetes-deployment/#install-using-kubectl).
+
+
+## Install Helm Repo and Charts
+You’ll need to **install the Helm repository** to start sending data to SigNoz cloud.
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+```
+The OpenTelemetry Collector’s configuration is exposed in the Helm chart. All additions made will be merged into the default configuration. We use this capability to add SigNoz as an exporter, and make pipelines as desired.
+
+For this we have to create a `values.yaml` which will override the existing configurations that comes with the Helm chart.
+
+```yaml
+default:
+  env:
+    - name: OTEL_SERVICE_NAME
+      valueFrom:
+        fieldRef:
+          apiVersion: v1
+          fieldPath: "metadata.labels['app.kubernetes.io/component']"
+    - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE
+      value: cumulative
+    - name: OTEL_RESOURCE_ATTRIBUTES
+      value: 'service.name=$(OTEL_SERVICE_NAME),service.namespace=opentelemetry-demo,service.version={{ .Values.appVersion }}'
+    - name: OTEL_COLLECTOR_NAME
+      value: signoz-otel-collector.<namespace>.svc.cluster.local
+```
+<!-- @Pandey can u please add how to form collector name for different configs + I couldn't get this working on my local - OTel Collector pod was crash looping, so I'm blindly trusting the docs here, From what I tried -  service.version={{ .Values.appVersion }} was throwing an error-->
path: docs/otel-demo/otel-demo-docs.md
user: login: ellipsis-dev[bot]
body: Remove personal commentary addressed to @Pandey; avoid unresolved queries in production docs.
```suggestion

```
created_at: 2025-03-19T05:15:14Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,308 @@
+# Configuring OpenTelemetry Demo App with SigNoz
+
+[The OpenTelemetry Astronomy Shop](https://github.com/open-telemetry/opentelemetry-demo) is an e-commerce web application, with **15 core microservices** in a **distributed system**. Designed as a **polyglot** environment, it leverages a diverse set of programming languages, including Go, Python, .NET, Java, and others, showcasing cross-language instrumentation with OpenTelemetry.
+
+This guide provides a step-by-step walkthrough for setting up the **OpenTelemetry Demo App** with **SigNoz** as backend for observability. It outlines steps to export telemetry data to **SigNoz self-hosted with Docker**, **SigNoz self-hosted with Kubernetes** and **SigNoz cloud**.
+
+# Send data to SigNoz Self-hosted with Docker
+
+In this guide you will install the OTel demo application using Docker and send telemetry data to SigNoz hosted with Docker, referred as SigNoz [Docker] from now.
+
+
+## Prerequisites
+- Docker and Docker Compose installed
+- 6 GB of RAM for the application [as per Opentelemetry documentation]
+- Nice to have Docker Desktop, for easy monitoring
+
+
+## Clone the OpenTelemetry Demo App Repository
+Clone the OTel demo app to any folder of your choice.
+```sh
+# Clone the OpenTelemetry Demo repository
+git clone https://github.com/open-telemetry/opentelemetry-demo.git
+cd opentelemetry-demo
+```
+
+## Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz [Docker] as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "http://host.docker.internal:4317"
+    tls:
+      insecure: true
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+
+The SigNoz OTel collector [sigNoz's otel-collector service] listens at 4317 port on localhost. When the OTel demo app is running within a Docker container and needs to transmit telemetry data to SigNoz, it cannot directly reference 'localhost' as this would refer to the container's own internal network. Instead, Docker provides a special DNS name, `host.docker.internal`, which resolves to the host machine's IP address from within containers. By configuring the OpenTelemetry Demo application to send data to `host.docker.internal:4317`, we establish a network path that allows the containerized application to transmit telemetry data across the container boundary to the SigNoz OTel collector running on the host machine's port 4317.
+
+>
+> Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden.
+ The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+>
+
+## Start the OpenTelemetry Demo App
+
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/docker-containers.png)
+
+
+
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Docker].
+
+## Monitor with SigNoz [Docker]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
+
+
+# Send data to SigNoz Self-hosted with Kubernetes
+
+In this guide you will install the OTel demo application using Helm and send telemetry data to SigNoz hosted with Kubernetes, referred as SigNoz [Kubernetes] from now.
+
+## Prerequisites
+
+- Helm charts installed
+- 6 GB of free RAM for the application [as per OpenTelemetry documentation]
+- A kubernetes cluster (EKS, GKE, Minikube)
+- kubectl [CLI for Kubernetes]
+
+>Note: We will be installing OTel demo app using Helm charts, since it is recommended by OpenTelemetry. If you wish to install using kubectl, follow [this](https://opentelemetry.io/docs/demo/kubernetes-deployment/#install-using-kubectl).
+
+
+## Install Helm Repo and Charts
+You’ll need to **install the Helm repository** to start sending data to SigNoz cloud.
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+```
+The OpenTelemetry Collector’s configuration is exposed in the Helm chart. All additions made will be merged into the default configuration. We use this capability to add SigNoz as an exporter, and make pipelines as desired.
+
+For this we have to create a `values.yaml` which will override the existing configurations that comes with the Helm chart.
+
+```yaml
+default:
+  env:
+    - name: OTEL_SERVICE_NAME
+      valueFrom:
+        fieldRef:
+          apiVersion: v1
+          fieldPath: "metadata.labels['app.kubernetes.io/component']"
+    - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE
+      value: cumulative
+    - name: OTEL_RESOURCE_ATTRIBUTES
+      value: 'service.name=$(OTEL_SERVICE_NAME),service.namespace=opentelemetry-demo,service.version={{ .Values.appVersion }}'
+    - name: OTEL_COLLECTOR_NAME
+      value: signoz-otel-collector.<namespace>.svc.cluster.local
+```
+<!-- @Pandey can u please add how to form collector name for different configs + I couldn't get this working on my local - OTel Collector pod was crash looping, so I'm blindly trusting the docs here, From what I tried -  service.version={{ .Values.appVersion }} was throwing an error-->
+
+Replace namespace with your appropriate namespace. This file will replace the chart’s existing settings with our new ones, ensuring telemetry data is sent to SigNoz [Kubernetes].
+
+> Note: When merging YAML values with Helm, objects are merged and arrays are replaced. The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+
+Now **install the helm chart** with a release name and namespace of your choice. Let's take *my-otel-demo* as the release name and *otel-demo* as the namespace for the context of the code snippet below,
+
+```sh
+# Create a new Kubernetes namespace called "otel-demo"
+kubectl create namespace otel-demo
+# Install the OpenTelemetry Demo Helm chart with the release name "my-otel-demo"
+helm install my-otel-demo open-telemetry/opentelemetry-demo --namespace otel-demo -f values.yaml
+```
+You should see a similar output on your terminal,
+![](/docs/img/otel-demo-helm.png)
+
+To verify if all the pods are running,
+```sh
+kubectl get pods -n otel-demo 
+```
+The output should look similar to this,
+
+![](/docs/img/otel-demo-pods.png)
+
+## Start the OpenTelemetry Demo App
+
+To expose the OTel demo app UI [frontend-proxy service] use the following command (replace my-otel-demo with your Helm chart release name):
+
+```sh
+kubectl port-forward svc/my-otel-demo-frontend-proxy 8080:8081
+```
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Kubernetes].
+
+
+
+## Monitor with SigNoz [Kubernetes]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
+
+
+# Send data to SigNoz Cloud
+The most easiest way to send data to SigNoz is via the cloud. This is a quick guide to send data to SigNoz cloud, for both docker and Kubernetes (Helm) deployments.
+
+## 1. Get your SigNoz cloud endpoint
+1. Sign up or log in to [SigNoz Cloud](https://signoz.io/)
+2. Generate a new access token within the ingestion settings. This token will serve as your authentication method for transmitting telemetry data.
+
+## 2. Docker based deployment of OTel demo app
+
+If you have installed the OTel demo application using docker, follow the steps below to send data to SigNoz Cloud.
+
+### Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "https://ingest.{your-region}.signoz.cloud:443"
+    tls:
+      insecure: false
+    headers:
+      signoz-access-token: <SIGNOZ-KEY>
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+Remember to replace the region and ingestion key with proper values as obtained from your account.
+
+>Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden. The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+
+### Start the OpenTelemetry Demo App
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/docker-containers.png)
+
+
+## 2. Kubernetes [Helm] based deployment of OTel demo app
+
+If you have installed the OTel demo application using Helm charts, follow the steps below to send data to SigNoz Cloud.
+
+### Install Helm Repo and Charts
+You’ll need to **install the Helm repository** to start sending data to SigNoz cloud.
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+```
+The OpenTelemetry Collector’s configuration is exposed in the Helm chart. All additions made will be merged into the default configuration. We use this capability to add SigNoz as an exporter, and make pipelines as desired.
+
+For this we have to create a `values.yml` which will override the existing configurations that comes with the Helm chart.
+```sh
+opentelemetry-collector:
+  config:
+    exporters:
+      otlp:
+        endpoint: "https://ingest.{your-region}.signoz.cloud:443"
+        tls:
+          insecure: false
+        headers:
+          signoz-acess-token: <SIGNOZ-KEY>
path: docs/otel-demo/otel-demo-docs.md
user: login: ellipsis-dev[bot]
body: Typo: 'signoz-acess-token' should be 'signoz-access-token'.
```suggestion
          signoz-access-token: <SIGNOZ-KEY>
```
created_at: 2025-03-19T05:15:14Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,308 @@
+# Configuring OpenTelemetry Demo App with SigNoz
+
+[The OpenTelemetry Astronomy Shop](https://github.com/open-telemetry/opentelemetry-demo) is an e-commerce web application, with **15 core microservices** in a **distributed system**. Designed as a **polyglot** environment, it leverages a diverse set of programming languages, including Go, Python, .NET, Java, and others, showcasing cross-language instrumentation with OpenTelemetry.
+
+This guide provides a step-by-step walkthrough for setting up the **OpenTelemetry Demo App** with **SigNoz** as backend for observability. It outlines steps to export telemetry data to **SigNoz self-hosted with Docker**, **SigNoz self-hosted with Kubernetes** and **SigNoz cloud**.
+
+# Send data to SigNoz Self-hosted with Docker
+
+In this guide you will install the OTel demo application using Docker and send telemetry data to SigNoz hosted with Docker, referred as SigNoz [Docker] from now.
+
+
+## Prerequisites
+- Docker and Docker Compose installed
+- 6 GB of RAM for the application [as per Opentelemetry documentation]
+- Nice to have Docker Desktop, for easy monitoring
+
+
+## Clone the OpenTelemetry Demo App Repository
+Clone the OTel demo app to any folder of your choice.
+```sh
+# Clone the OpenTelemetry Demo repository
+git clone https://github.com/open-telemetry/opentelemetry-demo.git
+cd opentelemetry-demo
+```
+
+## Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz [Docker] as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "http://host.docker.internal:4317"
+    tls:
+      insecure: true
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+
+The SigNoz OTel collector [sigNoz's otel-collector service] listens at 4317 port on localhost. When the OTel demo app is running within a Docker container and needs to transmit telemetry data to SigNoz, it cannot directly reference 'localhost' as this would refer to the container's own internal network. Instead, Docker provides a special DNS name, `host.docker.internal`, which resolves to the host machine's IP address from within containers. By configuring the OpenTelemetry Demo application to send data to `host.docker.internal:4317`, we establish a network path that allows the containerized application to transmit telemetry data across the container boundary to the SigNoz OTel collector running on the host machine's port 4317.
+
+>
+> Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden.
+ The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+>
+
+## Start the OpenTelemetry Demo App
+
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/docker-containers.png)
+
+
+
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Docker].
+
+## Monitor with SigNoz [Docker]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
+
+
+# Send data to SigNoz Self-hosted with Kubernetes
+
+In this guide you will install the OTel demo application using Helm and send telemetry data to SigNoz hosted with Kubernetes, referred as SigNoz [Kubernetes] from now.
+
+## Prerequisites
+
+- Helm charts installed
+- 6 GB of free RAM for the application [as per OpenTelemetry documentation]
+- A kubernetes cluster (EKS, GKE, Minikube)
+- kubectl [CLI for Kubernetes]
+
+>Note: We will be installing OTel demo app using Helm charts, since it is recommended by OpenTelemetry. If you wish to install using kubectl, follow [this](https://opentelemetry.io/docs/demo/kubernetes-deployment/#install-using-kubectl).
+
+
+## Install Helm Repo and Charts
+You’ll need to **install the Helm repository** to start sending data to SigNoz cloud.
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+```
+The OpenTelemetry Collector’s configuration is exposed in the Helm chart. All additions made will be merged into the default configuration. We use this capability to add SigNoz as an exporter, and make pipelines as desired.
+
+For this we have to create a `values.yaml` which will override the existing configurations that comes with the Helm chart.
+
+```yaml
+default:
+  env:
+    - name: OTEL_SERVICE_NAME
+      valueFrom:
+        fieldRef:
+          apiVersion: v1
+          fieldPath: "metadata.labels['app.kubernetes.io/component']"
+    - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE
+      value: cumulative
+    - name: OTEL_RESOURCE_ATTRIBUTES
+      value: 'service.name=$(OTEL_SERVICE_NAME),service.namespace=opentelemetry-demo,service.version={{ .Values.appVersion }}'
+    - name: OTEL_COLLECTOR_NAME
+      value: signoz-otel-collector.<namespace>.svc.cluster.local
+```
+<!-- @Pandey can u please add how to form collector name for different configs + I couldn't get this working on my local - OTel Collector pod was crash looping, so I'm blindly trusting the docs here, From what I tried -  service.version={{ .Values.appVersion }} was throwing an error-->
+
+Replace namespace with your appropriate namespace. This file will replace the chart’s existing settings with our new ones, ensuring telemetry data is sent to SigNoz [Kubernetes].
+
+> Note: When merging YAML values with Helm, objects are merged and arrays are replaced. The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+
+Now **install the helm chart** with a release name and namespace of your choice. Let's take *my-otel-demo* as the release name and *otel-demo* as the namespace for the context of the code snippet below,
+
+```sh
+# Create a new Kubernetes namespace called "otel-demo"
+kubectl create namespace otel-demo
+# Install the OpenTelemetry Demo Helm chart with the release name "my-otel-demo"
+helm install my-otel-demo open-telemetry/opentelemetry-demo --namespace otel-demo -f values.yaml
+```
+You should see a similar output on your terminal,
+![](/docs/img/otel-demo-helm.png)
+
+To verify if all the pods are running,
+```sh
+kubectl get pods -n otel-demo 
+```
+The output should look similar to this,
+
+![](/docs/img/otel-demo-pods.png)
+
+## Start the OpenTelemetry Demo App
+
+To expose the OTel demo app UI [frontend-proxy service] use the following command (replace my-otel-demo with your Helm chart release name):
+
+```sh
+kubectl port-forward svc/my-otel-demo-frontend-proxy 8080:8081
+```
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Kubernetes].
+
+
+
+## Monitor with SigNoz [Kubernetes]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
path: docs/otel-demo/otel-demo-docs.md
user: login: ellipsis-dev[bot]
body: Deployment label mismatch: Change `[Docker]` to `[Kubernetes]` as this section relates to a Kubernetes setup.
```suggestion
This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Kubernetes] as expected.
```
created_at: 2025-03-19T05:15:14Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,308 @@
+# Configuring OpenTelemetry Demo App with SigNoz
+
+[The OpenTelemetry Astronomy Shop](https://github.com/open-telemetry/opentelemetry-demo) is an e-commerce web application, with **15 core microservices** in a **distributed system**. Designed as a **polyglot** environment, it leverages a diverse set of programming languages, including Go, Python, .NET, Java, and others, showcasing cross-language instrumentation with OpenTelemetry.
+
+This guide provides a step-by-step walkthrough for setting up the **OpenTelemetry Demo App** with **SigNoz** as backend for observability. It outlines steps to export telemetry data to **SigNoz self-hosted with Docker**, **SigNoz self-hosted with Kubernetes** and **SigNoz cloud**.
+
+# Send data to SigNoz Self-hosted with Docker
+
+In this guide you will install the OTel demo application using Docker and send telemetry data to SigNoz hosted with Docker, referred as SigNoz [Docker] from now.
+
+
+## Prerequisites
+- Docker and Docker Compose installed
+- 6 GB of RAM for the application [as per Opentelemetry documentation]
+- Nice to have Docker Desktop, for easy monitoring
+
+
+## Clone the OpenTelemetry Demo App Repository
+Clone the OTel demo app to any folder of your choice.
+```sh
+# Clone the OpenTelemetry Demo repository
+git clone https://github.com/open-telemetry/opentelemetry-demo.git
+cd opentelemetry-demo
+```
+
+## Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz [Docker] as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "http://host.docker.internal:4317"
+    tls:
+      insecure: true
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+
+The SigNoz OTel collector [sigNoz's otel-collector service] listens at 4317 port on localhost. When the OTel demo app is running within a Docker container and needs to transmit telemetry data to SigNoz, it cannot directly reference 'localhost' as this would refer to the container's own internal network. Instead, Docker provides a special DNS name, `host.docker.internal`, which resolves to the host machine's IP address from within containers. By configuring the OpenTelemetry Demo application to send data to `host.docker.internal:4317`, we establish a network path that allows the containerized application to transmit telemetry data across the container boundary to the SigNoz OTel collector running on the host machine's port 4317.
+
+>
+> Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden.
+ The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+>
+
+## Start the OpenTelemetry Demo App
+
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/docker-containers.png)
+
+
+
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Docker].
+
+## Monitor with SigNoz [Docker]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
+
+
+# Send data to SigNoz Self-hosted with Kubernetes
+
+In this guide you will install the OTel demo application using Helm and send telemetry data to SigNoz hosted with Kubernetes, referred as SigNoz [Kubernetes] from now.
+
+## Prerequisites
+
+- Helm charts installed
+- 6 GB of free RAM for the application [as per OpenTelemetry documentation]
+- A kubernetes cluster (EKS, GKE, Minikube)
+- kubectl [CLI for Kubernetes]
+
+>Note: We will be installing OTel demo app using Helm charts, since it is recommended by OpenTelemetry. If you wish to install using kubectl, follow [this](https://opentelemetry.io/docs/demo/kubernetes-deployment/#install-using-kubectl).
+
+
+## Install Helm Repo and Charts
+You’ll need to **install the Helm repository** to start sending data to SigNoz cloud.
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+```
+The OpenTelemetry Collector’s configuration is exposed in the Helm chart. All additions made will be merged into the default configuration. We use this capability to add SigNoz as an exporter, and make pipelines as desired.
+
+For this we have to create a `values.yaml` which will override the existing configurations that comes with the Helm chart.
+
+```yaml
+default:
+  env:
+    - name: OTEL_SERVICE_NAME
+      valueFrom:
+        fieldRef:
+          apiVersion: v1
+          fieldPath: "metadata.labels['app.kubernetes.io/component']"
+    - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE
+      value: cumulative
+    - name: OTEL_RESOURCE_ATTRIBUTES
+      value: 'service.name=$(OTEL_SERVICE_NAME),service.namespace=opentelemetry-demo,service.version={{ .Values.appVersion }}'
+    - name: OTEL_COLLECTOR_NAME
+      value: signoz-otel-collector.<namespace>.svc.cluster.local
+```
+<!-- @Pandey can u please add how to form collector name for different configs + I couldn't get this working on my local - OTel Collector pod was crash looping, so I'm blindly trusting the docs here, From what I tried -  service.version={{ .Values.appVersion }} was throwing an error-->
+
+Replace namespace with your appropriate namespace. This file will replace the chart’s existing settings with our new ones, ensuring telemetry data is sent to SigNoz [Kubernetes].
+
+> Note: When merging YAML values with Helm, objects are merged and arrays are replaced. The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+
+Now **install the helm chart** with a release name and namespace of your choice. Let's take *my-otel-demo* as the release name and *otel-demo* as the namespace for the context of the code snippet below,
+
+```sh
+# Create a new Kubernetes namespace called "otel-demo"
+kubectl create namespace otel-demo
+# Install the OpenTelemetry Demo Helm chart with the release name "my-otel-demo"
+helm install my-otel-demo open-telemetry/opentelemetry-demo --namespace otel-demo -f values.yaml
+```
+You should see a similar output on your terminal,
+![](/docs/img/otel-demo-helm.png)
+
+To verify if all the pods are running,
+```sh
+kubectl get pods -n otel-demo 
+```
+The output should look similar to this,
+
+![](/docs/img/otel-demo-pods.png)
+
+## Start the OpenTelemetry Demo App
+
+To expose the OTel demo app UI [frontend-proxy service] use the following command (replace my-otel-demo with your Helm chart release name):
+
+```sh
+kubectl port-forward svc/my-otel-demo-frontend-proxy 8080:8081
+```
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Kubernetes].
+
+
+
+## Monitor with SigNoz [Kubernetes]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
+
+
+# Send data to SigNoz Cloud
+The most easiest way to send data to SigNoz is via the cloud. This is a quick guide to send data to SigNoz cloud, for both docker and Kubernetes (Helm) deployments.
+
+## 1. Get your SigNoz cloud endpoint
+1. Sign up or log in to [SigNoz Cloud](https://signoz.io/)
+2. Generate a new access token within the ingestion settings. This token will serve as your authentication method for transmitting telemetry data.
+
+## 2. Docker based deployment of OTel demo app
+
+If you have installed the OTel demo application using docker, follow the steps below to send data to SigNoz Cloud.
+
+### Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "https://ingest.{your-region}.signoz.cloud:443"
+    tls:
+      insecure: false
+    headers:
+      signoz-access-token: <SIGNOZ-KEY>
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+Remember to replace the region and ingestion key with proper values as obtained from your account.
+
+>Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden. The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+
+### Start the OpenTelemetry Demo App
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/docker-containers.png)
+
+
+## 2. Kubernetes [Helm] based deployment of OTel demo app
+
+If you have installed the OTel demo application using Helm charts, follow the steps below to send data to SigNoz Cloud.
+
+### Install Helm Repo and Charts
+You’ll need to **install the Helm repository** to start sending data to SigNoz cloud.
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+```
+The OpenTelemetry Collector’s configuration is exposed in the Helm chart. All additions made will be merged into the default configuration. We use this capability to add SigNoz as an exporter, and make pipelines as desired.
+
+For this we have to create a `values.yml` which will override the existing configurations that comes with the Helm chart.
+```sh
+opentelemetry-collector:
+  config:
+    exporters:
+      otlp:
+        endpoint: "https://ingest.{your-region}.signoz.cloud:443"
+        tls:
+          insecure: false
+        headers:
+          signoz-acess-token: <SIGNOZ-KEY>
+      debug:
+        verbosity: detailed
+    service:
+      pipelines:
+        traces:
+          exporters: [spanmetrics, otlp] 
+        metrics:
+          exporters: [otlp]
+        logs:
+          exporters: [otlp]
+```
+This file will replace the chart’s existing settings with our new ones, ensuring telemetry data is sent to SigNoz Cloud.
+
+> Note: When merging YAML values with Helm, objects are merged and arrays are replaced. The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+
+Now **install the helm chart** with a release name and namespace of your choice. Let's take *my-otel-demo* as the release name and *otel-demo* as the namespace for the context of the code snippet below,
+```sh
+# Create a new Kubernetes namespace called "otel-demo"
+kubectl create namespace otel-demo
+# Install the OpenTelemetry Demo Helm chart with the release name "my-otel-demo"
+helm install my-otel-demo open-telemetry/opentelemetry-demo --namespace otel-demo -f values.yaml
+```
+You should see a similar output on your terminal,
+![](/docs/contributing/img/otel-demo-helm.png)
path: docs/otel-demo/otel-demo-docs.md
user: login: ellipsis-dev[bot]
body: Inconsistent image path: Use a consistent directory (e.g., `/docs/img/otel-demo-helm.png`) for helm screenshots.
```suggestion
![](/docs/img/otel-demo-helm.png)
```
created_at: 2025-03-19T05:15:14Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,308 @@
+# Configuring OpenTelemetry Demo App with SigNoz
+
+[The OpenTelemetry Astronomy Shop](https://github.com/open-telemetry/opentelemetry-demo) is an e-commerce web application, with **15 core microservices** in a **distributed system**. Designed as a **polyglot** environment, it leverages a diverse set of programming languages, including Go, Python, .NET, Java, and others, showcasing cross-language instrumentation with OpenTelemetry.
+
+This guide provides a step-by-step walkthrough for setting up the **OpenTelemetry Demo App** with **SigNoz** as backend for observability. It outlines steps to export telemetry data to **SigNoz self-hosted with Docker**, **SigNoz self-hosted with Kubernetes** and **SigNoz cloud**.
+
+# Send data to SigNoz Self-hosted with Docker
+
+In this guide you will install the OTel demo application using Docker and send telemetry data to SigNoz hosted with Docker, referred as SigNoz [Docker] from now.
+
+
+## Prerequisites
+- Docker and Docker Compose installed
+- 6 GB of RAM for the application [as per Opentelemetry documentation]
+- Nice to have Docker Desktop, for easy monitoring
+
+
+## Clone the OpenTelemetry Demo App Repository
+Clone the OTel demo app to any folder of your choice.
+```sh
+# Clone the OpenTelemetry Demo repository
+git clone https://github.com/open-telemetry/opentelemetry-demo.git
+cd opentelemetry-demo
+```
+
+## Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz [Docker] as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "http://host.docker.internal:4317"
+    tls:
+      insecure: true
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+
+The SigNoz OTel collector [sigNoz's otel-collector service] listens at 4317 port on localhost. When the OTel demo app is running within a Docker container and needs to transmit telemetry data to SigNoz, it cannot directly reference 'localhost' as this would refer to the container's own internal network. Instead, Docker provides a special DNS name, `host.docker.internal`, which resolves to the host machine's IP address from within containers. By configuring the OpenTelemetry Demo application to send data to `host.docker.internal:4317`, we establish a network path that allows the containerized application to transmit telemetry data across the container boundary to the SigNoz OTel collector running on the host machine's port 4317.
+
+>
+> Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden.
+ The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+>
+
+## Start the OpenTelemetry Demo App
+
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/docker-containers.png)
+
+
+
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Docker].
+
+## Monitor with SigNoz [Docker]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
+
+
+# Send data to SigNoz Self-hosted with Kubernetes
+
+In this guide you will install the OTel demo application using Helm and send telemetry data to SigNoz hosted with Kubernetes, referred as SigNoz [Kubernetes] from now.
+
+## Prerequisites
+
+- Helm charts installed
+- 6 GB of free RAM for the application [as per OpenTelemetry documentation]
+- A kubernetes cluster (EKS, GKE, Minikube)
+- kubectl [CLI for Kubernetes]
+
+>Note: We will be installing OTel demo app using Helm charts, since it is recommended by OpenTelemetry. If you wish to install using kubectl, follow [this](https://opentelemetry.io/docs/demo/kubernetes-deployment/#install-using-kubectl).
+
+
+## Install Helm Repo and Charts
+You’ll need to **install the Helm repository** to start sending data to SigNoz cloud.
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+```
+The OpenTelemetry Collector’s configuration is exposed in the Helm chart. All additions made will be merged into the default configuration. We use this capability to add SigNoz as an exporter, and make pipelines as desired.
+
+For this we have to create a `values.yaml` which will override the existing configurations that comes with the Helm chart.
+
+```yaml
+default:
+  env:
+    - name: OTEL_SERVICE_NAME
+      valueFrom:
+        fieldRef:
+          apiVersion: v1
+          fieldPath: "metadata.labels['app.kubernetes.io/component']"
+    - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE
+      value: cumulative
+    - name: OTEL_RESOURCE_ATTRIBUTES
+      value: 'service.name=$(OTEL_SERVICE_NAME),service.namespace=opentelemetry-demo,service.version={{ .Values.appVersion }}'
+    - name: OTEL_COLLECTOR_NAME
+      value: signoz-otel-collector.<namespace>.svc.cluster.local
+```
+<!-- @Pandey can u please add how to form collector name for different configs + I couldn't get this working on my local - OTel Collector pod was crash looping, so I'm blindly trusting the docs here, From what I tried -  service.version={{ .Values.appVersion }} was throwing an error-->
+
+Replace namespace with your appropriate namespace. This file will replace the chart’s existing settings with our new ones, ensuring telemetry data is sent to SigNoz [Kubernetes].
+
+> Note: When merging YAML values with Helm, objects are merged and arrays are replaced. The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+
+Now **install the helm chart** with a release name and namespace of your choice. Let's take *my-otel-demo* as the release name and *otel-demo* as the namespace for the context of the code snippet below,
+
+```sh
+# Create a new Kubernetes namespace called "otel-demo"
+kubectl create namespace otel-demo
+# Install the OpenTelemetry Demo Helm chart with the release name "my-otel-demo"
+helm install my-otel-demo open-telemetry/opentelemetry-demo --namespace otel-demo -f values.yaml
+```
+You should see a similar output on your terminal,
+![](/docs/img/otel-demo-helm.png)
+
+To verify if all the pods are running,
+```sh
+kubectl get pods -n otel-demo 
+```
+The output should look similar to this,
+
+![](/docs/img/otel-demo-pods.png)
+
+## Start the OpenTelemetry Demo App
+
+To expose the OTel demo app UI [frontend-proxy service] use the following command (replace my-otel-demo with your Helm chart release name):
+
+```sh
+kubectl port-forward svc/my-otel-demo-frontend-proxy 8080:8081
+```
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Kubernetes].
+
+
+
+## Monitor with SigNoz [Kubernetes]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
+
+
+# Send data to SigNoz Cloud
+The most easiest way to send data to SigNoz is via the cloud. This is a quick guide to send data to SigNoz cloud, for both docker and Kubernetes (Helm) deployments.
+
+## 1. Get your SigNoz cloud endpoint
+1. Sign up or log in to [SigNoz Cloud](https://signoz.io/)
+2. Generate a new access token within the ingestion settings. This token will serve as your authentication method for transmitting telemetry data.
+
+## 2. Docker based deployment of OTel demo app
+
+If you have installed the OTel demo application using docker, follow the steps below to send data to SigNoz Cloud.
+
+### Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "https://ingest.{your-region}.signoz.cloud:443"
+    tls:
+      insecure: false
+    headers:
+      signoz-access-token: <SIGNOZ-KEY>
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+Remember to replace the region and ingestion key with proper values as obtained from your account.
+
+>Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden. The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+
+### Start the OpenTelemetry Demo App
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/docker-containers.png)
+
+
+## 2. Kubernetes [Helm] based deployment of OTel demo app
+
+If you have installed the OTel demo application using Helm charts, follow the steps below to send data to SigNoz Cloud.
+
+### Install Helm Repo and Charts
+You’ll need to **install the Helm repository** to start sending data to SigNoz cloud.
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+```
+The OpenTelemetry Collector’s configuration is exposed in the Helm chart. All additions made will be merged into the default configuration. We use this capability to add SigNoz as an exporter, and make pipelines as desired.
+
+For this we have to create a `values.yml` which will override the existing configurations that comes with the Helm chart.
+```sh
+opentelemetry-collector:
+  config:
+    exporters:
+      otlp:
+        endpoint: "https://ingest.{your-region}.signoz.cloud:443"
+        tls:
+          insecure: false
+        headers:
+          signoz-acess-token: <SIGNOZ-KEY>
+      debug:
+        verbosity: detailed
+    service:
+      pipelines:
+        traces:
+          exporters: [spanmetrics, otlp] 
+        metrics:
+          exporters: [otlp]
+        logs:
+          exporters: [otlp]
+```
+This file will replace the chart’s existing settings with our new ones, ensuring telemetry data is sent to SigNoz Cloud.
+
+> Note: When merging YAML values with Helm, objects are merged and arrays are replaced. The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+
+Now **install the helm chart** with a release name and namespace of your choice. Let's take *my-otel-demo* as the release name and *otel-demo* as the namespace for the context of the code snippet below,
+```sh
+# Create a new Kubernetes namespace called "otel-demo"
+kubectl create namespace otel-demo
+# Install the OpenTelemetry Demo Helm chart with the release name "my-otel-demo"
+helm install my-otel-demo open-telemetry/opentelemetry-demo --namespace otel-demo -f values.yaml
+```
+You should see a similar output on your terminal,
+![](/docs/contributing/img/otel-demo-helm.png)
+
+To verify if all the pods are running,
+```sh
+kubectl get pods -n otel-demo 
+```
+The output should look similar to this,
+
+![](/docs/img/otel-demo-pods.png)
+
+### Start the OpenTelemetry Demo App
+
+To expose the OTel demo app UI [frontend-proxy service] use the following command (replace my-otel-demo with your Helm chart release name):
+
+```sh
+kubectl port-forward svc/my-otel-demo-frontend-proxy 8080:8081
+```
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Kubernetes].
+
+
+## 3. Monitor with SigNoz
+1. Open your SigNoz account
+2. Navigate to Services to see multiple services listed down as shown in the snapshot below.
+
+![](/docs/img/demo-services.png)
+
+
+
+# What's next?
+
+If you’re eager to deepen your expertise in OpenTelemetry, explore this [blog]() for a comprehensive analysis of its advanced features such as error tracking, exception handling, and manual instrumentation explored using the OTel Demo app.
path: docs/otel-demo/otel-demo-docs.md
user: login: ellipsis-dev[bot]
body: The blog link is empty; please update the URL or remove the placeholder.
```suggestion
If you’re eager to deepen your expertise in OpenTelemetry, explore this [blog](https://example.com) for a comprehensive analysis of its advanced features such as error tracking, exception handling, and manual instrumentation explored using the OTel Demo app.
```
created_at: 2025-03-19T05:15:14Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,308 @@
+# Configuring OpenTelemetry Demo App with SigNoz
+
+[The OpenTelemetry Astronomy Shop](https://github.com/open-telemetry/opentelemetry-demo) is an e-commerce web application, with **15 core microservices** in a **distributed system**. Designed as a **polyglot** environment, it leverages a diverse set of programming languages, including Go, Python, .NET, Java, and others, showcasing cross-language instrumentation with OpenTelemetry.
+
+This guide provides a step-by-step walkthrough for setting up the **OpenTelemetry Demo App** with **SigNoz** as backend for observability. It outlines steps to export telemetry data to **SigNoz self-hosted with Docker**, **SigNoz self-hosted with Kubernetes** and **SigNoz cloud**.
+
+# Send data to SigNoz Self-hosted with Docker
+
+In this guide you will install the OTel demo application using Docker and send telemetry data to SigNoz hosted with Docker, referred as SigNoz [Docker] from now.
+
+
+## Prerequisites
+- Docker and Docker Compose installed
+- 6 GB of RAM for the application [as per Opentelemetry documentation]
path: docs/otel-demo/otel-demo-docs.md
user: login: ellipsis-dev[bot]
body: Typo: 'Opentelemetry documentation' should be 'OpenTelemetry documentation' for consistency.
```suggestion
- 6 GB of RAM for the application [as per OpenTelemetry documentation]
```
created_at: 2025-03-19T05:15:14Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,308 @@
+# Configuring OpenTelemetry Demo App with SigNoz
+
+[The OpenTelemetry Astronomy Shop](https://github.com/open-telemetry/opentelemetry-demo) is an e-commerce web application, with **15 core microservices** in a **distributed system**. Designed as a **polyglot** environment, it leverages a diverse set of programming languages, including Go, Python, .NET, Java, and others, showcasing cross-language instrumentation with OpenTelemetry.
+
+This guide provides a step-by-step walkthrough for setting up the **OpenTelemetry Demo App** with **SigNoz** as backend for observability. It outlines steps to export telemetry data to **SigNoz self-hosted with Docker**, **SigNoz self-hosted with Kubernetes** and **SigNoz cloud**.
+
+# Send data to SigNoz Self-hosted with Docker
+
+In this guide you will install the OTel demo application using Docker and send telemetry data to SigNoz hosted with Docker, referred as SigNoz [Docker] from now.
+
+
+## Prerequisites
+- Docker and Docker Compose installed
+- 6 GB of RAM for the application [as per Opentelemetry documentation]
+- Nice to have Docker Desktop, for easy monitoring
+
+
+## Clone the OpenTelemetry Demo App Repository
+Clone the OTel demo app to any folder of your choice.
+```sh
+# Clone the OpenTelemetry Demo repository
+git clone https://github.com/open-telemetry/opentelemetry-demo.git
+cd opentelemetry-demo
+```
+
+## Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz [Docker] as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "http://host.docker.internal:4317"
+    tls:
+      insecure: true
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+
+The SigNoz OTel collector [sigNoz's otel-collector service] listens at 4317 port on localhost. When the OTel demo app is running within a Docker container and needs to transmit telemetry data to SigNoz, it cannot directly reference 'localhost' as this would refer to the container's own internal network. Instead, Docker provides a special DNS name, `host.docker.internal`, which resolves to the host machine's IP address from within containers. By configuring the OpenTelemetry Demo application to send data to `host.docker.internal:4317`, we establish a network path that allows the containerized application to transmit telemetry data across the container boundary to the SigNoz OTel collector running on the host machine's port 4317.
+
+>
+> Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden.
path: docs/otel-demo/otel-demo-docs.md
user: login: ellipsis-dev[bot]
body: Typo: 'overriden' should be 'overridden'. (This issue appears in similar notes later as well.)
```suggestion
> Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overridden.
```
created_at: 2025-03-19T05:15:14Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,308 @@
+# Configuring OpenTelemetry Demo App with SigNoz
+
+[The OpenTelemetry Astronomy Shop](https://github.com/open-telemetry/opentelemetry-demo) is an e-commerce web application, with **15 core microservices** in a **distributed system**. Designed as a **polyglot** environment, it leverages a diverse set of programming languages, including Go, Python, .NET, Java, and others, showcasing cross-language instrumentation with OpenTelemetry.
+
+This guide provides a step-by-step walkthrough for setting up the **OpenTelemetry Demo App** with **SigNoz** as backend for observability. It outlines steps to export telemetry data to **SigNoz self-hosted with Docker**, **SigNoz self-hosted with Kubernetes** and **SigNoz cloud**.
+
+# Send data to SigNoz Self-hosted with Docker
+
+In this guide you will install the OTel demo application using Docker and send telemetry data to SigNoz hosted with Docker, referred as SigNoz [Docker] from now.
+
+
+## Prerequisites
+- Docker and Docker Compose installed
+- 6 GB of RAM for the application [as per Opentelemetry documentation]
+- Nice to have Docker Desktop, for easy monitoring
+
+
+## Clone the OpenTelemetry Demo App Repository
+Clone the OTel demo app to any folder of your choice.
+```sh
+# Clone the OpenTelemetry Demo repository
+git clone https://github.com/open-telemetry/opentelemetry-demo.git
+cd opentelemetry-demo
+```
+
+## Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz [Docker] as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "http://host.docker.internal:4317"
+    tls:
+      insecure: true
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+
+The SigNoz OTel collector [sigNoz's otel-collector service] listens at 4317 port on localhost. When the OTel demo app is running within a Docker container and needs to transmit telemetry data to SigNoz, it cannot directly reference 'localhost' as this would refer to the container's own internal network. Instead, Docker provides a special DNS name, `host.docker.internal`, which resolves to the host machine's IP address from within containers. By configuring the OpenTelemetry Demo application to send data to `host.docker.internal:4317`, we establish a network path that allows the containerized application to transmit telemetry data across the container boundary to the SigNoz OTel collector running on the host machine's port 4317.
+
+>
+> Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden.
+ The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+>
+
+## Start the OpenTelemetry Demo App
+
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/docker-containers.png)
+
+
+
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Docker].
+
+## Monitor with SigNoz [Docker]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
+
+
+# Send data to SigNoz Self-hosted with Kubernetes
+
+In this guide you will install the OTel demo application using Helm and send telemetry data to SigNoz hosted with Kubernetes, referred as SigNoz [Kubernetes] from now.
+
+## Prerequisites
+
+- Helm charts installed
+- 6 GB of free RAM for the application [as per OpenTelemetry documentation]
+- A kubernetes cluster (EKS, GKE, Minikube)
+- kubectl [CLI for Kubernetes]
+
+>Note: We will be installing OTel demo app using Helm charts, since it is recommended by OpenTelemetry. If you wish to install using kubectl, follow [this](https://opentelemetry.io/docs/demo/kubernetes-deployment/#install-using-kubectl).
+
+
+## Install Helm Repo and Charts
+You’ll need to **install the Helm repository** to start sending data to SigNoz cloud.
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+```
+The OpenTelemetry Collector’s configuration is exposed in the Helm chart. All additions made will be merged into the default configuration. We use this capability to add SigNoz as an exporter, and make pipelines as desired.
+
+For this we have to create a `values.yaml` which will override the existing configurations that comes with the Helm chart.
+
+```yaml
+default:
+  env:
+    - name: OTEL_SERVICE_NAME
+      valueFrom:
+        fieldRef:
+          apiVersion: v1
+          fieldPath: "metadata.labels['app.kubernetes.io/component']"
+    - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE
+      value: cumulative
+    - name: OTEL_RESOURCE_ATTRIBUTES
+      value: 'service.name=$(OTEL_SERVICE_NAME),service.namespace=opentelemetry-demo,service.version={{ .Values.appVersion }}'
+    - name: OTEL_COLLECTOR_NAME
+      value: signoz-otel-collector.<namespace>.svc.cluster.local
+```
+<!-- @Pandey can u please add how to form collector name for different configs + I couldn't get this working on my local - OTel Collector pod was crash looping, so I'm blindly trusting the docs here, From what I tried -  service.version={{ .Values.appVersion }} was throwing an error-->
+
+Replace namespace with your appropriate namespace. This file will replace the chart’s existing settings with our new ones, ensuring telemetry data is sent to SigNoz [Kubernetes].
+
+> Note: When merging YAML values with Helm, objects are merged and arrays are replaced. The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+
+Now **install the helm chart** with a release name and namespace of your choice. Let's take *my-otel-demo* as the release name and *otel-demo* as the namespace for the context of the code snippet below,
+
+```sh
+# Create a new Kubernetes namespace called "otel-demo"
+kubectl create namespace otel-demo
+# Install the OpenTelemetry Demo Helm chart with the release name "my-otel-demo"
+helm install my-otel-demo open-telemetry/opentelemetry-demo --namespace otel-demo -f values.yaml
+```
+You should see a similar output on your terminal,
+![](/docs/img/otel-demo-helm.png)
+
+To verify if all the pods are running,
+```sh
+kubectl get pods -n otel-demo 
+```
+The output should look similar to this,
+
+![](/docs/img/otel-demo-pods.png)
+
+## Start the OpenTelemetry Demo App
+
+To expose the OTel demo app UI [frontend-proxy service] use the following command (replace my-otel-demo with your Helm chart release name):
+
+```sh
+kubectl port-forward svc/my-otel-demo-frontend-proxy 8080:8081
+```
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Kubernetes].
+
+
+
+## Monitor with SigNoz [Kubernetes]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
+
+
+# Send data to SigNoz Cloud
+The most easiest way to send data to SigNoz is via the cloud. This is a quick guide to send data to SigNoz cloud, for both docker and Kubernetes (Helm) deployments.
+
+## 1. Get your SigNoz cloud endpoint
+1. Sign up or log in to [SigNoz Cloud](https://signoz.io/)
+2. Generate a new access token within the ingestion settings. This token will serve as your authentication method for transmitting telemetry data.
+
+## 2. Docker based deployment of OTel demo app
+
+If you have installed the OTel demo application using docker, follow the steps below to send data to SigNoz Cloud.
+
+### Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "https://ingest.{your-region}.signoz.cloud:443"
+    tls:
+      insecure: false
+    headers:
+      signoz-access-token: <SIGNOZ-KEY>
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+Remember to replace the region and ingestion key with proper values as obtained from your account.
+
+>Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden. The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+
+### Start the OpenTelemetry Demo App
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/docker-containers.png)
+
+
+## 2. Kubernetes [Helm] based deployment of OTel demo app
+
+If you have installed the OTel demo application using Helm charts, follow the steps below to send data to SigNoz Cloud.
+
+### Install Helm Repo and Charts
+You’ll need to **install the Helm repository** to start sending data to SigNoz cloud.
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+```
+The OpenTelemetry Collector’s configuration is exposed in the Helm chart. All additions made will be merged into the default configuration. We use this capability to add SigNoz as an exporter, and make pipelines as desired.
+
+For this we have to create a `values.yml` which will override the existing configurations that comes with the Helm chart.
+```sh
+opentelemetry-collector:
+  config:
+    exporters:
+      otlp:
+        endpoint: "https://ingest.{your-region}.signoz.cloud:443"
+        tls:
+          insecure: false
+        headers:
+          signoz-acess-token: <SIGNOZ-KEY>
+      debug:
+        verbosity: detailed
+    service:
+      pipelines:
+        traces:
+          exporters: [spanmetrics, otlp] 
+        metrics:
+          exporters: [otlp]
+        logs:
+          exporters: [otlp]
+```
+This file will replace the chart’s existing settings with our new ones, ensuring telemetry data is sent to SigNoz Cloud.
+
+> Note: When merging YAML values with Helm, objects are merged and arrays are replaced. The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+
+Now **install the helm chart** with a release name and namespace of your choice. Let's take *my-otel-demo* as the release name and *otel-demo* as the namespace for the context of the code snippet below,
+```sh
+# Create a new Kubernetes namespace called "otel-demo"
+kubectl create namespace otel-demo
+# Install the OpenTelemetry Demo Helm chart with the release name "my-otel-demo"
+helm install my-otel-demo open-telemetry/opentelemetry-demo --namespace otel-demo -f values.yaml
+```
+You should see a similar output on your terminal,
+![](/docs/contributing/img/otel-demo-helm.png)
+
+To verify if all the pods are running,
+```sh
+kubectl get pods -n otel-demo 
+```
+The output should look similar to this,
+
+![](/docs/img/otel-demo-pods.png)
+
+### Start the OpenTelemetry Demo App
+
+To expose the OTel demo app UI [frontend-proxy service] use the following command (replace my-otel-demo with your Helm chart release name):
+
+```sh
+kubectl port-forward svc/my-otel-demo-frontend-proxy 8080:8081
+```
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Kubernetes].
+
+
+## 3. Monitor with SigNoz
+1. Open your SigNoz account
+2. Navigate to Services to see multiple services listed down as shown in the snapshot below.
+
+![](/docs/img/demo-services.png)
+
+
+
+# What's next?
+
+If you’re eager to deepen your expertise in OpenTelemetry, explore this [blog]() for a comprehensive analysis of its advanced features such as error tracking, exception handling, and manual instrumentation explored using the OTel Demo app.
+
+Don't forget to check our OpenTelemetry [track](https://signoz.io/resource-center/opentelemetry/), guaranteed to take you from a newbie to sensei in no time!
+
+Also from a fellow OTel fan to another, we at [SigNoz](https://signoz.io/) are building an opensource, OTel native, observability platform (one of it's kind). So, show us love - star us on [GitHub](https://github.com/SigNoz/signoz), nitpick our [docs](https://signoz.io/docs/introduction/), or just tell your app we’re the ones who’ll catch its crashes mid-flight and finally shush all the 3am panic calls!
path: docs/otel-demo/otel-demo-docs.md
user: login: ellipsis-dev[bot]
body: Typo: 'one of it's kind' should be 'one of its kind'.
```suggestion
Also from a fellow OTel fan to another, we at [SigNoz](https://signoz.io/) are building an opensource, OTel native, observability platform (one of its kind). So, show us love - star us on [GitHub](https://github.com/SigNoz/signoz), nitpick our [docs](https://signoz.io/docs/introduction/), or just tell your app we’re the ones who’ll catch its crashes mid-flight and finally shush all the 3am panic calls!
```
created_at: 2025-03-19T05:15:14Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,308 @@
+# Configuring OpenTelemetry Demo App with SigNoz
+
+[The OpenTelemetry Astronomy Shop](https://github.com/open-telemetry/opentelemetry-demo) is an e-commerce web application, with **15 core microservices** in a **distributed system**. Designed as a **polyglot** environment, it leverages a diverse set of programming languages, including Go, Python, .NET, Java, and others, showcasing cross-language instrumentation with OpenTelemetry.
+
+This guide provides a step-by-step walkthrough for setting up the **OpenTelemetry Demo App** with **SigNoz** as backend for observability. It outlines steps to export telemetry data to **SigNoz self-hosted with Docker**, **SigNoz self-hosted with Kubernetes** and **SigNoz cloud**.
+
+# Send data to SigNoz Self-hosted with Docker
+
+In this guide you will install the OTel demo application using Docker and send telemetry data to SigNoz hosted with Docker, referred as SigNoz [Docker] from now.
+
+
+## Prerequisites
+- Docker and Docker Compose installed
+- 6 GB of RAM for the application [as per Opentelemetry documentation]
+- Nice to have Docker Desktop, for easy monitoring
+
+
+## Clone the OpenTelemetry Demo App Repository
+Clone the OTel demo app to any folder of your choice.
+```sh
+# Clone the OpenTelemetry Demo repository
+git clone https://github.com/open-telemetry/opentelemetry-demo.git
+cd opentelemetry-demo
+```
+
+## Modify OpenTelemetry Collector Config
+
+By default, the collector in the demo application will merge the configuration from two files:
+
+1. otelcol-config.yml &nbsp;&nbsp;[we don't touch this]
+2. otelcol-config-extras.yml &nbsp;&nbsp; [we modify this]
+
+To add SigNoz [Docker] as the backend, open the file `src/otel-collector/otelcol-config-extras.yml` and add the following,
+```yaml
+exporters:
+  otlp:
+    endpoint: "http://host.docker.internal:4317"
+    tls:
+      insecure: true
+  debug:
+    verbosity: detailed
+
+service:
+  pipelines:
+    metrics:
+      exporters: [otlp]
+    traces:
+      exporters: [spanmetrics, otlp]
+    logs: 
+      exporters: [otlp]
+```
+
+The SigNoz OTel collector [sigNoz's otel-collector service] listens at 4317 port on localhost. When the OTel demo app is running within a Docker container and needs to transmit telemetry data to SigNoz, it cannot directly reference 'localhost' as this would refer to the container's own internal network. Instead, Docker provides a special DNS name, `host.docker.internal`, which resolves to the host machine's IP address from within containers. By configuring the OpenTelemetry Demo application to send data to `host.docker.internal:4317`, we establish a network path that allows the containerized application to transmit telemetry data across the container boundary to the SigNoz OTel collector running on the host machine's port 4317.
+
+>
+> Note: When merging extra configuration values with the existing collector config (`src/otel-collector/otelcol-config.yml`), objects are merged and arrays are replaced resulting in previous pipeline configurations getting overriden.
+ The spanmetrics exporter must be included in the array of exporters for the traces pipeline if overridden. Not including this exporter will result in an error.
+>
+
+## Start the OpenTelemetry Demo App
+
+Both SigNoz and OTel demo app [frontent-proxy service, to be accurate] share common port allocation at 8080. To prevent port allocation conflicts, modify the OTel demo application config to use port 8081 as the `ENVOY_PORT` value as shown below, and run docker compose command.
+
+```sh
+ENVOY_PORT=8081 docker compose up -d
+```
+This spins up multiple microservices, with OpenTelemetry instrumentation enabled. you can verify this by,
+```sh
+docker compose ps -a
+```
+The result should look similar to this,
+![](/docs/img/docker-containers.png)
+
+
+
+Navigate to `http://localhost:8081/` where you can access OTel demo app UI. Generate some traffic to send to SigNoz [Docker].
+
+## Monitor with SigNoz [Docker]
+Signoz exposes it's UI at `http://localhost:8080/`. You should be able to see multiple services listed down as shown in the snapshot below.
+
+
+![](/docs/img/demo-services.png)
+
+This verifies that your OTel demo app is successfully sending telemetry data to SigNoz [Docker] as expected. 
+
+
+# Send data to SigNoz Self-hosted with Kubernetes
+
+In this guide you will install the OTel demo application using Helm and send telemetry data to SigNoz hosted with Kubernetes, referred as SigNoz [Kubernetes] from now.
+
+## Prerequisites
+
+- Helm charts installed
+- 6 GB of free RAM for the application [as per OpenTelemetry documentation]
+- A kubernetes cluster (EKS, GKE, Minikube)
+- kubectl [CLI for Kubernetes]
+
+>Note: We will be installing OTel demo app using Helm charts, since it is recommended by OpenTelemetry. If you wish to install using kubectl, follow [this](https://opentelemetry.io/docs/demo/kubernetes-deployment/#install-using-kubectl).
+
+
+## Install Helm Repo and Charts
+You’ll need to **install the Helm repository** to start sending data to SigNoz cloud.
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+```
+The OpenTelemetry Collector’s configuration is exposed in the Helm chart. All additions made will be merged into the default configuration. We use this capability to add SigNoz as an exporter, and make pipelines as desired.
+
+For this we have to create a `values.yaml` which will override the existing configurations that comes with the Helm chart.
+
+```yaml
+default:
+  env:
+    - name: OTEL_SERVICE_NAME
+      valueFrom:
+        fieldRef:
+          apiVersion: v1
+          fieldPath: "metadata.labels['app.kubernetes.io/component']"
+    - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE
+      value: cumulative
+    - name: OTEL_RESOURCE_ATTRIBUTES
+      value: 'service.name=$(OTEL_SERVICE_NAME),service.namespace=opentelemetry-demo,service.version={{ .Values.appVersion }}'
+    - name: OTEL_COLLECTOR_NAME
+      value: signoz-otel-collector.<namespace>.svc.cluster.local
+```
+<!-- @Pandey can u please add how to form collector name for different configs + I couldn't get this working on my local - OTel Collector pod was crash looping, so I'm blindly trusting the docs here, From what I tried -  service.version={{ .Values.appVersion }} was throwing an error-->
path: docs/otel-demo/otel-demo-docs.md
user: login: therealpandey
body: ```
    - name: OTEL_RESOURCE_ATTRIBUTES
      value: 'service.name=$(OTEL_SERVICE_NAME),service.namespace=opentelemetry-demo'
    - name: OTEL_COLLECTOR_NAME
      value: signoz-otel-collector.<namespace>.svc.cluster.local
  ```
This should work!      
created_at: 2025-03-21T07:45:35Z
author_association: MEMBER

PR comments:
user: login: CLAassistant
created_at: 2025-03-19T05:12:12Z
body: [![CLA assistant check](https://cla-assistant.io/pull/badge/signed)](https://cla-assistant.io/SigNoz/signoz?pullRequest=7358) <br/>All committers have signed the CLA.
author_association: NONE
user: login: welcome[bot]
created_at: 2025-03-24T11:40:55Z
body: Congrats on merging your first pull request!
![minion-party](https://i.imgur.com/Xlg59lP.gif)
We here at SigNoz are proud of you! 🥳

author_association: NONE