Srikanth Chekuri b9f4fcd681
Some checks failed
build-staging / js-build (push) Has been cancelled
build-staging / go-build (push) Has been cancelled
build-staging / prepare (push) Has been cancelled
build-staging / staging (push) Has been cancelled
cacheci / tests (push) Has been cancelled
Release Drafter / update_release_draft (push) Has been cancelled
chore(telemetrytypes): introduce LogicalField (#12499)
Possible options

1. The compatibility keys maps (the approach already in the code).

`backward_compat_keys.go` makes an alias key at metadata time. We
rejected this option because of evidence. The alias key resolves, but it
reads the wrong data. It prepares to `attributes_string['<alias>']`, and
that physical key does not hold the data.

2. The flat multi-key.

`GetKeys` returns multiple keys in order, and the downstream code uses
the list. The option fails on semantics. It removes one piece of
information that the downstream must have. The downstream must know the
difference between two cases:

- Two keys are the same field with two spellings so we can merge them
into one expression.
- Two keys are different fields with the same name. The condition
builder must make one condition for each key. The operator connects the
conditions.

Three failures show the problem:

- Negative operators connect with OR across the keys. A row that has
only one spelling then always matches. Example: `env != 'prod'` matches
each row that does not have one of the two keys.
- A row that has both spellings with different values gets no clear
result.
- A value position (group-by, select) needs exactly one expression for
one field. A flat list cannot point to that expression.

The information must live somewhere.

3. Annotations on `TelemetryFieldKey`

Maintain the `SemconvMembers` and `SemconvMaterializedColumns` fields on
the keys. The information is the same as in option 4. But it's awkward
because "these N keys are one family, in this order" lives in N copies,
one copy on each key.

4. introduce `LogicalField`

The information is the same as in option 3, but the structure holds it:

- The slice is the ambiguity.
- The group is the family.
- The member order is the precedence. The code sorts the members one
time, by family rank, at construction.
- The members point to the metadata entries. The code copies nothing and
changes nothing.
- The identity (signal, context, data type) is on the group. A merge
across contexts or data types is not possible. The design does not avoid
that merge; the design cannot express it.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2026-08-10 13:40:37 +00:00
2021-01-24 13:09:49 +05:30
2021-01-03 18:15:44 +05:30
2021-01-22 11:50:17 +05:30
2025-07-17 10:38:31 +00:00
2022-05-30 17:22:47 +05:30

SigNoz - Observability on Your Terms, Powered by Open Standards.

中文 · Deutsch · Português

GitHub issues GitHub release Slack community LinkedIn Tweet

SigNoz is an open-source observability platform built on OpenTelemetry. Were building an enterprise-grade alternative to fragmented monitoring stacks, with logs, metrics, traces, alerts, and dashboards in one place.

Choose how to run SigNoz

Fully managed SigNoz with a 30-day free trial, no credit card required, usage-based pricing that starts at $49, and regional data hosting.

Start free →

Enterprise

Enterprise Cloud, BYOC, or Enterprise Self-Hosted with compliance, support, custom retention, RBAC, ingestion controls, data residency, and region selection.

Explore Enterprise →

Community

Free open-source SigNoz that runs in your own infrastructure. Deploy with Docker, Kubernetes, or Linux and keep full control of your data plane.

Install SigNoz →

What can you monitor?

SigNoz helps teams debug production issues faster by connecting logs, metrics, traces, alerts, dashboards, exceptions, and agent-native workflows in one place.

APM Overview

Monitor service latency, error rate, throughput, Apdex, top endpoints, database calls, and external calls.

SigNoz APM dashboard showing latency, throughput, Apdex, and key operations

Learn more: APM documentation

Log Management

Ingest, search, aggregate, and correlate logs with traces and metrics using a visual query builder.

SigNoz logs explorer with filters, frequency chart, and log lines

Learn more: Log management documentation

Metrics and Dashboards

Build dashboards for application, infrastructure, and custom metrics using Query Builder, PromQL, or ClickHouse SQL.

SigNoz host metrics dashboard with system load and network charts

Learn more: Metrics documentation

Infrastructure Monitoring

Monitor Kubernetes clusters, pods, nodes, workloads, and host-level CPU, memory, disk, network, logs, and traces.

SigNoz Kubernetes infrastructure dashboard with pod and node metrics

Learn more: Infrastructure monitoring documentation

LLM and AI Observability

Trace LLM apps, RAG pipelines, prompts, tool calls, tokens, latency, and costs alongside application and infrastructure telemetry.

SigNoz LLM observability dashboard for traces, token usage, latency, and costs

Learn more: LLM observability documentation

Agent-Native Observability and MCP

Use the SigNoz MCP server to bring telemetry into coding agents, or use Noz inside SigNoz to investigate incidents, tune alerts, and build dashboards with production context. Noz is available only on SigNoz Cloud.

SigNoz Noz interface alongside MCP-powered agent workflow

Learn more: SigNoz MCP server docs · Agent skills docs

Distributed Tracing

Follow requests across services with flamegraphs, waterfalls, span events, filters, and trace analytics.

SigNoz distributed trace view with flamegraph and waterfall spans

Learn more: Distributed tracing documentation

Trace Funnels

Create funnels from traces to understand request-flow drop-offs, failed transitions, and systemic workflow issues.

SigNoz trace funnels showing request-flow drop-offs and failed transitions

Learn more: Trace funnels documentation

Also monitor: exceptions, alerts, external APIs, and integrations for OpenTelemetry, Prometheus, Kubernetes, cloud providers, language SDKs, application frameworks, databases, and LLM tools.

Why teams use SigNoz

  1. OpenTelemetry-native
    Instrument once with open standards and keep ownership of your telemetry.
  2. Correlated signals
    Move from service charts to traces, logs, infra metrics, and exceptions without switching tools.
  3. Single columnar database
    Built for high-cardinality, high-volume observability workloads.
  4. Predictable pricing
    No per-host pricing, no user-seat pricing, and no special pricing for custom metrics.
  5. Enterprise ready
    SOC 2 Type II and HIPAA compliance, RBAC, ingestion controls, custom retention, support, BYOC, and self-hosting.

Getting started

Start on Cloud

Create a managed SigNoz workspace and get your first dashboard without running observability infrastructure.

Start free on SigNoz Cloud

Self-host SigNoz

Run SigNoz in your own infrastructure with Foundry, Docker, Kubernetes, or Linux.

Foundry · Docker · Kubernetes · Linux

Send data

Instrument applications and infrastructure with OpenTelemetry, Prometheus, language SDKs, and integrations.

Instrumentation · Integrations

Comparisons to familiar tools

SigNoz is often adopted by teams moving from a stack of single-purpose tools or commercial platforms with unpredictable pricing.

Prometheus
Good if you just need metrics. SigNoz keeps metrics, logs, traces, dashboards, and alerts together so teams can debug with correlated context.

Jaeger
Jaeger only does distributed tracing. SigNoz adds metrics, logs, trace analytics, dashboards, alerts, exceptions, and trace-to-log workflows.

Elastic
SigNoz uses columnar database for efficient observability analytics and high-cardinality log workloads, with 50% lower resource requirement compared to Elastic during ingestion. Check the detailed study.

Loki
In the linked benchmark, SigNoz indexed all keys in the test setup, while Loki hit max stream errors when more labels were added. Check the detailed study.

Contributing

We ❤️ contributions big or small. Please read CONTRIBUTING.md to get started with making contributions to SigNoz.

Not sure how to get started? Just ping us on #contributing in our slack community.

As always, thanks to our amazing contributors!

SigNoz contributors
Description
No description provided
Readme MIT 442 MiB
Languages
TypeScript 51.4%
Go 37.8%
Python 6.6%
SCSS 3.9%
JavaScript 0.2%