Updates blog for OTel APM

data/blog/opentelemetry-apm.mdx

@@ -1,108 +1,122 @@
 ---
 
-title: An Open Source OpenTelemetry APM | SigNoz
+title: OpenTelemetry APM with SigNoz
 slug: opentelemetry-apm
-date: 2024-09-30
+date: 2025-09-30
 tags: [OpenTelemetry, SigNoz]
 authors: [ankit_anand]
-description: SigNoz is an open source APM built to support OpenTelemetry natively. In this article, we will talk about things to be kept in mind while selecting an OpenTelemetry APM. We will also see how SigNoz can help you in setting up full-stack observability....
+description: SigNoz is an APM built to support OpenTelemetry natively. In this article, we will talk about things to be kept in mind while selecting an OpenTelemetry APM. We will also see how SigNoz can help you in setting up full-stack observability....
 image: /img/blog/2023/03/opentelemetry_apm_cover-min.jpg
 keywords: [opentelemetry,opentelemetry apm,opentelemetry specification,open source,logs,metrics,traces,logs,signoz,apm tools,application performance monitoring]
 
 ---
 
-OpenTelemetry is a Cloud Native Computing Foundation(<a href = "https://www.cncf.io/" rel="noopener noreferrer nofollow" target="_blank">CNCF</a>) project aimed at standardizing the way we instrument applications for generating telemetry data(logs, metrics, and traces). However, OpenTelemetry does not provide storage and visualization for the collected telemetry data.
+OpenTelemetry has emerged as the open standard for instrumenting applications to generate telemetry data like logs, metrics, and traces. 
+It is incubated unser the CNCF, the same foundation that incubated Kubernetes. Primarily, designed for universal data collection, it remains **backend-agnostic**, leaving storage and
+visualization to your chosen observability platform.
 
-APM stands for Application Performance Monitoring or Application Performance Management. APM tools help engineering teams effectively monitor their applications by monitoring key metrics for application performance. With time, the way applications are built and deployed has changed. With containerisation technologies, software systems have become distributed and are more dynamic than ever in production environments.
+APM stands for Application Performance Management/ Monitoring. APM helps teams effectively monitor their applications by monitoring key metrics for application performance. 
+But setting up a robust monitoring and observability stack is challenging in modern, distributed applications. The first step for setting up observability is to instrument your applications for generating telemetry data
+which can ve achieved with OpenTelemetry. Let’s learn more about OpenTelemetry.
 
