DOCSEARCHbyAlgolia
Submit Docs

SigNoz Observability Platform

repository·main·Indexed 12 days ago

https://github.com/SigNoz/signoz

An open-source, OpenTelemetry-native observability platform providing a unified interface for logs, metrics, traces, alerts, and dashboards. Built on a high-performance columnar database, it replaces fragmented monitoring stacks. The platform is deployed via Foundry and includes a Vite-based frontend with a robust permission-based authorization (AuthZ) system and error boundary handling.

Tokens
122.3K
Snippets
370
Records
515
Agent score
97%

What's inside SigNoz

  1. Overview of SigNoz Observability Platform

    main
    SigNoz is an open-source observability platform built on OpenTelemetry. It provides a unified platform for logs, metrics, traces, alerts, and dashboards, serving as an alternative to fragmented monitoring stacks or commercial tools like DataDog and NewRelic. It is designed for high-cardinality observability workloads using a columnar database.

  2. Integrate Messaging Queues with SigNoz

    main

    SigNoz supports integration with messaging queues to collect observability data. The integration package provides the api and translation logic required to process data from supported queues.

    Currently, only Kafka is supported.

    To achieve full observability, you must configure two distinct data flows:

    1. Trace Collection: Configure your Kafka Producers and Consumers to send traces to SigNoz.
    2. Metrics Collection: Configure SigNoz to collect metrics from Kafka Brokers, Producers, and Consumers.

  3. Monitor applications and infrastructure with SigNoz

    main

    SigNoz provides a unified observability platform by connecting multiple signals in one place. Key monitoring capabilities include:

    • APM (Application Performance Monitoring): Monitor service latency, error rates, throughput, Apdex, key endpoints, database calls, and external calls.
    • Log Management: Ingest, search, aggregate, and correlate logs with traces and metrics using a visual query builder.
    • Metrics and Dashboards: Create dashboards for application, infrastructure, and custom metrics using Query Builder, PromQL, or ClickHouse SQL.
    • Infrastructure Monitoring: Monitor Kubernetes clusters, pods, nodes, workloads, and host-level metrics (CPU, memory, disk, network, logs, and traces).
    • LLM and AI Observability: Track LLM applications, RAG pipelines, prompts, tool calls, tokens, latency, and costs.
    • Distributed Tracing: Follow requests across services using flamegraphs, waterfalls, span events, and trace analysis.
    • Trace Funnels: Create funnels from traces to identify drops in request flows or systemic workflow failures.
    • Agent-native and MCP: Use the SigNoz MCP (Model Context Protocol) server to provide telemetry to programming agents. (Note: 'Noz' AI features are currently available only on SigNoz Cloud).

  4. Monitor application and infrastructure telemetry with SigNoz

    main

    SigNoz is an OpenTelemetry-native observability platform that correlates multiple signals in one place. You can monitor:

    • APM (Application Performance Monitoring): Track service latency, error rates, throughput, Apdex, top endpoints, database calls, and external calls.
    • Log Management: Ingest, search, aggregate, and correlate logs with traces and metrics using a visual query builder.
    • Metrics and Dashboards: Build dashboards for application, infrastructure, and custom metrics using Query Builder, PromQL, or ClickHouse SQL.
    • Infrastructure Monitoring: Monitor Kubernetes clusters (pods, nodes, workloads) and host-level metrics (CPU, memory, disk, network).
    • LLM and AI Observability: Trace LLM applications, RAG pipelines, prompts, tool calls, tokens, latency, and costs.
    • Distributed Tracing: Follow requests across services using flamegraphs, waterfalls, span events, and trace analytics.
    • Trace Funnels: Analyze request-flow drop-offs and failed transitions to understand systemic workflow issues.
    • Exceptions and Alerts: Monitor application exceptions and configure alerts based on telemetry data.

  5. Monitor various observability signals with SigNoz

    main

    SigNoz integrates multiple telemetry signals into a single platform:

    • APM (Application Performance Monitoring): Monitor service latency, error rates, throughput, Apdex, core endpoints, database calls, and external calls.
    • Log Management: Ingest, search, and aggregate logs. Use the visual query builder to correlate logs with traces and metrics.
    • Metrics and Dashboards: Build dashboards for applications and infrastructure using Query Builder, PromQL, or ClickHouse SQL.
    • Infrastructure Monitoring: Monitor Kubernetes clusters (Pods, Nodes, Workloads) and host-level metrics (CPU, Memory, Disk, Network).
    • LLM and AI Observability: Trace LLM applications and RAG pipelines, including prompts, tool calls, tokens, latency, and costs.
    • Distributed Tracing: Track requests across services using flame graphs, waterfall views, Span events, and trace analysis.
    • Trace Funnels: Create funnels based on traces to identify drop-off points and failed conversions in request flows.
    • Agent-native Observability: Use the SigNoz MCP server to bring telemetry data into programming agents, or use Noz (Cloud only) to investigate incidents and build dashboards via AI.

  6. Understand the SigNoz Frontend project structure

    main

    The frontend codebase is organized into the following directory structure:

    • src/api/: Contains API clients and React Query hooks.
    • src/components/: Shared UI components.
    • src/container/: Page-level containers.
    • src/hooks/: Custom React hooks.
    • src/pages/: Route-level pages.
    • src/providers/: React context providers.
    • src/store/: Redux store management.
    • src/types/: TypeScript definitions.

  7. Understand the AuthZ permission system

    main

    SigNoz uses a permission-based authorization (AuthZ) system for the frontend to control access to specific UI elements and features.

    Important Note on Backend Enforcement: The backend does not yet enforce all permissions. If you are creating a new page or content that represents a resource not currently listed in the supported resources, you should skip the AuthZ implementation for now, as the backend will not validate these permissions.

  8. Use SigNoz MCP Server and Agent-Native Observability

    main

    SigNoz provides agent-native observability features:

    • SigNoz MCP Server: Allows you to bring telemetry data directly into coding agents via the Model Context Protocol (MCP).
    • Noz in SigNoz: An AI-driven interface (available in SigNoz Cloud) used to investigate incidents, improve alerts, and create dashboards with production context.

    For more details, refer to the SigNoz MCP Server documentation or Agent Skills documentation.

  9. Core Rules for Authorization UI

    main

    When structuring pages for the permission system, follow these rules to ensure a consistent user experience:

    1. Routes are always reachable: A page route should always render first. Individual components or sections within the page are gated, not the route itself.
    2. update dependency: An update action requires both read and update permissions. If a user cannot read the current value, do not show an edit affordance.
    3. delete independence: delete permissions are independent of read. Users with delete but no read should still see delete controls.
    4. No per-row gating: Never gate individual rows in a list. If a user has list permission, render all rows. Check read permission only when the user attempts to open a specific row (e.g., in a drawer or detail route).
    5. Gate the narrowest possible element: Prefer gating a button, a section, or a specific sub-resource rather than an entire page.
    6. Sub-resource autonomy: A user might lack read on a parent resource (e.g., Service Accounts) but still have create permissions on a sub-resource (e.g., API Keys). Do not block the parent if it hides allowed sub-resource actions.

  10. Best practices for using Error Boundaries

    main

    To effectively use error boundaries in your application, follow these guidelines:

    • Use Sparingly: Do not wrap every component. Focus on critical UI elements, third-party integrations, data-heavy components, or route-level components.
    • Meaningful Fallbacks: Provide helpful fallback UI that guides users rather than leaving them with a broken screen.
    • Log Errors: Always implement error logging (via onError or Sentry) to ensure you can debug production issues.
    • Component Names: Ensure components have a proper displayName to make the componentStack useful for debugging.
    • Test Scenarios: Explicitly test error scenarios to verify that your boundaries catch errors and display fallbacks correctly.

  11. How Foundry deployment commands work

    main

    Foundry manages deployments using two primary commands that separate manifest generation from application:

    • foundryctl forge: Generates deployment manifests from a casting.yaml file. This command is safe to run repeatedly as it does not interact with running containers.
    • foundryctl cast: Applies the generated manifests. It recreates containers and reuses the volumes specified in your configuration or patches.

    If you prefer not to use foundryctl cast, you can manually apply the generated artifacts located in pours/deployment/ using standard Docker commands.

    # Manual deployment using generated artifacts
cd pours/deployment
docker compose up -d                        # For Compose
docker stack deploy -c compose.yaml signoz  # For Swarm

  12. Compare SigNoz with other observability tools

    main

    SigNoz is designed as an alternative to specialized or commercial tools:

    ToolComparison with SigNoz
    PrometheusPrometheus focuses on metrics; SigNoz combines metrics, logs, traces, dashboards, and alerts for correlated debugging.
    JaegerJaeger is specialized for distributed tracing; SigNoz adds metrics, logs, trace analysis, dashboards, and alerting.
    ElasticSigNoz uses a columnar database for efficient observability analysis and high-cardinality logs, requiring ~50% fewer resources during ingestion compared to Elastic.
    LokiSigNoz indexes all keys, whereas Loki may encounter max stream errors when increasing the number of labels.