Configuration

SigNoz provides multiple methods to configure your installation. This document outlines the available configuration options and their usage. It also outlines some common use cases and how to achieve them.

Configuration Options

YAML Configuration Files (under development)

SigNoz accepts configuration through YAML files using the --config flag. You can specify multiple configuration files that will be merged during startup:

signoz --config base.yaml --config override.yaml

Precedence Rules

When multiple configuration files are specified:

• Files are merged from right to left
• Values in later files take precedence over earlier files
• In the example above, settings in override.yaml will override any conflicting settings in base.yaml

Available Options

For a comprehensive list of all available configuration options, refer to our example configuration file. The file is continuously updated with new options as they are added.

Environment Variables

All configuration options can be specified or overridden using environment variables. This provides flexibility for different deployment scenarios and container-based environments.

Naming Convention

Environment variables in SigNoz follow a specific naming convention to ensure consistency and prevent conflicts:

1. SIGNOZ Prefix

   • All environment variables must start with SIGNOZ_

2. YAML Path Translation

   • YAML configuration paths are converted to uppercase
   • Dots (.) in YAML paths become underscores (_)
   • Example:
     Copy

     web.enabled: true

     becomes:
     Copy

     SIGNOZ_WEB_ENABLED=true

3. Handling Underscores

   • Original underscores in YAML keys are converted to double underscores (__)
   • This prevents ambiguity between dots and underscores in the original configuration
   • Example:
     Copy

     sqlstore.max_open_conns: 10

     becomes:
     Copy

     SIGNOZ_SQLSTORE_MAX__OPEN__CONNS=10

Examples

Environment variables take precedence over values specified in configuration files.

Querier Query Concurrency

The querier runs the ClickHouse queries that back each query-range request, such as a multi-panel dashboard load or an alert evaluation. Use max_concurrent_queries under the querier section to cap how many of those ClickHouse queries run in parallel for a single request. Running the sub-queries concurrently (up to this limit) instead of one at a time improves response latency for requests that issue many queries, such as dashboards with many panels or alert rules with many conditions.

Set it in your configuration file:

querier:
  max_concurrent_queries: 8

Or through the equivalent environment variable:

SIGNOZ_QUERIER_MAX__CONCURRENT__QUERIES=8

See the example configuration file for the full querier section and other available options.