-APM tools have also evolved to newer ways of reporting metrics for container-based applications. For newer age architectures like microservices and serverless, it’s difficult for engineering teams to have a central overview of how their applications are performing. But monitoring technology also evolved and gave birth to [distributed tracing](https://signoz.io/blog/distributed-tracing-in-microservices/). With distributed tracing, you can trace user requests across services and protocols.
-
-But setting up a robust monitoring and [observability stack](https://signoz.io/guides/observability-stack/) is challenging in distributed applications. The first step for setting up observability is to instrument your applications for generating telemetry data. OpenTelemetry provides a consistent instrumentation layer for your entire application stack, including open source frameworks and libraries. Let’s learn more about OpenTelemetry.
-
-<SignUps />
 
 ## What is OpenTelemetry?
 
-OpenTelemetry is an open-source collection of tools, APIs, and SDKs that aims to standardize the way we generate and collect telemetry data. It follows a specification-driven development. The <a href = "https://github.com/open-telemetry/opentelemetry-specification" rel="noopener noreferrer nofollow" target="_blank">OpenTelemetry specification</a> has design and implementation guidelines for how the instrumentation libraries should be implemented. In addition, it provides client libraries in all the major programming languages which follow the specification.
+OpenTelemetry is an open-source collection of tools, APIs, and SDKs that aims to standardize the way we generate and collect telemetry data. It follows a specification-driven development. The <a href = "https://github.com/open-telemetry/opentelemetry-specification" rel="noopener noreferrer nofollow" target="_blank">OpenTelemetry specification</a> has design and implementation guidelines for how the instrumentation libraries should be implemented.
+In addition, it provides client libraries in all the major programming languages which follow the specification.
 
 OpenTelemetry was formed after the merger of two open-source projects - OpenCensus and OpenTracing in 2019. Since then, it has been the go-to open-source standard for instrumenting cloud-native applications.
 
 The specification is designed into distinct types of telemetry known as signals. Presently, OpenTelemetry has specifications for these three signals:
 
 - Logs
-- Metrics and
+- Metrics
 - Traces
 
-Together these three signals form the [three pillars of observability](https://signoz.io/blog/three-pillars-of-observability/). OpenTelemetry is the bedrock for setting up an observability framework. The application code is instrumented using OpenTelemetry client libraries, which enables the generation of telemetry data. Once the telemetry data is generated and collected, OpenTelemetry needs a backend analysis tool to which it can send the data.
+Together these three signals form the [three pillars of observability](https://signoz.io/blog/three-pillars-of-observability/). The application code is instrumented using OpenTelemetry client libraries, which enables the generation of telemetry data. Once the telemetry data is generated and collected, OpenTelemetry needs a backend analysis tool to which it can send the data.
 
-OpenTelemetry can send to multiple backends. You can use different backends for each signal in OpenTelemetry. But managing different tools is not recommended. Engineering teams also need to correlate all signals for effective analysis. And that’s where an APM tool is needed.
+OpenTelemetry can send to multiple backends. You can use different backends for each signal in OpenTelemetry. But managing different tools for **instrumentation** is not recommended. Engineering teams also need to correlate all signals for effective analysis. That’s where an APM tool is needed.
 
 ## Things to keep in mind while choosing an OpenTelemetry APM
 
-Below is the list of factors that should be taken into consideration before selecting an OpenTelemetry APM:
-
-- **Support for all distinct signals of OpenTelemetry**<br></br>
-Currently, OpenTelemetry collects telemetry data in three distinct signals, namely, logs, metrics, and traces. Setting up a robust observability framework requires the use of all three signals.
-An OpenTelemetry APM should be able to ingest and visualize all three signals. Moreover, the frontend of the OpenTelemetry APM should also provide features to easily correlate the signals.
-- **Native support for OpenTelemetry semantic conventions**<br></br>
-In OpenTelemetry, every component of a distributed system is defined as an attribute. The attribute is nothing but a key-value pair. These attributes are defined by the OpenTelemetry specification as OpenTelemetry semantic conventions. For example, here is a glimpse of how HTTP conventions look like:
-
-
-    | Attribute | Description | Example |
-    | --- | --- | --- |
-    | http.method | HTTP request method | GET; POST; HEAD |
-    | http.target | The full request target as passed in an HTTP request line or equivalent | /blog/june/ |
-    | http.scheme | The URI scheme that identifies the used protocol | http; https |
-
-    An OpenTelemetry APM should have native support to store data with OpenTelemetry semantic conventions. Existing observability vendors usually transform the data collected using OpenTelemetry semantic conventions into their propriety formats. But OpenTelemetry has a <a href = "https://github.com/open-telemetry/semantic-conventions" rel="noopener noreferrer nofollow" target="_blank">huge list</a> of semantic conventions which might not be fully utilized in such scenarios.
-
-- **Should allow aggregates on trace data**<br></br>
-Running aggregates on trace data enables you to create service-centric views. OpenTelemetry also provides you the ability to create custom tags. Combined with custom tags and aggregated trace data gives you a powerful magnifying glass to surface performance issues in your services. For example, you can get the error rate and 99th percentile latency of `customer_type: gold` or `deployment_version: v2` or `external_call: paypal`
-- **Open Source**<br></br>
-OpenTelemetry is an open source standard with a huge community backing. It is testimonial to the fact that community-driven projects can solve large complex engineering problems. It is not necessary for the OpenTelemetry APM to be open source.
-
-    But having an open-source OpenTelemetry APM can enable you to have a full-stack open-source solution. Open-source solutions have more flexibility, and if you self-host, you don’t need to worry about things like data privacy.
-
-
-Most SaaS APMs now claim to be 100% compatible with OpenTelemetry. But it’s difficult to move away from legacy systems. A solution built natively for OpenTelemetry can be a good choice for OpenTelemetry APM. And that’s where [SigNoz](https://signoz.io/) comes into the picture.
+When chosing an OpenTelemetry APM, it's wise to keep a few pointers in mind:
 
-## SigNoz - An APM built natively for OpenTelemetry
+- First, your APM must **fully support all three of OpenTelemetry's signals** like logs, metrics, and traces. A good observability framework
+  requires all three, and the APM should not only ingest and visualize them but also provide features to *easily correlate them* for a
+  unified view of application performance.
+
+-  Second, look for **native support for OpenTelemetry semantic conventions**. These standardized attributes (key-value pairs) define the
+  components of your distributed system. For example,  let's consider an application that makes a call to a PostgreSQL database. 
+  A trace generated with OpenTelemetry would include standardized attributes to describe this operation, such as:
+
+      - "db.system": "postgresql"
+      - "db.statement": "SELECT * FROM users WHERE id = 123"
+      - "net.peer.name": "user-db.prod.internal"
+      - "db.operation": "SELECT"
+
+  While many vendors transform this data into proprietary formats, an APM that natively supports these 
+  conventions can fully leverage the rich, detailed context that OpenTelemetry provides, which is often lost in
+  translation. This also lets us directly search, filter, and create alerts using the official OpenTelemetry attribute names.
 
-SigNoz is a full-stack [open source APM](https://signoz.io/application-performance-monitoring/) built natively to support OpenTelemetry. At SigNoz, we believe that OpenTelemetry is going to be the world standard for instrumenting cloud-native applications.
 
-SigNoz supports OpenTelemetry semantic conventions and provides visualization for all three distinct types of signals supported by OpenTelemetry.
+- Finally, the **ability to run aggregates on trace data** is critical for creating service-centric insights. By combining aggregation with
+  custom tags, your team can create powerful queries to isolate performance issues. For example, you could easily surface the error
+  rate and 99th percentile latency for a specific customer segment (e.g., user_status: active) or a new deployment
+  (deployment_version: v2).
+
+In a market where most SaaS APMs claim OpenTelemetry compatibility, it's crucial to look deeper. Many of these are legacy platforms
+that struggle to move away from proprietary data models, preventing you from realizing the full benefits of OpenTelemetry's rich
+conventions. A solution **built natively for OpenTelemetry**, however, is architected from the start to embrace these standards. This is
+where SigNoz comes in, offering a powerful choice for teams committed to a genuine OpenTelemetry-first approach.
+
+
+## SigNoz - An APM built natively for OpenTelemetry
+
+SigNoz is an APM built natively to support OpenTelemetry. It supports OpenTelemetry semantic conventions and 
+provides visualization for all three distinct types of signals supported by OpenTelemetry.
 
 The steps to send telemetry data to SigNoz involves:
 
-- [Instrument application](https://signoz.io/docs/instrumentation/) code with language-specific OpenTelemetry libraries
+- Instrument application code with language-specific OpenTelemetry libraries
 - Configure OpenTelemetry Exporters to send data to SigNoz
 - Visualize and analyze telemetry data using SigNoz dashboards
 
+Here's a detailed guide to instrument your application with OpenTelemetry [here](https://signoz.io/docs/instrumentation/).
+
 Here’s a picture depicting how OpenTelemetry fits within an application and SigNoz.
 
 <figure data-zoomable align='center'>
 <img src="/img/blog/2022/05/distributed_tracing_app_otel_signoz.webp" alt="How OpenTelemetry fits within an application and an observability backend"/>
 <figcaption><i>How OpenTelemetry fits within a microservice-based application and OpenTelemetry APM - SigNoz</i></figcaption>
 </figure>
 
-SigNoz cloud is the easiest way to run SigNoz. You can sign up [here](https://signoz.io/teams/) for a free account and get 30 days of unlimited access to all features.
+You can use SigNoz cloud or self-host it depending on your requirements.
+
+### SigNoz Cloud
+
+The easiest and quickest way to get started is with SigNoz Cloud. It is a fully managed service, so you don't have to fret about
+installing, maintaining, or scaling your observability platform. You can start sending your OpenTelemetry data to it in minutes.
 
-You can also install and self-host SigNoz yourself. It can be installed on macOS or Linux computers in just three steps by using a simple install script.
+  This option is best for:
+   1/ Teams who want a production-ready observability platform immediately.
+   2/ Organizations that prefer a hassle-free, managed solution without operational overhead.
 
-The install script automatically installs Docker Engine on Linux. However, on macOS, you must manually install <a href = "https://docs.docker.com/engine/install/" rel="noopener noreferrer nofollow" target="_blank" >Docker Engine</a> before running the install script.
+You can sign up for a free account on the SigNoz Cloud [website] (https://signoz.io/cloud/). Read more on how to 
+configure your application to send data to SigNoz Cloud [here](https://signoz.io/docs/cloud/).
 
-```bash
-git clone -b main <https://github.com/SigNoz/signoz.git>
-cd signoz/deploy/
-./install.sh
 
-```
+### Self-Host SigNoz
 
-You can visit our documentation for more installation option.
+You can also install and manage SigNoz on your own infrastructure using Docker or Kubernetes. This gives you complete control over
+your data, configuration, and privacy.
 
-![/img/blog/common/deploy_docker_documentation.webp](/img/blog/common/deploy_docker_documentation.webp)
+  This option is best for:
+   * Users with strict data residency or security requirements.
+   * Teams who want maximum control and customization over their observability stack.
+
+  You can install SigNoz on your own host using a simple one-line command. You can find the full instructions in the official
+  [documentation] (https://signoz.io/docs/install/).
 
-Once your application is instrumented with OpenTelemetry client libraries, the data can be sent to SigNoz by specifying a specific port on the machine where SigNoz is installed.
 
 You can then use Signoz to monitor application metrics with out-of-box charts and visualization.
 
@@ -114,7 +128,7 @@ You can then use Signoz to monitor application metrics with out-of-box charts an
 The tracing signal from OpenTelemetry instrumentation helps you correlate events across services. With SigNoz, you can visualize your tracing data using [Flamegraphs and Gantt charts](https://signoz.io/blog/flamegraphs/). It shows you a complete breakdown of the request along with every bit of data collected with OpenTelemetry semantic conventions.
 
 <figure data-zoomable align='center'>
-<img src="/img/blog/common/signoz_flamegraphs.webp" alt="Detailed Flamegraphs & Gantt charts"/>
+<img src="/img/blog/2025/09/signoz-flamegraphs.webp" alt="Detailed Flamegraphs & Gantt charts"/>
 <figcaption><i>Tracing data collected by OpenTelemetry can be visualized with the help of Flamegraphs and Gantt charts on the SigNoz dashboard</i></figcaption>
 </figure>
 
@@ -125,33 +139,6 @@ SigNoz also lets you run aggregates on your tracing data. Running aggregates on
 <figcaption><i>Running aggregates on your tracing data enables you to create service-centric views</i></figcaption>
 </figure>
 
-You can check out the [SigNoz GitHub](https://github.com/signoz/signoz) repo here:
-
-![/img/blog/common/signoz_github.webp](/img/blog/common/signoz_github.webp)
-
-## Best Practices for OpenTelemetry Instrumentation
-
-To get the most out of OpenTelemetry APM, consider these best practices:
-
-1. Automatic vs. manual instrumentation:
-    - Use auto-instrumentation libraries when available for quick setup
-    - Supplement with manual instrumentation for custom business logic
-2. Sampling strategies for optimal performance:
-    - Implement tail-based sampling for production environments
-    - Use head-based sampling for development and testing
-3. Handling sensitive data in telemetry:
-    - Implement data scrubbing in your instrumentation code
-    - Use the OpenTelemetry Collector for centralized data processing
-4. Versioning and upgrading OpenTelemetry components:
-    - Keep SDKs and collectors up-to-date
-    - Use semantic versioning to manage breaking changes
-
-## Key Takeaways
-
-- OpenTelemetry APM standardizes telemetry data collection across your entire stack
-- It offers vendor-neutral, portable observability that prevents lock-in
-- Implementing OpenTelemetry APM improves visibility in complex, distributed systems
-- Native [OpenTelemetry tools](https://signoz.io/blog/opentelemetry-visualization/) like SigNoz enhance the APM experience with tailored features
 
 ## FAQs