287b60cbe6
* feat(statsreporter): expose collected stats via GET /api/v1/stats Extract per-org stats collection out of the analytics reporter into an always-on Aggregator (collector fan-out + telemetry-store counts) shared by the reporter and a new HTTP handler. The GET /api/v1/stats endpoint returns the caller's org stats regardless of whether scheduled reporting is enabled. * refactor(statsreporter): collect telemetry stats via the querier Move the trace/log/metric row-count and last-observed queries out of the stats aggregator and into the querier, which now implements statsreporter.StatsCollector. The aggregator becomes a pure collector fan-out and no longer depends on telemetrystore; the querier is wired in as one of the stats collectors. * chore: regenerate openapi spec and frontend client Backend docs/api/openapi.yml gains the GET /api/v1/stats (GetStats) operation; the Orval client gains a useGetStats hook and GetStats200 type. * chore: remove comment from querier Collect * fix(statsreporter): use MustNewUUID for org from claims Claims come from validated auth context, so the org UUID is guaranteed valid; drop the dead NewUUID error branch. * fix(flagger): use MustNewUUID for org from claims Claims come from validated auth context, so the org UUID is guaranteed valid; drop the dead NewUUID error branch. * docs(contributing): note MustNewUUID for IDs from claims * perf(querier): combine count and last-observed into one query per signal Each signal's COUNT(*) and max(timestamp) scan the same table, so fetch both in a single query — 3 queries instead of 6. Same emitted keys and empty-table guard.
Go
This document provides an overview of contributing to the SigNoz backend written in Go. The SigNoz backend is built with Go, focusing on performance, maintainability, and developer experience. We strive for clean, idiomatic code that follows established Go practices while addressing the unique needs of an observability platform.
We adhere to three primary style guides as our foundation:
- Effective Go - For writing idiomatic Go code
- Code Review Comments - For understanding common comments in code reviews
- Google Style Guide - Additional practices from Google
We recommend (almost enforce) reviewing these guides before contributing to the codebase. They provide valuable insights into writing idiomatic Go code and will help you understand our approach to backend development. In addition, we have a few additional rules that make certain areas stricter than the above which can be found in area-specific files in this package:
- Abstractions - When to introduce new types and intermediate representations
- Errors - Structured error handling
- Endpoint - HTTP endpoint patterns
- Flagger - Feature flag patterns
- Handler - HTTP handler patterns
- Provider - Dependency injection and provider patterns
- Packages - Naming, layout, and conventions for
pkg/packages - Service - Managed service lifecycle with
factory.Service - SQL - Database and SQL patterns
- Types - Domain types, request/response bodies, and storage rows in
pkg/types/