diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8f017100d..8ee6e47d3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -577,8 +577,6 @@ Docs pages must be added to the sidebar navigation. } ``` -Optional: To mark a doc as new, include `className: 'new-doc'` on the entry. - If you introduced a new tag in your doc frontmatter, add its tooltip definition in `constants/tagDefinitions.ts`. ### Step 8: Add and Commit Your Changes diff --git a/README.md b/README.md index 57d333c8d..d5b3defb1 100644 --- a/README.md +++ b/README.md @@ -60,33 +60,3 @@ Looking to contribute a blog or improve docs? See the full guidelines in [CONTRI If you have any questions or need further assistance, feel free to reach out to us on [SigNoz Slack Community](https://signoz.io/slack). --- - -## Add a `NEW` tag to Documentation - -We can add a `NEW` tag for doc that went live recently. To do this, you just need to add `className: 'new-doc'` key value pair to the doc in the `docsSideNav.ts` file. For example, if a new doc for LLM monitoring went live, you can add a new tag to it as follows: - -```tsx -{ - route: '/docs/community/llm-monitoring', - label: 'LLM Monitoring', - type: 'doc', - className: 'new-doc', -}, - -``` - -You can do the same for a Category. For example, if you're adding a new category with the label `Azure Monitoring` and it has multiple docs inside it, you can add a new tag as shown below: - -```tsx - -{ - label: 'Azure Monitoring', - type: 'category', - className: 'new-doc', - items: [ - { - ... - }, - ], - -``` diff --git a/components/MDXComponents.tsx b/components/MDXComponents.tsx index be8b9aeb3..1a3e0bf53 100644 --- a/components/MDXComponents.tsx +++ b/components/MDXComponents.tsx @@ -64,6 +64,7 @@ import LLMMonitoringListicle from './LLMMonitoring/LLMMonitoringListicle' import OtelCollectorFlow from './OtelCollectorFlow/OtelCollectorFlow' import ResponseTimeVisualizer from './APMMetrics/ResponseTimeVisualizer' +import MetricsQuickStartOverview from './Metrics/MetricsQuickStartOverview' export const components: MDXComponents = { Image, @@ -128,4 +129,5 @@ export const components: MDXComponents = { CollectionAgentsListicle, ResponseTimeVisualizer, ProductFeatureShowcase, + MetricsQuickStartOverview, } diff --git a/components/Metrics/MetricsQuickStartOverview.tsx b/components/Metrics/MetricsQuickStartOverview.tsx new file mode 100644 index 000000000..4e36d063b --- /dev/null +++ b/components/Metrics/MetricsQuickStartOverview.tsx @@ -0,0 +1,183 @@ +'use client' + +import React, { useState } from 'react' +import { + SiDocker, + SiKubernetes, + SiNginx, + SiMongodb, + SiPostgresql, + SiRedis, + SiApachekafka, + SiMysql, +} from 'react-icons/si' +import { FaJava, FaWindows } from 'react-icons/fa' +import IconCardGrid from '../Card/IconCardGrid' + +interface MetricsQuickStartOverviewProps { + category?: 'all' | 'infrastructure' | 'databases' | 'web-servers' | 'messaging' | 'runtimes' +} + +export default function MetricsQuickStartOverview({ + category = 'all', +}: MetricsQuickStartOverviewProps) { + const sections = [ + { id: 'all', label: 'All' }, + { id: 'infrastructure', label: 'Infrastructure' }, + { id: 'databases', label: 'Databases' }, + { id: 'web-servers', label: 'Web Servers' }, + { id: 'messaging', label: 'Messaging' }, + { id: 'runtimes', label: 'Runtimes' }, + ] + + const [activeSection, setActiveSection] = useState(category === 'all' ? 'all' : category) + + const NavigationPills = () => ( +
+ {sections.map((section) => ( + + ))} +
+ ) + + const renderInfrastructureSection = () => ( +
+

Infrastructure

+ , + clickName: 'Docker Metrics Link', + }, + { + name: 'Kubernetes', + href: '/docs/opentelemetry-collection-agents/k8s/k8s-infra/overview', + icon: , + clickName: 'Kubernetes Metrics Link', + }, + ]} + sectionName="Infrastructure Metrics" + gridCols="grid-cols-2 sm:grid-cols-3 md:grid-cols-4" + /> +
+ ) + + const renderDatabasesSection = () => ( +
+

Databases

+ , + clickName: 'MongoDB Metrics Link', + }, + { + name: 'PostgreSQL', + href: '/docs/integrations/postgresql', + icon: , + clickName: 'PostgreSQL Metrics Link', + }, + { + name: 'Redis', + href: '/docs/integrations/redis', + icon: , + clickName: 'Redis Metrics Link', + }, + { + name: 'MySQL', + href: '/docs/metrics-management/mysql-metrics', + icon: , + clickName: 'MySQL Metrics Link', + }, + ]} + sectionName="Database Metrics" + gridCols="grid-cols-2 sm:grid-cols-3 md:grid-cols-4" + /> +
+ ) + + const renderWebServersSection = () => ( +
+

Web Servers

+ , + clickName: 'NGINX Metrics Link', + }, + ]} + sectionName="Web Server Metrics" + gridCols="grid-cols-2 sm:grid-cols-3 md:grid-cols-4" + /> +
+ ) + + const renderMessagingSection = () => ( +
+

Messaging

+ , + clickName: 'Kafka Metrics Link', + }, + ]} + sectionName="Messaging Metrics" + gridCols="grid-cols-2 sm:grid-cols-3 md:grid-cols-4" + /> +
+ ) + + const renderRuntimesSection = () => ( +
+

Runtimes

+ , + clickName: 'JVM Metrics Link', + }, + { + name: 'JMX', + href: '/docs/tutorial/jmx-metrics', + icon: , + clickName: 'JMX Metrics Link', + } + ]} + sectionName="Runtime Metrics" + gridCols="grid-cols-2 sm:grid-cols-3 md:grid-cols-4" + /> +
+ ) + + return ( +
+ + {(activeSection === 'all' || activeSection === 'infrastructure') && renderInfrastructureSection()} + {(activeSection === 'all' || activeSection === 'databases') && renderDatabasesSection()} + {(activeSection === 'all' || activeSection === 'web-servers') && renderWebServersSection()} + {(activeSection === 'all' || activeSection === 'messaging') && renderMessagingSection()} + {(activeSection === 'all' || activeSection === 'runtimes') && renderRuntimesSection()} +
+ ) +} diff --git a/constants/docsSideNav.ts b/constants/docsSideNav.ts index e4fbd75b2..179edb5a9 100644 --- a/constants/docsSideNav.ts +++ b/constants/docsSideNav.ts @@ -43,7 +43,6 @@ const docsSideNav = [ type: 'doc', route: '/docs/product-features/saved-view', label: 'Saved View', - // className: 'new-doc', // Add this if you want to add a new tag in sidebar }, { type: 'doc', @@ -145,7 +144,7 @@ const docsSideNav = [ type: 'doc', label: 'Linux', route: '/docs/install/linux', - className: 'new-doc', + }, ], }, @@ -519,6 +518,11 @@ const docsSideNav = [ route: '/docs/manage/administrator-guide/sso/user-guides/sso-google', label: 'Google Workspace - Single Sign-on Authentication', }, + { + type: 'doc', + route: '/docs/tutorial/setting-up-sso-saml-with-keycloak', + label: 'Setting Up SSO SAML 2.0 With Keycloak', + }, ], }, ], @@ -939,7 +943,7 @@ const docsSideNav = [ type: 'doc', route: '/docs/instrumentation/opentelemetry-quarkus', label: 'Quarkus', - className: 'new-doc', + }, { type: 'doc', @@ -1104,7 +1108,7 @@ const docsSideNav = [ // isExpanded: false, // label: 'Mobile Instrumentation', // route: '/docs/mobile-instrumentation', - // // className: 'new-doc', + // // // route: '', // // link: { // // type: 'doc', @@ -1382,7 +1386,7 @@ const docsSideNav = [ type: 'doc', route: '/docs/logs-management/send-logs/windows-events-log', label: 'Windows Event logs', - // className: 'new-doc', + }, { type: 'doc', @@ -1514,8 +1518,7 @@ const docsSideNav = [ { type: 'doc', route: '/docs/logs-management/long-term-storage', - label: 'Long Term Storage', - className: 'new-doc', + label: 'Long Term Storage' }, { type: 'category', @@ -1541,21 +1544,17 @@ const docsSideNav = [ label: 'Metrics', type: 'category', isExpanded: false, + route: '/docs/metrics-management/overview', items: [ { type: 'doc', - route: '/docs/metrics-management/metrics-explorer', - label: 'Metrics Explorer', - }, - { - type: 'doc', - route: '/docs/userguide/send-metrics-cloud', - label: 'Send Metrics to SigNoz Cloud', + route: '/docs/metrics-management/overview', + label: 'Overview', }, { type: 'doc', - route: '/docs/userguide/send-metrics', - label: 'Send Metrics (Self Hosted)', + route: '/docs/metrics-management/metrics-explorer', + label: 'Metrics Explorer', }, { type: 'doc', @@ -1573,32 +1572,88 @@ const docsSideNav = [ label: 'Cloud provider metric delay', }, { - type: 'doc', - route: '/docs/metrics-management/configure-custom-buckets', - label: 'Configure custom buckets for histograms', + type: 'doc', + route: '/docs/metrics-management/configure-custom-buckets', + label: 'Configure custom buckets for histograms', }, { label: 'Send Metrics', type: 'category', isExpanded: false, + route: '/docs/metrics-management/send-metrics', items: [ { type: 'doc', - className: 'new-doc', - route: '/docs/metrics-management/docker-container-metrics', - label: 'Docker container metrics', + route: '/docs/userguide/prometheus-metrics', + label: 'Prometheus Metrics', }, { type: 'doc', - className: 'new-doc', - route: '/docs/metrics-management/nginx-metrics', - label: 'NGINX metrics', + route: '/docs/userguide/otel-collector-metrics', + label: 'Otel Collector Receivers', }, { - type: 'doc', - className: 'new-doc', - route: '/docs/metrics-management/mysql-metrics', - label: 'MySQL metrics', + type: 'category', + label: 'Infrastructure', + isExpanded: false, + items: [ + { + type: 'doc', + route: '/docs/metrics-management/docker-container-metrics', + label: 'Docker container metrics', + }, + { + type: 'doc', + route: '/docs/tutorial/traefik-observability', + label: 'Traefik Observability', + }, + ], + }, + { + type: 'category', + label: 'Databases', + isExpanded: false, + items: [ + { + type: 'doc', + route: '/docs/tutorial/mongodb-metrics', + label: 'MongoDB Metrics', + }, + { + type: 'doc', + route: '/docs/metrics-management/mysql-metrics', + label: 'MySQL', + }, + ], + }, + { + type: 'category', + label: 'Web Servers', + isExpanded: false, + items: [ + { + type: 'doc', + route: '/docs/metrics-management/nginx-metrics', + label: 'NGINX', + }, + ], + }, + { + type: 'category', + label: 'Runtimes', + isExpanded: false, + items: [ + { + type: 'doc', + route: '/docs/tutorial/jvm-metrics', + label: 'JVM', + }, + { + type: 'doc', + route: '/docs/tutorial/jmx-metrics', + label: 'JMX Metrics', + }, + ], }, ], }, @@ -1625,7 +1680,6 @@ const docsSideNav = [ { label: 'Cost Meter', type: 'category', - className: 'new-doc', isExpanded: false, items: [ { @@ -1654,7 +1708,6 @@ const docsSideNav = [ { label: 'Manage', type: 'category', - className: 'new-doc', isExpanded: false, items: [ { @@ -2366,7 +2419,6 @@ const docsSideNav = [ label: 'Integrations', type: 'category', isExpanded: false, - className: 'new-doc', route: '/docs/integrations/integrations-list', items: [ { @@ -2377,19 +2429,19 @@ const docsSideNav = [ { type: 'doc', route: '/docs/integrations/aws/one-click-aws-integrations', - className: 'new-doc', + label: 'Overview', }, { type: 'doc', route: '/docs/integrations/aws/ecs', - className: 'new-doc', + label: 'ECS', }, { type: 'doc', route: '/docs/integrations/aws/s3-sync', - className: 'new-doc', + label: 'S3 Sync', }, ], @@ -2397,7 +2449,6 @@ const docsSideNav = [ { label: 'Temporal', type: 'category', - className: 'new-doc', isExpanded: false, items: [ { @@ -2539,7 +2590,7 @@ const docsSideNav = [ label: 'Celery', type: 'category', isExpanded: false, - //className: 'new-doc', + //route: '/docs/integrations/integrations-list', items: [ { @@ -2559,9 +2610,7 @@ const docsSideNav = [ { label: 'External API Monitoring', type: 'category', - className: 'new-doc', isExpanded: false, - // route: '', items: [ { type: 'doc', @@ -2578,9 +2627,7 @@ const docsSideNav = [ { label: 'Trace Funnels', type: 'category', - className: 'new-doc', isExpanded: false, - // route: '', items: [ { type: 'doc', @@ -2597,9 +2644,7 @@ const docsSideNav = [ { label: 'CICD Monitoring', type: 'category', - className: 'new-doc', isExpanded: false, - // route: '', items: [ { label: 'GitHub', @@ -2776,51 +2821,10 @@ const docsSideNav = [ }, ], }, - { - label: 'Tutorials', - type: 'category', - isExpanded: false, - route: '/docs/tutorials', - // link: { - // type: 'generated-index', - // title: 'Tutorials', - // description: - // 'SigNoz tutorials are step-by-step training exercises that guide you through monitoring your applications and infrastructure.', - // route: '/docs/tutorial/tutorials', - // }, - items: [ - { - type: 'doc', - route: '/docs/tutorial/jvm-metrics', - label: 'Spring Boot JVM Metrics', - }, - { - type: 'doc', - route: '/docs/tutorial/jmx-metrics', - label: 'JMX Metrics', - }, - { - type: 'doc', - route: '/docs/tutorial/mongodb-metrics', - label: 'MongoDB Metrics', - }, - { - type: 'doc', - route: '/docs/tutorial/setting-up-sso-saml-with-keycloak', - label: 'Setting Up SSO SAML 2.0 With Keycloak', - }, - { - type: 'doc', - route: '/docs/tutorial/traefik-observability', - label: 'Traefik Observability', - }, - ], - }, { label: 'AWS Monitoring', type: 'category', isExpanded: false, - // route: '', items: [ //'aws/getting-started', { @@ -2929,7 +2933,6 @@ const docsSideNav = [ }, { label: 'From Grafana Stack', - className: 'new-doc', type: 'category', isExpanded: false, route: '/docs/migration/migrate-from-grafana-to-signoz', @@ -2963,7 +2966,6 @@ const docsSideNav = [ }, { label: 'From ELK Stack', - className: 'new-doc', type: 'category', isExpanded: false, route: '/docs/migration/migrate-from-elk-to-signoz', @@ -2997,7 +2999,6 @@ const docsSideNav = [ }, { label: 'From New Relic', - className: 'new-doc', type: 'category', isExpanded: false, route: '/docs/migration/migrate-from-newrelic-to-signoz', @@ -3031,7 +3032,6 @@ const docsSideNav = [ }, { label: 'From Honeycomb', - className: 'new-doc', type: 'category', isExpanded: false, route: '/docs/migration/migrate-from-honeycomb-to-signoz', @@ -3055,7 +3055,6 @@ const docsSideNav = [ }, { label: 'From OpenTelemetry', - className: 'new-doc', type: 'category', isExpanded: false, route: '/docs/migration/migrate-from-opentelemetry-to-signoz', @@ -3083,7 +3082,6 @@ const docsSideNav = [ label: 'Azure Monitoring', type: 'category', isExpanded: false, - // className: 'new-doc', route: '/docs/azure-monitoring', items: [ { @@ -3240,7 +3238,6 @@ const docsSideNav = [ label: 'GCP Monitoring', type: 'category', isExpanded: false, - // className: 'new-doc', route: '/docs/gcp-monitoring', items: [ { diff --git a/data/docs/manage/administrator-guide/sso/overview.mdx b/data/docs/manage/administrator-guide/sso/overview.mdx index c1f28608b..57afe9ce2 100644 --- a/data/docs/manage/administrator-guide/sso/overview.mdx +++ b/data/docs/manage/administrator-guide/sso/overview.mdx @@ -1,8 +1,10 @@ --- -date: 2025-10-21 +date: 2025-11-20 id: sso-overview tags: [SigNoz Cloud, Self-Host] title: Single Sign on (SSO) - Overview +description: Overview of single sign-on (SSO) in SigNoz. +doc_type: explanation --- SigNoz supports single sign-on (SSO), allowing users to authenticate through an external identity provider (IdP) instead of maintaining SigNoz-specific passwords. @@ -41,3 +43,4 @@ Looking for step-by-step setup? See the user guides below: - [SAML with Okta](/docs/manage/administrator-guide/sso/user-guides/saml-okta) - [SAML with AWS IAM Identity Center (AWS SSO)](/docs/manage/administrator-guide/sso/user-guides/saml-awsso) - [SAML with JumpCloud](/docs/manage/administrator-guide/sso/user-guides/saml-jumpcloud) +- [SAML with Keycloak](/docs/manage/administrator-guide/sso/user-guides/saml-keycloak) \ No newline at end of file diff --git a/data/docs/metrics-management/overview.mdx b/data/docs/metrics-management/overview.mdx new file mode 100644 index 000000000..a029d20f9 --- /dev/null +++ b/data/docs/metrics-management/overview.mdx @@ -0,0 +1,39 @@ +--- +date: 2025-11-19 +title: Metrics Overview +id: metrics-overview +tags: [SigNoz Cloud, Self-Host] +description: Overview of metrics management capabilities in SigNoz. +doc_type: explanation +--- + +Metrics provide numerical data over time to help you monitor application and infrastructure behavior. SigNoz enables you to collect, query, and visualize metrics from diverse sources, including OpenTelemetry SDKs, the OTel Collector, and Prometheus. + +Use this section to find guides for sending data, exploring metrics, and setting up dashboards and alerts. + +## Key capabilities + +- **Flexible ingestion**: Collect metrics from applications, infrastructure, and existing Prometheus setups. SigNoz also derives APM metrics from traces automatically. +- **Interactive exploration**: Use the [Metrics Explorer](https://signoz.io/docs/metrics-management/metrics-explorer/) to query and visualize data with a visual builder or advanced query languages like PromQL and ClickHouse SQL. +- **Dashboards and Alerts**: Build custom [dashboards](https://signoz.io/docs/userguide/manage-dashboards/) or use pre-built templates. Configure [alerts](https://signoz.io/docs/alerts-management/metrics-based-alerts/) to notify your team of anomalies. +- **Unified context**: Correlate metrics with traces and logs for faster root cause analysis. + +## Get started + +- [Send metrics to SigNoz](https://signoz.io/docs/userguide/send-metrics-cloud/) – Start ingesting metrics. +- [APM metrics from traces](https://signoz.io/docs/traces-management/guides/apm-metrics/) – Leverage automatic metrics from traces. + +## Work with metrics + +- [Use Metrics Explorer](https://signoz.io/docs/metrics-management/metrics-explorer/) – Query and visualize your data. +- [Manage dashboards](https://signoz.io/docs/userguide/manage-dashboards/) – Create and organize dashboards. +- [Configure alerts](https://signoz.io/docs/alerts-management/metrics-based-alerts/) – Set up metric-based alerts. +- [Infrastructure monitoring](https://signoz.io/docs/infrastructure-monitoring/overview/) – Monitor hosts and Kubernetes clusters. + +## Concepts and reference + +- [Metric types and aggregations](https://signoz.io/docs/metrics-management/types-and-aggregation/) – Understand Counters, Gauges, and Histograms. +- [Data storage](https://signoz.io/docs/metrics-management/data-storage/) – Learn how metrics are stored. +- [PromQL guide](https://signoz.io/docs/userguide/write-a-prom-query-with-new-format/) – Write Prometheus-style queries. +- [ClickHouse SQL guide](https://signoz.io/docs/userguide/write-a-metrics-clickhouse-query/) – Use SQL for advanced analytics. +- [Metrics Query API](http://localhost:3000/docs/metrics-management/query-range-api/) – API reference for querying SigNoz metrics. diff --git a/data/docs/metrics-management/query-range-api.mdx b/data/docs/metrics-management/query-range-api.mdx index 1adecd5b8..d0d358763 100644 --- a/data/docs/metrics-management/query-range-api.mdx +++ b/data/docs/metrics-management/query-range-api.mdx @@ -1,8 +1,9 @@ --- -date: 2025-03-22 -title: Query Range API -tags : [SigNoz Cloud, Self-Host] -id: query-range-api +date: 2025-11-20 +title: Metrics Query API +tags: [SigNoz Cloud, Self-Host] +description: API reference for querying SigNoz metrics. +doc_type: reference --- ## Overview diff --git a/data/docs/metrics-management/send-metrics.mdx b/data/docs/metrics-management/send-metrics.mdx new file mode 100644 index 000000000..df0427be1 --- /dev/null +++ b/data/docs/metrics-management/send-metrics.mdx @@ -0,0 +1,28 @@ +--- +date: 2025-11-19 +title: Send Metrics +id: send-metrics +description: Send metrics to SigNoz from applications, infrastructure, and third-party services. +tags: [SigNoz Cloud, Self-Host] +doc_type: explanation +--- + +SigNoz supports ingesting metrics from a wide range of sources, including OpenTelemetry SDKs, the OpenTelemetry Collector, and Prometheus. + +## Quick Start + +Choose your technology stack to get started with sending metrics to SigNoz: + + + +## Ways to send metrics + +- **OpenTelemetry SDKs**: Instrument your application code to capture custom metrics. +- **OpenTelemetry Collector**: Collect infrastructure metrics (host, K8s, Docker) and receive metrics from other agents. [Learn more](/docs/userguide/otel-collector-metrics). +- **Prometheus**: Send existing Prometheus metrics to SigNoz via remote write or by scraping exporters. [Learn more](/docs/userguide/prometheus-metrics). + +## Next steps + +- [Explore Metrics](/docs/metrics-management/metrics-explorer) +- [Create Dashboards](/docs/userguide/manage-dashboards) +- [Set up Alerts](/docs/alerts-management/metrics-based-alerts) diff --git a/data/docs/tutorials.mdx b/data/docs/tutorials.mdx deleted file mode 100644 index a55daf675..000000000 --- a/data/docs/tutorials.mdx +++ /dev/null @@ -1,83 +0,0 @@ ---- -date: 2024-06-06 -id: tutorials -title: Tutorials ---- - -SigNoz tutorials are step-by-step training exercises that guide you through monitoring your applications and infrastructure. - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/data/docs/userguide/otel-collector-metrics.mdx b/data/docs/userguide/otel-collector-metrics.mdx new file mode 100644 index 000000000..4b9468d1e --- /dev/null +++ b/data/docs/userguide/otel-collector-metrics.mdx @@ -0,0 +1,91 @@ +--- +date: 2025-11-19 +id: otel-collector-metrics +title: Otel Collector Receivers +description: Send metrics to SigNoz using any OpenTelemetry Collector receiver. +tags: [SigNoz Cloud, Self-Host] +doc_type: howto +--- + +import GetHelp from '@/components/shared/get-help.md' + +## Overview + +SigNoz supports all receivers listed in the [opentelemetry-collector-contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver) repository. You can check the [OpenTelemetry Registry](https://opentelemetry.io/ecosystem/registry/?component=receiver) to find available receivers. You can configure any of these receivers to collect metrics from various services and infrastructure components. + +## Prerequisites + +- [SigNoz Otel Collector installed](/docs/opentelemetry-collection-agents/get-started/) +- Access to the `otel-collector-config.yaml` file. + +## Steps + +To enable a specific receiver, you need to configure it in the `receivers` section and then add it to the `service` pipeline. + +### Step 1: Configure the Receiver + +Open `otel-collector-config.yaml` and add the receiver configuration. For example, to enable the `rabbitmq` receiver: + +```yaml +receivers: + rabbitmq: + endpoint: http://localhost:15672 + username: + password: + collection_interval: 30s +``` + +Refer to the [OpenTelemetry Collector Contrib Receivers](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver) for specific configuration options for your desired receiver. + +### Step 2: Enable the Receiver in Pipeline + +Add the receiver name to the `receivers` list in the `metrics` pipeline under `service`. + +```yaml {4} +service: + pipelines: + metrics: + receivers: [otlp, rabbitmq] + processors: [batch] + exporters: [otlp] +``` + +### Step 3: Restart the Collector + +Depending on your setup, restart the appropriate service to apply changes. + + + + +If you are using SigNoz Cloud or running a standalone OpenTelemetry Collector agent, you only need to restart the collector agent. Do **not** restart SigNoz. + +```bash +# Example for systemd service +sudo systemctl restart otel-collector + +# Example for Docker +docker restart +``` + + + + +If you are running the default SigNoz Self-Hosted bundle (Docker Standalone), the collector is part of the stack. You can restart the specific container or the stack. + +```bash +# Go to your signoz/deploy/docker directory +docker compose -f docker-compose.yaml restart otel-collector +``` + + + + +## Validate + +1. Go to the **[Metrics Explorer](/docs/metrics-management/metrics-explorer/)** in SigNoz. +2. Search for metrics starting with the receiver prefix (e.g., `rabbitmq_` for RabbitMQ receiver). +3. Verify that data is appearing in the query results. + +## Get Help + + diff --git a/data/docs/userguide/prometheus-metrics.mdx b/data/docs/userguide/prometheus-metrics.mdx new file mode 100644 index 000000000..2c8588681 --- /dev/null +++ b/data/docs/userguide/prometheus-metrics.mdx @@ -0,0 +1,140 @@ +--- +date: 2025-11-19 +id: prometheus-metrics +title: Prometheus Metrics +description: Send metrics to SigNoz using the Prometheus receiver in OpenTelemetry Collector. +tags: [SigNoz Cloud, Self-Host] +doc_type: howto +--- + +import GetHelp from '@/components/shared/get-help.md' + +## Overview + +SigNoz supports all exporters listed on the [Prometheus Exporters and Integrations](https://prometheus.io/docs/instrumenting/exporters/) page. To ingest Prometheus metrics, we use the [Prometheus Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/prometheusreceiver). If you have a running Prometheus instance or expose metrics in Prometheus format, you can scrape them into SigNoz by configuring the Prometheus receiver in your OpenTelemetry Collector. + +## Prerequisites + +- [SigNoz Otel Collector installed](/docs/opentelemetry-collection-agents/get-started/) +- Access to the `otel-collector-config.yaml` file (location varies by installation method). +- A target exposing Prometheus metrics. + +## Steps + +### Step 1: Configure the Prometheus Receiver + +To enable the Prometheus receiver, you must edit the `receivers` section of your `otel-collector-config.yaml` file. + +1. Open your `otel-collector-config.yaml` file in a text editor. + +2. You can enable the receiver by either creating a new job or adding a target to an existing job. + + **Option A: Create a new job** + + Add a new `job_name` under `scrape_configs`. This is useful for separating different sources of metrics. + + ```yaml {10-13} + receivers: + prometheus: + config: + scrape_configs: + - job_name: "otel-collector" + scrape_interval: 30s + static_configs: + - targets: ["otel-collector:8889"] + - job_name: "my-new-job" + scrape_interval: 30s + static_configs: + - targets: ["localhost:8080"] + ``` + + **Option B: Add a target to an existing job** + + Add your target to the `targets` list of an existing job. + + ```yaml {9} + receivers: + prometheus: + config: + scrape_configs: + - job_name: "otel-collector" + scrape_interval: 30s + static_configs: + - targets: ["otel-collector:8889", "localhost:8080"] + ``` + + + **Scraping from the host machine** + + If your Prometheus instance is running on the host machine and you are running the OpenTelemetry Collector in Docker (including the default SigNoz Self-Hosted setup): + - Linux: Replace `localhost` with `172.17.0.1` + - macOS: Replace `localhost` with `host.docker.internal` + + For SigNoz Cloud users running the collector as a binary on the host, `localhost` will work correctly. + + + Note that jobs are scraped in parallel, while targets within a job are scraped serially. + +### Step 2: Enable the Prometheus Receiver + +Once you have configured the receiver, you need to enable it in the metrics pipeline. + +1. In your `otel-collector-config.yaml` file, locate the `service` section. +2. Under `pipelines` -> `metrics` -> `receivers`, add `prometheus`. + + ```yaml {4} + service: + pipelines: + metrics: + receivers: [otlp, prometheus] + processors: [batch] + exporters: [otlp] + ``` + +### Step 3: Restart the Collector + +Depending on your setup, restart the appropriate service to apply changes. + + + + +If you are using SigNoz Cloud or running a standalone OpenTelemetry Collector agent, you only need to restart the collector agent. + +```bash +# Example for systemd service +sudo systemctl restart otel-collector + +# Example for Docker +docker restart +``` + + + + +If you are running the default SigNoz Self-Hosted bundle (Docker Standalone), the collector is part of the stack. You can restart the specific container or the stack. + +```bash +# Go to your signoz/deploy/docker directory +docker compose -f docker-compose.yaml restart otel-collector +``` + + + + +## Validate + +To verify that metrics are being received: +1. Go to the **[Metrics Explorer](/docs/metrics-management/metrics-explorer/)** in SigNoz. +2. Search for a metric you expect to see (e.g., `up` or a specific metric from your application). +3. You can also verify data arrival in the **Dashboards** section by creating a panel with your metric. + +## Troubleshooting + +If you don't see metrics: +- Check the OpenTelemetry Collector logs for errors. +- Verify network connectivity between the Collector and the target. +- Ensure the scrape interval is appropriate. + +## Get Help + + diff --git a/data/docs/userguide/send-metrics-cloud.mdx b/data/docs/userguide/send-metrics-cloud.mdx deleted file mode 100644 index 2e159f620..000000000 --- a/data/docs/userguide/send-metrics-cloud.mdx +++ /dev/null @@ -1,284 +0,0 @@ ---- -date: 2024-06-06 -id: send-metrics-cloud -tags : [SigNoz Cloud] -title: Send Metrics to SigNoz Cloud ---- - -import GetHelp from '@/components/shared/get-help.md' -import SaveChangesRestart from '@/components/shared/save-changes-and-restart.md' - -## Methods to Send Metrics -There are two primary ways to send metrics to SigNoz: - -1. From your application -2. From OpenTelemetry Collector - -This document will cover sending metrics from the OpenTelemetry Collector. - -## Prerequisites -Before you begin, ensure you have the following: - -- A running instance of SigNoz Cloud. -- OpenTelemetry Collector installed. -- Appropriate access and permissions. - -In this document, we will cover how to send metrics from OpenTelemetry Collector. The Collector is a swiss-army knife that can collect metrics from various sources and send them to SigNoz. - -- [How does OpenTelemetry Collector collect data](#how-does-opentelemetry-collector-collect-data) -- [Enable a Specific Metric Receiver](#enable-a-specific-metric-receiver) -- [Enable a Prometheus Receiver](#enable-a-prometheus-receiver) -- [Find Metrics available in SigNoz](#find-metrics-available-in-signoz) - - [Metrics from Hostmetrics receiver](#metrics-from-hostmetrics-receiver) -- [Related Videos](#related-videos) -- [Get Help](#get-help) - -## How does OpenTelemetry Collector collect data? - -Data collection in OpenTelemetry Collector is facilitated through receivers. Receivers are configured via YAML under the top-level `receivers` section. To ensure a valid configuration, at least one receiver must be enabled. - -Below is an example of an **`otlp`** receiver: - -```yaml -receivers: - otlp: - protocols: - grpc: - http: -``` - -The OTLP receiver accepts data through gRPC or HTTP in the OTLP format. - -Here’s a sample configuration for an otlp receiver: - -```yaml -receivers: - otlp: - protocols: - http: - endpoint: "localhost:4318" - cors: - allowed_origins: - - http://test.com - # Origins can have wildcards with *, use * by itself to match any origin. - - https://*.example.com - allowed_headers: - - Example-Header - max_age: 7200 -``` - -To see more configuration options for otlp receiver, you can checkout [this link](https://github.com/open-telemetry/opentelemetry-collector/blob/main/receiver/otlpreceiver/README.md). - -Once a receiver is configured, it needs to be **enabled** to start the data flow. This involves setting up **pipelines** within a **`service`**. A **pipeline** acts as a streamlined pathway for data, outlining how it should be processed and where it should go. A pipeline comprises of the following: - -- **Receivers:** These are entry points for data into the OpenTelemetry Collector, responsible for collecting data from various sources and feeding it into the pipeline. -- **Processors:** Metrics data is processed using the **`batch`** processor. This processor batches metrics before exporting them, optimizing the data flow. -- **Exporters:** Metrics processed through this pipeline are exported to the OTLP endpoint mentioned in the configuration file. - -Below is an example pipeline configuration: - -```yaml -service: - pipelines: - metrics: - receivers: [otlp, httpcheck] - processors: [batch] - exporters: [otlp] -``` - -Here’s a breakdown of the above metrics pipeline: - -- **Receivers:** This pipeline is configured to receive metrics data from two sources: OTLP and HTTP Check. The **`otlp`** receiver collects metrics using both gRPC and HTTP protocols, while the **`httpcheck`** receiver gathers metrics from the HTTP endpoint. -- **Processors:** Metrics data is processed using the **`batch`** processor. This processor likely batches metrics before exporting them, optimizing the data flow. -- **Exporters:** Metrics processed through this pipeline are exported to the OTLP destination. The **`otlp`** exporter sends data to an endpoint specified in the configuration. - -## Enable a Specific Metric Receiver - -SigNoz supports all the receivers that are listed in the [opentelemetry-collector-contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver) GitHub repository. To configure a new metric receiver, you must edit the `receivers` and `service::pipelines` sections of the `otel-collector-config.yaml` file. The following example shows the default configuration in which the `hostmetrics` receiver is enabled: - -```yaml {8-20,52} -receivers: - otlp: - protocols: - grpc: - endpoint: localhost:4317 - http: - endpoint: localhost:4318 - hostmetrics: - collection_interval: 30s - scrapers: - cpu: {} - disk: {} - load: {} - filesystem: {} - memory: {} - network: {} - paging: {} - process: - mute_process_name_error: true - mute_process_exe_error: true - mute_process_io_error: true - processes: {} -processors: - batch: - send_batch_size: 1000 - timeout: 10s - # Ref: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/README.md - resourcedetection: - detectors: [env, system, ec2] # include ec2 for AWS, gcp for GCP and azure for Azure. - # Using OTEL_RESOURCE_ATTRIBUTES envvar, env detector adds custom labels. - timeout: 2s - override: false - system: - hostname_sources: [os] # alternatively, use [dns,os] for setting FQDN as host.name and os as fallback -exporters: - otlp: - endpoint: "ingest.{region}.signoz.cloud:443" # replace {region} with your region - tls: - insecure: false - headers: - "signoz-ingestion-key": "" - debug: - verbosity: detailed -service: - telemetry: - metrics: - address: localhost:8888 - pipelines: - metrics: - receivers: [otlp] - processors: [batch] - exporters: [otlp] - metrics/hostmetrics: - receivers: [hostmetrics] - processors: [resourcedetection, batch] - exporters: [otlp] -``` - -To enable a new OpenTelemetry receiver, follow the steps below: - -1. Open the `otel-collector-config.yaml` file in a plain-text editor. -2. Configure your receivers. The following example shows how you can enable a `rabbitmq` receiver: - -```yaml {21-25,53} -receivers: - otlp: - protocols: - grpc: - endpoint: localhost:4317 - http: - endpoint: localhost:4318 - hostmetrics: - collection_interval: 30s - scrapers: - cpu: {} - disk: {} - load: {} - filesystem: {} - memory: {} - network: {} - paging: {} - process: - mute_process_name_error: true - mute_process_exe_error: true - mute_process_io_error: true - processes: {} - rabbitmq: - endpoint: http://localhost:15672 - username: - password: - collection_interval: 30s -processors: - batch: - send_batch_size: 1000 - timeout: 10s - # Ref: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/README.md - resourcedetection: - detectors: [env, system, ec2] # include ec2 for AWS, gcp for GCP and azure for Azure. - # Using OTEL_RESOURCE_ATTRIBUTES envvar, env detector adds custom labels. - timeout: 2s - override: false - system: - hostname_sources: [os] # alternatively, use [dns,os] for setting FQDN as host.name and os as fallback -exporters: - otlp: - endpoint: "ingest.{region}.signoz.cloud:443" # replace {region} with your region - tls: - insecure: false - headers: - "signoz-ingestion-key": "" - debug: - verbosity: detailed -service: - telemetry: - metrics: - address: localhost:8888 - pipelines: - metrics: - receivers: [otlp, rabbitmq] - processors: [batch] - exporters: [otlp] - metrics/hostmetrics: - receivers: [hostmetrics] - processors: [resourcedetection, batch] - exporters: [otlp] -``` - For details about configuring OpenTelemetry receivers, see the [README](https://github.com/open-telemetry/opentelemetry-collector/blob/main/receiver/README.md) page of the `opentelemetry-collector` GitHub repository. - -## Enable a Prometheus Receiver - -SigNoz supports all the exporters that are listed on the [Exporters and Integrations](https://prometheus.io/docs/instrumenting/exporters/) page of the Prometheus documentation. If you have a running Prometheus instance, and you expose metrics in Prometheus, then you can scrape them in SigNoz by configuring Prometheus receivers in the `receivers::prometheus::config::scrape_configs` section of the `otel-collector-config.yaml` file. - -To enable a Prometheus receiver, follow the steps below: -1. Open the `otel-collector-config.yaml` file in a plain-text editor. -2. Enable a new Prometheus receiver. Depending on your use case, there are two ways in which you can enable a new Prometheus exporter: - - **By creating a new job**: The following example shows how you can enable a Prometheus receiver by creating a new job named `my-new-job`: - ```yaml {10-13} - ... - # Data sources: metrics - prometheus: - config: - scrape_configs: - - job_name: "otel-collector" - scrape_interval: 30s - static_configs: - - targets: ["otel-collector:8889"] - - job_name: "my-new-job" - scrape_interval: 30s - static_configs: - - targets: ["localhost:8080"] - ... - # This file was truncated for brevity. - ``` - - **By adding a new target to an existing job**: The following example shows the default `otel-collector` job to which a new target (`localhost:8080`) was added: - ```yaml {9} - ... - # Data sources: metrics - prometheus: - config: - scrape_configs: - - job_name: "otel-collector" - scrape_interval: 30s - static_configs: - - targets: ["otel-collector:8889", "localhost:8080"] - ... - # This file was truncated for brevity. - ``` - Note that all the jobs are scraped in parallel, and all targets inside a job are scraped serially. For more details about configuring jobs and targets, see the following sections of the Prometheus documentation: - - [``](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config) - - [Jobs and Instances](https://prometheus.io/docs/concepts/jobs_instances/) - - If you'd like to learn more about how to monitor Prometheus Metrics with OpenTelemetry Collector, - refer to this [blog](https://signoz.io/blog/opentelemetry-collector-prometheus-receiver/#how-does-opentelemetry-collector-collect-data). - -## Find Metrics available in SigNoz - -You can use this metrics to plot in the [Dashboard](/docs/userguide/manage-dashboards) section. - -## Related Videos - -- [How to view Prometheus Metrics in SigNoz](https://youtu.be/QGJYNYzfM9o) - -## Get Help - - \ No newline at end of file diff --git a/data/docs/userguide/send-metrics.mdx b/data/docs/userguide/send-metrics.mdx deleted file mode 100644 index 934412a17..000000000 --- a/data/docs/userguide/send-metrics.mdx +++ /dev/null @@ -1,233 +0,0 @@ ---- -date: 2024-06-06 -id: send-metrics -tags : [Self-Host] -title: Send Metrics to SigNoz (Self Hosted) -description: Learn how to send metrics to self-hosted SigNoz using OpenTelemetry. Follow detailed steps to enable and configure metric receivers. ---- - -import GetHelp from '@/components/shared/get-help.md' -import SaveChangesRestart from '@/components/shared/save-changes-and-restart.md' - - -By default, when you install SigNoz, only the [Hostmetric receiver][1] -is enabled. Before you can query other metrics, you must first enable -additional receivers in SigNoz. - -There are two ways in which you can send metrics to SigNoz using OpenTelemetry: -- [Enable a Specific Metric Receiver](#enable-a-specific-metric-receiver) -- [Enable a Prometheus Receiver](#enable-a-prometheus-receiver) -- [Find Metrics available in SigNoz](#find-metrics-available-in-signoz) - - [Metrics from Hostmetrics receiver](#metrics-from-hostmetrics-receiver) -- [Related Videos](#related-videos) -- [Get Help](#get-help) - -Depending on your choice, use one of the sections below. - -## Enable a Specific Metric Receiver - -SigNoz supports all the receivers that are listed in the [opentelemetry-collector-contrib][2] -GitHub repository. To configure a new metric receiver, you must edit the `receivers` -section of the `deploy/docker/otel-collector-config.yaml` file. -The following example shows the default configuration in which the `hostmetrics` -receiver is enabled: - -```yaml {14-22} -receivers: - otlp/spanmetrics: - protocols: - grpc: - endpoint: "localhost:12345" - otlp: - protocols: - grpc: - http: - jaeger: - protocols: - grpc: - thrift_http: - hostmetrics: - collection_interval: 30s - scrapers: - cpu: - load: - memory: - disk: - filesystem: - network: -processors: - batch: - send_batch_size: 1000 - timeout: 10s -# This file was truncated for brevity -``` - -To enable a new OpenTelemetry receiver, follow the steps below: - -1. Move into the directory in which you installed SigNoz, and open the - `deploy/docker/otel-collector-config.yaml` file in a - plain-text editor. -2. Configure your receivers. The following example shows how you can - enable a receiver named `examplereceiver`: - ```yaml {23,24} - receivers: - otlp/spanmetrics: - protocols: - grpc: - endpoint: "localhost:12345" - otlp: - protocols: - grpc: - http: - jaeger: - protocols: - grpc: - thrift_http: - hostmetrics: - collection_interval: 30s - scrapers: - cpu: - load: - memory: - disk: - filesystem: - network: - examplereceiver: - endpoint: 1.2.3.4:8080 - processors: - batch: - send_batch_size: 1000 - timeout: 10s - # This file was truncated for brevity. - ``` - For details about configuring OpenTelemetry receivers, see the [README][3] - page of the `opentelemetry-collector` GitHub repository. -3. - -## Enable a Prometheus Receiver - -SigNoz supports all the exporters that are listed on the -[Exporters and Integrations](https://prometheus.io/docs/instrumenting/exporters/) -page of the Prometheus documentation. If you have a running Prometheus instance, -and you expose metrics in Prometheus, then you can scrape them in SigNoz by -configuring Prometheus receivers in the `receivers.prometheus.config.scrape_configs` -section of the `deploy/docker/otel-collector-config.yaml` file. - -To enable a Prometheus receiver, follow the steps below: -1. Open the `deploy/docker/otel-collector-config.yaml` - file in a plain-text editor. -2. Enable a new Prometheus receiver. Depending on your use case, there - are two ways in which you can enable a new Prometheus exporter: - - **By creating a new job**: The following example shows how you can - enable a Prometheus receiver by creating a new job named `my-new-job`: - ```yaml {15-18} - receivers: - otlp: - protocols: - grpc: - http: - - # Data sources: metrics - prometheus: - config: - scrape_configs: - - job_name: "otel-collector" - scrape_interval: 30s - static_configs: - - targets: ["otel-collector:8889"] - - job_name: "my-new-job" - scrape_interval: 30s - static_configs: - - targets: ["localhost:8080"] - processors: - batch: - send_batch_size: 1000 - timeout: 10s - # This file was truncated for brevity. - ``` - - **By adding a new target to an existing job**: The following example shows the - default `otel-collector` job to which a new target (`localhost:8080`) was added: - ```yaml {14} - receivers: - otlp: - protocols: - grpc: - http: - - # Data sources: metrics - prometheus: - config: - scrape_configs: - - job_name: "otel-collector" - scrape_interval: 30s - static_configs: - - targets: ["otel-collector:8889", "localhost:8080"] - processors: - batch: - send_batch_size: 1000 - timeout: 10s - # This file was truncated for brevity. - ``` - - - - To correctly scrape from prometheus instance running on the host machine, replace - `localhost:8080` with `172.17.0.1:8080` for Linux and `host.docker.internal:8080` - for MacOS. - - - - Note that all the jobs are scraped in parallel, and all targets inside a job are - scraped serially. For more details about configuring jobs and targets, see the - following sections of the Prometheus documentation: - - [`][5] - - [Jobs and Instances][6] -3. - - -You can use this metrics to plot in the [Dashboard][8] section. - -### Metrics from Hostmetrics receiver - -Metrics which are available if hostmetrics is enabled. This is enabled in -SigNoz default installation. - -| Metrics | Description | -| -------------------------------------- | ----------- | -| `system_filesystem_usage_total` | | -| `system_network_dropped_total` | | -| `system_cpu_time_total` | | -| `system_disk_merged_total` | | -| `system_disk_io_time_total` | | -| `system_disk_operations_total` | | -| `system_network_errors_total` | | -| `system_network_io_total` | | -| `system_disk_weighted_io_time_total` | | -| `system_network_packets_total` | | -| `system_disk_operation_time_total` | | -| `system_cpu_load_average_5m` | | -| `system_memory_usage_total` | | -| `system_disk_pending_operations_total` | | -| `system_disk_io_total` | | -| `system_cpu_load_average_15m` | | -| `system_cpu_load_average_1m` | | - -## Related Videos - -- [How to view Prometheus Metrics in SigNoz][9] - -## Get Help - - - ---- - -[1]: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/README.md -[2]: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver -[3]: https://github.com/open-telemetry/opentelemetry-collector/blob/main/receiver/README.md -[4]: https://prometheus.io/docs/instrumenting/exporters/ -[5]: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config -[6]: https://prometheus.io/docs/concepts/jobs_instances/ -[7]: https://clickhouse.com/docs/en/getting-started/install/ -[8]: /docs/userguide/manage-dashboards -[9]: https://youtu.be/QGJYNYzfM9o \ No newline at end of file diff --git a/jsconfig.json b/jsconfig.json index 3e415566f..758d5dcc3 100644 --- a/jsconfig.json +++ b/jsconfig.json @@ -1,5 +1,6 @@ { "compilerOptions": { + "jsx": "react", "baseUrl": ".", "paths": { "@/components/*": ["components/*"], diff --git a/next.config.js b/next.config.js index 5dfe71cf2..c86204e89 100644 --- a/next.config.js +++ b/next.config.js @@ -877,6 +877,21 @@ module.exports = () => { destination: '/docs/setup/docker/troubleshooting/faq', permanent: true, }, + { + source: '/docs/userguide/send-metrics-cloud/', + destination: '/docs/userguide/otel-collector-metrics/', + permanent: true, + }, + { + source: '/docs/userguide/send-metrics/', + destination: '/docs/userguide/otel-collector-metrics/', + permanent: true, + }, + { + source: '/docs/tutorials/', + destination: '/docs/install/', + permanent: true, + } ] }, webpack: (config, options) => {