diff --git a/data/blog/aws-xray-vs-jaeger.mdx b/data/blog/aws-xray-vs-jaeger.mdx
index e32c01f9e..8c8f075b1 100644
--- a/data/blog/aws-xray-vs-jaeger.mdx
+++ b/data/blog/aws-xray-vs-jaeger.mdx
@@ -9,7 +9,7 @@ image: /img/blog/2021/09/aws_xray_vs_jaeger_cover.webp
keywords: [jaeger,aws x ray,aws,distributed tracing,traces]
---
-Both AWS X-Ray and Jaeger are distributed tracing tools used for performance monitoring in a microservices architecture. Jaeger was originally built by teams at Uber and then open-sourced in 2015. On the other hand, AWS X-Ray is a distributed tracing tool provided by AWS specifically focused on distributed tracing for applications using Amazon Cloud Services.
+Both AWS X-Ray and Jaeger are distributed tracing tools used for performance monitoring in a microservices architecture. Jaeger was originally built by teams at Uber and then open-sourced in 2015. On the other hand, AWS X-Ray is a distributed [tracing tool](https://signoz.io/blog/distributed-tracing-tools/) provided by AWS specifically focused on distributed tracing for applications using Amazon Cloud Services.
@@ -33,7 +33,7 @@ In the world of microservices, a user request travels through hundreds of servic
+- **Distributed [context propagation](https://signoz.io/blog/opentelemetry-context-propagation/)**
One of the challenges of distributed systems is to have a standard format for passing context across process boundaries and services. Jaeger provides client libraries that support code instrumentation in multiple languages to propagate context across services - **Distributed transaction monitoring**
- Jaeger comes with a web UI written in Javascript. The dashboard can be used to see traces and spans across services. + Jaeger comes with a web UI written in Javascript. The dashboard can be used to see [traces and spans](https://signoz.io/comparisons/opentelemetry-trace-vs-span/) across services. - **Root Cause Analysis**
Using traces you can drill down to services causing latency in particular user request. @@ -111,7 +111,7 @@ A large distributed application will have lots of sensitive telemetry data. AWS
diff --git a/data/blog/can-you-have-a-career-in-node-without-observability.mdx b/data/blog/can-you-have-a-career-in-node-without-observability.mdx
index 70239b807..8ef0e5053 100644
--- a/data/blog/can-you-have-a-career-in-node-without-observability.mdx
+++ b/data/blog/can-you-have-a-career-in-node-without-observability.mdx
@@ -60,7 +60,7 @@ Since we don’t want to use expensive paid tools, we’ll use OpenTelemetry to
## Instrumenting a Node application with OpenTelemetry
-This guide starts from the OpenTelemetry [getting started guide for Javascript](https://opentelemetry.io/docs/instrumentation/js/getting-started/nodejs/), but resolves some fragmentation in that documentation and adds a final part where you report data to an OpenTelemetry dashboard with SigNoz. This guide requires no special knowledge beyond the ability to read Javascript and run commands in bash.
+This guide starts from the OpenTelemetry [getting started guide for Javascript](https://opentelemetry.io/docs/instrumentation/js/getting-started/nodejs/), but resolves some fragmentation in that documentation and adds a final part where you report data to an [OpenTelemetry dashboard](https://signoz.io/blog/opentelemetry-visualization/) with SigNoz. This guide requires no special knowledge beyond the ability to read Javascript and run commands in bash.
### Step 1: Building our app
@@ -118,7 +118,7 @@ You can start the application with `node app.js` and you can visit [`http://loca
### Step 2: Add Auto-instrumentation
-A source of some confusion for new developers is the difference between manual instrumentation and auto-instrumentation. Remember that our goal with a basic application is trace data that shows where work is occurring as our application handles requests. It’s possible to construct this trace data 100% manually by adding calls into your code similar to the way you might be adding logging now. The OpenTelemetry SDK has support for creating and sending traces, letting you define trace context, add attributes and starting and stopping the time measurements (called ‘spans’) that make up a trace. For this example we’ll use the automatic option, which requires no direct changes to our code, and instead patches in wrappers for our functions that will automatically create traces.
+A source of some confusion for new developers is the difference between manual instrumentation and auto-instrumentation. Remember that our goal with a basic application is trace data that shows where work is occurring as our application handles requests. It’s possible to construct this trace data 100% manually by adding calls into your code similar to the way you might be adding logging now. The [OpenTelemetry SDK](https://signoz.io/comparisons/opentelemetry-api-vs-sdk/) has support for creating and sending traces, letting you define trace context, add attributes and starting and stopping the time measurements (called ‘spans’) that make up a trace. For this example we’ll use the automatic option, which requires no direct changes to our code, and instead patches in wrappers for our functions that will automatically create traces.
If you haven’t interacted with an automatic instrumentation package before it can seem quite magical, but if you look at our Flask app it’s rather easy to imagine how we can start a trace (when handing a request at a single route) and how we can label the following spans (function names), and how they can be connected.
@@ -209,7 +209,7 @@ If you leave the application running, the `PeriodicExportingMetricReader` will e
## Step 3: Report Traces to a SigNoz dashboard
-We’ll report traces to a dashboard on SigNoz.io. SigNoz offers a fully free and open source version you can run on your own cloud or laptop, but since we’re developers not operations specialists, we can use the new SigNoz cloud to create an online endpoint and dashboard.
+We’ll report traces to a dashboard on [SigNoz.io](https://signoz.io/application-performance-monitoring/). SigNoz offers a fully free and open source version you can run on your own cloud or laptop, but since we’re developers not operations specialists, we can use the new SigNoz cloud to create an online endpoint and dashboard.
Head to [https://signoz.io/teams/](https://signoz.io/teams/) to sign up for a team account to try it out.
@@ -274,7 +274,7 @@ process.on("SIGTERM", () => {
```
@@ -289,7 +289,7 @@ Some key features of SEM include:
- Identification of security concerns through a centralized log server.
- Detecting substantial changes in log sources.
-- Monitoring of essential metrics in real-time through its centralized log management system.
+- Monitoring of essential metrics in real-time through its centralized [log management system](https://signoz.io/blog/open-source-log-management/).
- Conducting event log analysis using a unified dashboard.
### 3. Splunk
@@ -345,13 +345,13 @@ Some key features of ManageEngine EventLog Analyzer are:
## Implement centralized logging using OpenTelemetry and SigNoz
-[SigNoz](https://signoz.io/) is an open source APM that provides logs, metrics, and traces under a single pane of glass. You can also correlate the telemetry signals to drive contextual insights faster. Using an open source APM has its advantages. You can self-host SigNoz in your environment to adhere to data privacy guidelines. Moreover, SigNoz has a thriving [slack community](https://signoz.io/slack) where you can ask questions and discuss best practices.
+[SigNoz](https://signoz.io/) is an [open source APM](https://signoz.io/application-performance-monitoring/) that provides logs, metrics, and traces under a single pane of glass. You can also correlate the telemetry signals to drive contextual insights faster. Using an open source APM has its advantages. You can self-host SigNoz in your environment to adhere to data privacy guidelines. Moreover, SigNoz has a thriving [slack community](https://signoz.io/slack) where you can ask questions and discuss best practices.
SigNoz uses OpenTelemetry to collect logs. OpenTelemetry is a Cloud Native Computing Foundation ( CNCF ) project aimed at standardizing how we instrument applications for generating telemetry data(logs, metrics, and traces).
OpenTelemetry provides a stand-alone service known as [OpenTelemetry Collector](https://signoz.io/blog/opentelemetry-collector-complete-guide/), which can be used to centralize the collection of logs from multiple sources.
-Apart from OpenTelemetry Collector, it also provides various receivers and processors for collecting first-party and third-party logs directly via OpenTelemetry Collector or existing agents such as FluentBit. [Collecting logs](https://signoz.io/blog/opentelemetry-logs/) with OpenTelemetry can help you set up a robust observability stack.
+Apart from OpenTelemetry Collector, it also provides various receivers and processors for collecting first-party and third-party logs directly via OpenTelemetry Collector or existing agents such as FluentBit. [Collecting logs](https://signoz.io/blog/opentelemetry-logs/) with OpenTelemetry can help you set up a robust [observability stack](https://signoz.io/guides/observability-stack/).
Let us see how you can collect application logs with OpenTelemetry.
@@ -369,7 +369,7 @@ There are **two** ways to collect application logs with OpenTelemetry:
In this approach, you can modify your logging library that is used by the application to use the logging SDK provided by OpenTelemetry and directly forward the logs from the application to OpenTelemetry. This approach removes any need for agents/intermediary medium but loses the simplicity of having the log file locally. @@ -380,7 +380,7 @@ For centralized logging, you can use various receivers and processors provided b OpenTelemetry provides instrumentation for generating logs. You need a backend for storing, querying, and analyzing your logs. [SigNoz](https://signoz.io/), a full-stack open source APM is built to support OpenTelemetry natively. It uses a columnar database - ClickHouse, for storing logs effectively. Big companies like Uber and Cloudflare have shifted to ClickHouse for log analytics. -The logs tab in SigNoz has advanced features like a log query builder, search across multiple fields, structured table view, JSON view, etc. +The logs tab in SigNoz has advanced features like a log [query builder](https://signoz.io/blog/query-builder-v5/), search across multiple fields, structured table view, JSON view, etc.
@@ -403,7 +403,7 @@ To control data volume and costs:
- Implement log sampling for high-volume, low-priority events
- Use tiered storage to balance performance and cost
-- Regularly review and optimize your log retention policies
+- Regularly review and optimize your [log retention](https://signoz.io/guides/log-retention/) policies
### Ensuring Log Data Quality and Consistency
@@ -417,7 +417,7 @@ Maintain high-quality log data by:
For complex infrastructures:
-- Use a centralized logging tool that supports multiple cloud providers
+- Use a [centralized logging](https://signoz.io/blog/centralized-logging/#1-signoz) tool that supports multiple cloud providers
- Implement a consistent logging strategy across all environments
- Consider using a cloud-agnostic logging solution for flexibility
@@ -467,7 +467,7 @@ Centralized logging is important because it improves security and compliance, en
The main components of a centralized logging system include log collection (gathering logs from various sources), log storage (storing logs in a central repository), and log analysis and visualization (using specialized tools to analyze and visualize the logs).
### What are some best practices for centralized logging?
-Some best practices for centralized logging include setting up log rotation and retention policies, implementing alerting and notification systems, ensuring data privacy and security, choosing the right logging solution, implementing log parsing and analysis, and regularly monitoring and maintaining the logging infrastructure.
+Some best practices for centralized logging include setting up log rotation and retention policies, implementing alerting and notification systems, ensuring data privacy and security, choosing the right logging solution, implementing [log parsing](https://signoz.io/guides/log-parsing/) and analysis, and regularly monitoring and maintaining the logging infrastructure.
### How can OpenTelemetry and SigNoz be used for centralized logging?
OpenTelemetry can be used to collect logs from multiple sources using its Collector component. SigNoz, an open-source APM tool, can then be used as a backend for storing, querying, and analyzing these logs. SigNoz provides features like a log query builder, search across multiple fields, and structured table views for effective log management.
diff --git a/data/blog/challenges-in-choosing-a-monitoring-tool-for-fintech-companies-in-india.mdx b/data/blog/challenges-in-choosing-a-monitoring-tool-for-fintech-companies-in-india.mdx
index 79bfeea31..8bc94f3e3 100644
--- a/data/blog/challenges-in-choosing-a-monitoring-tool-for-fintech-companies-in-india.mdx
+++ b/data/blog/challenges-in-choosing-a-monitoring-tool-for-fintech-companies-in-india.mdx
@@ -156,7 +156,7 @@ Can fintech firms send application performance data without including any **Per
You can consider using data scrubbers for removing PII data, but they are not full-proof. Also, it comes with the risk of occasional misses as your application will constantly be evolving.
-Another way is to give guidelines to developers that they dont log or send PII data to APM tools. But it is fraught with the risk of human error.
+Another way is to give guidelines to developers that they dont log or send PII data to [APM tools](https://signoz.io/blog/open-source-apm-tools/). But it is fraught with the risk of human error.
## Way to go for Fintech Companies
@@ -164,7 +164,7 @@ So what are the options of having robust performance monitoring in place?
Self-hosted versions of popular open-source software like Prometheus and Jaeger can be a good solution. But they have their own challenges, and not all companies can afford to solve the complexity of running a self-hosted version of the current popular open-source tools.
-Most of these tools solve a particular use-case, e.g., Prometheus is used for metrics monitoring, and Jaeger is used for distributed tracing. However, the true advantage of an APM solution comes by combining metrics with distributed tracing.
+Most of these tools solve a particular use-case, e.g., Prometheus is used for metrics monitoring, and Jaeger is used for [distributed tracing](https://signoz.io/distributed-tracing/). However, the true advantage of an APM solution comes by combining metrics with distributed tracing.
One option is to have the client software write log messages to a file stored on the client's device. This approach is relatively simple and can be useful for collecting logs from standalone client applications or gathering log data from devices that are not always connected to a network. @@ -59,19 +59,19 @@ The specific approach that is used will depend on the needs and requirements of ## Client Logging with OpenTelemetry -OpenTelemetry can be used to collect client-side logs, metrics, and traces. OpenTelemetry is an open-source collection of tools, APIs, and SDKs that aims to standardize how we generate and collect telemetry data. +[OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/) can be used to collect client-side logs, metrics, and traces. OpenTelemetry is an open-source collection of tools, APIs, and SDKs that aims to standardize how we generate and collect telemetry data. Using OpenTelemetry client libraries in various languages, you can generate and collect a lot of useful information with telemetry signals. For browser instrumentation, OpenTelemetry provides client libraries in Javascript to instrument your broswer. You can read more about implementing OpenTelemetry browser instrumentation [here](https://opentelemetry.io/docs/instrumentation/js/getting-started/browser/). -Once the logs are collected, you will ideally need a log management tool to store, query and analyze your logs. SigNoz, an open source APM can help you to store and analyze your client logs. +Once the logs are collected, you will ideally need a log management tool to store, query and analyze your logs. SigNoz, an [open source APM](https://signoz.io/application-performance-monitoring/) can help you to store and analyze your client logs. ## Analyze your client logs with SigNoz SigNoz is a full-stack open-source APM that can be used as a log management tool. SigNoz uses a columnar database ClickHouse to store logs, which is very efficient at ingesting and storing logs data. Columnar databases like ClickHouse are very effective in storing log data and making it available for analysis. -The logs tab in SigNoz has advanced features like a log query builder, search across multiple fields, structured table view, JSON view, etc. +The logs tab in [SigNoz](https://signoz.io/docs/introduction/) has advanced features like a log query builder, search across multiple fields, structured table view, JSON view, etc.
diff --git a/data/blog/cloud-infrastructure.mdx b/data/blog/cloud-infrastructure.mdx
index ea3d5da99..3fd384705 100644
--- a/data/blog/cloud-infrastructure.mdx
+++ b/data/blog/cloud-infrastructure.mdx
@@ -311,7 +311,7 @@ While cloud infrastructure offers significant benefits. It also presents challen
- Cloud infrastructure forms the foundation of cloud computing, offering flexibility and scalability.
- Core components include hardware, virtualization, storage, and networking resources.
- Various delivery and deployment models cater to different business needs.
-- To maintain a healthy cloud infrastructure, SigNoz offers performance monitoring, request tracing, KPI visualization, log centralization, and custom alerts.
+- To maintain a healthy cloud infrastructure, SigNoz offers performance monitoring, request tracing, KPI visualization, [log centralization](https://signoz.io/blog/centralized-logging/), and custom alerts.
- Challenges involve security, compliance, and cost management.
## FAQs
@@ -326,7 +326,7 @@ Cloud infrastructure empowers businesses to rapidly provision resources, scale a
### How does SigNoz aid in cloud infrastructure management?
-SigNoz provides monitoring, request tracing, key performance indicator (KPI) visualization, log centralization, and custom alerts to maintain optimal cloud infrastructure performance and health.
+[SigNoz](https://signoz.io/docs/architecture/) provides monitoring, request tracing, key performance indicator (KPI) visualization, log centralization, and custom alerts to maintain optimal cloud infrastructure performance and health.
### Can all app types leverage cloud infrastructure?
diff --git a/data/blog/cloud-strategy.mdx b/data/blog/cloud-strategy.mdx
index 8fda2eff7..59caa651f 100644
--- a/data/blog/cloud-strategy.mdx
+++ b/data/blog/cloud-strategy.mdx
@@ -224,7 +224,7 @@ Compliance can be at risk if you fail to meet regulatory requirements and standa
### Cost management
-Cloud strategy brings cloud cost management as one of the main challenges for an organization planning to migrate to the cloud. The uncontrolled cost of the cloud can cripple an organization because it can easily get out of hand. Monitoring of cloud practices and proper cost management is highly essential to prevent that. Best practices relating to the optimization of costs, along with continuous monitoring of cloud usage, are a must.
+Cloud strategy brings cloud cost management as one of the main challenges for an organization planning to migrate to the cloud. The uncontrolled cost of the cloud can cripple an organization because it can easily get out of hand. Monitoring of cloud practices and proper cost management is highly essential to prevent that. Best practices relating to the optimization of costs, along with [continuous monitoring](https://signoz.io/comparisons/continuous-monitoring-tools/) of cloud usage, are a must.
### Performance and latency
@@ -248,7 +248,7 @@ Although cloud providers like AWS provide monitoring tools like Cloudwatch, it i
SigNoz offers several key features that can support your cloud strategy:
-1. **Distributed tracing**: Visualize request flows across microservices, helping you identify bottlenecks and optimize performance.
+1. **[Distributed tracing](https://signoz.io/blog/distributed-tracing/)**: Visualize request flows across microservices, helping you identify bottlenecks and optimize performance.
2. **Metrics monitoring**: Track custom metrics and key performance indicators (KPIs) to ensure your cloud environment meets business objectives.
3. **Log management**: Centralize and analyze logs from various cloud services and applications for troubleshooting and compliance.
4. **Alerting and notifications**: Set up proactive alerts to detect and respond to issues before they impact your business.
diff --git a/data/blog/cloud-teams-plan-now-at-49usd.mdx b/data/blog/cloud-teams-plan-now-at-49usd.mdx
index 2e6e42ab4..6972c4112 100644
--- a/data/blog/cloud-teams-plan-now-at-49usd.mdx
+++ b/data/blog/cloud-teams-plan-now-at-49usd.mdx
@@ -50,7 +50,7 @@ Despite this urgent need, most observability tools are expensive and complex. Le
## We’re here to help
-We’ve always been committed to democratizing observability, starting with our open-source platform. With our new $49/month SigNoz Cloud plan, we’re extending that same ethos to our cloud offering, removing cost barriers and giving every builder, founder, and developer the tools they need to ship reliable, scalable AI products from day one.
+We’ve always been committed to democratizing observability, starting with our open-source platform. With our new $49/month [SigNoz](https://signoz.io/docs/introduction/) Cloud plan, we’re extending that same ethos to our cloud offering, removing cost barriers and giving every builder, founder, and developer the tools they need to ship reliable, scalable AI products from day one.
If you’re building with LLMs and AI coding assistants, observability is the foundation for reliability, trust, and speed.
diff --git a/data/blog/cloud-vs-self-hosted-deployment-guide.mdx b/data/blog/cloud-vs-self-hosted-deployment-guide.mdx
index 0d5e1b2e6..f0491cb9b 100644
--- a/data/blog/cloud-vs-self-hosted-deployment-guide.mdx
+++ b/data/blog/cloud-vs-self-hosted-deployment-guide.mdx
@@ -20,7 +20,7 @@ This guide will walk you through our two primary deployment approaches, **SigNoz
## The Starting Point for Most: SigNoz Cloud
-For the vast majority of teams, **SigNoz Cloud** is the simplest and fastest path to powerful, enterprise-grade observability. It’s a fully managed, production-ready service designed to let you focus on your product, not on managing another piece of infrastructure.
+For the vast majority of teams, **SigNoz Cloud** is the simplest and fastest path to powerful, enterprise-grade observability. It’s a fully managed, [production-ready](https://signoz.io/guides/production-readiness-checklist/) service designed to let you focus on your product, not on managing another piece of infrastructure.
Think of it this way: you wouldn't build your own data center to host your application, so why build and manage the complex infrastructure needed for a scalable observability platform?
@@ -54,9 +54,9 @@ If you fall into one of these categories, you still have options. We offer three
Our [Community Edition](https://signoz.io/docs/install/self-host/) is the open-source version of SigNoz with 22.8K stars on GitHub. It’s a complete observability platform that you can deploy and manage entirely on your own.
-It's the perfect starting point for developers, small teams, and personal projects. More importantly, it serves as a powerful evaluation tool within large enterprises. Instead of waiting weeks for procurement and compliance reviews, your engineers can deploy the Community Edition immediately to run a proof-of-concept and demonstrate the value of SigNoz.
+It's the perfect starting point for developers, small teams, and personal projects. More importantly, it serves as a powerful evaluation tool within large enterprises. Instead of waiting weeks for procurement and compliance reviews, your engineers can deploy the Community Edition immediately to run a proof-of-concept and demonstrate the value of [SigNoz](https://signoz.io/docs/introduction/).
-- **Best for:** Getting started quickly, evaluations, and teams comfortable with managing their own observability stack.
+- **Best for:** Getting started quickly, evaluations, and teams comfortable with managing their own [observability stack](https://signoz.io/guides/observability-stack/).
- **The Trade-off:** You are responsible for the entire lifecycle of the platform, from deployment and scaling to updates and maintenance.
### 2. Enterprise Self-Hosted: Control with Confidence
diff --git a/data/blog/cloudwatch-alternatives.mdx b/data/blog/cloudwatch-alternatives.mdx
index 60a4e849d..ba0c8dcd7 100644
--- a/data/blog/cloudwatch-alternatives.mdx
+++ b/data/blog/cloudwatch-alternatives.mdx
@@ -118,7 +118,7 @@ These limitations have led to a growing need for more comprehensive, multi-cloud
- Better support for diverse tech stacks
- More advanced analytics and visualization capabilities
- Improved cost-effectiveness for large-scale deployments
-- Enhanced features for distributed tracing and APM
+- Enhanced features for [distributed tracing](https://signoz.io/blog/distributed-tracing/) and APM
## Top CloudWatch Alternatives
@@ -196,7 +196,7 @@ Grafana provides a central UI to set and manage alerts with a central UI.
Datadog’s strength lies in delivering unified visibility across an organization's entire technological stack, empowering teams with profound insights and efficient troubleshooting. It supports real-time monitoring, advanced alerting, and customizable dashboards, making it particularly favored among DevOps teams and businesses operating in cloud-native environments.
-It seamlessly integrates with various tools and services, ensuring a smooth incorporation into existing workflows. It also has a suite of products encompassing log management, infrastructure monitoring, APM, and security monitoring, catering to the diverse needs of organizations.
+It seamlessly integrates with various tools and services, ensuring a smooth incorporation into existing workflows. It also has a suite of products encompassing log management, [infrastructure monitoring](https://signoz.io/guides/infrastructure-monitoring/), APM, and security monitoring, catering to the diverse needs of organizations.
@@ -281,11 +281,11 @@ The CloudWatch alternative you choose should be able to monitor services in mult
- **Metrics, logs, and traces**Using a single tool for all your monitoring needs helps consolidate the engineering bandwidth you spend on monitoring. Using a single tool for logs, metrics, and traces also helps to correlate different signals for better insights. - **Ease of shifting out**
-You should use a tool that is easy to get started with. A tool that helps in getting CloudWatch metrics easily will make the process of shifting out easier. +You should use a tool that is easy to get started with. A tool that helps in getting [CloudWatch metrics](https://signoz.io/blog/cloudwatch-metrics/) easily will make the process of shifting out easier. - **Pricing**
Monitoring data is huge, and different vendors bill differently. A tool like [Datadog](https://signoz.io/blog/pricing-comparison-signoz-vs-datadog-vs-newrelic-vs-grafana/#no-limits-on-custom-metrics-with-signoz) can get costly very soon. You should choose a tool that provides good value for your money. -SigNoz is a great CloudWatch alternative that provides logs, metrics and traces under a single pane of glass. It comes with great out-of-the-box charts for application metrics, database calls, apdex, and much more. The log management in SigNoz is also highly scalable, with an advanced query builder to search and filter logs quickly. +SigNoz is a great CloudWatch alternative that provides logs, metrics and traces under a single pane of glass. It comes with great out-of-the-box charts for application metrics, database calls, apdex, and much more. The log management in SigNoz is also highly scalable, with an advanced [query builder](https://signoz.io/blog/query-builder-v5/) to search and filter logs quickly. ## SigNoz: An Open-Source Alternative Worth Considering @@ -294,7 +294,7 @@ While exploring CloudWatch alternatives, it's worth considering SigNoz—an open **Key Features of SigNoz:** - Unified dashboard for metrics, traces, and logs -- Built on OpenTelemetry for standardized data collection +- Built on [OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/) for standardized data collection - Customizable dashboards and alerts - Cost-effective, especially for large-scale deployments diff --git a/data/blog/cloudwatch-metrics.mdx b/data/blog/cloudwatch-metrics.mdx index 4655a1e87..8349dfd4a 100644 --- a/data/blog/cloudwatch-metrics.mdx +++ b/data/blog/cloudwatch-metrics.mdx @@ -38,7 +38,7 @@ Cloudwatch offers two levels of monitoring: - **Basic Monitoring:** This is the default monitoring level for AWS services. It provides a standard set of metrics at no additional charge, with data points typically available at five-minute intervals. - **Detailed Monitoring:** Offers more granular data insights, with metrics available at one-minute intervals. It’s offered only by some AWS services, and you must choose to activate it. This option is particularly useful for short-term performance changes and more precise troubleshooting. -Here’s a list of services that offer detailed monitoring in AWS: +Here’s a list of services that offer detailed [monitoring in AWS](https://signoz.io/guides/aws-monitoring/): - Amazon API Gateway - Amazon CloudFront @@ -269,7 +269,7 @@ Here are a few tips to have in mind when looking for a CloudWatch alternative: ### Avoid Vendor Lock-in -A crucial factor to evaluate is the potential risk of vendor lock-in. If there are plans to migrate to a different platform, opting for a CloudWatch alternative becomes essential. CloudWatch is intricately designed for AWS resources, and transitioning to another platform might lead to a loss of valuable service-related data accumulated over time. +A crucial factor to evaluate is the potential risk of vendor lock-in. If there are plans to migrate to a different platform, opting for a [CloudWatch alternative](https://signoz.io/blog/cloudwatch-alternatives/) becomes essential. CloudWatch is intricately designed for AWS resources, and transitioning to another platform might lead to a loss of valuable service-related data accumulated over time. ### Choose a cost-effective solution @@ -296,7 +296,7 @@ Key architecture features of SigNoz: - Filter and query logs, build dashboards and alerts based on attributes in logs - Monitor infrastructure metrics such as CPU utilization or memory usage - Record exceptions automatically in Python, Java, Ruby, and Javascript -- Easy to set alerts with DIY query builder +- Easy to set alerts with DIY [query builder](https://signoz.io/blog/query-builder-v5/)
diff --git a/data/blog/container-monitoring-tools.mdx b/data/blog/container-monitoring-tools.mdx
index c688d8ca7..5516312fb 100644
--- a/data/blog/container-monitoring-tools.mdx
+++ b/data/blog/container-monitoring-tools.mdx
@@ -34,7 +34,7 @@ The most fundamental way to see how your containers are performing is by running
These metrics might be of some use in development and debugging but are not very user-friendly for production use-case. You won’t be able to determine the root cause of failures, understand usage patterns, usage peaks, etc.
-To better understand your application, you must be able to see patterns in your container performance easily. That’s where Docker container monitoring tools come into the picture.
+To better understand your application, you must be able to see patterns in your container performance easily. That’s where Docker [container monitoring tools](https://signoz.io/guides/container-monitoring/#the-evolution-of-container-monitoring-in-devops) come into the picture.
Here’s a list of the top 15 monitoring tools that can help you monitor your container-based applications.
@@ -190,7 +190,7 @@ It is a feature-packed enterprise solution with built-in integration from Docker
Splunk is a full-stack infrastructure monitoring solution that can address real-time cloud monitoring requirements at scale. It has support for both clouds and on-premises. It supports the integration of various tools, databases, and data processing platforms.
-Furthermore, it uses a docker logging driver, which outputs logs in a JSON file. It collects the data from multiple containers in multiple regions to a centralized server and feeds it into an analyzer.
+Furthermore, it uses a [docker logging driver](https://signoz.io/blog/docker-logging/), which outputs logs in a JSON file. It collects the data from multiple containers in multiple regions to a centralized server and feeds it into an analyzer.
### Sumo Logic
@@ -219,7 +219,7 @@ Sumo Logic is able to achieve these techniques with the help of a user agent and
Most traditional monitoring tools monitor infrastructure at the host level. But having insights into container performance is required to run container-based applications. Traditional monitoring tools are not suited to monitor container-based applications.
-A monitoring tool that can give you container-level insights along with capabilities to monitor performance at aggregated levels is best suited to monitor container-based applications. You can try out SigNoz to monitor your containerized application. As it is based on OpenTelemetry, you can make use of tags to see aggregated performance of containers.
+A monitoring tool that can give you container-level insights along with capabilities to monitor performance at aggregated levels is best suited to monitor container-based applications. You can try out SigNoz to monitor your containerized application. As it is based on [OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/), you can make use of tags to see aggregated performance of containers.
## Getting started with SigNoz
diff --git a/data/blog/context-propagation-in-distributed-tracing.mdx b/data/blog/context-propagation-in-distributed-tracing.mdx
index a2658be7f..07ef0b157 100644
--- a/data/blog/context-propagation-in-distributed-tracing.mdx
+++ b/data/blog/context-propagation-in-distributed-tracing.mdx
@@ -53,7 +53,7 @@ The underlying concept behind recreating an execution flow is based on identifyi
- all events related to a specific execution flow
- a causal relationship between events
-Together, this forms the substrate of tracing data which is then analyzed and visualized by tracing tools. To collect both these data points, context propagation comes into the picture.
+Together, this forms the substrate of tracing data which is then analyzed and visualized by [tracing tools](https://signoz.io/blog/distributed-tracing-tools/). To collect both these data points, context propagation comes into the picture.
Suppose a request gets triggered at the frontend client in a fictional e-commerce website. It will travel to different services to complete the user request. For example, users might have requested a search for a particular category of products, or they might want to know the discount codes available. The request will traverse all the services involved in completing the request.
@@ -93,9 +93,9 @@ Today’s applications based on distributed systems are quite complex. Multiple
World Wide Web Consortium (W3C) has recommendations on the format of trace contexts. The aim is to develop a standardized format of passing trace context over standard protocols like HTTP. It saves a lot of time in distributed tracing implementation and ensures interoperability between various tracing tools.
-Popular open standards for application instrumentation(the process of enabling application code to generate trace data) like OpenTelemetry follow the W3C Trace Context specification.
+Popular open standards for [application instrumentation](https://signoz.io/docs/instrumentation/)(the process of enabling application code to generate trace data) like OpenTelemetry follow the W3C Trace Context specification.
-There are two important identifiers used for passing context propagation:
+There are two important identifiers used for passing [context propagation](https://signoz.io/blog/opentelemetry-context-propagation/):
- A global identifier usually called **TraceID** identifies the set of correlated events
- An identifier for child events usually called **SpanID** to show the causal relationship between events in an execution flow
@@ -106,7 +106,7 @@ For example,
diff --git a/data/blog/current-state-of-opentelemetry.mdx b/data/blog/current-state-of-opentelemetry.mdx
index 21c7673bf..bda1a050f 100644
--- a/data/blog/current-state-of-opentelemetry.mdx
+++ b/data/blog/current-state-of-opentelemetry.mdx
@@ -16,7 +16,7 @@ The telemetry data collected by OpenTelemetry consist of logs, metrics, and trac
-At SigNoz, we are building an OpenTelemetry native APM. We believe in the mission of ubiquitous observability with OpenTelemetry. Managing distributed systems at scale is a pain, and OpenTelemetry aims to solve a lot of pain points for developers and devops folks.
+At [SigNoz](https://signoz.io/docs/introduction/), we are building an OpenTelemetry native APM. We believe in the mission of ubiquitous observability with OpenTelemetry. Managing distributed systems at scale is a pain, and OpenTelemetry aims to solve a lot of pain points for developers and devops folks.
I sat down with Pranay, the CEO and co-founder at SigNoz to discuss the current state of OpenTelemetry and how it fits in the DevOps ecosystem.
@@ -29,12 +29,12 @@ To understand complex distributed systems, DevOps engineers need to implement a
Two important reasons that make OpenTelemetry important to IT Ops are:
-- **OpenTelemetry makes your instrumentation future-proof**+- **[OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/) makes your instrumentation future-proof**
OpenTelemetry is an open standard and open source implementation with contributors from companies like AWS, Microsoft, Splunk, etc. It provides instrumentation libraries in almost all major programming languages and covers most of the popular open source frameworks. If tomorrow your team decides to use a new open source library in the tech stack, you can have the peace of mind that Opentelemetry will provide instrumentation for it. - **It is vendor-neutral and supports different telemetry signals like metrics, traces, logs, events**
Opentelemetry is the instrumentation standard. You can use any backend & storage layer to store telemetry data and frontend to visualize that data. -So as long as these components support the OTLP format ( OpenTelemetry’s format), they can process and visualize OTel data +So as long as these components support the OTLP format ( OpenTelemetry’s format), they can process and visualize [OTel](https://signoz.io/blog/what-is-opentelemetry/) data ### What do you see as the main business benefits OpenTelemetry will ultimately deliver? @@ -66,7 +66,7 @@ OpenTelemetry also provides a stand-alone service called the [OpenTelemetry Col ### How does APM fit in with OpenTelemetry? -**Pranay:** APM tools can provide support for OpenTelemetry data formats. As OpenTelemetry provides support for all telemetry signals - logs, metrics, and traces, it is possible for an APM tool to be based completely on OpenTelemetry. At SigNoz, we are building an OpenTelemetry native APM. +**Pranay:** [APM tools](https://signoz.io/blog/open-source-apm-tools/) can provide support for OpenTelemetry data formats. As OpenTelemetry provides support for all telemetry signals - logs, metrics, and traces, it is possible for an APM tool to be based completely on OpenTelemetry. At SigNoz, we are building an OpenTelemetry native APM. ### How does AIOps fit in with OpenTelemetry? diff --git a/data/blog/datadog-alternatives.mdx b/data/blog/datadog-alternatives.mdx index 0aded2712..1136979ce 100644 --- a/data/blog/datadog-alternatives.mdx +++ b/data/blog/datadog-alternatives.mdx @@ -11,7 +11,7 @@ keywords: [datadog alternatives,datadog,datadog competitors,apm tools,datadog al --- -The rising costs and complexities of monitoring cloud infrastructure are pushing many organizations to explore alternatives to Datadog. With monthly bills sometimes reaching thousands of dollars and feature sets that can be overwhelming, teams are looking for practical, cost-effective solutions that better fit their needs. Whether you're managing a fast-growing startup or overseeing DevOps in a large enterprise, it's crucial to understand your options to make informed decisions about your monitoring stack. +The rising costs and complexities of monitoring cloud infrastructure are pushing many organizations to explore [alternatives to Datadog](https://signoz.io/blog/datadog-alternatives/#signoz). With monthly bills sometimes reaching thousands of dollars and feature sets that can be overwhelming, teams are looking for practical, cost-effective solutions that better fit their needs. Whether you're managing a fast-growing startup or overseeing DevOps in a large enterprise, it's crucial to understand your options to make informed decisions about your monitoring stack. ## Why Organizations Look for Datadog Alternatives @@ -93,7 +93,7 @@ SigNoz is an excellent alternative to Datadog. It can be used as a drop-in repla SigNoz is built from the ground up to be OpenTelemetry native. This means we fully leverage OTel's semantic conventions, providing deeper, out-of-the-box insights. Unlike Datadog, **we don't charge you extra for "custom metrics" when you're using OpenTelemetry**. This fundamental difference means you can embrace open standards without the fear of a massive bill. -We've also recently launched features that double down on our OTel-native approach, including: +We've also recently launched features that double down on our [OTel](https://signoz.io/blog/what-is-opentelemetry/)-native approach, including: - **[Trace Funnels](https://signoz.io/blog/tracing-funnels-observability-distributed-systems/):** Intelligently sample and analyze traces to focus on what's important. - **[External API Monitoring](https://signoz.io/docs/application-monitoring/api-monitoring/):** Gain visibility into the performance of third-party APIs your application depends on. @@ -166,7 +166,7 @@ Here's an feature overview of SigNoz: - **Browser & Mobile Monitoring**: Track frontend and mobile app performance - **Infrastructure Monitoring**: Monitor hosts, containers and cloud services - **Log Management**: Centralized log aggregation and analysis -- **Synthetic Monitoring**: Proactive monitoring of user journeys +- **Synthetic Monitoring**: [Proactive monitoring](https://signoz.io/guides/proactive-monitoring/) of user journeys - **Serverless Monitoring**: Monitor AWS Lambda and other serverless platforms - **AIOps & Analytics**: AI-powered insights and anomaly detection @@ -208,7 +208,7 @@ For a detailed comparison, read more on [DataDog vs New Relic](https://signoz.io ### Key Features - **Application Performance Monitoring**: End-to-end visibility with OneAgent technology -- **Infrastructure Monitoring**: Monitor hosts, cloud services and virtual machines +- **[Infrastructure Monitoring](https://signoz.io/guides/infrastructure-monitoring/)**: Monitor hosts, cloud services and virtual machines - **Container Monitoring**: Support for Docker, Kubernetes environments - **Network Monitoring**: Deep network visibility and analysis - **Root Cause Analysis**: AI-powered problem detection and analysis @@ -259,12 +259,12 @@ Grafana's observability platform is built on the LGTM stack: - **Loki:** An efficient log aggregation system that indexes log metadata, enabling cost-effective storage and fast querying, integrated seamlessly with Grafana. - **Grafana**: A versatile visualization tool offering customizable dashboards to display and analyze data from various sources, including metrics, logs, and traces. - **Tempo**: A [**distributed tracing**](https://signoz.io/blog/distributed-tracing-in-microservices/) backend focused on scalability, storing and querying trace data, with easy integration into Grafana for visualization. -- **Mimir**: A long-term, scalable storage system for Prometheus metrics, ensuring high performance and availability for large-scale metric data. +- **Mimir**: A long-term, scalable storage system for [Prometheus metrics](https://signoz.io/guides/what-are-the-4-types-of-metrics-in-prometheus/), ensuring high performance and availability for large-scale metric data. ### Key Features - **Visualization & Dashboarding**: Create customizable dashboards to analyze and display data from multiple sources -- **LGTM Stack Integration**: Core observability components working together seamlessly +- **[LGTM Stack](https://signoz.io/docs/migration/migrate-from-grafana-to-signoz/) Integration**: Core observability components working together seamlessly - **Cloud-Native Support**: Designed for modern containerized and microservices architectures - **Open Source Foundation**: Built on open-source technologies with strong community support - **Multi-Backend Support**: Connect to various data sources and backends @@ -315,7 +315,7 @@ With dynamic topology mapping, you can have an overview of your network devices - Cloud Monitoring (AWS, Azure, GCP) - Application Performance Monitoring - Log Analytics -- Distributed Tracing +- [Distributed Tracing](https://signoz.io/blog/distributed-tracing/) - Configuration Monitoring - Service Insights @@ -415,9 +415,9 @@ It offers both on-premises and cloud-based solutions, and it has a wide range of ### Key Features - **Metrics Monitoring**: Sematext offers monitoring solutions that allow organizations to collect and visualize metrics from various sources, including servers, applications, containers, and cloud services. -- **Log Management**: Sematext provides log management tools that enable the collection, aggregation, and analysis of log data from different components of an organization's technology stack. +- **Log Management**: Sematext provides [log management tools](https://signoz.io/blog/open-source-log-management/) that enable the collection, aggregation, and analysis of log data from different components of an organization's technology stack. - **Tracing and APM:** Sematext offers application performance monitoring and tracing capabilities, allowing organizations to trace requests and transactions through their applications. -- **Infrastructure Monitoring:** Sematext's solutions cover infrastructure monitoring, allowing organizations to monitor server health, resource utilization, and network performance. +- **Infrastructure Monitoring:** Sematext's solutions cover infrastructure monitoring, allowing organizations to [monitor server health](https://signoz.io/guides/server-health-monitoring/), resource utilization, and network performance.
- DataDog's APM tool provides end-to-end distributed tracing from frontend devices to databases. You can connect the collected traces to infrastructure metrics, network calls, and live processes. + DataDog's APM tool provides end-to-end [distributed tracing](https://signoz.io/distributed-tracing/) from frontend devices to databases. You can connect the collected traces to infrastructure metrics, network calls, and live processes. - **Security monitoring**
Using DataDog security monitoring, you can analyze operational and security logs in real-time. It provides built-in threshold and anomaly detection rules to detect threats quickly. @@ -156,7 +156,7 @@ With SigNoz, you can do the following: - Filter and query logs, build dashboards and alerts based on attributes in logs - Monitor infrastructure metrics such as CPU utilization or memory usage - Record exceptions automatically in Python, Java, Ruby, and Javascript -- Easy to set alerts with DIY query builder +- Easy to set alerts with DIY [query builder](https://signoz.io/blog/query-builder-v5/) SigNoz comes with out of box visualization of things like RED metrics. diff --git a/data/blog/datadog-vs-grafana.mdx b/data/blog/datadog-vs-grafana.mdx index fa210b539..8f7ed4b8d 100644 --- a/data/blog/datadog-vs-grafana.mdx +++ b/data/blog/datadog-vs-grafana.mdx @@ -16,7 +16,7 @@ If you're in looking for an all-encompassing observability solution and are not [](https://signoz.io/blog/pricing-comparison-signoz-vs-datadog-vs-newrelic-vs-grafana/) -Grafana is primarily used to visualize your time-series database data into meaningful charts from which you can draw insights. Grafana can be used to build an open-source stack for APM, time-series, and logs monitoring, but you will need to consider the effort and cost of maintaining a self-hosted stack. +Grafana is primarily used to visualize your time-series database data into meaningful charts from which you can draw insights. Grafana can be used to build an open-source stack for APM, time-series, and [logs monitoring](https://signoz.io/blog/log-monitoring/), but you will need to consider the effort and cost of maintaining a self-hosted stack. In this post, we will compare DataDog with Grafana based on the following categories: @@ -31,7 +31,7 @@ We will also explore the key features of DataDog and Grafana. The disadvantage of DataDog is that it does not specialize in any one domain. And the good thing about Grafana is that it can be combined with specialized tools for monitoring your application. -The disadvantage of using Grafana is the cost and bandwidth required to maintain it. GrafanaLabs, the company behind Grafana, also offers a cloud version that aims to provide a fully managed observability stack. +The disadvantage of using Grafana is the cost and bandwidth required to maintain it. GrafanaLabs, the company behind Grafana, also offers a cloud version that aims to provide a fully managed [observability stack](https://signoz.io/guides/observability-stack/). Some of the key differences between DataDog and Grafana: @@ -54,7 +54,7 @@ Some of the key differences between DataDog and Grafana: - Log Management - APM - Security Monitoring - - Infrastructure Monitoring + - [Infrastructure Monitoring](https://signoz.io/guides/infrastructure-monitoring/) - Network Monitoring Grafana can be combined with popular tools for monitoring use-cases: - ElasticSearch(for logs) @@ -154,7 +154,7 @@ Some of the key features of SigNoz are: - Out-of-the-box charts for application metrics like p90, p99, latency, error rates, request rates, etc. - Distributed tracing to get end-to-end visibility of your services - Monitor any metrics important to you, build dashboards for specific use-cases -- Logs Management equipped with a powerful search and filter query builder +- Logs Management equipped with a powerful search and filter [query builder](https://signoz.io/blog/query-builder-v5/) - Exceptions monitoring to track exceptions in your application - Easy to set alerts with DIY query builder diff --git a/data/blog/datadog-vs-jaeger.mdx b/data/blog/datadog-vs-jaeger.mdx index 7541a1cbd..954e2a883 100644 --- a/data/blog/datadog-vs-jaeger.mdx +++ b/data/blog/datadog-vs-jaeger.mdx @@ -37,7 +37,7 @@ The most fundamental difference is the deployment model, which dictates control, - **Jaeger** is **self-hosted and open-source**. You deploy and manage all components (collectors, storage, UI) on your own infrastructure, whether on-premises or in the cloud. This gives you full control over your data and architecture but requires significant engineering effort to deploy, scale, and maintain. - A key update is that **Jaeger v2** is now built on the OpenTelemetry Collector, making it more modular and aligned with modern standards. + A key update is that **Jaeger v2** is now built on the [OpenTelemetry Collector](https://signoz.io/blog/opentelemetry-collector-complete-guide/), making it more modular and aligned with modern standards. ### Scope & Features: All-in-One Swiss Army Knife or a Precision Scalpel? @@ -51,7 +51,7 @@ What kind of visibility do you truly need? Are you looking for a comprehensive o caption="Datadog's UI allows correlating traces with other signals like logs and metrics." /> -- **Jaeger** is a **specialized distributed tracing tool**. It excels at capturing, visualizing, and analyzing traces but does not handle metrics or logs. To get a complete picture, you must integrate it with other tools like Prometheus (for metrics) and Elasticsearch/Loki (for logs), which requires manual effort to correlate data (e.g., by ensuring trace IDs are present in logs). +- **Jaeger** is a **specialized distributed [tracing tool](https://signoz.io/blog/distributed-tracing-tools/)**. It excels at capturing, visualizing, and analyzing traces but does not handle metrics or logs. To get a complete picture, you must integrate it with other tools like Prometheus (for metrics) and Elasticsearch/Loki (for logs), which requires manual effort to correlate data (e.g., by ensuring trace IDs are present in logs). ### Instrumentation & Integration: How Much Hand-Holding Do You Need? @@ -59,7 +59,7 @@ How do you get telemetry data from out your apps and into your observability pla - **Datadog** offers over 500+ turnkey integrations and auto-instrumentation libraries that make data collection easy. While it supports OpenTelemetry, its ecosystem is primarily designed for a seamless experience with its own agents. -- **Jaeger** integrates primarily through **open standards**, specifically OpenTelemetry. This prevents vendor lock-in at the code level—you can instrument your applications once with OpenTelemetry and send the data to Jaeger or any other compatible backend. This offers flexibility but requires more hands-on configuration than Datadog's plug-and-play approach. +- **Jaeger** integrates primarily through **open standards**, specifically [OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/). This prevents vendor lock-in at the code level—you can instrument your applications once with OpenTelemetry and send the data to Jaeger or any other compatible backend. This offers flexibility but requires more hands-on configuration than Datadog's plug-and-play approach.
- Prometheus provides a query language called PromQL. Using PromQL, you can filter and aggregate metrics data in real-time. + Prometheus provides a query language called PromQL. Using PromQL, you can filter and [aggregate metrics](https://signoz.io/docs/metrics-management/types-and-aggregation/) data in real-time. - **Pull model data collection**
- In contrast to most APM tools, Prometheus data collection is pull-based. It requires you to run an HTTP server that exposes Prometheus metrics. + In contrast to most [APM tools](https://signoz.io/blog/open-source-apm-tools/), [Prometheus data](https://signoz.io/guides/how-does-grafana-get-data-from-prometheus/) collection is pull-based. It requires you to run an HTTP server that exposes Prometheus metrics. - **Alert manager**
You can use a rules.yml file to set alerts for critical issues. You need to install the alert manager to get useful notifications from Prometheus. It has some cool features like grouping alerts into one notification and silencing alerts for a period of time. @@ -246,7 +246,7 @@ Some of the things SigNoz can help you track: - Filter and query logs, build dashboards and alerts based on attributes in logs - Monitor infrastructure metrics such as CPU utilization or memory usage - Record exceptions automatically in Python, Java, Ruby, and Javascript -- Easy to set alerts with DIY query builder +- Easy to set alerts with DIY [query builder](https://signoz.io/blog/query-builder-v5/) ## Getting started with SigNoz diff --git a/data/blog/deep-temporal-observability.mdx b/data/blog/deep-temporal-observability.mdx index 352de0f77..aea776d2d 100644 --- a/data/blog/deep-temporal-observability.mdx +++ b/data/blog/deep-temporal-observability.mdx @@ -24,7 +24,7 @@ This is a real pain for anyone running production workloads on Temporal. You nee You end up jumping between dashboards, grepping logs, and manually stitching together context. It’s slow, error-prone, and not scalable for modern distributed systems. -Now, with SigNoz, you can observe your Temporal workflows end-to-end-correlating metrics, traces, and logs in one unified view. This makes it dramatically easier to pinpoint bottlenecks, troubleshoot failures, and optimize performance. +Now, with [SigNoz](https://signoz.io/docs/introduction/), you can observe your Temporal workflows end-to-end-correlating metrics, traces, and logs in one unified view. This makes it dramatically easier to pinpoint bottlenecks, troubleshoot failures, and optimize performance. ## Why We Built This @@ -45,11 +45,11 @@ We built deep Temporal observability in SigNoz so you can: ### 1. Instrumentation -[Instrument](https://signoz.io/docs/integrations/temporal-cloud-metrics/) your Temporal app with OpenTelemetry. We support Go and TypeScript out of the box. The instrumentation attaches all the right attributes like workflow ID, activity type, namespace, task queue, etc. to your telemetry data. +[Instrument](https://signoz.io/docs/integrations/temporal-cloud-metrics/) your Temporal app with [OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/). We support Go and TypeScript out of the box. The instrumentation attaches all the right attributes like workflow ID, activity type, namespace, task queue, etc. to your telemetry data. ### 2. Unified View in SigNoz -Once your app is running, SigNoz shows both client and worker services with default APM metrics, traces, and logs. For example: +Once your app is running, SigNoz shows both client and worker services with default [APM metrics](https://signoz.io/guides/apm-metrics/), traces, and logs. For example: - In the traces tab, you see every workflow execution, broken down by activities. Each activity span shows duration and all relevant attributes. - You can filter traces and logs by workflow ID, worker, or activity type, and group by any attribute. diff --git a/data/blog/deeper-trace-analytics-root-and-entry-spans.mdx b/data/blog/deeper-trace-analytics-root-and-entry-spans.mdx index 8b6375336..fac80a03b 100644 --- a/data/blog/deeper-trace-analytics-root-and-entry-spans.mdx +++ b/data/blog/deeper-trace-analytics-root-and-entry-spans.mdx @@ -13,7 +13,7 @@ keywords: [opentelemetry, traces, root span, entry span, SigNoz] Debugging distributed systems can often feel like searching for a needle in a haystack. When issues arise, engineers need faster ways to pinpoint critical spans within their traces. -With our latest Deeper Trace Analytics update, SigNoz now enables powerful filtering for root and entry spans—making it significantly easier to analyze and debug distributed traces. +With our latest Deeper Trace Analytics update, [SigNoz](https://signoz.io/docs/introduction/) now enables powerful filtering for root and entry spans—making it significantly easier to analyze and debug [distributed traces](https://signoz.io/blog/distributed-tracing/). ## Watch Demo @@ -125,7 +125,7 @@ We’re just getting started with advanced trace analytics! 🚀 Coming soon: With Deeper Trace Analytics, it is easier to debug distributed systems. Find the most critical spans, analyze performance bottlenecks, and optimize your services quickly. -In order to send traces to SigNoz, you will have to instrument your application with OpenTelemetry. +In order to send traces to SigNoz, you will have to instrument your application with [OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/).
diff --git a/data/blog/distributed-tracing-in-microservices.mdx b/data/blog/distributed-tracing-in-microservices.mdx
index 7f5b3abee..8d411b2c9 100644
--- a/data/blog/distributed-tracing-in-microservices.mdx
+++ b/data/blog/distributed-tracing-in-microservices.mdx
@@ -47,7 +47,7 @@ It is hard to monitor a microservices-based application because of its distribut
+3. **Setting up [Opentelemetry agent](https://signoz.io/comparisons/opentelemetry-collector-vs-agent/)**
For instrumenting Java applications, OpenTelemetry has a very handy Java JAR agent that can be attached to any Java 8+ application. The JAR agent can detect a number of [popular libraries and frameworks](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md) and instrument it right out of the box. You don't need to add any code for that. Download the [latest version](https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/latest/download/opentelemetry-javaagent.jar) of the Java JAR agent, and copy jar agent file in your application code. We have placed the agent under the folder named `agents`. @@ -175,7 +175,7 @@ Below are the steps to run the sample Java application with OpenTelemetry:
+4. **Setting up SigNoz as the [OpenTelemetry backend](https://signoz.io/blog/opentelemetry-backend/)**
To set up OpenTelemetry to collect and export telemetry data, you need to specify OTLP (OpenTelemetry Protocol) endpoint. It consists of the IP of the machine where SigNoz is installed and the port number at which SigNoz listens. OTLP endpoint for SigNoz - `
+ `@opentelemetry/sdk-node` - This package provides the full [OpenTelemetry SDK](https://signoz.io/comparisons/opentelemetry-api-vs-sdk/) for Node.js including tracing and metrics.
`@opentelemetry/auto-instrumentations-node` - This module provides a simple way to initialize multiple Node instrumentations.
@@ -155,7 +155,7 @@ Below are the steps to run the sample nodejs application with OpenTelemetry: You can check out the code sample [here](https://github.com/SigNoz/distributed-tracing-nodejs-sample/blob/main/src/tracer.ts). -4. **Setting up SigNoz as the OpenTelemetry backend**
+4. **Setting up SigNoz as the [OpenTelemetry backend](https://signoz.io/blog/opentelemetry-backend/)**
We have set up environment variables required by OpenTelemetry in the `scripts` section of `package.json`. To set up OpenTelemetry to collect and export telemetry data, you need to specify OTLP (OpenTelemetry Protocol) endpoint. It consists of the IP of the machine where SigNoz is installed and the port number at which SigNoz listens. diff --git a/data/blog/distributed-tracing-span.mdx b/data/blog/distributed-tracing-span.mdx index 592ca98af..d5074fc1c 100644 --- a/data/blog/distributed-tracing-span.mdx +++ b/data/blog/distributed-tracing-span.mdx @@ -15,7 +15,7 @@ Spans are fundamental building blocks of distributed tracing. A single trace in  -Distributed tracing is critical to application performance monitoring in microservice-based architecture. Before we deep dive into spans, let's have a brief overview of distributed tracing. +[Distributed tracing](https://signoz.io/blog/distributed-tracing/) is critical to application performance monitoring in microservice-based architecture. Before we deep dive into spans, let's have a brief overview of distributed tracing. ## What is distributed tracing? In a microservices architecture, a user request travels through hundreds, even thousands of services before serving the user what they need. Engineering teams often responsible for maintaining single services have no visibility over how the system performs as a whole. @@ -87,7 +87,7 @@ Combining all the spans in a trace can give you a detailed idea about how the re **Span context:**
A Span context uniquely identifies the request a span is part of. It serves as a container holding critical information that links together spans across various services and machines. Span context consists of three core components: -- **Trace ID:** The same trace ID as in the trace context, linking spans to the broader trace. +- **[Trace ID](https://signoz.io/comparisons/opentelemetry-trace-id-vs-span-id/):** The same trace ID as in the trace context, linking spans to the broader trace. - **Span ID:** A unique identifier for each span within the trace, which is crucial for distinguishing the span's role within the trace. - **Timestamps:** Timing details for span creation. @@ -143,9 +143,9 @@ In essence, Traces give a broad overview of a request journey while Spans give a ## Getting started with Distributed Tracing -Distributed tracing has become a key debugging tool for applications based on microservices architecture. If you want to implement distributed tracing for your application, you can use SigNoz - a full stack open source APM. +Distributed tracing has become a key debugging tool for applications based on microservices architecture. If you want to implement distributed tracing for your application, you can use SigNoz - a full stack [open source APM](https://signoz.io/application-performance-monitoring/). -SigNoz provides metrics monitoring, log management, and distributed tracing under a single pane of glass and is built to support OpenTelemetry natively. OpenTelemetry is quietly becoming the world standard for application instrumentation. Using OpenTelemetry, you can avoid vendor lock-in and it comes with handy client libraries which can help you get started with distributed tracing easily. +SigNoz provides metrics monitoring, log management, and distributed tracing under a single pane of glass and is built to support OpenTelemetry natively. OpenTelemetry is quietly becoming the world standard for [application instrumentation](https://signoz.io/docs/instrumentation/). Using OpenTelemetry, you can avoid vendor lock-in and it comes with handy client libraries which can help you get started with distributed tracing easily. SigNoz provides easy-to-use visualizations like flamegraphs and Gantt charts from tracing data collected with OpenTelemetry. diff --git a/data/blog/distributed-tracing-tools.mdx b/data/blog/distributed-tracing-tools.mdx index 04d2c6c0c..25de9806e 100644 --- a/data/blog/distributed-tracing-tools.mdx +++ b/data/blog/distributed-tracing-tools.mdx @@ -29,7 +29,7 @@ Here, we'll look at some of the best distributed tracing tools. We'll see what e | Datadog | Commercial | Wide range of integrations, unified platform | Tiered pricing | | Elastic APM | Open-source / Commercial | Part of ELK stack, machine learning features | Free (basic), Tiered pricing for advanced features | -Now, let's explore the top 15 distributed tracing tools in 2025. +Now, let's explore the top 15 [distributed tracing tools](https://signoz.io/blog/distributed-tracing-tools/) in 2025. ## SigNoz @@ -50,9 +50,9 @@ With SigNoz, you can do the following: - Filter and query logs, build dashboards and alerts based on attributes in logs - Monitor infrastructure metrics such as CPU utilization or memory usage - Record exceptions automatically in Python, Java, Ruby, and JavaScript -- Easy to set alerts with DIY query builder +- Easy to set alerts with DIY [query builder](https://signoz.io/blog/query-builder-v5/) - Advanced Trace Analytics powered by ClickHouse Queries -- Detect N+1 query problems +- Detect [N+1 query](https://signoz.io/blog/N-1-query-distributed-tracing/) problems (Feel free to check the page for a complete list of features: [https://signoz.io/distributed-tracing/](https://signoz.io/distributed-tracing/).) @@ -72,7 +72,7 @@ With SigNoz, you can do the following: - Supports OpenTelemetry Protocol (OTLP) while maintaining compatibility with OpenTracing - Works with multiple storage backends like Cassandra, Elasticsearch, OpenSearch, ClickHouse, and more - Head-based and tail-based sampling to optimize storage and performance. -- Exposes Prometheus metrics and structured logs via Zap +- Exposes [Prometheus metrics](https://signoz.io/guides/what-are-the-4-types-of-metrics-in-prometheus/) and structured logs via Zap Jaeger's UI can be used to see individual traces. You can filter the traces based on service, duration, and tags. @@ -151,7 +151,7 @@ With Turbo360 BAM, you can track key properties and allow users to locate a tran - Automatic injection and collection of data - Integrates with OpenTelemetry and the W3C Trace Context, ensuring that even serverless functions, service meshes, and hybrid-cloud environments are fully observable - Dynatrace's AI engine (Davis) leverages the rich data from PurePath and correlates trace information with logs, metrics, and other telemetry. -- Collects high-fidelity data on every component interaction within a transaction. The data capture includes timing data, context propagation via thread-local storage, and method-level insights. +- Collects high-fidelity data on every component interaction within a transaction. The data capture includes timing data, [context propagation](https://signoz.io/blog/opentelemetry-context-propagation/) via thread-local storage, and method-level insights. - Always-on code profiling and diagnostics tools for application analysis One of the limitations of Dynatrace is the constraints on the number of unique values (or “buckets”) that Dynatrace can process for certain request attributes within PurePaths. For instance, community feedback has noted a hard-coded limit of around 1,000 distinct buckets per attribute: @@ -209,7 +209,7 @@ Note that ServiceNow Cloud Observability -The IBM Instana is a distributed tracing tool aimed at microservice applications. The Instana platform offers website monitoring, cloud & infrastructure monitoring, and an observability platform, apart from distributed tracing of microservice applications. +The IBM Instana is a distributed tracing tool aimed at microservice applications. The Instana platform offers website monitoring, cloud & [infrastructure monitoring](https://signoz.io/guides/infrastructure-monitoring/), and an observability platform, apart from distributed tracing of microservice applications. ### Why Use IBM Instana for Distributed Tracing @@ -279,7 +279,7 @@ analysis. It stores all trace data in Splunk Cloud's offering. - No sample, full fidelity trace data ingestion. You can capture all trace data to ensure your cloud-native application works as it should. - Splunk APM provides a seamless correlation between infrastructure metrics and application performance metrics. - AI-driven troubleshooting -- Unified observability across multiple telemetry datasets +- [Unified observability](https://signoz.io/unified-observability/) across multiple telemetry datasets That said, Splunk can also be overwhelming for various reasons: @@ -323,7 +323,7 @@ When evaluating distributed tracing tools, consider these essential features: - **End-to-end visibility**: The ability to trace requests across all services and components in your system. - **Language and framework support**: Compatibility with the programming languages and frameworks you use. -- **Integration capabilities**: Seamless integration with your existing monitoring and observability stack. +- **Integration capabilities**: Seamless integration with your existing monitoring and [observability stack](https://signoz.io/guides/observability-stack/). - **Scalability**: The capacity to handle high volumes of trace data in production environments. - **Data visualization**: Intuitive dashboards and service maps for easy analysis. - **Sampling techniques**: Methods to manage data volume without losing critical information. @@ -405,7 +405,7 @@ The main challenges include managing data volume, ensuring data privacy and secu ### How do you choose the right distributed tracing tool? -When selecting a distributed tracing tool, consider factors such as compatibility with your technology stack, ease of implementation and maintenance, scalability, integration with existing monitoring tools, cost and licensing model, data retention and storage options, analysis and visualization capabilities, and support for OpenTelemetry standards. +When selecting a distributed tracing tool, consider factors such as compatibility with your technology stack, ease of implementation and maintenance, scalability, integration with existing monitoring tools, cost and licensing model, data retention and storage options, analysis and visualization capabilities, and support for [OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/) standards. --- diff --git a/data/blog/distributed-tracing.mdx b/data/blog/distributed-tracing.mdx index 8eafb1f90..83dc39841 100644 --- a/data/blog/distributed-tracing.mdx +++ b/data/blog/distributed-tracing.mdx @@ -24,7 +24,7 @@ Distributed tracing is a method to track user requests in their entirety as it t In a distributed system, a click from a user initiates a transaction that can travel through hundreds of components before completing the user request. Distributed tracing is the technique that shows how the different components interact together to complete the user request. -The top two important data points that distributed tracing captures about a user request are: +The top two important data points that [distributed tracing](https://signoz.io/distributed-tracing/) captures about a user request are: - the time taken to traverse each component in a distributed system - the sequential flow of the request from its start to the end @@ -37,7 +37,7 @@ The microservices architecture allows multiple technology stacks, decentralized The benefits of microservices architecture come with the increased complexity of operation and troubleshooting. A user request can travel hundreds or even thousands of these components to fulfill a single-use case. As such, there are many failure points in the application, and robust monitoring is needed to identify failure points and latency issues. -But traditional monitoring tools are not adequate to monitor microservices architectures. This is because these tools were designed to monitor a single application instance. The metrics collected from a single instance will not give us insights into how a user request performed as it touches multiple components, but the data collected with distributed tracing can give us those insights. +But traditional monitoring tools are not adequate to [monitor microservices](https://signoz.io/guides/microservices-monitoring/) architectures. This is because these tools were designed to monitor a single application instance. The metrics collected from a single instance will not give us insights into how a user request performed as it touches multiple components, but the data collected with distributed tracing can give us those insights. ## Understanding a Trace @@ -104,7 +104,7 @@ Distributed tracing can also serve as a knowledge base for your engineering team OpenTelemetry is an open-source project under CNCF(Cloud Native Computing Foundation) that aims to standardize the process of creation and management of telemetry data like logs, metrics, and traces. Other notable projects under CNCF are Kubernetes, Helm, and etcd. -OpenTelemetry is used to instrument application code to generate telemetry data. Instrumentation is the process of enabling your application code to emit telemetry data. For example, you can use [OpenTelemetry Java agent](https://signoz.io/opentelemetry/java-agent/) to instrument your Spring Boot applications to send out telemetry data automatically. +OpenTelemetry is used to [instrument application](https://signoz.io/docs/instrumentation/) code to generate telemetry data. Instrumentation is the process of enabling your application code to emit telemetry data. For example, you can use [OpenTelemetry Java agent](https://signoz.io/opentelemetry/java-agent/) to instrument your Spring Boot applications to send out telemetry data automatically. The question is why is OpenTelemetry important for the future of distributed tracing. The reasons can be summarized in the following points: diff --git a/data/blog/diving-in-to-opentelemetry-data-with-our-new-trace-and-logs-explorer.mdx b/data/blog/diving-in-to-opentelemetry-data-with-our-new-trace-and-logs-explorer.mdx index 5a6aa432c..8f44496a0 100644 --- a/data/blog/diving-in-to-opentelemetry-data-with-our-new-trace-and-logs-explorer.mdx +++ b/data/blog/diving-in-to-opentelemetry-data-with-our-new-trace-and-logs-explorer.mdx @@ -9,7 +9,7 @@ image: /img/blog/2023/08/query-builder/query-builder-cover.jpg hide_table_of_contents: false keywords: [OpenTelemetry,Clickhouse] --- -The team at SigNoz would like to share recent developments released this month that greatly enhance the ability to dynamically query your trace and log data. With these tools anyone can explore complex OpenTelemetry data and gain insight into their stack. +The team at SigNoz would like to share recent developments released this month that greatly enhance the ability to dynamically query your trace and log data. With these tools anyone can explore complex [OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/) data and gain insight into their stack. @@ -72,7 +72,7 @@ Directly from results you can add the query to a dashboard and set up an alert. ## Conclusion -In the ever-evolving landscape of observability tools, SigNoz continues to make significant strides towards providing an open-source alternative to proprietary solutions. +In the ever-evolving landscape of observability tools, [SigNoz](https://signoz.io/docs/introduction/) continues to make significant strides towards providing an open-source alternative to proprietary solutions. By addressing the inherent limitations of query-based exploration, SigNoz has broken down barriers that often restrict meaningful engagement with observability data. Our new query builder for logs and traces allows teams to bring in SRE's and Operations Engineers to the process of querying their observability data. diff --git a/data/blog/docker-container-lifecycle.mdx b/data/blog/docker-container-lifecycle.mdx index 85652c328..756c68487 100644 --- a/data/blog/docker-container-lifecycle.mdx +++ b/data/blog/docker-container-lifecycle.mdx @@ -195,7 +195,7 @@ We have covered all the topics related to Docker in brief and took a deep dive i Once your Docker containers are up and running, you need to take care of the resource usage and performance of containers and their hosts. Docker provides different ways to access these metrics for monitoring, for example, [docker stats](https://signoz.io/blog/docker-stats/). -Docker [container monitoring](https://signoz.io/blog/container-monitoring-tools/) is critical for running containerized applications. For a robust monitoring and observability setup, you need to use a tool that visualizes the metrics important for container monitoring and also lets you set alerts on critical metrics. For Docker container monitoring, you can use [SigNoz](https://signoz.io/) - an open source APM. +Docker [container monitoring](https://signoz.io/blog/container-monitoring-tools/) is critical for running containerized applications. For a robust monitoring and observability setup, you need to use a tool that visualizes the metrics important for container monitoring and also lets you set alerts on critical metrics. For Docker container monitoring, you can use [SigNoz](https://signoz.io/) - an [open source APM](https://signoz.io/application-performance-monitoring/). SigNoz uses OpenTelemetry to collect metrics from your container for monitoring. OpenTelemetry is becoming the world standard for instrumentation of cloud-native applications, and it is backed by the CNCF foundation, the same foundation under which Kubernetes graduated. diff --git a/data/blog/docker-log-rotation.mdx b/data/blog/docker-log-rotation.mdx index d821af36f..a635b71d6 100644 --- a/data/blog/docker-log-rotation.mdx +++ b/data/blog/docker-log-rotation.mdx @@ -9,7 +9,7 @@ image: /img/blog/2022/07/docker_log_rotation_cover.jpeg keywords: [docker,docker logs,docker log rotation,docker logging drivers] --- -It is essential to configure log rotation for Docker containers. Log rotation is not performed by default, and if it’s not configured, logs on the Docker host can build up and eat up disk space. This guide will teach us how to set up Docker log rotation. +It is essential to configure log rotation for Docker containers. Log rotation is not performed by default, and if it’s not configured, logs on the Docker host can build up and eat up disk space. This guide will teach us how to set up [Docker log rotation](https://signoz.io/blog/docker-log-rotation/#configuring-docker-log-rotation). @@ -18,7 +18,7 @@ It is essential to configure log rotation for Docker containers. Log rotation is Logs are an essential piece of telemetry data. Logs can be used to debug performance issues in applications. They produce a thorough list of the events that take place in your application, which can be used to troubleshoot issues and identify the root cause of a problem. With containerization, it is easier to scale applications. But the operation complexity has increased manifolds. Containers are ephemeral. Frequently changing container-based environments are challenging to monitor. [Docker logs](https://signoz.io/blog/docker-logs/) can help debug performance issues. -Applications in Docker containers emit logs through `stdout` and `stderr` output streams. The logging driver that you choose can access these streams. Based on your logging driver, you can configure the format and storage of Docker logs. You can also send the emitted logs to a central log management system. +Applications in Docker containers emit logs through `stdout` and `stderr` output streams. The logging driver that you choose can access these streams. Based on your logging driver, you can configure the format and storage of Docker logs. You can also send the emitted logs to a central [log management system](https://signoz.io/blog/open-source-log-management/). Before deep-diving into configuring Docker log rotation, let's briefly overview Docker logs. @@ -36,7 +36,7 @@ In Docker, primarily, there are two types of log files. Docker does not impose a size restriction on logging files. Hence they will inevitably increase over time and consume storage if left unchecked. You can imagine the growth of log files over time and the amount of storage they would require in a scenario where you have numerous containers running. -Limiting the size and quantity of locally stored log files is the main goal of log rotation. Docker logs must be cycled at predetermined intervals because manually deleting logs is a laborious task. But the first question is, where are Docker logs stored? +Limiting the size and quantity of locally stored log files is the main goal of log rotation. Docker logs must be cycled at predetermined intervals because manually deleting logs is a laborious task. But the first question is, [where are Docker logs](https://signoz.io/guides/docker-view-logs/#exporting-logs) stored?
+**Step 1:** Go to the [Docker daemon](https://signoz.io/guides/docker-daemon-logs/) configuration file location:
On Linux: `/etc/docker/` directory On Windows: `C:\ProgramData\docker\config\daemon.json` @@ -186,7 +186,7 @@ You can also have a look at the Uber and Cloudflare have shifted from Elasticsearch to ClickHouse for storing their log data. @@ -577,9 +577,9 @@ SigNoz uses a columnar database - ClickHouse, for storing logs efficiently. Big But logs are just one aspect of getting insights from your software systems. Modern applications are complex distributed systems. For debugging performance issues, you need to make your systems observable. Logs, when combined with metrics and traces form an observability dataset that can help you debug performance issues quickly. -SigNoz can help you monitor your application by collecting all types of telemetry data. It correlates all your telemetry data(logs, metrics, and traces) into a single suite of monitoring. It is built to support OpenTelemetry natively. OpenTelemetry is becoming the world standard for instrumenting cloud-native applications. +SigNoz can help you monitor your application by collecting all types of telemetry data. It correlates all your telemetry data(logs, metrics, and traces) into a single suite of monitoring. It is built to support [OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/) natively. OpenTelemetry is becoming the world standard for instrumenting cloud-native applications. -You can check out SigNoz GitHub repo: +You can check out [SigNoz GitHub](https://github.com/signoz/signoz) repo:  diff --git a/data/blog/docker-logs.mdx b/data/blog/docker-logs.mdx index 66331ed23..9bfcae1b6 100644 --- a/data/blog/docker-logs.mdx +++ b/data/blog/docker-logs.mdx @@ -68,7 +68,7 @@ Gaining insight into the activity and performance of your Docker containers is e ### Accessing Docker logs with Docker CLI -The Docker Command Line Interface (CLI) provides a means for users to interact with Docker components, including containers, images, networks, and more. To access logs generated by Docker containers, the docker logs command can be utilized. +The Docker Command Line Interface (CLI) provides a means for users to interact with Docker components, including containers, images, networks, and more. To access logs generated by Docker containers, the [docker logs](https://signoz.io/guides/docker-logs-location/) command can be utilized. The syntax for accessing docker logs with the CLI: @@ -81,7 +81,7 @@ where: - `CONTAINER` is the name or ID of the container that you want to view the logs of. - `OPTIONS` is an optional flag that you can use to specify the details of the logs that you want to retrieve. To explore different options available for usage, refer to Docker's official documentation. -The docker logs command retrieves and displays the logs generated by a container in the console. The logs can be viewed in real-time or after the container has stopped. By default, the command retrieves all logs produced by the container, however, the user has the option to specify a time range or limit the number of logs displayed. This provides a flexible approach to accessing and reviewing the logs of a container. The docker logs command is a valuable tool for debugging and monitoring the performance of Docker containers. +The [docker logs command](https://signoz.io/guides/docker-view-logs/) retrieves and displays the logs generated by a container in the console. The logs can be viewed in real-time or after the container has stopped. By default, the command retrieves all logs produced by the container, however, the user has the option to specify a time range or limit the number of logs displayed. This provides a flexible approach to accessing and reviewing the logs of a container. The docker logs command is a valuable tool for debugging and monitoring the performance of Docker containers. ### Accessing Docker Logs with Docker API @@ -107,7 +107,7 @@ The Docker Application Programming Interface (API) enables developers to access You will need to replace `
@@ -221,7 +221,7 @@ Docker logs are critical components of managing and maintaining the health of Do
It is important to have a robust and efficient log management strategy in place, as it helps to ensure that logs are captured, stored, and analyzed effectively. Adopting a dedicated log management tool, instead of relying solely on the native methods of accessing and managing Docker logs, can provide a range of advanced features and greater flexibility for analyzing and processing logs from your containers.
-Log management tools like SigNoz can enhance the capability to handle logs generated by Docker containers. It offers a comprehensive and scalable approach to log analytics that can cater to specific needs and requirements, which might not be met by the native Docker logging options like logging drivers or the Docker API. For instance, advanced log parsing, filtering, or transforming functions that are not feasible using just the logging drivers or the Docker API can be carried out with SigNoz.
+[Log management tools](https://signoz.io/blog/open-source-log-management/) like SigNoz can enhance the capability to handle logs generated by Docker containers. It offers a comprehensive and scalable approach to log analytics that can cater to specific needs and requirements, which might not be met by the native Docker logging options like logging drivers or the Docker API. For instance, advanced [log parsing](https://signoz.io/guides/log-parsing/), filtering, or transforming functions that are not feasible using just the logging drivers or the Docker API can be carried out with SigNoz.
---
diff --git a/data/blog/docker-stats.mdx b/data/blog/docker-stats.mdx
index 7340ca5ca..31bfd1763 100644
--- a/data/blog/docker-stats.mdx
+++ b/data/blog/docker-stats.mdx
@@ -172,7 +172,7 @@ Here is the list of applicable placeholders to use with the Go template syntax:
## Final Thoughts
-In this article, we discussed ways to monitor resource usage metrics in Docker focused on the `docker stats` command. Other ways of using The Docker stats, Pseudo-files in sysfs, and REST API exposed by the Docker daemon are native ways of monitoring resource utilization metrics.
+In this article, we discussed ways to monitor resource usage metrics in Docker focused on the `docker stats` command. Other ways of using The Docker stats, Pseudo-files in sysfs, and REST API exposed by the [Docker daemon](https://signoz.io/guides/docker-daemon-logs/) are native ways of monitoring resource utilization metrics.
Docker container monitoring is critical for running containerized applications. For a robust monitoring and observability setup, you need to use a tool that visualizes the metrics important for container monitoring and also lets you set alerts on critical metrics. SigNoz is an open-source observability tool that can help you do that.
diff --git a/data/blog/docker-syslog.mdx b/data/blog/docker-syslog.mdx
index 45129ad51..bcdeaba21 100644
--- a/data/blog/docker-syslog.mdx
+++ b/data/blog/docker-syslog.mdx
@@ -13,9 +13,9 @@ keywords: [docker syslog,docker logs,logging,syslog,log management,log analytics
Logs are useful for troubleshooting and identifying issues in applications, as they provide a record of events and activities. However, managing log data can be challenging due to the large volume of log events generated by modern applications, as well as the need to balance the level of detail in the logs and the impact on the application's performance.
-Collecting logs from Docker can be challenging when running a large number of containers or running Docker on multiple hosts. These challenges include managing a large volume of logs, accessing logs from multiple hosts, ensuring the security of logs, and getting a comprehensive view of container and application behavior. A centralized logging system can help address these challenges by allowing you to store and manage all of your logs in a single location.
+Collecting logs from Docker can be challenging when running a large number of containers or running Docker on multiple hosts. These challenges include managing a large volume of logs, accessing logs from multiple hosts, ensuring the security of logs, and getting a comprehensive view of container and application behavior. A [centralized logging system](https://signoz.io/blog/centralized-logging/) can help address these challenges by allowing you to store and manage all of your logs in a single location.
-Docker Syslog is a built-in logging system provided by Docker that allows you to centralize and manage the logs produced by your Docker containers. In this article, we will delve into the capabilities of Docker Syslog, discuss how to configure and use it as a centralized logging solution for your Docker containers and demonstrate how it can be utilized to effectively manage and analyze your [Docker logs](https://signoz.io/blog/docker-logs/).
+Docker Syslog is a built-in logging system provided by Docker that allows you to centralize and manage the logs produced by your Docker containers. In this article, we will delve into the capabilities of Docker Syslog, discuss how to configure and use it as a [centralized logging solution](https://signoz.io/blog/centralized-logging/#1-signoz) for your Docker containers and demonstrate how it can be utilized to effectively manage and analyze your [Docker logs](https://signoz.io/blog/docker-logs/).
## Understanding Syslog
@@ -68,7 +68,7 @@ The Syslog logging driver can be set up for both the Docker daemon and container
To configure the Docker Daemon to the Syslog driver:
-**Step 1:** Go to the Docker daemon configuration file location:
+**Step 1:** Go to the [Docker daemon](https://signoz.io/guides/docker-daemon-logs/) configuration file location:
On Linux: `/etc/docker/daemon.json` directory
On Windows: `C:\\\\ProgramData\\\\docker\\\\config\\\\daemon.json`
@@ -191,7 +191,7 @@ To fine-tune your Docker Syslog setup, consider these advanced options:
```
-1. **Severity levels**: Set appropriate Syslog severity levels:
+1. **Severity levels**: Set appropriate [Syslog severity](https://signoz.io/guides/syslog-levels/) levels:
```json
{
@@ -225,7 +225,7 @@ Using Docker with the syslog logging driver has several limitations that users s
- **No Built-in Log Rotation**: By default, the syslog driver does not handle log rotation on the Docker host. This can result in log files growing indefinitely, potentially consuming significant disk space over time.
- **Decompression Overhead**: Reading log information from rotated and compressed log files requires decompression, temporarily increasing disk usage and CPU load. This can impact system performance, especially under heavy logging activities.
-- **Limited Metadata**: The syslog logging driver may include less metadata about the Docker containers compared to other logging drivers, such as the name, ID, or labels of the container. This can limit the ability to filter and search logs effectively.
+- **Limited Metadata**: The syslog logging driver may include less metadata about the Docker containers compared to other logging drivers, such as the name, ID, or labels of the container. This can limit the ability to filter and [search logs](https://signoz.io/docs/logs-management/logs-api/search-logs/) effectively.
## Troubleshooting Common Docker Syslog Issues
@@ -260,7 +260,7 @@ These commands provide insights into container logging configuration and output.
While traditional log management tools offer valuable insights, modern observability platforms like SigNoz provide a more comprehensive approach to container monitoring.
-SigNoz is a full-stack open-source Application Performance Monitoring tool that you can use for monitoring logs, metrics, and traces. One key aspect of observability is log management, and SigNoz provides a range of tools for collecting, analyzing, and visualizing Docker logs.
+SigNoz is a full-stack open-source Application Performance Monitoring tool that you can use for [monitoring logs](https://signoz.io/blog/log-monitoring/), metrics, and traces. One key aspect of observability is log management, and SigNoz provides a range of tools for collecting, analyzing, and visualizing Docker logs.
It uses ClickHouse, a columnar database, to efficiently store and provide access to log data for analysis.
@@ -273,7 +273,7 @@ SigNoz complements Docker Syslog by offering:
SigNoz uses OpenTelemetry for instrumenting applications. OpenTelemetry, backed by CNCF, is quickly becoming the world standard for instrumenting cloud-native applications.
-The logs tab in SigNoz has advanced features like a log query builder, search across multiple fields, structured table view, JSON view, etc.
+The logs tab in SigNoz has advanced features like a log [query builder](https://signoz.io/blog/query-builder-v5/), search across multiple fields, structured table view, JSON view, etc.
@@ -302,8 +302,8 @@ With the advanced Log Query Builder, you can filter out logs quickly with a mix
To maximize the benefits of Docker Syslog, follow these best practices:
-1. **Structure log messages**: Use JSON logging for easier parsing and analysis.
-2. **Implement log retention policies**: Balance storage costs with compliance requirements.
+1. **Structure log messages**: Use [JSON logging](https://signoz.io/blog/json-logs/) for easier parsing and analysis.
+2. **Implement [log retention](https://signoz.io/guides/log-retention/) policies**: Balance storage costs with compliance requirements.
3. **Monitor logging performance**: Watch for increased latency or resource usage.
4. **Use environment variables**: Externalize logging configuration for flexibility.
5. **Implement log sampling**: Reduce volume for high-throughput applications.
@@ -321,9 +321,9 @@ In this article, we discussed Syslog, Docker Syslog as a logging driver, and how
It is important to have a separate log management platform that provides additional capabilities and flexibility for managing and analyzing the Syslog logs from your Docker containers.
-A centralized log management tool can also help to ensure that you have a robust and scalable solution for log analytics that meets your specific needs and requirements, as the Syslog server or logging driver may not have the necessary features or capabilities to fully manage and analyze the logs. For example, you may want to perform complex log parsing, filtering, or transformation operations that are not possible with the Syslog server or logging driver.
+A centralized log management tool can also help to ensure that you have a robust and scalable solution for log analytics that meets your specific needs and requirements, as the Syslog server or logging driver may not have the necessary features or capabilities to fully manage and analyze the logs. For example, you may want to perform complex [log parsing](https://signoz.io/guides/log-parsing/), filtering, or transformation operations that are not possible with the Syslog server or logging driver.
-An advanced centralized logging platform/tool for collecting your logs is [SigNoz](https://signoz.io/) - an open source log management solution.
+An advanced centralized logging platform/tool for collecting your logs is [SigNoz](https://signoz.io/) - an [open source log management](https://signoz.io/blog/open-source-log-management/) solution.
## Key Takeaways
diff --git a/data/blog/dynatrace-alternative.mdx b/data/blog/dynatrace-alternative.mdx
index b22803744..96ea2d6af 100644
--- a/data/blog/dynatrace-alternative.mdx
+++ b/data/blog/dynatrace-alternative.mdx
@@ -15,7 +15,7 @@ If you're looking for an open-source alternative to Dynatrace, then you're at th
-In today's digital economy, more and more companies are shifting to cloud-native and microservice architecture to support global scale and distributed teams. But distributed systems also make it impossible for engineering teams to track how user requests perform across services. Application performance monitoring tools provide the visibility needed to resolve performance issues quickly.
+In today's digital economy, more and more companies are shifting to cloud-native and microservice architecture to support global scale and distributed teams. But distributed systems also make it impossible for engineering teams to track how user requests perform across services. [Application performance monitoring tools](https://signoz.io/blog/open-source-apm-tools/) provide the visibility needed to resolve performance issues quickly.
Dynatrace is a great SaaS tool when it comes to application performance monitoring. But there are a few challenges when it comes to enterprise SaaS products, and it's just not a great fit for every company.
@@ -40,7 +40,7 @@ Some of the key features of good observability tools are:
## Why choose an open-Source alternative to Dynatrace?
-APM and observability tools are critical tools in a developer's kit. These tools improve developer efficiency, save bandwidth by resolving issues quickly, and increase developer productivity.
+[APM and observability](https://signoz.io/guides/apm-vs-observability/) tools are critical tools in a developer's kit. These tools improve developer efficiency, save bandwidth by resolving issues quickly, and increase developer productivity.
An open-source product is always a better choice for any developer tool. Some of the key advantages of open-source developer tools are:
@@ -74,7 +74,7 @@ Some of our key features which makes SigNoz vastly superior to current open-sour
- Filter and query logs, build dashboards and alerts based on attributes in logs
- Monitor infrastructure metrics such as CPU utilization or memory usage
- Record exceptions automatically in Python, Java, Ruby, and Javascript
-- Easy to set alerts with DIY query builder
+- Easy to set alerts with DIY [query builder](https://signoz.io/blog/query-builder-v5/)
### Out of box application metrics
@@ -140,7 +140,7 @@ Detailed flamegraph & Gantt charts to find the exact cause of the issue and whic
### Logs Management with advanced log query builder and live tailing
-SigNoz provides Logs management with advanced log query builder. You can also monitor your logs in real-time using live tailing.
+[SigNoz](https://signoz.io/docs/introduction/) provides Logs management with advanced log query builder. You can also monitor your logs in real-time using live tailing.
diff --git a/data/blog/dynatrace-alternatives.mdx b/data/blog/dynatrace-alternatives.mdx
index 971b9a251..ec9a76cab 100644
--- a/data/blog/dynatrace-alternatives.mdx
+++ b/data/blog/dynatrace-alternatives.mdx
@@ -39,7 +39,7 @@ keywords: [dynatrace alternatives,dynatrace competitors,dynatrace,application mo
"@id": "https://signoz.io/blog/dynatrace-alternatives/"
},
"description": "Are you tired of Dynatrace's complex UI or find it very expensive? Here are top 9 Dynatrace alternatives & competitors in 2024. Explore options like SigNoz, Datadog, AppDynamics, and more for your application monitoring needs.",
- "keywords": "dynatrace alternatives, dynatrace competitors, application monitoring, opentelemetry, signoz, apm tools",
+ "keywords": "dynatrace alternatives, dynatrace competitors, application monitoring, opentelemetry, signoz, [apm tools](https://signoz.io/blog/open-source-apm-tools/)",
"articleSection": "Technology",
"inLanguage": "en",
"isPartOf": {
@@ -178,7 +178,7 @@ keywords: [dynatrace alternatives,dynatrace competitors,dynatrace,application mo
-Are you looking for a Dynatrace alternative? Then you have come to the right place. In this article, we will go through the top 9 Dynatrace alternatives. First, let's briefly discuss what Dynatrace offers and why you might consider other solutions.
+Are you looking for a [Dynatrace alternative](https://signoz.io/blog/dynatrace-alternatives/)? Then you have come to the right place. In this article, we will go through the top 9 Dynatrace alternatives. First, let's briefly discuss what Dynatrace offers and why you might consider other solutions.
@@ -213,7 +213,7 @@ List of top Dynatrace alternatives in 2024:
## SigNoz (Open-Source)
-[SigNoz](https://signoz.io/) stands out as an excellent alternative to Dynatrace, being a comprehensive open-source Application Performance Management (APM) solution. It provides application metrics, distributed tracing, and logging capabilities, all under a single dashboard. SigNoz is an open source APM that provides a SaaS-like experience depending on your needs. It is built to support OpenTelemetry natively. OpenTelemetry is quietly becoming the world standard for instrumenting cloud-native applications. It has a user-friendly interface and is easy to get started with.
+[SigNoz](https://signoz.io/) stands out as an excellent alternative to Dynatrace, being a comprehensive open-source Application Performance Management (APM) solution. It provides application metrics, distributed tracing, and logging capabilities, all under a single dashboard. SigNoz is an [open source APM](https://signoz.io/application-performance-monitoring/) that provides a SaaS-like experience depending on your needs. It is built to support OpenTelemetry natively. OpenTelemetry is quietly becoming the world standard for instrumenting cloud-native applications. It has a user-friendly interface and is easy to get started with.
Some of the key features of SigNoz include:
@@ -448,9 +448,9 @@ Selecting the ideal Dynatrace alternative requires careful consideration of your
5. **Test before committing**: Take advantage of free trials or proof-of-concept periods to ensure the solution meets your needs in practice.
-The above Dynatrace alternatives can be a good option to meet your monitoring needs. If you're moving out of Dynatrace, a good option can be to move out of closed SaaS vendors and shift towards open source solution. Many application owners are now shifting to **OpenTelemetry** for their observability data. OpenTelemetry is an open-source collection of APIs, SDKs, and tools. It can be used to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior.
+The above Dynatrace alternatives can be a good option to meet your monitoring needs. If you're moving out of Dynatrace, a good option can be to move out of closed SaaS vendors and shift towards open source solution. Many application owners are now shifting to **[OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/)** for their observability data. OpenTelemetry is an open-source collection of APIs, SDKs, and tools. It can be used to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior.
-Using OpenTelemetry to generate telemetry data fress you from vendor lock-in as it gives you an option to export the data to a backend of your choice. For an OpenTelemetry backend, SigNoz can be a great choice. It is built to support OpenTelemetry data natively.
+Using OpenTelemetry to generate telemetry data fress you from vendor lock-in as it gives you an option to export the data to a backend of your choice. For an [OpenTelemetry backend](https://signoz.io/blog/opentelemetry-backend/), SigNoz can be a great choice. It is built to support OpenTelemetry data natively.
## Getting started with SigNoz
@@ -504,7 +504,7 @@ The top alternatives to Dynatrace include SigNoz (open-source), Datadog, AppDyna
People might look for Dynatrace alternatives due to its complexity, which can make it less accessible for quick data utilization. Additionally, Dynatrace's pricing model can be expensive for large enterprises with extensive monitoring needs, and the costs may not always align perfectly with usage patterns.
### What is SigNoz and how does it compare to Dynatrace?
-SigNoz is an open-source Application Performance Management (APM) solution that provides application metrics, distributed tracing, and logging capabilities under a single dashboard. It offers a user-friendly interface, is built to support OpenTelemetry natively, and provides a SaaS-like experience. SigNoz can be a cost-effective alternative to Dynatrace, especially for organizations looking for an open-source solution.
+SigNoz is an open-source Application Performance Management (APM) solution that provides application metrics, [distributed tracing](https://signoz.io/blog/distributed-tracing/), and logging capabilities under a single dashboard. It offers a user-friendly interface, is built to support OpenTelemetry natively, and provides a SaaS-like experience. SigNoz can be a cost-effective alternative to Dynatrace, especially for organizations looking for an open-source solution.
### How does the pricing of Dynatrace alternatives compare?
Pricing models vary among Dynatrace alternatives. Some, like SigNoz, offer usage-based pricing starting at $49 per month. Others, like Datadog and New Relic, have decentralized pricing models based on specific products or data ingestion. Many alternatives offer tiered pricing structures, including free plans for basic usage. It's important to evaluate each tool's pricing structure based on your specific monitoring needs and scale.
@@ -512,7 +512,7 @@ Pricing models vary among Dynatrace alternatives. Some, like SigNoz, offer usage
### What are the key features to look for in a Dynatrace alternative?
When considering Dynatrace alternatives, look for features such as:
1. Application Performance Monitoring (APM)
-2. Infrastructure Monitoring
+2. [Infrastructure Monitoring](https://signoz.io/guides/infrastructure-monitoring/)
3. Distributed Tracing
4. Log Management
5. Real-User Monitoring
diff --git a/data/blog/eks-monitoring-with-opentelemetry.mdx b/data/blog/eks-monitoring-with-opentelemetry.mdx
index 3ddd07257..af879a793 100644
--- a/data/blog/eks-monitoring-with-opentelemetry.mdx
+++ b/data/blog/eks-monitoring-with-opentelemetry.mdx
@@ -186,7 +186,7 @@ Deploying the OpenTelemetry Collector can be approached in two distinct ways, de
SigNoz provides Helm charts that package OpenTelemetry Collectors in a flavor optimized for SigNoz users. It simplifies the installation with some defaults.
-**Step 1: Install SigNoz Helm Chart**
+**Step 1: Install [SigNoz Helm Chart](https://signoz.io/docs/install/self-host/)**
To set up the OpenTelemetry Collector for SigNoz, you'll first need your ingestion key and the specific region your instance is hosted in. This information is vital for configuring the collector to send data to your SigNoz instance securely. You can retrieve these details from your SigNoz settings page.
@@ -270,7 +270,7 @@ Review the output for the `OTEL_EXPORTER_OTLP_ENDPOINT`, `SIGNOZ_API_KEY`, and `
### Advanced: Installing with OpenTelemetry Helm Charts
-Before proceeding with the vanilla charts, ensure you deeply understand your current infrastructure and OpenTelemetry's configuration requirements. This approach is recommended for advanced users who need to integrate the collector into a multi-faceted observability stack.
+Before proceeding with the vanilla charts, ensure you deeply understand your current infrastructure and OpenTelemetry's configuration requirements. This approach is recommended for advanced users who need to integrate the collector into a multi-faceted [observability stack](https://signoz.io/guides/observability-stack/).
Refer to the official documentation for the Helm chart for comprehensive instructions and configuration options: OpenTelemetry Helm Charts Documentation.
@@ -372,7 +372,7 @@ If you want to get started quickly with Kubernetes monitoring, you can use the f
## Conclusion
-In this tutorial, you installed an OpenTelemetry Collector to collect kubelet metrics from your EKS cluster and send the collected data to SigNoz for monitoring and alerts.
+In this tutorial, you installed an [OpenTelemetry Collector](https://signoz.io/guides/opentelemetry-collector-vs-exporter/) to collect [kubelet metrics](https://signoz.io/docs/userguide/k8s-metrics/) from your EKS cluster and send the collected data to SigNoz for monitoring and alerts.
Visit our [complete guide](https://signoz.io/blog/opentelemetry-collector-complete-guide/) on OpenTelemetry Collector to learn more about it. OpenTelemetry is quietly becoming the world standard for open-source observability, and by using it, you can have advantages like a single standard for all telemetry signals, no vendor lock-in, etc.
diff --git a/data/blog/elasticsearch-vs-splunk.mdx b/data/blog/elasticsearch-vs-splunk.mdx
index 9be86eed7..3a984d0f1 100644
--- a/data/blog/elasticsearch-vs-splunk.mdx
+++ b/data/blog/elasticsearch-vs-splunk.mdx
@@ -10,7 +10,7 @@ keywords: [elasticsearch vs splunk,splunk,elasticsearch,elk,elk stack,grafana,lo
---
{/* */}
-Elasticsearch and Splunk can both be used as log analysis tools for software applications. Elasticsearch, as part of the Elastic Stack, offers a highly scalable, open-source solution for real-time search and analytics across diverse data types, excelling in customization but with a steeper learning curve. In contrast, Splunk provides a more user-friendly, proprietary platform focused on log management and security analytics, offering ease of use and powerful data correlation features, but at a potentially higher cost and lesser scalability compared to Elasticsearch.
+Elasticsearch and Splunk can both be used as [log analysis tools](https://signoz.io/comparisons/log-analysis-tools/) for software applications. Elasticsearch, as part of the Elastic Stack, offers a highly scalable, open-source solution for real-time search and analytics across diverse data types, excelling in customization but with a steeper learning curve. In contrast, Splunk provides a more user-friendly, proprietary platform focused on log management and security analytics, offering ease of use and powerful data correlation features, but at a potentially higher cost and lesser scalability compared to Elasticsearch.
@@ -155,7 +155,7 @@ Big companies like Uber have OpenTelemetry for instrumenting applications. OpenTelemetry, backed by CNCF, is quickly becoming the world standard for instrumenting cloud-native applications.
-The logs tab in SigNoz has advanced features like a log query builder, search across multiple fields, structured table view, JSON view, etc.
+The logs tab in SigNoz has advanced features like a log [query builder](https://signoz.io/blog/query-builder-v5/), search across multiple fields, structured table view, JSON view, etc.
diff --git a/data/blog/elk-alternative-open-source.mdx b/data/blog/elk-alternative-open-source.mdx
index 857b3b20c..9f437fafb 100644
--- a/data/blog/elk-alternative-open-source.mdx
+++ b/data/blog/elk-alternative-open-source.mdx
@@ -10,7 +10,7 @@ keywords: [elk alternative,elk alternative open source,elk stack,elasticsearch,k
---
-ELK is the acronym Elasticsearch, Logstash, and Kibana, and combined, it is one of the most popular log analytics tools. Elastic changed the license of Elasticsearch and Kibana from the fully open Apache 2 license to a proprietary dual license. The ELK stack is also hard to manage at scale. SigNoz can be used as a lightweight alternative to the ELK stack.
+ELK is the acronym Elasticsearch, Logstash, and Kibana, and combined, it is one of the most popular [log analytics tools](https://signoz.io/comparisons/log-analysis-tools/). Elastic changed the license of Elasticsearch and Kibana from the fully open Apache 2 license to a proprietary dual license. The ELK stack is also hard to manage at scale. SigNoz can be used as a lightweight alternative to the ELK stack.
@@ -102,7 +102,7 @@ Log data is often vast, and developers need to check and see the logs they are i
### Correlating Logs with other Observability signals
-As SigNoz uses OpenTelemetry to collect and parse logs, you can use it to correlate logs with other observability signals like traces and metrics. Correlating logs with other observability signals can enrich your logs data and help debug applications faster.
+As [SigNoz](https://signoz.io/docs/introduction/) uses OpenTelemetry to collect and [parse logs](https://signoz.io/guides/log-parsing/), you can use it to correlate logs with other observability signals like traces and metrics. Correlating logs with other observability signals can enrich your logs data and help debug applications faster.
### Seamless transition from your existing logging pipelines
diff --git a/data/blog/elk-alternatives.mdx b/data/blog/elk-alternatives.mdx
index 7b7364fcb..b3f10d06a 100644
--- a/data/blog/elk-alternatives.mdx
+++ b/data/blog/elk-alternatives.mdx
@@ -58,7 +58,7 @@ Below are the top 14 ELK stack alternatives:
## SigNoz (Open Source)
-[SigNoz](https://signoz.io/) is a full-stack open source APM that provides log collection and analytics. SigNoz uses a columnar database ClickHouse to store logs, which is very efficient at ingesting and storing logs data. Columnar databases like ClickHouse are very effective in storing log data and making it available for analysis.
+[SigNoz](https://signoz.io/) is a full-stack [open source APM](https://signoz.io/application-performance-monitoring/) that provides log collection and analytics. SigNoz uses a columnar database ClickHouse to store logs, which is very efficient at ingesting and storing logs data. Columnar databases like ClickHouse are very effective in storing log data and making it available for analysis.
Big companies like Uber have shifted from the Elastic stack to ClickHouse for their log analytics platform. Cloudflare too was using Elasticsearch for many years but shifted to ClickHouse because of limitations in handling large log volumes with Elasticsearch.
@@ -70,7 +70,7 @@ In a [logs performance benchmark](https://signoz.io/blog/logs-performance-benchm
SigNoz uses OpenTelemetry for instrumenting applications. OpenTelemetry, backed by CNCF, is quietly becoming the world standard for instrumenting cloud-native applications.
-The logs tab in SigNoz has advanced features like a log query builder, search across multiple fields, structured table view, JSON view, etc.
+The logs tab in SigNoz has advanced features like a log [query builder](https://signoz.io/blog/query-builder-v5/), search across multiple fields, structured table view, JSON view, etc.
@@ -274,7 +274,7 @@ Any search can be saved to create a troubleshooting workflow. It also helps you
## Choosing the right log analytics tool
-One of the most challenging parts of analyzing log data is the sheer volume of data generated. An effective log analytics tool should efficiently collect and store huge volumes of data. Once the data is collected and stored, log analysis is where tools can make a difference. Enabling users to search through logs quickly and run queries and aggregates to identify the root cause of issues in their application or infrastructure are critical aspects of a good log analytics tool.
+One of the most challenging parts of analyzing log data is the sheer volume of data generated. An effective [log analytics tool](https://signoz.io/comparisons/log-analysis-tools/#signoz) should efficiently collect and store huge volumes of data. Once the data is collected and stored, log analysis is where tools can make a difference. Enabling users to search through logs quickly and run queries and aggregates to identify the root cause of issues in their application or infrastructure are critical aspects of a good log analytics tool.
While choosing a log analytics tool, a few factors should be kept in mind.
diff --git a/data/blog/enabling-a-million-spans-in-trace-details-page.mdx b/data/blog/enabling-a-million-spans-in-trace-details-page.mdx
index 4994254d6..eadfdbd96 100644
--- a/data/blog/enabling-a-million-spans-in-trace-details-page.mdx
+++ b/data/blog/enabling-a-million-spans-in-trace-details-page.mdx
@@ -212,7 +212,7 @@ Now, even if users scroll to the **490,000th span**, they **instantly see where
## Traces Without Limits
-By combining **database optimization, virtualization, pre-order traversal, and intelligent pagination**, we enabled traces with **millions of spans** to load seamlessly on **SigNoz**.
+By combining **database optimization, virtualization, pre-order traversal, and intelligent pagination**, we enabled traces with **millions of spans** to load seamlessly on **[SigNoz](https://signoz.io/docs/introduction/)**.
We are excited to see how this enables our users to debug performance issues where traces are huge. A quick recap of what we did:
diff --git a/data/blog/flamegraphs.mdx b/data/blog/flamegraphs.mdx
index da445d997..ce2ce338c 100644
--- a/data/blog/flamegraphs.mdx
+++ b/data/blog/flamegraphs.mdx
@@ -100,7 +100,7 @@ Finally, in the context of distributed systems, Flamegraphs can help trace reque
Distributed tracing is a crucial technique for monitoring and diagnosing the performance of complex, microservices-based applications.
-Flamegraphs, originally designed for profiling single applications, have been adapted to visualize distributed tracing data, offering many deep insights into how requests propagate across our multiple services and microservices.
+Flamegraphs, originally designed for profiling single applications, have been adapted to visualize [distributed tracing](https://signoz.io/distributed-tracing/) data, offering many deep insights into how requests propagate across our multiple services and microservices.
Here's a detailed explanation of how Flamegraphs are used in the context of distributed tracing:
@@ -123,7 +123,7 @@ You can use OpenTelemetry to generate traces from your application. OpenTelemetr
For distributed tracing, you can check out these [docs](https://signoz.io/docs/instrumentation/) to implement it in different programming languages.
-Once you have instrumented your application with OpenTelemetry, you can send the traces to a backend observability tool like SigNoz for visualization.
+Once you have instrumented your application with [OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/), you can send the traces to a backend observability tool like SigNoz for visualization.
### Visualizing Distributed Traces with Flamegraphs
@@ -136,7 +136,7 @@ Once you have captured trace data from your services, you can feed it into a too
## Getting started with Flamegraphs for traces
-Getting started with Flamegraphs for traces involves a series of steps to collect and visualize performance data. We'll use OpenTelemetry (OTel) and SigNoz as examples to walk you through the process.
+Getting started with Flamegraphs for traces involves a series of steps to collect and visualize performance data. We'll use OpenTelemetry ([OTel](https://signoz.io/blog/what-is-opentelemetry/)) and SigNoz as examples to walk you through the process.
### 1. Instrument Your Code with OpenTelemetry:
@@ -146,7 +146,7 @@ Here are detailed guidelines to instrument your application(s) and visualize the
### 2. Generate Flamegraphs:
-Once you've instrumented your code, you can configure your SDK or OpenTelemetry exporter to send data to SigNoz.
+Once you've instrumented your code, you can configure your SDK or [OpenTelemetry exporter](https://signoz.io/guides/opentelemetry-collector-vs-exporter/) to send data to SigNoz.
- Run your application and perform actions or generate load to capture traces.
- In SigNoz, navigate to the trace data section and select the span you want to analyze. [Spans](https://signoz.io/blog/distributed-tracing-span/) are fundamental building blocks of distributed tracing. A single trace in distributed tracing consists of a series of tagged time intervals known as spans.
@@ -169,7 +169,7 @@ The following illustration shows the Span Details page:
**Legend**:
-1. Trace ID: At the top of the page, SigNoz displays the ID of the currently selected trace.
+1. [Trace ID](https://signoz.io/comparisons/opentelemetry-trace-id-vs-span-id/): At the top of the page, SigNoz displays the ID of the currently selected trace.
2. Flame Graph: Shows the flame graph.
3. Time: Displays the start time and duration of the currently selected trace.
4. Focus: Allows you to focus on a specific span.
diff --git a/data/blog/fluentd-vs-fluentbit.mdx b/data/blog/fluentd-vs-fluentbit.mdx
index 457f257f0..7827db6c3 100644
--- a/data/blog/fluentd-vs-fluentbit.mdx
+++ b/data/blog/fluentd-vs-fluentbit.mdx
@@ -168,7 +168,7 @@ keywords: [logs,fluentd,fluentbit,logging,centralized logging,log management,log
As applications grow in complexity, the ability to gather, process, and analyze logs becomes crucial for maintaining system health and troubleshooting issues. Two popular open-source log collectors have emerged as frontrunners in this space: FluentD and FluentBit.
-But how do you choose between them? This article dives deep into the FluentD vs FluentBit debate, exploring their features, performance, and use cases to help you make an informed decision.
+But how do you choose between them? This article dives deep into the [FluentD vs FluentBit](https://signoz.io/comparisons/opentelemetry-vs-fluentbit/) debate, exploring their features, performance, and use cases to help you make an informed decision.
@@ -407,7 +407,7 @@ Both tools offer buffering mechanisms and can be configured for persistent stora
### Which tool is better suited for Kubernetes environments?
-While both can work well, FluentBit's lower resource footprint and native container support make it a popular choice for Kubernetes logging.
+While both can work well, FluentBit's lower resource footprint and native container support make it a popular choice for [Kubernetes logging](https://signoz.io/blog/kubernetes-logging/).
### Are there any licensing differences between FluentD and FluentBit?
diff --git a/data/blog/fluentd-vs-logstash.mdx b/data/blog/fluentd-vs-logstash.mdx
index 302cb9696..f5075c533 100644
--- a/data/blog/fluentd-vs-logstash.mdx
+++ b/data/blog/fluentd-vs-logstash.mdx
@@ -16,7 +16,7 @@ When we have large-scale, distributed systems, Logging becomes essential for obs
-In this scenario, Log management tools rescue the DevOps and SRE teams in order to help them monitor and improve performance, debug errors, and visualize events.
+In this scenario, [Log management tools](https://signoz.io/blog/open-source-log-management/) rescue the DevOps and SRE teams in order to help them monitor and improve performance, debug errors, and visualize events.
In layman's terms, a log analysis tool has the following major components:
@@ -25,7 +25,7 @@ In layman's terms, a log analysis tool has the following major components:
- Logs storage
- Logs visualization
-In this article, we will be discussing two very famous open-source log collectors that are Logstash and Fluentd. The hidden gems of any log analysis tool are the log collectors. They run on servers, pull server metrics, parse all the logs, and then transfer them to the systems like Elasticsearch or Postgresql. It's their routing mechanism that eventually makes log analysis possible.
+In this article, we will be discussing two very famous open-source log collectors that are Logstash and Fluentd. The hidden gems of any [log analysis tool](https://signoz.io/comparisons/log-analysis-tools/#solarwinds) are the log collectors. They run on servers, pull server metrics, parse all the logs, and then transfer them to the systems like Elasticsearch or Postgresql. It's their routing mechanism that eventually makes log analysis possible.
Both Logstash and Fluentd are open-source data collectors under the Apache 2 license. Logstash is popularly known as the ‘L’ part of the ELK stack managed by Elastic itself. Whereas Fluentd is built, and managed by Treasure Data and is a part of CNCF.
@@ -79,7 +79,7 @@ Fluentd uses a tagging approach, whereas Logstash uses if-then-else statements f
### Log Parsing
-The components for log parsing differ tool per tool. Fluentd uses standard [built-in parsers](https://docs.docker.com/config/containers/logging/fluentd/)(JSON, regex, CSV, etc.), and Logstash uses [plugins](https://www.elastic.co/guide/en/logstash/current/filter-plugins.html) for this. This makes Fluentd more favorable over Logstash as we don’t have to deal with any external plugin for this feature.
+The components for [log parsing](https://signoz.io/guides/log-parsing/) differ tool per tool. Fluentd uses standard [built-in parsers](https://docs.docker.com/config/containers/logging/fluentd/)(JSON, regex, CSV, etc.), and Logstash uses [plugins](https://www.elastic.co/guide/en/logstash/current/filter-plugins.html) for this. This makes Fluentd more favorable over Logstash as we don’t have to deal with any external plugin for this feature.
### Docker support
@@ -88,7 +88,7 @@ So if you're running your applications with Docker, FluentD is a more natural ch
## When to prefer Fluentd over Logstash or vice-versa
-For the Kubernetes environments or teams working with Docker, Fluentd is the ideal candidate for a logs collector. Fluentd has a built-in Docker logging driver and parser. You don't need an extra agent on the container to push logs to FluentD. Because of this feature, Fluentd makes the architecture less complex and less risky for logging errors. Moreover, when memory is your pain point, then go for Fluentd as it is more memory-efficient due to the lack of JVM and java runtime dependencies.
+For the Kubernetes environments or teams working with Docker, Fluentd is the ideal candidate for a logs collector. Fluentd has a built-in [Docker logging driver](https://signoz.io/blog/docker-logging/) and parser. You don't need an extra agent on the container to push logs to FluentD. Because of this feature, Fluentd makes the architecture less complex and less risky for logging errors. Moreover, when memory is your pain point, then go for Fluentd as it is more memory-efficient due to the lack of JVM and java runtime dependencies.
On the other hand, Logstash works well with Elasticsearch and Kibana. So, if you already have Elasticsearch and Kibana in your infrastructure then Logstash would be your best bet for a log collector. In general, if you are looking for a more managed and supported system, then always go for Logstash.
@@ -96,7 +96,7 @@ If you have come this far, you surely are looking to try your hands at a log man
## Log management in Signoz
-SigNoz is a full-stack open source Application Performance Monitoring tool that you can use for monitoring logs, metrics, and traces. Having all the important telemetry signals under a single dashboard leads to less operational overhead. Users can also access telemetry data with richer context by correlating these signals.
+SigNoz is a full-stack open source Application Performance Monitoring tool that you can use for [monitoring logs](https://signoz.io/blog/log-monitoring/), metrics, and traces. Having all the important telemetry signals under a single dashboard leads to less operational overhead. Users can also access telemetry data with richer context by correlating these signals.
SigNoz uses a columnar database ClickHouse to store logs, which is very efficient at ingesting and storing logs data. Columnar databases like ClickHouse are very effective in storing log data and making it available for analysis.
@@ -104,7 +104,7 @@ Big companies like Uber have OpenTelemetry for instrumenting applications. OpenTelemetry, backed by CNCF, is quickly becoming the world standard for instrumenting cloud-native applications.
-The logs tab in SigNoz has advanced features like a log query builder, search across multiple fields, structured table view, JSON view, etc.
+The logs tab in SigNoz has advanced features like a log [query builder](https://signoz.io/blog/query-builder-v5/), search across multiple fields, structured table view, JSON view, etc.
diff --git a/data/blog/gathering-data-with-opentelemetry-collector.mdx b/data/blog/gathering-data-with-opentelemetry-collector.mdx
index e1d95812a..6f146e80c 100644
--- a/data/blog/gathering-data-with-opentelemetry-collector.mdx
+++ b/data/blog/gathering-data-with-opentelemetry-collector.mdx
@@ -28,7 +28,7 @@ Below is the recording and an edited transcript of the conversation.
This is the first in a series of OpenTelemetry webinars. This series will be product-agnostic, and we will not be focusing on SigNoz specifically. We promise this will not be an extended sales pitch; instead, we will be discussing high-level concepts in OpenTelemetry engineering.
-I am joined today by Pranay, co-founder and CEO of SigNoz. We will be discussing some basic concepts of the OpenTelemetry collector. We have drawn a few questions from the CNCF Slack channel, and those specific questions have already been answered. Therefore, we will not be addressing those questions directly.
+I am joined today by Pranay, co-founder and CEO of SigNoz. We will be discussing some basic concepts of the [OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/) collector. We have drawn a few questions from the CNCF Slack channel, and those specific questions have already been answered. Therefore, we will not be addressing those questions directly.
We will also not be discussing the specific setups that people mentioned in their questions, but we will be covering similar topics that have been asked about on Reddit and in the CNCF Slack channel.
@@ -203,9 +203,9 @@ Let us assume that you are currently using Jaeger or SigNoz as your backend. If
This is one of the interesting aspects of this type of OTel collector. By the way, I have just shown this in the sidecar pattern. For example, the things you see in the dotted green light are what come with SigNoz.
-So, if you are running an instance of SigNoz itself, it comes with a central OTel collector, a storage backend (clickhouse in our case), and then the visualization and query layer. So, basically, the OTel collectors that are running as sidecars point to the SigNoz OTel collector, and we take care of the rest.
+So, if you are running an instance of [SigNoz](https://signoz.io/docs/introduction/) itself, it comes with a central OTel collector, a storage backend (clickhouse in our case), and then the visualization and query layer. So, basically, the OTel collectors that are running as sidecars point to the SigNoz OTel collector, and we take care of the rest.
-**Nica:** I believe this is one of the reasons why some vendors who have previously sold closed-source SaaS observability solutions are now nervous about the existence of the OpenTelemetry project.
+**Nica:** I believe this is one of the reasons why some vendors who have previously sold closed-source SaaS observability solutions are now nervous about the existence of the [OpenTelemetry project](https://signoz.io/blog/opentelemetry-apm/).
While there is certainly an effort to embrace these standards, there is also some concern. I believe one of the reasons for this is the simple fact that you can configure OpenTelemetry to send data to a different OpenTelemetry endpoint. Of course, different tools like Prometheus and Jaeger will have different advantages and disadvantages, and they will be used for different purposes.
@@ -227,7 +227,7 @@ Returning to the topic of sidecar patterns, one advantage is that each OTel coll
This pattern provides much greater configurability for the OTel collector for each application individually. Additionally, because all of these OTel collectors are acting independently for each application, load balancing is much easier when running the system at scale.
-If the OTel collector in the observability system is scaling, you want to ensure that all of these systems or parts in the OpenTelemetry collector which are in the application pod can scale much faster. After all, they are independently sending data to the OTel collector. And because the aggregation level happens at the application level, the traffic is smoothed out, making it much easier to handle higher workloads.
+If the OTel collector in the observability system is scaling, you want to ensure that all of these systems or parts in the [OpenTelemetry collector](https://signoz.io/blog/opentelemetry-collector-complete-guide/) which are in the application pod can scale much faster. After all, they are independently sending data to the OTel collector. And because the aggregation level happens at the application level, the traffic is smoothed out, making it much easier to handle higher workloads.
@@ -238,7 +238,7 @@ If the OTel collector in the observability system is scaling, you want to ensure
-The other only disadvantage or one of the disadvantages of this is that because you are running an application pod with each, like an OTel collector with each of the application pods, you are just running so many of them and that is higher resource requirements.
+The other only disadvantage or one of the disadvantages of this is that because you are running an application pod with each, like an [OTel](https://signoz.io/blog/what-is-opentelemetry/) collector with each of the application pods, you are just running so many of them and that is higher resource requirements.
So generally the OTel collector should run within five to ten megabytes and then if you say are running 100 pods. that sort of scales up.
@@ -279,11 +279,11 @@ The trade-off in this setting is that, because there is only one OTel collector
**Nica:** Okay
-**Pranay:** Prometheus is renowned for its utilization of a pull-based system. In essence, the Prometheus data exposure involves designating a specific endpoint. A Prometheus scraper is then employed to retrieve data from this endpoint, exemplifying the pull-based approach.
+**Pranay:** Prometheus is renowned for its utilization of a pull-based system. In essence, the [Prometheus data](https://signoz.io/guides/how-does-grafana-get-data-from-prometheus/) exposure involves designating a specific endpoint. A Prometheus scraper is then employed to retrieve data from this endpoint, exemplifying the pull-based approach.
In a contrasting manner, the post-based system involves transmitting data to the OTel (OpenTelemetry) selector. This is particularly evident in the default operational mode of OpenTelemetry SDKs. In this scenario, data is accumulated, queued, and subsequently dispatched to the collector.
-**Nica:** When considering the configuration of new pods, it is typical to specify the collective location and integrate the appropriate OpenTelemetry SDK. This practice is particularly relevant for instances like a Java pod executing a job application. Consequently, upon setting up a new pod, the anticipation is that it will automatically commence forwarding data to the collector without explicit intervention.
+**Nica:** When considering the configuration of new pods, it is typical to specify the collective location and integrate the appropriate [OpenTelemetry SDK](https://signoz.io/comparisons/opentelemetry-api-vs-sdk/). This practice is particularly relevant for instances like a Java pod executing a job application. Consequently, upon setting up a new pod, the anticipation is that it will automatically commence forwarding data to the collector without explicit intervention.
**Pranay:** Admittedly, the concept behind facilitating a push-based system for the transfer of metrics and logs from a recently established pod to a shared collector remains somewhat nebulous to me. It seems that the predominant approach adopted by OpenTelemetry is of the push variety.
@@ -310,7 +310,7 @@ But there are a few scenarios where this has been used. For instance, if someone
Yeah so the way we are thinking about this is that many of our users want to just create metrics, so say for 80% of the users, we have provided a query-builder which is like you can use UI to create metrics, you can filter based on different things like you can filter based on group by query. -So for the 80% of the users, I think query builder will suffice, which they can use to write metrics, etc, and then we support PromQL and ClickHouse native queries. +So for the 80% of the users, I think [query builder](https://signoz.io/blog/query-builder-v5/) will suffice, which they can use to write metrics, etc, and then we support PromQL and ClickHouse native queries. So PromQL will be there and it's for people who are more comfortable with that but we are focusing more on making the users write native ClickHouse queries much easier. @@ -439,7 +439,7 @@ Yeah, same. Cortex does the same type of thing because it also uses S3. Cool, so I wanted to ask a little bit about the project itself and I'm going to just put the road map up on the chat so that people know kind of what's going on with the project and then they also have a link to the GitHub but I did want to ask about how people can get involved, how they can contribute to it as well. So maybe you could share a little bit about that? ***Pranay:***
-Yeah sure so I think we have got lots of contributions, from contributors in SigNoz already but I think a couple of key areas where we are actively looking for contribution, is testing SigNoz in different languages and frameworks and reporting that and like maybe sharing documentation on what that is because as you know like the surface area of the product is very big, like OpenTelemetry itself supports so many languages and then even in those languages, there are so many frameworks and by adding another small team. +Yeah sure so I think we have got lots of contributions, from contributors in [SigNoz](https://signoz.io/docs/introduction/) already but I think a couple of key areas where we are actively looking for contribution, is testing SigNoz in different languages and frameworks and reporting that and like maybe sharing documentation on what that is because as you know like the surface area of the product is very big, like OpenTelemetry itself supports so many languages and then even in those languages, there are so many frameworks and by adding another small team. We can't create blocks for everything, so if people are trying different languages and frameworks or if people can create talks or try for that language with which they're comfortable, and then share docs with us, that would be very helpful. @@ -481,9 +481,9 @@ So your goal is all OpenTelemetry in terms of getting data into the platform not We have to support fluency and fluent bid and we give a customer a huge list of things they can use to send us data which is nice but also the customers say which one should I use and we have to say, use what you know. ***Pranay:***
-Yes, we are taking the route of default OpenTelemetry support, and we are seeing that's like serving like 80 percent of the use cases or customers and that's fine for us as of now because being a small team we don't want to integrate different libraries and builds exporters for all of those. +Yes, we are taking the route of default [OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/) support, and we are seeing that's like serving like 80 percent of the use cases or customers and that's fine for us as of now because being a small team we don't want to integrate different libraries and builds exporters for all of those. -So as of now, we are supporting OpenTelemetry and I think even OpenTelemetry allows you to send through Fluentbit, the OTel collector allows you to send through Fluentbit. +So as of now, we are supporting OpenTelemetry and I think even OpenTelemetry allows you to send through [Fluentbit](https://signoz.io/docs/userguide/fluentbit_to_signoz/), the [OTel collector](https://signoz.io/blog/opentelemetry-collector-complete-guide/) allows you to send through Fluentbit. So, of course, there may be many protocols that we don't support but we'll take an 80-20 approach. @@ -534,7 +534,7 @@ If I'm going to collect all of this data that shows something is okay and fine, Yeah, it makes a lot of sense, we have not thought about that. We are primarily focused on application metrics but now that you are telling me, I see… ***Jonah:***
-But as you go and I know some of your examples like monitoring Redis or monitoring MongoDB or ClickHouse, for example, now you're moving more into infrastructure where you know some of those logs may not be useful. +But as you go and I know some of your examples like monitoring Redis or [monitoring MongoDB](https://signoz.io/blog/mongodb-monitoring-tools/) or ClickHouse, for example, now you're moving more into infrastructure where you know some of those logs may not be useful. I mean Redis generates huge volumes of access log type data but you want some of it, you want metrics from it but you don't need all of the 200, 500 millisecond response time. That's fine I don't need that you know so yeah definitely. diff --git a/data/blog/getting-started-with-opentelemetry.mdx b/data/blog/getting-started-with-opentelemetry.mdx index b2ad80d63..3af7e61e5 100644 --- a/data/blog/getting-started-with-opentelemetry.mdx +++ b/data/blog/getting-started-with-opentelemetry.mdx @@ -31,7 +31,7 @@ Below is the recording and an edited transcript of the conversation. If you are already considering dashboards and how you store your data, this may not be the information you need. However, I am joined today by Pranay, co-founder of SigNoz. Pranay, what do you hope people will take away from this starter guide? -**Pranay:** We decided to create this guide because we saw that many people in the SigNoz community already understand what OpenTelemetry is and have been using it. We also run an OpenTelemetry end-user group for the APAC region, and we see that many people have initial questions like, "How do I get started with OpenTelemetry? Is the log stable? How do I start sending my application tracing data?" +**Pranay:** We decided to create this guide because we saw that many people in the SigNoz community already understand what OpenTelemetry is and have been using it. We also run an OpenTelemetry end-user group for the APAC region, and we see that many people have initial questions like, "How do I get started with OpenTelemetry? Is the log stable? How do I start sending my [application tracing](https://signoz.io/distributed-tracing/) data?" These are the basic questions that any team needs to answer before investing in OpenTelemetry. So, we thought we would create a guide that covers some of the more basic topics so that people who are just starting out with OpenTelemetry can get an overview and a sense of where the project is headed. We will then go back to more technical questions in the future. @@ -40,7 +40,7 @@ We plan to alternate between more technical questions and more beginner-friendly **Nica:** It has been interesting for me to learn about the availability of beginner and advanced information for OpenTelemetry. OpenTelemetry is not intended as a beginner's tool, but rather as a tool for those who need to do distributed tracing through complex architectures. Since its inception, much of the material has started by diving deep into the topic. -Speaking of more advanced topics, I wanted to answer a question that was asked in chat: "Hey, we talked about Kafka with OTel in the later webinar, when's that going to happen?" The webinar will be held next month because we are going away for our whole staff meeting. I will announce the date and time in the topic and message you directly when we are ready. We wanted to do it this week, but it turned out to require a little more research. +Speaking of more advanced topics, I wanted to answer a question that was asked in chat: "Hey, we talked about Kafka with [OTel](https://signoz.io/blog/what-is-opentelemetry/) in the later webinar, when's that going to happen?" The webinar will be held next month because we are going away for our whole staff meeting. I will announce the date and time in the topic and message you directly when we are ready. We wanted to do it this week, but it turned out to require a little more research. I think I now know most of how to do it. I may or may not go and do all the work to set up a local Kafka queue to test it out, but that is a more advanced topic. I would love to talk about it, especially as it relates to sending OpenTelemetry data into a queue within your network. Nishant has just mentioned that the live webinar hours are not great for us, and we will be shifting those around a bit. @@ -57,7 +57,7 @@ So, a pretty common question that we see, especially people who are dipping into > “***A common question, especially among new DevOps engineers or SREs who want to add some observability: “What’s the first thing I should instrument with OpenTelemetry***” -**Pranay:** Indeed, it depends on who is asking the question. For an application developer, the most interesting thing might be APM, or application performance monitoring. If you are writing code and want to understand whether your code is performing well or has high latency, you might start with APM or distributed tracing to see the latency of your APIs. Are your database calls or external calls taking longer than usual? +**Pranay:** Indeed, it depends on who is asking the question. For an application developer, the most interesting thing might be APM, or application performance monitoring. If you are writing code and want to understand whether your code is performing well or has high latency, you might start with APM or [distributed tracing](https://signoz.io/blog/distributed-tracing/) to see the latency of your APIs. Are your database calls or external calls taking longer than usual? However, if you are part of the platform team or DevOps team, the first thing you might want to look at is infrastructure metrics. These are the most important metrics to track, as they can tell you whether your machines are running smoothly and whether your CPU, memory, and other resources are being used efficiently. @@ -83,7 +83,7 @@ I think I'm going to briefly step through this just because it's kind of a basic I recommend starting with infrastructure metrics if you want to understand the OpenTelemetry project. Do not start with Kubernetes by trying to spin up five namespaces that talk to each other through a synchronous data store. Instead, start with something that is easy to debug, easy to look at, and where data collection will work right off the bat. -The OpenTelemetry collector is a good choice for this because it is well packaged and easy to run anywhere. It is also easy for the collector to gather basic host metrics, and the OpenTelemetry operator can grab a bunch of info metrics off of your cluster easily. +The OpenTelemetry collector is a good choice for this because it is well packaged and easy to run anywhere. It is also easy for the collector to gather basic host metrics, and the [OpenTelemetry operator](https://signoz.io/blog/opentelemetry-operator-complete-guide/) can grab a bunch of info metrics off of your cluster easily. In short, start with something simple and easy to manage, and then work your way up to more complex systems. I also appreciate these metrics because the purpose of these metrics is obvious when thinking about them. This may seem like a basic concept, but I believe it is worth discussing that, when considering something like a CPU, all of the OpenTelemetry processor steps are easy to understand. @@ -190,7 +190,7 @@ My understanding is that you can't move your distributed trace into AWS X-Ray, f Some of the time I see people getting confused, "Hey if I use OpenTelemetry, do I also share dashboards?" So that's not really in the scope of the project. -**Nica:** And so, we don't cover very much in this talk, but, while it's very straightforward to use a tool SigNoz or Prometheus or Grafana, to do a basic dashboard and say, "Hey, I'm going to track the CPU metrics," it's a good place to start. +**Nica:** And so, we don't cover very much in this talk, but, while it's very straightforward to use a tool [SigNoz](https://signoz.io/docs/introduction/) or Prometheus or Grafana, to do a basic dashboard and say, "Hey, I'm going to track the CPU metrics," it's a good place to start. I think we can all understand that then you get to more advanced cases, and you're gonna want to evaluate a tool or two, right? To look at, does it give me the data that I need? What are we using from our observability tools now, and where do we want that to go? @@ -204,7 +204,7 @@ I think we can all understand that then you get to more advanced cases, and you' > Once you're collecting these hosted infrastructure metrics, a good second step is thinking about logging. -And again you can have your path through here, but just it's worth considering, thinking about how we're handling logging. It should be pretty doable as a project, and you can also use some of that collector power to do some of your log parsing which might improve your experience a little bit. +And again you can have your path through here, but just it's worth considering, thinking about how we're handling logging. It should be pretty doable as a project, and you can also use some of that collector power to do some of your [log parsing](https://signoz.io/guides/log-parsing/) which might improve your experience a little bit.
@@ -216,7 +216,7 @@ Now I want to make one note here. This is my first big mistake when I started wr
The metric situation is a little complicated on Ruby, and I'm not good to speak to that, but the logs are what we're talking about here because this sort of makes it look as if you have Ruby or you're on Rust or what have you, that you have no support for sending in your logs to this OpenTelemetry endpoint.
-But that's probably not the case, right? So, the issue here is we’d like to have full SDK support within each of these frameworks, to be able to say, "Okay, from the start, I'm going to do OpenTelemetry logging, so I'm going to install the Ruby OpenTelemetry SDK and make a call to that SDK every time I want a log", which would be rad, and I agree, we'd to see that implemented.
+But that's probably not the case, right? So, the issue here is we’d like to have full SDK support within each of these frameworks, to be able to say, "Okay, from the start, I'm going to do [OpenTelemetry logging](https://signoz.io/blog/opentelemetry-logs/), so I'm going to install the Ruby [OpenTelemetry SDK](https://signoz.io/comparisons/opentelemetry-api-vs-sdk/) and make a call to that SDK every time I want a log", which would be rad, and I agree, we'd to see that implemented.
But you are already sending your logs somewhere. I hope your logs are not just getting dumped into the console and killing your instance. So, given that you've already done that work, again, there's that thing with the collector, right? That it has its ways to import data. It has multiple projects to import data. If you look at the contrib repo for the OpenTelemetry collector, you can look at these receivers.
@@ -230,7 +230,7 @@ They're, "Hey, you can send these logs anywhere”. Of course, you can send them
OpenTelemetry also supports these log collectors, for example, I think they support FluentD, Fluent Bit, and Logstash. So, if you already have a pipeline set up with any of these three log collectors, you can configure the OpenTelemetry collector to get logs from there.
-You don't have to do any work, you just can start configuring whatever is configured in your log collector, so you can just start sending that data to the OpenTelemetry collector.
+You don't have to do any work, you just can start configuring whatever is configured in your log collector, so you can just start sending that data to the [OpenTelemetry collector](https://signoz.io/blog/opentelemetry-collector-complete-guide/).
So, Nica was pointing out that OpenTelemetry official site lists as logs are not implemented, saying “Is there a Ruby SDK to send logs directly?” But as you know, there are other ways to send logs.
@@ -258,7 +258,7 @@ The data that OpenTelemetry SDKs send, such as tracing data, can be used for mor
The data is there, but the project is not currently focused on security use cases. The vendors are also more focused on observability. Therefore, OpenTelemetry is not currently suitable for security use cases.
-**Nica:** Yeah, I would say, in terms of just using the OpenTelemetry project to do a ton of security, you're not gonna have some of the things you would expect as you have in a basic security tool.
+**Nica:** Yeah, I would say, in terms of just using the [OpenTelemetry project](https://signoz.io/blog/opentelemetry-apm/) to do a ton of security, you're not gonna have some of the things you would expect as you have in a basic security tool.
I just wanted to point out this talk from Ron Vider at Oxeye, who is using OpenTelemetry to do security monitoring, and there are some other examples out there.
@@ -289,7 +289,7 @@ And so, this is a little bit of vision for the future and also why it may make s
This is possible because if you pass the context of the log to the trace, you can determine which logs were emitted during the request propagation of the trace. This information can be viewed by simply clicking a link.
-I encourage you to check out this feature in SigNoz. I believe that the project is headed in a positive direction because it has defined a uniform resource layer and a concept of baggage, which allows for context propagation across signals, metrics, traces, and logs.
+I encourage you to check out this feature in SigNoz. I believe that the project is headed in a positive direction because it has defined a uniform resource layer and a concept of baggage, which allows for [context propagation](https://signoz.io/blog/opentelemetry-context-propagation/) across signals, metrics, traces, and logs.
I believe that the project is headed in a direction where it will be able to correlate metrics, traces, and logs much more deeply. One way that this can be achieved is through the use of resources.
diff --git a/data/blog/grafana-alternatives.mdx b/data/blog/grafana-alternatives.mdx
index 988eefb51..05bc3260c 100644
--- a/data/blog/grafana-alternatives.mdx
+++ b/data/blog/grafana-alternatives.mdx
@@ -41,7 +41,7 @@ If these challenges sound familiar, you’re not alone. In this article, we expl
Under the hood, Grafana is powered by multiple tools like Loki, Tempo, Mimir & Prometheus. In contrast, SigNoz is built as a unified tool serving logs, metrics, and traces in a single pane of glass.
-SigNoz uses a single datastore - ClickHouse to power its observability stack. This makes SigNoz much better in correlating signals and driving better insights.
+SigNoz uses a single datastore - ClickHouse to power its [observability stack](https://signoz.io/guides/observability-stack/). This makes SigNoz much better in correlating signals and driving better insights.
### OpenTelemetry Support
@@ -49,7 +49,7 @@ SigNoz is built to support OpenTelemetry.
diff --git a/data/blog/grafana-vs-splunk.mdx b/data/blog/grafana-vs-splunk.mdx
index c9adb10cd..419ed7680 100644
--- a/data/blog/grafana-vs-splunk.mdx
+++ b/data/blog/grafana-vs-splunk.mdx
@@ -58,7 +58,7 @@ With Splunk, you can search and analyze large amounts of data in real-time, and
While Splunk and Grafana are both data collection and analysis tools, they have different features and approaches in regard to data collection & ingestion.
-**Splunk is a centralized log management tool** that can collect and store large amounts of data from various sources. This data is stored in an index, where it can be analyzed using Splunk's powerful search language.
+**Splunk is a [centralized log management](https://signoz.io/blog/centralized-logging/) tool** that can collect and store large amounts of data from various sources. This data is stored in an index, where it can be analyzed using Splunk's powerful search language.
As per the official documents of Splunk, data collection depends on what type of data source a client is using. These are the methods that Splunk uses for data collection.
@@ -240,7 +240,7 @@ In general, Splunk is comparatively more scalable than Grafana especially when i
## Choosing between Grafana and Splunk
-If you are looking for a comprehensive platform that can help you ingest, analyze, and visualize diverse types of data and logs, then Splunk would be a great choice. Splunk is a top-notch log aggregator that can collect and index data from various sources. It offers advanced search and filter capabilities, making it easy to search and analyze data of any format or source. Its powerful search engine enables advanced data processing and analytics while providing robust security and alert management features.
+If you are looking for a comprehensive platform that can help you ingest, analyze, and visualize diverse types of data and logs, then Splunk would be a great choice. Splunk is a top-notch [log aggregator](https://signoz.io/comparisons/log-aggregation-tools/) that can collect and index data from various sources. It offers advanced search and filter capabilities, making it easy to search and analyze data of any format or source. Its powerful search engine enables advanced data processing and analytics while providing robust security and alert management features.
Splunk is suitable for businesses facing complex data analysis needs, businesses that require complex data analysis, especially large enterprises that deal with extensive log volumes and require robust security and alert management features.
@@ -257,7 +257,7 @@ In summary, choose Splunk if you need a versatile platform for comprehensive dat
## SigNoz - an alternative to Grafana and Splunk
-SigNoz is an open source APM that provides metrics, logs, and traces under a [single pane of glass](https://signoz.io/blog/single-pane-of-glass-monitoring/). It uses OpenTelemetry for application instrumentation. OpenTelemetry is quietly becoming the world standard for instrumenting cloud-native applications. SigNoz can be a great alternative to Grafana and Splunk.
+[SigNoz](https://signoz.io/docs/introduction/) is an [open source APM](https://signoz.io/application-performance-monitoring/) that provides metrics, logs, and traces under a [single pane of glass](https://signoz.io/blog/single-pane-of-glass-monitoring/). It uses [OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/) for [application instrumentation](https://signoz.io/docs/instrumentation/). OpenTelemetry is quietly becoming the world standard for instrumenting cloud-native applications. SigNoz can be a great alternative to Grafana and Splunk.
It is available both as an [open-source software](https://github.com/SigNoz/signoz) and a [cloud offering](https://signoz.io/teams/).
diff --git a/data/blog/ha-prometheus-cortex-cassandra.mdx b/data/blog/ha-prometheus-cortex-cassandra.mdx
index 194dea316..1dd3a8f76 100644
--- a/data/blog/ha-prometheus-cortex-cassandra.mdx
+++ b/data/blog/ha-prometheus-cortex-cassandra.mdx
@@ -18,7 +18,7 @@ In this blog, we explain how we enable high availability Prometheus using Cortex
## Why need Cortex?
- Long term storage backend for Prometheus - by default Prometheus saves data to local disk and retains for 15 days. Cortex connects to DBs to store data for longer time range. DBs that can be easily integrated are Cassandra, BigTable and DynamoDB
-- Enabling HA Prometheus - Usually folks run a singe Prometheus per cluster. If that node is down or Prometheus gets killed, you will find gaps in your graph till the time k8s recreates Prometheus pod. With Cortex, you can run multiple instances of Prometheus in your cluster and Cortex will de-duplicate metrics for you.
+- Enabling HA Prometheus - Usually folks run a singe Prometheus per cluster. If that node is down or Prometheus gets killed, you will find gaps in your graph till the time k8s recreates [Prometheus pod](https://signoz.io/guides/prometheus-queries-to-get-cpu-and-memory-usage-in-kubernetes-pods/). With Cortex, you can run multiple instances of Prometheus in your cluster and Cortex will de-duplicate metrics for you.
- Single pane of view for multi-cluster Prometheus - When you have multiple Prometheuses across multiple clusters, provisioning 1 Grafana dashboard for each cluster will quickly become a pain. Also, aggregating metrics over multiple clusters won't be possible. Cortex enables this by letting Prometheuses in each cluster write their metrics to single DB and provide a label for your cluster. A Grafana dashboard built on top of the shared DB will enable queries to any of the clusters.
[](https://github.com/SigNoz/signoz)
@@ -269,7 +269,7 @@ We can set validation limits in the distributor to check:
**Further Reading**
-Before you make Cortex production-ready, you should go through the below docs to understand the functionality better.
+Before you make Cortex [production-ready](https://signoz.io/guides/production-readiness-checklist/), you should go through the below docs to understand the functionality better.
- [Cortex Arguments Explained](https://github.com/cortexproject/cortex/blob/874d48958ce436b3c71c37b01c0269aa41552d83/docs/configuration/arguments.md)
- [Running Cortex in Production](https://cortexmetrics.io/docs/blocks-storage/production-tips//)
diff --git a/data/blog/hacktoberfest.mdx b/data/blog/hacktoberfest.mdx
index 7c1a17eb7..cd522d590 100644
--- a/data/blog/hacktoberfest.mdx
+++ b/data/blog/hacktoberfest.mdx
@@ -57,7 +57,7 @@ Here are a few benefits of contributing to open-source:
- Contributions to open-source is a strong proof of someone's technical acumen. It's better to have contributions on your preferred tech stack rather than just mentioning about it on your CV
- Contributing to open-source is fun! You get to meet new people while accumulating new skills along the way
-At SigNoz, we believe that the future of software is open-source. SigNoz is a full-stack **application performance monitoring tool** with which we hope to empower developers to solve issues in production quickly. We believe a **developer-first** and **community-driven approach** would be best suited for a product that is used by developers day in and day out.
+At [SigNoz](https://signoz.io/docs/introduction/), we believe that the future of software is open-source. SigNoz is a full-stack **application performance monitoring tool** with which we hope to empower developers to solve issues in production quickly. We believe a **developer-first** and **community-driven approach** would be best suited for a product that is used by developers day in and day out.
We have a vibrant community of **more than 1400 developers** collaborating together to build the next-gen open-source monitoring solution to keep your systems in fine health. The best thing about open-source is its community where you get to meet a diverse set of people coming together to solve some challenging problems.
diff --git a/data/blog/health-check-monitoring-with-opentelemetry.mdx b/data/blog/health-check-monitoring-with-opentelemetry.mdx
index c83e93910..ffcbc4dd8 100644
--- a/data/blog/health-check-monitoring-with-opentelemetry.mdx
+++ b/data/blog/health-check-monitoring-with-opentelemetry.mdx
@@ -48,7 +48,7 @@ Monitoring HTTP endpoints is crucial for ensuring the continuous availability, o
In today's fast-paced digital landscape, system reliability is paramount. Health check monitoring plays a crucial role in maintaining this reliability by:
-1. **Ensuring high availability**: Continuous monitoring helps minimize downtime by quickly identifying and addressing issues.
+1. **Ensuring high availability**: [Continuous monitoring](https://signoz.io/comparisons/continuous-monitoring-tools/) helps minimize downtime by quickly identifying and addressing issues.
2. **Enabling early detection**: Problems are often caught before they escalate and impact end-users.
3. **Facilitating rapid response**: Automated alerts allow teams to react swiftly to anomalies.
4. **Supporting DevOps practices**: Regular health checks align with continuous delivery and integration principles.
@@ -58,7 +58,7 @@ In today's fast-paced digital landscape, system reliability is paramount. Health
Effective health check monitoring offers numerous advantages:
- **Improved system reliability**: Consistent monitoring leads to more stable systems and higher user satisfaction.
-- **Reduced MTTD and MTTR**: Mean Time to Detect (MTTD) and Mean Time to Resolve (MTTR) decrease with proactive monitoring.
+- **Reduced MTTD and MTTR**: Mean Time to Detect (MTTD) and Mean Time to Resolve (MTTR) decrease with [proactive monitoring](https://signoz.io/guides/proactive-monitoring/).
- **Enhanced capacity planning**: Monitoring data informs decisions about resource allocation and scaling.
- **Better SLA compliance**: Regular checks help ensure adherence to Service Level Agreements.
@@ -323,7 +323,7 @@ For HTTP endpoint monitoring, you can use the time-series chart.
Storing high-cardinality data may require additional memory and storage resources compared to low-cardinality data. The increased number of unique values can contribute to larger index sizes, more memory consumption, and potentially increased storage requirements. - **Lack of high-level metrics:**
-This one is counter-intuitive; if you’re storing SKU’s of course there’s not an ‘average’ SKU, but when you’re able to present high-level metrics like average request time, most commonly used geo area, etc, it can stand out that there’s no way to present an average or even most-frequent value meaningfully. In my experience working with APM tools this came up! high-level dashboards would display ‘most frequent’ values for metrics, but on closer inspection the value had occurred three times over 2 million rows. This meant things like the ‘Number 1 userID’ on all transactions represented 0.000001% of all transactions. +This one is counter-intuitive; if you’re storing SKU’s of course there’s not an ‘average’ SKU, but when you’re able to present high-level metrics like average request time, most commonly used geo area, etc, it can stand out that there’s no way to present an average or even most-frequent value meaningfully. In my experience working with [APM tools](https://signoz.io/blog/open-source-apm-tools/) this came up! high-level dashboards would display ‘most frequent’ values for metrics, but on closer inspection the value had occurred three times over 2 million rows. This meant things like the ‘Number 1 userID’ on all transactions represented 0.000001% of all transactions. ## Why High Cardinality Data Matters in Modern Applications @@ -173,7 +173,7 @@ To effectively manage high cardinality data, consider these approaches: ### Observability Tools for High Cardinality Data -Observability is crucial for understanding system behavior in distributed systems with high cardinality data. SigNoz, an open-source observability platform, offers powerful capabilities for handling high cardinality data: +Observability is crucial for understanding system behavior in distributed systems with high cardinality data. [SigNoz](https://signoz.io/docs/introduction/), an open-source observability platform, offers powerful capabilities for handling high cardinality data: - Efficient data ingestion and storage optimized for high cardinality fields. - Advanced querying and visualization tools for exploring high-dimensional data. diff --git a/data/blog/how-our-engineers-use-ai.mdx b/data/blog/how-our-engineers-use-ai.mdx index 9dc1397ff..5f3c71aef 100644 --- a/data/blog/how-our-engineers-use-ai.mdx +++ b/data/blog/how-our-engineers-use-ai.mdx @@ -144,7 +144,7 @@ PRDs require you to think through, be innovative, align with feature goals and s ## #10 AI to help write Docs? Pass. -Documentation, especially user-facing docs or developer guides, is another area where our team has pulled back on using AI. At SigNoz, **we treat documents also like products**, and a lot of attention is given to ensure they’re insanely user-friendly. However, AI helps a lot with reviews, grammar checks, structure, outline, etc. The thought and idea behind a doc is always human. +Documentation, especially user-facing docs or developer guides, is another area where our team has pulled back on using AI. At [SigNoz](https://signoz.io/docs/introduction/), **we treat documents also like products**, and a lot of attention is given to ensure they’re insanely user-friendly. However, AI helps a lot with reviews, grammar checks, structure, outline, etc. The thought and idea behind a doc is always human. We are also [actively looking for a human to join us](https://jobs.ashbyhq.com/SigNoz/c852f108-4677-4dba-b05d-c9cd4f31e872), who can create excellent docs! diff --git a/data/blog/improvements-to-logs-search-and-filter.mdx b/data/blog/improvements-to-logs-search-and-filter.mdx index 45849470c..d5c44844e 100644 --- a/data/blog/improvements-to-logs-search-and-filter.mdx +++ b/data/blog/improvements-to-logs-search-and-filter.mdx @@ -46,7 +46,7 @@ Users can now utilize quick filters to drill down into logs more efficiently. Fo ### Sync with Query Builder -The filters sync with the query builder including multiple queries to ensure that changes are applied to the relevant queries. For example, in the below product screenshot the user is editing Query B and the filter panel reflects filters for Query B. +The filters sync with the [query builder](https://signoz.io/blog/query-builder-v5/) including multiple queries to ensure that changes are applied to the relevant queries. For example, in the below product screenshot the user is editing Query B and the filter panel reflects filters for Query B.
diff --git a/data/blog/is-opentelemetry-a-first-class-citizen-in-your-dashboard-a-datadog-and-newrelic-comparison.mdx b/data/blog/is-opentelemetry-a-first-class-citizen-in-your-dashboard-a-datadog-and-newrelic-comparison.mdx
index 984a879cd..8c052c411 100644
--- a/data/blog/is-opentelemetry-a-first-class-citizen-in-your-dashboard-a-datadog-and-newrelic-comparison.mdx
+++ b/data/blog/is-opentelemetry-a-first-class-citizen-in-your-dashboard-a-datadog-and-newrelic-comparison.mdx
@@ -12,7 +12,7 @@ keywords: [opentelemetry,signoz,observability]
> "Trade isn't about goods. Trade is about information. Goods sit in the warehouse until information moves them.” > C. J. Cherryh -OpenTelemetry is the future of Observability, APM, Monitoring, whatever you want to call ‘the process of knowing what our software is doing.’ It’s becoming common knowledge that your time is better spent gaining experience with an open, standardized system for telemetry than closed-source or otherwise proprietary standard. This truth is so universally acknowledged that all the big players in the market have made announcements of how they’re embracing OpenTelemetry. Often these statements mention how ‘open is the future’ et cetera. But how committed are these teams to OpenTelemetry? In this series, we’ll talk about how native OpenTelemetry tools compare to APM products that have adopted OpenTelemetry only partially. In this article, we will explore how, in both New Relic and Datadog, OpenTelemetry data is a ‘second class citizen.’ +OpenTelemetry is the future of Observability, APM, Monitoring, whatever you want to call ‘the process of knowing what our software is doing.’ It’s becoming common knowledge that your time is better spent gaining experience with an open, standardized system for telemetry than closed-source or otherwise proprietary standard. This truth is so universally acknowledged that all the big players in the market have made announcements of how they’re embracing OpenTelemetry. Often these statements mention how ‘open is the future’ et cetera. But how committed are these teams to OpenTelemetry? In this series, we’ll talk about how native [OpenTelemetry tools](https://signoz.io/blog/opentelemetry-visualization/) compare to APM products that have adopted OpenTelemetry only partially. In this article, we will explore how, in both New Relic and Datadog, OpenTelemetry data is a ‘second class citizen.’ @@ -30,7 +30,7 @@ The result is a system that is gently sloped. It guides the user, without them e ## The Big Gap Between Datadog’s Marketing and their Tools -Right from the installation stage… something feels amiss when trying to use OpenTelemetry with Datadog. There seem to be no actual use cases listed for OpenTelemetry. The guide on their documentation for trying OpenTelemetry reporting with a simple Python app is out of date, and there’s something kind of odd about the linked of articles from their OpenTelemetry overview: +Right from the installation stage… something feels amiss when trying to use [OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/) with Datadog. There seem to be no actual use cases listed for OpenTelemetry. The guide on their documentation for trying OpenTelemetry reporting with a simple Python app is out of date, and there’s something kind of odd about the linked of articles from their OpenTelemetry overview:
@@ -66,7 +66,7 @@ You cannot link traces and logs automatically with the [DataDog OpenTelemetry](h
@@ -104,14 +104,14 @@ This gap exemplifies the drawbacks of Datadog’s attempt to fully integrate Ope
### Limitations: a separate path for metrics
-One of the central tenets of OpenTelemetry is that, at some point in the near future, the project will achieve a consistent standard for measuring all three observability signals _and correlating them_ with a single point of collection such that even metrics can be implicitly tied to particular traces and logs. This vision isn’t perfectly achieved yet, but it is surprisingly easy to report logs, traces, and metrics with consistent tagging to a native OpenTelemetry backend.
+One of the central tenets of OpenTelemetry is that, at some point in the near future, the project will achieve a consistent standard for measuring all three observability signals _and correlating them_ with a single point of collection such that even metrics can be implicitly tied to particular traces and logs. This vision isn’t perfectly achieved yet, but it is surprisingly easy to report logs, traces, and metrics with consistent tagging to a native [OpenTelemetry backend](https://signoz.io/blog/opentelemetry-backend/).
In datadog, however, metrics and logging are gathered in a way quite separate from traces.
- Logs are gathered by tailing a target file
-- Metrics require you to either connect an OpenTelemetry collector to datadog or use `DogStatsD` . The `StatsD` route appears to be unsupported by any OpenTelemetry SDK
+- Metrics require you to either connect an [OpenTelemetry collector](https://signoz.io/blog/opentelemetry-collector-complete-guide/) to datadog or use `DogStatsD` . The `StatsD` route appears to be unsupported by any OpenTelemetry SDK
-Adding calls to send metrics with the OpenTelemetry SDK on an application reporting traces to Datadog, much like the trace span events mentioned above, appears to be a noop. The agent and Datadog tracing neither logs an error nor reports any data.
+Adding calls to send metrics with the [OpenTelemetry SDK](https://signoz.io/comparisons/opentelemetry-api-vs-sdk/) on an application reporting traces to Datadog, much like the trace span events mentioned above, appears to be a noop. The agent and Datadog tracing neither logs an error nor reports any data.
One limitation did surprise me: it doesn’t appear that span data is available as a ‘metric’ to be queried in Datadog.
diff --git a/data/blog/jaeger-microservices.mdx b/data/blog/jaeger-microservices.mdx
index 063439b2c..67bb68f1a 100644
--- a/data/blog/jaeger-microservices.mdx
+++ b/data/blog/jaeger-microservices.mdx
@@ -88,7 +88,7 @@ Let us see in detail what these components are and how these components come tog
Instrumentation is the process of generating telemetry data(logs, metrics, and traces) from your application code. It is essentially writing code that enables your application code to emit telemetry data, which can be used later to investigate issues.
-Most distributed tracing tools offer clients libraries, agents, and SDKs to [instrument application](https://signoz.io/docs/instrumentation/) code. Jaeger's client libraries for instrumentation are based on OpenTracing APIs.
+Most distributed [tracing tools](https://signoz.io/blog/distributed-tracing-tools/) offer clients libraries, agents, and SDKs to [instrument application](https://signoz.io/docs/instrumentation/) code. Jaeger's client libraries for instrumentation are based on OpenTracing APIs.
OpenTracing was an open-source project aimed at providing vendor-neutral APIs and instrumentation for distributed tracing. It later got merged into OpenTelemetry. Jaeger has official client libraries in the following languages:
@@ -140,7 +140,7 @@ Jaeger's UI is basic but comprehensive when it comes to distributed tracing.
## Challenges of using Jaeger
-Jaeger is a preferred choice when it comes to distributed tracing. But engineering teams need more than traces to resolve issues quickly. They need access to both metrics and traces. Metrics such as response times, error rates, request rates, and CPU usage are equally important to understand application performance.
+Jaeger is a preferred choice when it comes to [distributed tracing](https://signoz.io/distributed-tracing/). But engineering teams need more than traces to resolve issues quickly. They need access to both metrics and traces. Metrics such as response times, error rates, request rates, and CPU usage are equally important to understand application performance.
A few key challenges of using Jaeger as a distributed tracing tool are as follows:
@@ -148,7 +148,7 @@ A few key challenges of using Jaeger as a distributed tracing tool are as follow
- Databases supported by Jaeger need active maintenance.
- Jaeger's web UI is limited with basic visualizations.
-For a fast-moving engineering team, you need dashboards that can drive quick insights and resolution. And that's where [SigNoz](https://signoz.io/) comes into the picture. It is a great alternative to Jaeger for distributed tracing in microservices.
+For a fast-moving engineering team, you need dashboards that can drive quick insights and resolution. And that's where [SigNoz](https://signoz.io/) comes into the picture. It is a great alternative to Jaeger for [distributed tracing in microservices](https://signoz.io/blog/distributed-tracing-in-microservices/).
## SigNoz - a Jaeger alternative for microservices
SigNoz is a full-stack open-source application performance monitoring and observability tool which can be used in place of Jaeger. SigNoz is built to support OpenTelemetry natively. OpenTelemetry is becoming the world standard to generate and maintain telemetry data(Logs, metrics, and traces).
diff --git a/data/blog/jaeger-vs-elastic-apm.mdx b/data/blog/jaeger-vs-elastic-apm.mdx
index 74452efd6..580725680 100644
--- a/data/blog/jaeger-vs-elastic-apm.mdx
+++ b/data/blog/jaeger-vs-elastic-apm.mdx
@@ -9,21 +9,21 @@ image: /img/blog/2021/09/jaeger_vs_elastic_apm_cover-min.webp
keywords: [jaeger,elastic apm,distributed tracing,apm tools,application performance monitoring]
---
-Jaeger is an open-source end-to-end distributed tracing tool for microservices architecture. On the other hand, Elastic APM is an application performance monitoring system that is built on top of the ELK Stack (Elasticsearch, Logstash, Kibana, Beats). In this article, let's explore their key features, differences, and alternatives.
+Jaeger is an open-source end-to-end distributed [tracing tool](https://signoz.io/blog/distributed-tracing-tools/) for microservices architecture. On the other hand, Elastic APM is an application performance monitoring system that is built on top of the ELK Stack (Elasticsearch, Logstash, Kibana, Beats). In this article, let's explore their key features, differences, and alternatives.
-Application performance monitoring is the process of keeping your app's health in check. APM tools enable you to be proactive about meeting the demands of your customers. There are many components to a good APM tool like metrics monitoring, distributed tracing, log management, alert systems, etc.
+Application performance monitoring is the process of keeping your app's health in check. [APM tools](https://signoz.io/blog/open-source-apm-tools/) enable you to be proactive about meeting the demands of your customers. There are many components to a good APM tool like metrics monitoring, distributed tracing, log management, alert systems, etc.
Jaeger and Elastic APM are both popular tools in the domain of application performance monitoring. But both have different scope and use-cases.
## Key Features of Jaeger
Jaeger was originally built by teams at Uber and then open-sourced. It is used for end-to-end distributed tracing for microservices. Some of the key features of Jaeger includes:
-- **Distributed context propagation**+- **Distributed [context propagation](https://signoz.io/blog/opentelemetry-context-propagation/)**
One of the challenges of distributed systems is to have a standard format for passing context across process boundaries and services. Jaeger provides client libraries that support code instrumentation in multiple languages to propagate context across services - **Distributed transaction monitoring**
@@ -73,12 +73,12 @@ The four major components of elastic APM has the following features: Some of the key features of Elastic APM includes: - **Root Cause investigations**
-Elastic APM provides a dashboard for showing a service's transactions and dependencies which can be used to identify issues. +[Elastic APM](https://signoz.io/comparisons/opentelemetry-vs-elastic-apm/) provides a dashboard for showing a service's transactions and dependencies which can be used to identify issues. - **Service Maps**
With service maps, you can see how your services are connected to each other. It provides a convenient way to see which services need optimization. -- **Distributed Tracing**
+- **[Distributed Tracing](https://signoz.io/distributed-tracing/)**
Distributed tracing provides an overview of how user requests are performing across services. - **Anamoly Detection with machine learning**
diff --git a/data/blog/jaeger-vs-newrelic.mdx b/data/blog/jaeger-vs-newrelic.mdx index 83e8ab220..9a25e8c87 100644 --- a/data/blog/jaeger-vs-newrelic.mdx +++ b/data/blog/jaeger-vs-newrelic.mdx @@ -42,11 +42,11 @@ A trace context is passed along when requests travel between services, which tra ## Key Features of Jaeger Jaeger was originally built by teams at Uber and then open-sourced. It is used for end-to-end distributed tracing for microservices. Some of the key features of Jaeger includes: -- **Distributed context propagation**
+- **Distributed [context propagation](https://signoz.io/blog/opentelemetry-context-propagation/)**
One of the challenges of distributed systems is to have a standard format for passing context across process boundaries and services. Jaeger provides client libraries that supports code instrumentation in multiple languages to propagate context across services - **Distributed transaction monitoring**
-Jaeger comes with a web UI written in Javascript. The dashboard can be used to see traces and spans across services. +Jaeger comes with a web UI written in Javascript. The dashboard can be used to see [traces and spans](https://signoz.io/comparisons/opentelemetry-trace-vs-span/) across services. - **Root Cause Analysis**
Using traces you can drill down to services causing latency in particular user request. @@ -72,7 +72,7 @@ Once you have identified, which service or query is creating latency, you can us Some of the key features and services that New Relic provides: -- **Infrastructure monitoring**
+- **[Infrastructure monitoring](https://signoz.io/guides/infrastructure-monitoring/)**
New Relic can connect your application performance with your infrastructure health to provide you better insights for quick troubleshooting. - **Telemetry Data platform**
@@ -100,7 +100,7 @@ New Relic provides integrations with all leading cloud providers and also suppor As New Relic is a SaaS vendor, it is not free. Standard offering includes plans for teams up to 5 full users. Their pricing depends on the amount of data ingested with 100 GB free data ingest and \$0.25 per extra GB. ## Comparing Jaeger and New Relic -From the description above, you might have a good idea about the differences between Jaeger and New Relic. The key difference between the two projects is their scope. While Jaeger is an end-to-end distributed tracing tool, New Relic is a SaaS vendor offering many out-of-the-box services. +From the description above, you might have a good idea about the differences between Jaeger and New Relic. The key difference between the two projects is their scope. While Jaeger is an end-to-end distributed [tracing tool](https://signoz.io/blog/distributed-tracing-tools/), New Relic is a SaaS vendor offering many out-of-the-box services. Apart from distributed tracing, New Relic offers log management, infrastructure monitoring, network monitoring, and application monitoring. It also provides AIOps capabilities. @@ -132,7 +132,7 @@ Let's focus on the distributed tracing capabilities of both the tools and see th
+- **Distributed [context propagation](https://signoz.io/blog/opentelemetry-context-propagation/)**
One of the challenges of distributed systems is to have a standard format for passing context across process boundaries and services. Jaeger provides client libraries that support code instrumentation in multiple languages to propagate context across services - **Distributed transaction monitoring**
@@ -62,13 +62,13 @@ Prometheus enables you to capture time-series data as metrics. These metrics can ``` - **Flexible query language**
- Prometheus provides a query language called PromQL. Using PromQL, you can filter and aggregate metrics data in real-time. + Prometheus provides a query language called PromQL. Using PromQL, you can filter and [aggregate metrics](https://signoz.io/docs/metrics-management/types-and-aggregation/) data in real-time. - **Pull model data collection**
- In contrast to most APM tools, Prometheus data collection is pull-based. It requires you to run an HTTP server that exposes Prometheus metrics. + In contrast to most APM tools, [Prometheus data](https://signoz.io/guides/how-does-grafana-get-data-from-prometheus/) collection is pull-based. It requires you to run an HTTP server that exposes Prometheus metrics. - **Graphing and dashboarding support**
- For visualization, Prometheus has three options: Prometheus Expression Browser, Grafana, and Prometheus Console Templates. Grafana is a popular data visualization tool, and it supports querying Prometheus. Although it requires time and effort to set up custom Prometheus metrics with Grafana, it can give you some solid visualization. + For visualization, Prometheus has three options: Prometheus Expression Browser, Grafana, and Prometheus Console Templates. Grafana is a popular data visualization tool, and it supports querying Prometheus. Although it requires time and effort to set up custom [Prometheus metrics](https://signoz.io/guides/what-are-the-4-types-of-metrics-in-prometheus/) with Grafana, it can give you some solid visualization.
@@ -212,7 +212,7 @@ Org management will enable teams using SigNoz to collaborate better. There are t
---
-Now that you have an idea of why you should choose SigNoz if you're considering Jaeger as a distributed tracing tool, let's see in brief two important things about SigNoz:
+Now that you have an idea of why you should choose SigNoz if you're considering Jaeger as a distributed [tracing tool](https://signoz.io/blog/distributed-tracing-tools/), let's see in brief two important things about SigNoz:
- How does SigNoz collects data?
- How to install and get started with SigNoz?
diff --git a/data/blog/jaeger-vs-tempo.mdx b/data/blog/jaeger-vs-tempo.mdx
index a510d1c03..c1ea2b325 100644
--- a/data/blog/jaeger-vs-tempo.mdx
+++ b/data/blog/jaeger-vs-tempo.mdx
@@ -18,7 +18,7 @@ Jaeger is a popular open-source tool that graduated as a project from Cloud Nati
But before we dive into the details of Jaeger and Grafana Tempo, let's take a short detour to understand distributed tracing.
## What is distributed tracing?
-In the world of microservices, a user request travels through hundreds of services before serving a user what they need. To make a business scalable, engineering teams are responsible for particular services with no insight into how the system performs as a whole. And that's where distributed tracing comes into the picture.
+In the world of microservices, a user request travels through hundreds of services before serving a user what they need. To make a business scalable, engineering teams are responsible for particular services with no insight into how the system performs as a whole. And that's where [distributed tracing](https://signoz.io/distributed-tracing/) comes into the picture.
Jaeger's client libraries for instrumentation are based on OpenTracing APIs. OpenTracing was an open-source project aimed at providing vendor-neutral APIs and instrumentation for distributed tracing. It later got merged into [OpenTelemetry](https://opentelemetry.io/). @@ -152,11 +152,11 @@ Grafana Tempo also has an open-source version that is free to use and has no lic ### Visualization layer -In terms of the visualization layer, Grafana Tempo has the edge over Jaeger. Grafana Tempo is distributed tracing tool by Grafana - an open-source data visualization layer. You can connect different data sources to Grafana for visualization. Grafana has a built-in Tempo data source that can be used to query Tempo and visualize traces. +In terms of the visualization layer, [Grafana Tempo](https://signoz.io/comparisons/opentelemetry-vs-tempo/) has the edge over Jaeger. Grafana Tempo is distributed tracing tool by Grafana - an open-source data visualization layer. You can connect different data sources to Grafana for visualization. Grafana has a built-in Tempo data source that can be used to query Tempo and visualize traces.
@@ -74,7 +74,7 @@ You can add additional data in JSON logging very easily. For example, you might
### Have a consistent structure
-Having a consistent structure in your logging format will make it easier to extract and analyze the data you need. For example, you might define a set of standard fields that you include in every log message, such as "timestamp", "level", and "message".
+Having a consistent structure in your [logging format](https://signoz.io/guides/what-is-pythons-default-logging-formatter/) will make it easier to extract and analyze the data you need. For example, you might define a set of standard fields that you include in every log message, such as "timestamp", "level", and "message".
### Keep log messages concise and informative
@@ -90,9 +90,9 @@ Use a JSON linter to check your JSON code for syntax errors and formatting issue
### Use a log management tool
-If you are working with a large volume of JSON logs, it can be helpful to use a tool like SigNoz. SigNoz can help you search for specific log messages, filter log messages by severity level, and create visualizations to help you understand the patterns in your log data.
+If you are working with a large volume of JSON logs, it can be helpful to use a tool like [SigNoz](https://signoz.io/docs/introduction/). SigNoz can help you search for specific log messages, filter log messages by severity level, and create visualizations to help you understand the patterns in your log data.
-JSON logging is a powerful and flexible tool for logging in web applications. By using a consistent structure, keeping log messages concise and informative, using appropriate data types, and using a JSON linter and log management tool, you can get the most out of your JSON log files.
+JSON logging is a powerful and flexible tool for logging in web applications. By using a consistent structure, keeping log messages concise and informative, using appropriate data types, and using a JSON linter and log management tool, you can get the most out of your [JSON log](https://signoz.io/docs/logs-pipelines/guides/json/) files.
## Examples of JSON Logs
@@ -162,7 +162,7 @@ A log management tool is used to collect, process, and analyze log data. A log m
JSON logs combined with a good log analytics tool can help you query and filter out log messages quickly.
-SigNoz is a full-stack open source APM that you can use to process your JSON logs. SigNoz uses a columnar database ClickHouse to store logs, which is very efficient at ingesting and storing logs data. Columnar databases like ClickHouse are very effective in storing log data and making it available for analysis.
+SigNoz is a full-stack [open source APM](https://signoz.io/application-performance-monitoring/) that you can use to process your JSON logs. SigNoz uses a columnar database ClickHouse to store logs, which is very efficient at ingesting and storing logs data. Columnar databases like ClickHouse are very effective in storing log data and making it available for analysis.
The logs tab in SigNoz has advanced features like a log query builder, search across multiple fields, structured table view, JSON view, etc.
diff --git a/data/blog/justifying-a-million-dollar-observability-bill.mdx b/data/blog/justifying-a-million-dollar-observability-bill.mdx
index ad55e5b30..b464458ce 100644
--- a/data/blog/justifying-a-million-dollar-observability-bill.mdx
+++ b/data/blog/justifying-a-million-dollar-observability-bill.mdx
@@ -43,7 +43,7 @@ def do_work(work_type):
print("doing some work...")
```
-Now let’s add OpenTelemetry manual instrumentation:
+Now let’s add [OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/) manual instrumentation:
```python
# Acquire a tracer
@@ -90,7 +90,7 @@ Obviously a contrived example, but it’s worth noting that there were more line
### Cost reductions are possible
-Again, this is not the focus of this piece (geez don’t you read the introductory paragraphs??), but it’s important to note that it’s completely possible to significantly reduce the costs of observability. Tools like the OpenTelemetry Collector have tons of processors available to filter, parse, and compress data so that you’re sending way less data than your app’s actual workload.
+Again, this is not the focus of this piece (geez don’t you read the introductory paragraphs??), but it’s important to note that it’s completely possible to significantly reduce the costs of observability. Tools like the [OpenTelemetry Collector](https://signoz.io/blog/opentelemetry-collector-complete-guide/) have tons of processors available to filter, parse, and compress data so that you’re sending way less data than your app’s actual workload.
And open-source options are absolutely going to give more bang for your buck than closed-source SaaS tools. While companies like Datadog and New Relic may claim support for open standards like OpenTelemetry, [the reality is a little different](https://signoz.io/blog/is-opentelemetry-a-first-class-citizen-in-your-dashboard-a-datadog-and-newrelic-comparison/).
@@ -122,7 +122,7 @@ If this situation is hard to believe, consider that most airlines can’t specif
### The real argument for observability: the cost of not having it
-When a developer uses a cool tracing tool to find the bit of code that’s slowing down performance, the dollar benefit of that act to the company is extremely difficult to show. You might try calculating how long the developer would have spent trying to fix the problem without the tool, but that’s always going to be a _very_ rough estimate since a proper observability tool fundamentally alters the way dev teams operate so a simple time estimate is unlikely to be accurate.
+When a developer uses a cool [tracing tool](https://signoz.io/blog/distributed-tracing-tools/) to find the bit of code that’s slowing down performance, the dollar benefit of that act to the company is extremely difficult to show. You might try calculating how long the developer would have spent trying to fix the problem without the tool, but that’s always going to be a _very_ rough estimate since a proper observability tool fundamentally alters the way dev teams operate so a simple time estimate is unlikely to be accurate.
No, the real way to show what observability has to offer is the cost of _not_ having it. The cost of downtime, system slowdowns, and dissatisfied users is one that every exec can estimate.
@@ -144,8 +144,8 @@ The initial rush to implement observability tools like Datadog, New Relic, and S
### OpenTelemetry and SigNoz can help with out-of-control-costs
-This piece helps explain why observability SaaS offerings have often received a blank check as long as they reduced the risk of downtime. We haven't discussed why, so often, observability bills continue to grow and often outpace the growth in infrastructure costs. To explain that, we have to admit that part of the story is lock-in. With a closed-source SaaS offering for observability, switching service providers means at least an arduous change of installed software agents. In the worst case, teams will have added thousands of custom metric calls to their application code which will all have to be changed to switch APM tools. Inevitably, this leaves customers 'stuck' and unable to do much as their observability bill grows.
+This piece helps explain why observability SaaS offerings have often received a blank check as long as they reduced the risk of downtime. We haven't discussed why, so often, observability bills continue to grow and often outpace the growth in infrastructure costs. To explain that, we have to admit that part of the story is lock-in. With a closed-source SaaS offering for observability, switching service providers means at least an arduous change of installed software agents. In the worst case, teams will have added thousands of custom metric calls to their application code which will all have to be changed to switch [APM tools](https://signoz.io/blog/open-source-apm-tools/). Inevitably, this leaves customers 'stuck' and unable to do much as their observability bill grows.
OpenTelemetry can solve this problem. By implementing open standards for how observability data is gathered and transmitted, OpenTelemetry makes it very easy to switch service providers. If you're using the OpenTelemetry Collector (and you should be), all you have to do is reconfigure your collection endpoint in a single place.
-Along with OpenTelemetry, you'll need a backend to report and chart data. The OpenTelemetry project is neutral about your data backend, but a tool like SigNoz uses the power of Clickhouse to store data efficiently, and it even has a self-hosted option.
+Along with OpenTelemetry, you'll need a backend to report and chart data. The [OpenTelemetry project](https://signoz.io/blog/opentelemetry-apm/) is neutral about your data backend, but a tool like SigNoz uses the power of Clickhouse to store data efficiently, and it even has a self-hosted option.
diff --git a/data/blog/kafka-monitoring-opentelemetry.mdx b/data/blog/kafka-monitoring-opentelemetry.mdx
index f79511472..753f8885c 100644
--- a/data/blog/kafka-monitoring-opentelemetry.mdx
+++ b/data/blog/kafka-monitoring-opentelemetry.mdx
@@ -10,7 +10,7 @@ keywords: [kafka monitoring, opentelemetry, distributed tracing, signoz, trouble
---
## Introduction
-Over the past few years in the observability and monitoring space, we've received numerous complaints from users about the lack of detailed monitoring for messaging queues, particularly Kafka. With the introduction of instrumentation standards like OpenTelemetry, we realized there must be a better solution to this problem.
+Over the past few years in the [observability and monitoring](https://signoz.io/blog/observability-vs-monitoring/) space, we've received numerous complaints from users about the lack of detailed monitoring for messaging queues, particularly Kafka. With the introduction of instrumentation standards like OpenTelemetry, we realized there must be a better solution to this problem.
We delved deeper into the problem, seeking to understand how to improve the process of identifying and resolving issues in messaging systems, making it much easier for users.
@@ -18,11 +18,11 @@ The following sections focus on Kafka as a representative messaging queue to ill
We would love to hear if these problem statements resonate with the community and welcome any feedback on how this can be more useful to you. We have also shared some wireframes of proposed solutions to concretize our current thought process. **We appreciate any feedback on which flows and starting points would be most useful to you.**
-One of our key objectives is to leverage distributed tracing. Most current monitoring solutions for Kafka show metrics about Kafka, but metrics are often aggregated and don’t give much details on exactly where things are going wrong. Traces on the other hand show you the exact path a message takes, offering much more detailed information. Our focus is on how we can use this trace information to resolve issues more quickly and effectively.
+One of our key objectives is to leverage [distributed tracing](https://signoz.io/distributed-tracing/). Most current monitoring solutions for Kafka show metrics about Kafka, but metrics are often aggregated and don’t give much details on exactly where things are going wrong. Traces on the other hand show you the exact path a message takes, offering much more detailed information. Our focus is on how we can use this trace information to resolve issues more quickly and effectively.
## Background
-In the modern distributed architecture, Infrastructure monitoring has become crucial, there are many components which contribute to system stability. In this blog post, we will see how end-to-end observability of Messaging queues can be achieved using [OpenTelemetry](https://opentelemetry.io/) and the problems it can solve to ensure the stability and scalability of Distributed Asynchronous Architectures.
+In the modern distributed architecture, [Infrastructure monitoring](https://signoz.io/guides/infrastructure-monitoring/) has become crucial, there are many components which contribute to system stability. In this blog post, we will see how end-to-end observability of Messaging queues can be achieved using [OpenTelemetry](https://opentelemetry.io/) and the problems it can solve to ensure the stability and scalability of Distributed Asynchronous Architectures.
@@ -49,7 +49,7 @@ Some challenges that can be solved include:
4. Insights into maintaining, scaling and capacity planning of brokers of Kafka
-For this, we assume that the Kakfa producers and consumers use OpenTelemetry client libraries for context propagation. If you’re new to OpenTelemetry or want to follow along with an example, you can follow the [github guide](https://github.com/SigNoz/kafka-opentelemetry-instrumentation) which will help you configure the above kafka setup along with producer and consumer applications in Java, which are automatically instrumented with [Opentelemetry Java Agent](https://github.com/open-telemetry/opentelemetry-java-instrumentation). You’d be able to see metrics and traces in the SigNoz UI.
+For this, we assume that the Kakfa producers and consumers use OpenTelemetry client libraries for [context propagation](https://signoz.io/blog/opentelemetry-context-propagation/). If you’re new to OpenTelemetry or want to follow along with an example, you can follow the [github guide](https://github.com/SigNoz/kafka-opentelemetry-instrumentation) which will help you configure the above kafka setup along with producer and consumer applications in Java, which are automatically instrumented with [Opentelemetry Java Agent](https://github.com/open-telemetry/opentelemetry-java-instrumentation). You’d be able to see metrics and traces in the [SigNoz](https://signoz.io/docs/introduction/) UI.
**Fig 2** below describes the setup from the [guide](https://github.com/SigNoz/kafka-opentelemetry-instrumentation). We use JMX receiver, [Kafkametrics receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/kafkametricsreceiver/README.md) from OpenTelemetry and also traces data sent in OTLP format.
diff --git a/data/blog/kibana-vs-grafana.mdx b/data/blog/kibana-vs-grafana.mdx
index 1e49a48f4..d970f8a2d 100644
--- a/data/blog/kibana-vs-grafana.mdx
+++ b/data/blog/kibana-vs-grafana.mdx
@@ -267,7 +267,7 @@ In Grafana, you can build dashboards combining multiple data sources. Dashboards
- **Dashboard Collaboration**Grafana allows users to share dashboard within their organization and also create public dashboards in some cases. It also provides role-based access control features for effective team collaboration. - **Alert Manager**
-Grafana provides an alerting UI that users can use to set and manage alerts on metrics. It also includes in-built support for Prometheus alert manager. Grafana sends alerts through several different notifiers, including email, PagerDuty, Slack, texts, and more. +Grafana provides an alerting UI that users can use to set and manage alerts on metrics. It also includes in-built support for [Prometheus alert manager](https://signoz.io/guides/how-do-i-add-alerts-to-prometheus/). Grafana sends alerts through several different notifiers, including email, PagerDuty, Slack, texts, and more. ## Comparing Grafana and Kibana @@ -598,15 +598,15 @@ Modern observability trends show that for effective monitoring of application, a - Metrics - Traces -The above three signals are popularly known as the three pillars of observability. The easier a tool makes it to get started with these three signals, the better. Grafana Labs provide multiple solutions to collect and monitor logs, metrics, and traces. You need to stitch together the following three tools for a full-stack observability solution: +The above three signals are popularly known as [the three pillars of observability](https://signoz.io/blog/three-pillars-of-observability/). The easier a tool makes it to get started with these three signals, the better. Grafana Labs provide multiple solutions to collect and monitor logs, metrics, and traces. You need to stitch together the following three tools for a full-stack observability solution: - Loki for logs - Prometheus - Grafana combo for metrics - Tempo for traces -Elastic, on the other hand, provides Elastic APM, its observability solution meant for cloud-native applications. But the Elastic stack is mainly known for its log analytics solution. +Elastic, on the other hand, provides [Elastic APM](https://signoz.io/comparisons/opentelemetry-vs-elastic-apm/), its observability solution meant for cloud-native applications. But the Elastic stack is mainly known for its log analytics solution. -SigNoz is a full-stack open-source observability tool that provides logs, metrics, and traces under a single pane of glass. It can serve as your one-stop solution for all observability needs. Even for log analytics, SigNoz can be a better choice when compared to Elasticsearch and Loki by Grafana. We found [SigNoz to be 2.5x more efficient](https://signoz.io/blog/logs-performance-benchmark/) in ingestion when compared to ELK stack. Loki doesn’t perform well if you want to index and query high cardinality data. +SigNoz is a full-stack open-source observability tool that provides logs, metrics, and traces under a single pane of glass. It can serve as your one-stop solution for all observability needs. Even for log analytics, SigNoz can be a better choice when compared to Elasticsearch and Loki by Grafana. We found [SigNoz to be 2.5x more efficient](https://signoz.io/blog/logs-performance-benchmark/) in ingestion when compared to ELK stack. Loki doesn’t perform well if you want to index and query [high cardinality data](https://signoz.io/blog/high-cardinality-data/). SigNoz comes with out-of-box application metrics charts. @@ -632,7 +632,7 @@ Using [Flamegraphs and Gantt charts](https://signoz.io/blog/flamegraphs/), you c 2. Grafana provides broader data source support and excels in metrics visualization, making it ideal for diverse monitoring needs. 3. Both tools offer strong visualization capabilities but differ in query languages, setup processes, and primary use cases. 4. Consider your project requirements, existing infrastructure, and team skills when choosing between Kibana and Grafana. -5. SigNoz offers an alternative solution with integrated tracing, metrics, and logs, providing a comprehensive observability platform. +5. [SigNoz](https://signoz.io/docs/introduction/) offers an alternative solution with integrated tracing, metrics, and logs, providing a comprehensive observability platform. ## FAQs diff --git a/data/blog/kubectl-logs-tail.mdx b/data/blog/kubectl-logs-tail.mdx index 38569e97e..ece2954f9 100644 --- a/data/blog/kubectl-logs-tail.mdx +++ b/data/blog/kubectl-logs-tail.mdx @@ -281,7 +281,7 @@ Here are some use cases where `kubectl logs tail`` command can be useful: `kubectl logs tail` is a useful command for accessing and following the logs of a running container in a Kubernetes cluster. While it can be a convenient way to view and troubleshoot logs in real-time, it may not be the most efficient or comprehensive solution for managing logs in a production environment. These limitations include the lack of built-in features for organizing, storing, or analyzing logs, and the lack of options for filtering or highlighting specific log events. In addition, the command does not provide any alerting or notification capabilities and does not integrate with other tools or platforms for log management or analysis. -To overcome these limitations, consider using a third-party log management system like [SigNoz](https://signoz.io/), which provides a centralized platform for storing, analyzing, and visualizing logs from multiple sources. SigNoz can help you to gain insights into the performance and health of your Kubernetes applications, and identify and resolve issues more efficiently. +To overcome these limitations, consider using a third-party [log management system](https://signoz.io/blog/open-source-log-management/) like [SigNoz](https://signoz.io/), which provides a centralized platform for storing, analyzing, and visualizing logs from multiple sources. SigNoz can help you to gain insights into the performance and health of your Kubernetes applications, and identify and resolve issues more efficiently. ## Kubectl log analysis with SigNoz @@ -289,7 +289,7 @@ SigNoz is a cloud-native observability platform that provides comprehensive logs One of the key features offered by SigNoz is the ability to analyze logs generated by `kubectl`. This is accomplished by forwarding the cluster logs to SigNoz, which then automatically ingests and indexes the logs. This allows users to query and analyze the logs in real-time through the SigNoz web interface or API. -SigNoz's logs tab offers numerous advanced features, including a log query builder, the ability to search through multiple fields, a structured table view, and the option to view logs in JSON format. +SigNoz's logs tab offers numerous advanced features, including a log [query builder](https://signoz.io/blog/query-builder-v5/), the ability to search through multiple fields, a structured table view, and the option to view logs in JSON format.
diff --git a/data/blog/kubectl-logs.mdx b/data/blog/kubectl-logs.mdx
index 39681be4d..65b581021 100644
--- a/data/blog/kubectl-logs.mdx
+++ b/data/blog/kubectl-logs.mdx
@@ -248,7 +248,7 @@ kubectl logs works best for:
- Short-term log analysis
- Small to medium clusters (under 50 nodes)
-Production environments with hundreds of nodes require centralized logging solutions for performance and comprehensive analysis.
+Production environments with hundreds of nodes require [centralized logging](https://signoz.io/blog/centralized-logging/) solutions for performance and comprehensive analysis.
## Integration with Centralized Logging
@@ -296,13 +296,13 @@ kubectl logs api-pod | grep "trace_id: abc123"
While kubectl logs provides essential debugging capabilities, comprehensive Kubernetes monitoring requires integrated observability solutions combining logs, metrics, and distributed tracing.
-SigNoz offers comprehensive Kubernetes infrastructure monitoring built on OpenTelemetry, providing full-stack observability designed specifically for Kubernetes environments.
+SigNoz offers comprehensive Kubernetes [infrastructure monitoring](https://signoz.io/guides/infrastructure-monitoring/) built on OpenTelemetry, providing full-stack observability designed specifically for Kubernetes environments.
diff --git a/data/blog/kubernetes-observability-with-opentelemetry.mdx b/data/blog/kubernetes-observability-with-opentelemetry.mdx
index c3bc089d3..c68e7738b 100644
--- a/data/blog/kubernetes-observability-with-opentelemetry.mdx
+++ b/data/blog/kubernetes-observability-with-opentelemetry.mdx
@@ -11,7 +11,7 @@ keywords: [kubernetes observability, opentelemetry, kubernetes monitoring, kuber
Kubernetes provides a wealth of telemetry data from container metrics and application traces to cluster events and logs. OpenTelemetry [OTel] offers a vendor-neutral, end-to-end solution for collecting and exporting this telemetry in a standardised format.
-In this blog, we’ll walk through a Kubernetes observability setup on Minikube using OpenTelemetry, but you can easily extend the setup to your Kubernetes setup as well. We’ll deploy an example instrumented application, then set up the OpenTelemetry Collector in two modes - DaemonSet and Deployment, using the official Helm charts. This two-pronged approach will capture both service-level metrics and traces, as well as cluster-level metrics and events, giving you full visibility into your Kubernetes environment.
+In this blog, we’ll walk through a [Kubernetes observability](https://signoz.io/guides/kubernetes-observability/) setup on Minikube using OpenTelemetry, but you can easily extend the setup to your Kubernetes setup as well. We’ll deploy an example instrumented application, then set up the OpenTelemetry Collector in two modes - DaemonSet and Deployment, using the official Helm charts. This two-pronged approach will capture both service-level metrics and traces, as well as cluster-level metrics and events, giving you full visibility into your Kubernetes environment.
This walkthrough aims to give you a solid practical foundation and a clear blueprint to instrument your own Kubernetes cluster using OpenTelemetry.
@@ -46,7 +46,7 @@ Let’s start our minikube.
minikube start --memory 8192 --cpus 6
```
-The OpenTelemetry Helm repository should be added:
+The [OpenTelemetry](https://signoz.io/blog/what-is-opentelemetry/) Helm repository should be added:
```bash
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
@@ -71,7 +71,7 @@ We already have a pod running OTel collector, which comes bundled with the demo.
-At this point, our Minikube cluster has a running demo application. Now we’ll set up two OpenTelemetry Collectors:
+At this point, our Minikube cluster has a running demo application. Now we’ll set up two [OpenTelemetry Collectors](https://signoz.io/blog/opentelemetry-collector-complete-guide/):
- One running on each node [DaemonSet] to act as an **agent**
- And one running as a single-instance gateway [Deployment] for cluster-level data.
@@ -80,7 +80,7 @@ Using both ensures we capture **all layers of telemetry**.
## OpenTelemetry Collector as a DaemonSet [Agent]
-First, we deploy the collector as a DaemonSet. This means an OTel Collector pod will run on **each node** of the cluster [in Minikube’s case, just one node = one pod]. This “agent” collector will focus on node and pod-level metrics, container logs, and will serve as a local OTLP endpoint for application telemetry.
+First, we deploy the collector as a DaemonSet. This means an [OTel](https://signoz.io/blog/what-is-opentelemetry/) Collector pod will run on **each node** of the cluster [in Minikube’s case, just one node = one pod]. This “agent” collector will focus on node and pod-level metrics, container logs, and will serve as a local OTLP endpoint for application telemetry.
In OTel terms, the DaemonSet collector will include components like,
@@ -162,13 +162,13 @@ You should see **one pod** [named something like `otel-collector-*****`] for the
Great.
-We now have the **OTel agent** running, which automatically scrapes host metrics and listens for app telemetry on each node.
+We now have the **[OTel agent](https://signoz.io/comparisons/opentelemetry-collector-vs-agent/)** running, which automatically scrapes host metrics and listens for app telemetry on each node.
### Functionality of the Collector Daemonset
We set `mode: daemonset` to get one collector per node. The Helm chart will handle setting the proper Kubernetes `DaemonSet` object, including RBAC permissions, **host ports**, and volume mounts needed to access the host’s logs and kubelet API.
-- The `kubernetesAttributes` processor is enabled to auto-annotate metrics, traces, and logs with Kubernetes context or meta [e.g. add `k8s.pod.name`, `k8s.node.name`, etc.] for correlation. This is crucial for connecting *application telemetry with the platform/ infra telemetry*.
+- The `kubernetesAttributes` processor is enabled to auto-annotate metrics, traces, and logs with Kubernetes context or meta [e.g. add `k8s.pod.name`, `k8s.node.name`, etc.] for correlation. This is crucial for connecting *[application telemetry](https://signoz.io/comparisons/opentelemetry-vs-application-insights/) with the platform/ infra telemetry*.
- The `kubeletMetrics` preset enables the `kubeletstats` receiver. This receiver pulls resource usage metrics from each node’s Kubelet API. It provides metrics like **container memory usage**, **pod CPU usage**, and **node network errors**, among others.
For example, it will report how much CPU and memory each pod/container is using, which is vital for performance monitoring and right-sizing.
@@ -179,14 +179,14 @@ By default, the Helm chart also leaves an OTLP receiver open [on the collector
## Kubernetes Logging
-The *logsCollection* preset in our DaemonSet collector is designed to collect logs from `/var/log/pods/...` on each node, capturing the container *stdout/ stderr*. This is a common and effective method for integrating application logs into your observability pipeline. However, it's essential to understand the broader context of Kubernetes logging.
+The *logsCollection* preset in our DaemonSet collector is designed to collect logs from `/var/log/pods/...` on each node, capturing the container *stdout/ stderr*. This is a common and effective method for integrating application logs into your [observability pipeline](https://signoz.io/guides/observability-pipeline/). However, it's essential to understand the broader context of Kubernetes logging.
### Kubernetes Logging Best Practices
Effective logging in Kubernetes involves more than just collecting *stdout/stderr*. Here are some best practices:
1. **Log to Standard Output/Error:** This is the most fundamental practice. Containerised applications should write all logs to *stdout* and *stderr*. Kubernetes automatically captures these streams and hands them off to the container runtime [e.g., containerd, Docker], which then writes them to a file on the node [typically in `/var/log/pods/
diff --git a/data/blog/llm-observability.mdx b/data/blog/llm-observability.mdx
index 7da43cdf5..570717dd7 100644
--- a/data/blog/llm-observability.mdx
+++ b/data/blog/llm-observability.mdx
@@ -137,7 +137,7 @@ keywords: [LLM Observability, AI monitoring, machine learning, performance optim
},
{
"@type": "HowToStep",
- "name": "Install OpenTelemetry SDK",
+ "name": "Install [OpenTelemetry SDK](https://signoz.io/comparisons/opentelemetry-api-vs-sdk/)",
"text": "Install the OpenTelemetry SDK in your LLM application using pip."
},
{
@@ -179,7 +179,7 @@ For those eager to dive into practical implementation, you can jump directly to
## What is LLM Observability and Why It Matters
-LLM Observability refers to the end-to-end visibility into the performance and behavior of Large Language Model applications. It extends beyond traditional machine learning monitoring by focusing on the unique aspects of LLMs, such as prompt engineering, retrieval-augmented generation, and fine-tuning processes.
+LLM Observability refers to the end-to-end visibility into the performance and behavior of Large Language Model applications. It extends beyond traditional [machine learning monitoring](https://signoz.io/guides/model-monitoring/) by focusing on the unique aspects of LLMs, such as prompt engineering, retrieval-augmented generation, and fine-tuning processes.
**Why does LLM Observability matter?**
@@ -307,7 +307,7 @@ To maximize the benefits of LLM Observability, follow these best practices:
Several tools can help you implement effective LLM Observability:
@@ -111,7 +111,7 @@ Log data is often vast, and developers need to check and see the logs they are i
### Correlating Logs with other Observability signals
-As SigNoz uses OpenTelemetry to collect and parse logs, you can use it to correlate logs with other observability signals like traces and metrics. Correlating logs with other observability signals can enrich your logs data and help debug applications faster.
+As [SigNoz](https://signoz.io/docs/introduction/) uses OpenTelemetry to collect and [parse logs](https://signoz.io/guides/log-parsing/), you can use it to correlate logs with other observability signals like traces and metrics. Correlating logs with other observability signals can enrich your logs data and help debug applications faster.
### Seamless transition from your existing logging pipelines
diff --git a/data/blog/logs-performance-benchmark.mdx b/data/blog/logs-performance-benchmark.mdx
index f52866bce..88298c530 100644
--- a/data/blog/logs-performance-benchmark.mdx
+++ b/data/blog/logs-performance-benchmark.mdx
@@ -30,7 +30,7 @@ We will go through how we have created the environment for benchmarking the diff
For any log management tool to be efficient, the following three factors are very important.
- **Ingestion**- Distributed cloud-native applications can generate logs at a humungous scale. Log management tools should be efficient at ingesting log data at scale. + Distributed cloud-native applications can generate logs at a humungous scale. [Log management tools](https://signoz.io/blog/open-source-log-management/) should be efficient at ingesting log data at scale. - **Query**
Logs help in troubleshooting, and troubleshooting should be fast. The end-user experience depends on how fast a user can query relevant logs. @@ -43,7 +43,7 @@ For any log management tool to be efficient, the following three factors are ver - **For ingestion**, we found SigNoz to be **2.5x faster** than ELK and consumed **50% less resources**. - For querying benchmarks, we tested out different types of commonly used queries. While ELK was better at performing queries like COUNT, SigNoz is **13x faster than ELK** for **aggregate queries**. - **Storage** used by SigNoz for the same amount of logs is about **half of what ELK uses.** -- Loki doesn’t perform well if you want to index and query high cardinality data. In our setup for Loki we were not able to push it to ingest high cardinality labels/indexes. +- Loki doesn’t perform well if you want to index and query [high cardinality data](https://signoz.io/blog/high-cardinality-data/). In our setup for Loki we were not able to push it to ingest high cardinality labels/indexes. We saw Loki team has [recently shared](https://twitter.com/sukhanisandeep/status/1615243908241588224) some improvements in querying speed, but this benchmark is not updated based on this update and we have not verified if it would help in high cardinality data. If anyone in the community has been able to get good performance for high cardinality data, we would love to learn more. @@ -94,9 +94,9 @@ SigNoz cluster architecture for the performance benchmark looks as the following