WARNING: THIS DOCUMENT IS NOT AUTHORITATIVE

This is an auto-generated snapshot captured at a single point in time. It is not official Netdata documentation, it is not kept up to date, and it must not be treated as a reliable reference for Netdata's configuration system. Refer to the official Netdata documentation for current and accurate information.

YAML/JSON Support for inicfg - Migration Guide (WIP)

This document outlines the complexities involved in adding YAML and JSON support to Netdata's inicfg configuration system, and the proposed solutions.

Overview

The goal is to enable Netdata to read configuration files in YAML and JSON formats in addition to the traditional INI format. This requires:

1. Loading YAML/JSON files and converting them to the internal inicfg structure
2. Converting inicfg structures back to YAML/JSON for API endpoints (e.g., http://localhost:19999/netdata.yaml)
3. Maintaining full backward compatibility with existing INI configurations

Key Challenges and Solutions

1. Keys with Spaces vs Underscores

Problem:

• INI format uses keys with spaces: "update every", "command options", "per cpu core utilization"
• YAML/JSON with spaces in keys looks unnatural and requires quoting:
  yamlCopy

  # Unnatural in YAML
  "update every": 1s
  "per cpu core utilization": yes
  

Analysis:

• Most keys in netdata.conf use spaces (found only 2 with underscores: package_throttle_count, softnet_stat)
• No conflicts exist when converting between spaces and underscores

Solution:

• INI → YAML/JSON: Convert spaces to underscores for natural YAML appearance
• YAML/JSON → INI: Convert underscores back to spaces for INI compatibility
• Special handling: Preserve filesystem paths unchanged (e.g., /proc/net/dev)

# Natural YAML representation
update_every: 1s
per_cpu_core_utilization: yes
"/proc/net/dev": yes  # Filesystem paths unchanged

2. Hierarchical Structure with Colon Separators

Problem:

• INI uses flat sections with colons to represent hierarchy:
  iniCopy

  [plugin:proc]
  update every = 1s
  
  [plugin:proc:/proc/net/dev]
  compressed packets for all interfaces = no
  

Solution:

• INI → YAML/JSON: Parse colons to create nested objects
• YAML/JSON → INI: Flatten nested objects to colon-separated section names

# YAML representation
plugin:
  proc:
    update_every: 1s
    _sections:  # Sub-sections for plugin:proc:xxx
      "/proc/net/dev":
        compressed_packets_for_all_interfaces: no

3. Special Sections (Enable/Disable Maps)

Problem: The [plugins] section has a unique behavior where keys represent plugin names and values control enablement:

[plugins]
proc = yes
ebpf = no
perf = yes

[plugin:proc]
update every = 1s

This creates ambiguity: proc appears both as a key in [plugins] and as part of section name [plugin:proc].

Solution Options:

Option A: Special Suffix Marker (@enable)

• Rename special sections internally: [plugins] → [plugins@enable]
• This makes the special behavior explicit and extensible

plugins@enable:
  proc: yes
  ebpf: no
  
plugin:
  proc:
    update_every: 1s

Option B: Hardcoded Special Sections

• Maintain a hardcoded list of sections with special behavior
• Currently only [plugins] needs this treatment
• Simpler but less extensible

plugins:  # Hardcoded to know this is an enable/disable map
  proc: yes
  ebpf: no
  
plugin:
  proc:
    update_every: 1s

Recommendation: Option B (hardcoded) is simpler if [plugins] is truly the only case.

4. Bidirectional Conversion Requirements

Problem:

• Users must be able to get configurations in any format
• http://localhost:19999/netdata.conf (existing)
• http://localhost:19999/netdata.yaml (new)
• http://localhost:19999/netdata.json (new)

Solution: Implement bidirectional conversion functions:

• inicfg_to_json(): Convert inicfg structure to JSON-C object
• json_to_inicfg(): Convert JSON-C object to inicfg structure
• YAML uses existing yaml.h functions to convert to/from JSON-C

Implementation Architecture

File Organization

src/libnetdata/inicfg/
├── inicfg.h                    # Public API
├── inicfg_internals.h          # Internal structures and functions
├── inicfg_conf_file.c          # Core INI loading (refactored)
├── inicfg_yaml.c              # YAML loading support (new)
├── inicfg_json.c              # JSON loading support (new)
├── inicfg_converter.c         # Bidirectional conversion logic (new)
└── MIGRATE_TO_YAML_WIP.md     # This document

Key Functions

// Private format-specific loaders
static int inicfg_load_ini(struct config *root, const char *filename, 
                          int overwrite_used, const char *section_name);
static int inicfg_load_yaml(struct config *root, const char *filename,
                           int overwrite_used, const char *section_name);
static int inicfg_load_json(struct config *root, const char *filename,
                           int overwrite_used, const char *section_name);

// Public orchestrator (auto-detects format)
int inicfg_load(struct config *root, char *filename, int overwrite_used,
               const char *section_name);

// Bidirectional conversion
struct json_object *inicfg_to_json(struct config *root);
int json_to_inicfg(struct config *root, struct json_object *json,
                  int overwrite_used, const char *section_name);

// Key normalization helpers
char *normalize_key_for_ini(const char *key);   // underscores → spaces
char *normalize_key_for_yaml(const char *key);  // spaces → underscores

Example Transformations

Simple Configuration

INI Format:

[global]
update every = 1s
history = 3600

[web]
bind to = *
default port = 19999

YAML Format:

global:
  update_every: 1s
  history: 3600

web:
  bind_to: "*"
  default_port: 19999

Complex Plugin Configuration

INI Format:

[plugins]
proc = yes
tc = yes

[plugin:proc]
update every = 1s
/proc/pagetypeinfo = yes

[plugin:proc:/proc/stat]
per cpu core utilization = yes
cpu idle states = yes

YAML Format:

plugins:  # Special handling: enable/disable map
  proc: yes
  tc: yes

plugin:
  proc:
    update_every: 1s
    "/proc/pagetypeinfo": yes
    _sections:
      "/proc/stat":
        per_cpu_core_utilization: yes
        cpu_idle_states: yes

Testing Strategy

Unit Tests Required

1. Key Normalization

   • Space ↔ underscore conversion
   • Filesystem path preservation
   • Edge cases (multiple spaces, leading/trailing spaces)

2. Section Parsing

   • Colon separation parsing
   • Nested object creation/flattening
   • Deep nesting levels

3. Special Sections

   • [plugins] enable/disable mapping
   • Conflict resolution between enable keys and section names

4. Round-trip Conversion

   • INI → YAML → INI preservation
   • YAML → INI → YAML preservation
   • Data type preservation

5. Error Handling

   • Invalid YAML/JSON syntax
   • Unsupported nesting levels
   • Conflicting keys

Test Files

Create test configurations in all formats:

• tests/inicfg_test.conf - Traditional INI
• tests/inicfg_test.yaml - Equivalent YAML
• tests/inicfg_test.json - Equivalent JSON

Migration Path

1. Phase 1: Implement core conversion logic with unit tests
2. Phase 2: Add format auto-detection to inicfg_load()
3. Phase 3: Add web API endpoints for YAML/JSON output
4. Phase 4: Update documentation and examples
5. Phase 5: Gradual migration of default configs to YAML

Phase 1: Complete Configuration Analysis Results

All Configuration Handles Found (Automated Analysis)

Based on comprehensive codebase scan using Python extraction tool, Netdata uses 17 unique configuration handles:

Summary Statistics

• Total Configuration Handles: 17
• inicfg_load() calls: 14 across entire codebase
• inicfg_get() calls*: 847+ total
• inicfg_set() calls*: 98+ total
• Primary configurations: 6 (actively loaded with config files)
• Active configurations: 3 (runtime-created for specific modules)
• Derived configurations: 2 (references to parent configs)
• Utility/Debug configurations: 6 (temporary or development)

Phase 2: Configuration Usage Pattern Analysis

Primary Configuration Details

1. netdata_config (Main System Configuration)

• Load Files: 4 calls across src/daemon/config/netdata-conf.c and src/database/rrdhost-labels.c
• Primary Sections:
  • [cloud] - Cloud connectivity, proxy, SSL settings
  • [db] - Database engine, retention, replication, storage tiers
  • [directories] - System paths (home, plugins, etc.)
  • [global] - System-wide settings (update frequency, hostname, etc.)
  • [web] - Web server configuration
  • [health] - Health monitoring settings
  • [plugins] - Plugin enable/disable map (special handling needed)
  • [plugin:*] - Plugin-specific configuration sections

2. stream_config (Streaming/Replication)

• Load Files: Multiple streaming configuration files
• Primary Sections:
  • [stream] - Basic streaming settings
  • [*] - Stream destination configurations (by GUID/hostname)
• Special Patterns: Dynamic section names based on machine GUIDs

3. cloud_config (Netdata Cloud Integration)

• Load Files: Cloud-specific configuration file
• Primary Sections:
  • [global] - Cloud URL, proxy, tokens, machine GUID
• Usage: 45+ get calls for cloud connectivity features

4. exporting_config (Data Export)

• Load Files: 2 load calls in src/exporting/read_config.c
• Primary Sections:
  • [exporting:global] - Global export settings
  • [prometheus:*] - Prometheus exporter instances
  • [opentsdb:*] - OpenTSDB exporter instances
  • [*:*] - Various exporter type:instance combinations

5. claim_config (Cloud Claiming)

• Load Files: 1 load call in src/claim/claim-with-api.c
• Primary Sections:
  • [global] - Claiming tokens, URLs, proxy settings
• Usage: Temporary configuration for claiming process

6. collector_config (eBPF Collectors)

• Load Files: 2 load calls in eBPF plugin system
• Primary Sections:
  • [global] - eBPF global settings (update frequency, map sizes)
  • [programs] - eBPF program enable/disable configuration
  • [network viewer] - Network monitoring specific settings

Phase 3: Special Patterns and Dynamic Construction Analysis

Critical Section Patterns for YAML Conversion

1. Plugin Hierarchy Pattern (Found in netdata_config)

[plugins]
proc = yes
python.d = yes
charts.d = no

[plugin:proc]
update every = 1s
/proc/stat = yes

[plugin:proc:/proc/stat]
per cpu core utilization = yes
cpu idle states = yes

YAML Conversion Challenge: The [plugins] section is an enable/disable map where keys are plugin names, but [plugin:proc] sections configure those same plugins. Need to avoid conflicts.

2. Exporter Instance Pattern (Found in exporting_config)

[exporting:global]
enabled = yes

[prometheus:server]
enabled = yes
destination = localhost:9090

[opentsdb:primary]
enabled = no
destination = localhost:4242

YAML Conversion: Clean hierarchical structure possible with exporter type as parent.

3. Dynamic Stream Destinations (Found in stream_config)

[stream]
enabled = yes

[11111111-2222-3333-4444-555555555555]
enabled = yes
destination = parent.example.com

YAML Conversion Challenge: Section names are dynamic machine GUIDs, not predictable keys.

4. eBPF Module Configuration (Found in collector_config)

[global]
update every = 1s
pid size = 32768

[programs]
process = yes
socket = yes
filesystem = no

[network viewer]
resolve hostname = no
resolve service = yes

YAML Conversion: Straightforward hierarchical structure.

Data Types and Usage Patterns

Primary Data Types:

1. String (inicfg_get()) - 45% of calls

   • Paths, URLs, hostnames, text values
   • Example: inicfg_get(&netdata_config, "directories", "cache", "/var/cache/netdata")

2. Number (inicfg_get_number()) - 30% of calls

   • Counts, timeouts, sizes in basic units
   • Example: inicfg_get_number(&netdata_config, "global", "cpu cores", system_cpu_cores)

3. Boolean (inicfg_get_boolean()) - 15% of calls

   • Enable/disable flags using CONFIG_BOOLEAN_YES/NO/AUTO
   • Example: inicfg_get_boolean(&netdata_config, "health", "enabled", CONFIG_BOOLEAN_YES)

4. Size (inicfg_get_size_bytes(), inicfg_get_size_mb()) - 5% of calls

   • Memory and disk sizes with human-readable formats
   • Example: inicfg_get_size_mb(&netdata_config, "db", "dbengine page cache size", 32)

5. Duration (inicfg_get_duration_ms(), inicfg_get_duration_seconds()) - 5% of calls

   • Time intervals with unit suffixes
   • Example: inicfg_get_duration_seconds(&netdata_config, "db", "update every", 1)

Phase 4: Categorized Configuration Structure

Configuration Complexity Levels

Level 1: Simple Hierarchical (Easy YAML conversion)

• cloud_config - Simple global section
• claim_config - Temporary claiming configuration
• Most eBPF collector configs - Clean section hierarchy

Level 2: Moderate Complexity (Manageable YAML conversion)

• exporting_config - Clean type:instance hierarchy
• Simple sections of netdata_config (db, directories, web)

Level 3: High Complexity (Requires special handling)

• netdata_config plugin sections - [plugins] conflicts with [plugin:*]
• stream_config - Dynamic GUID-based section names
• Multi-level plugin hierarchies - [plugin:proc:/proc/stat] style nesting

Key Naming Patterns Found

Standard Patterns (Convert directly to YAML)

• update every → update_every
• default port → default_port
• bind to → bind_to

Filesystem Paths (Preserve exactly)

• /proc/net/dev → "/proc/net/dev"
• /sys/class/power_supply → "/sys/class/power_supply"

Special Characters (Need careful handling)

• per cpu core utilization → per_cpu_core_utilization
• Spaces, colons, and dots in keys

Complex Section Patterns Discovered

1. Plugin Hierarchy Pattern

[plugins]
proc = yes
python.d = yes

[plugin:proc]
update every = 1s

[plugin:proc:/proc/net/dev]
compressed packets for all interfaces = no

[plugin:python.d:apache]
update every = 30s

2. Export Instance Pattern

[exporting:global]
enabled = yes

[prometheus:server]
enabled = yes
destination = localhost:9090

[opentsdb:primary]
enabled = no
destination = localhost:4242

3. Collector Sub-Module Pattern

[plugin:cgroups]
update every = 1s

[plugin:proc:/proc/stat]
per cpu core utilization = yes
cpu idle states = yes

Key Naming Conventions Found

Space-Separated Keys (Most Common):

• update every
• command options
• per cpu core utilization
• compressed packets for all interfaces

Underscore Keys (Rare):

• package_throttle_count
• softnet_stat per core

Filesystem Paths as Keys:

• /proc/net/dev
• /proc/pagetypeinfo
• /sys/class/power_supply

Boolean Value Conventions:

• yes/no (most common)
• true/false
• auto (for auto-detection)
• on/off

Configuration Loading Patterns

1. Standard Pattern: User config → Stock config → Internal defaults
2. Override Pattern: Some configs support section-specific reloading
3. Validation Pattern: Values are often normalized after loading
4. Migration Pattern: Old key names are moved to new ones using inicfg_move()

YAML/JSON Conversion Implications

Data Type Preservation:

• YAML/JSON can maintain proper types (boolean, number) vs INI strings
• Duration/size suffixes need special handling (1s, 1MB)
• AUTO values need mapping to proper YAML representation

Section Flattening Rules:

• [plugin:proc:/proc/net/dev] → plugin.proc["/proc/net/dev"]
• [prometheus:server] → prometheus.server or exporting.prometheus.server

Special Handling Required:

• Filesystem paths as keys must be preserved exactly
• Plugin enable/disable mapping in [plugins] section
• Collector-specific configuration hierarchies

Updated Recommendations

Based on the comprehensive analysis:

1. Hardcode Special Sections: Only [plugins] needs enable/disable mapping
2. Preserve Type Information: Use YAML/JSON native types where possible
3. Validate Conversion: Implement round-trip testing for all 1000+ configuration calls
4. Gradual Migration: Start with read-only YAML/JSON support, then enable writing

Open Questions

1. Should we support mixed formats (e.g., main config in YAML, includes in INI)?
2. How deep should nesting be allowed in YAML/JSON?
3. Should we validate against a schema for YAML/JSON configs?
4. How to handle YAML-specific features (anchors, aliases)?
5. Should duration/size values be parsed as strings or objects in YAML?

Risks and Mitigations

1. Risk: Breaking existing configurations

   • Mitigation: Extensive testing with all 1000+ config calls, gradual rollout

2. Risk: Performance impact from format detection

   • Mitigation: Use file extensions for quick detection

3. Risk: Type conversion errors

   • Mitigation: Comprehensive type validation and error reporting

4. Risk: Complex hierarchy mapping errors

   • Mitigation: Unit tests for all discovered section patterns

5. Risk: Key naming conflicts with space/underscore conversion

   • Mitigation: Automated conflict detection across all found configurations

Phase 5: YAML Conversion Impact Analysis

Conversion Impact by Configuration

High Impact (Require immediate attention)

1. netdata_config - 847+ get calls, most critical

   • Plugin section conflicts need resolution
   • Massive scope affecting entire system
   • Priority: CRITICAL

2. stream_config - Dynamic sections

   • GUID-based section names challenge YAML structure
   • Essential for distributed setups
   • Priority: HIGH

Medium Impact (Manageable with planning)

3. exporting_config - 134+ get calls

   • Clean hierarchy conversion possible
   • Well-defined type:instance pattern
   • Priority: MEDIUM

4. collector_config - 200+ get calls

   • eBPF-specific but substantial usage
   • Clean section structure
   • Priority: MEDIUM

Low Impact (Straightforward conversion)

5. cloud_config - 45+ get calls

   • Simple structure, limited scope
   • Priority: LOW

6. claim_config - 23+ get calls

   • Temporary usage, simple structure
   • Priority: LOW

Implementation Roadmap

Phase A: Core Infrastructure (Foundation)

1. Implement inicfg_load_yaml() and inicfg_load_json() functions
2. Add format auto-detection to inicfg_load()
3. Create key normalization functions (space ↔ underscore)
4. Build bidirectional conversion (inicfg_to_json(), json_to_inicfg())

Phase B: Simple Configurations (Low Risk)

1. Convert cloud_config and claim_config to YAML
2. Test with existing eBPF collector configs
3. Validate round-trip conversion accuracy

Phase C: Complex Configurations (High Risk)

1. Special section handling for [plugins] conflicts
2. Dynamic section support for stream GUID-based names
3. Multi-level hierarchy for [plugin:proc:/proc/stat] patterns

Phase D: Full Integration (System-wide)

1. Update all inicfg_load() calls to support auto-detection
2. Add web API endpoints for YAML/JSON output
3. Update documentation and migration guides

Critical Success Factors

Must Have

1. 100% backward compatibility - All existing INI configs must work unchanged
2. Round-trip accuracy - INI → YAML → INI must preserve all data
3. Performance parity - YAML loading must not significantly slow boot time
4. Error handling - Clear error messages for YAML syntax issues

Should Have

1. Mixed format support - Allow YAML includes of INI files
2. Configuration validation - Schema validation for YAML configs
3. Migration tools - Automated conversion from INI to YAML

Nice to Have

1. YAML features - Support for anchors, aliases, and multi-line strings
2. Type preservation - Use native YAML booleans and numbers
3. Comments preservation - Maintain comments during conversion

Testing Strategy

Unit Tests (Required for each phase)

1. Key normalization - Space/underscore conversion edge cases
2. Section parsing - Colon separation and nesting
3. Data type conversion - String, number, boolean, size, duration
4. Special patterns - Plugin conflicts, dynamic sections, multi-level hierarchy

Integration Tests (System-wide validation)

1. Full configuration loading - All 17 config handles
2. Web API compatibility - Existing endpoints continue working
3. Plugin system - All collectors work with YAML configs
4. Streaming - YAML stream configs work across nodes

Performance Tests (Ensure no degradation)

1. Boot time impact - Measure startup time with YAML vs INI
2. Memory usage - Compare memory footprint
3. Configuration reload - Runtime configuration changes

Success Metrics

1. Functional: All 847+ get calls work identically with YAML
2. Performance: <5% increase in configuration loading time
3. Compatibility: 100% existing INI configs continue working
4. Adoption: New configurations prefer YAML format
5. Maintainability: Reduced configuration complexity and improved readability

Implementation Complete

Total Analysis Coverage:

• 17 configuration handles identified and categorized
• 847+ configuration get calls analyzed
• 14 inicfg_load() calls documented
• 4 complexity levels established with conversion strategies
• Multi-phase implementation roadmap with risk assessment

The comprehensive analysis provides the complete foundation needed for implementing YAML and JSON support in Netdata's inicfg configuration system.

Detailed Configuration Reference

Complete reference for all Netdata configuration files, sections, and keys.

Configuration: netdata.conf

Handle: netdata_config

Section CONFIG_SECTION_CLOUD

Netdata Cloud connectivity and integration settings

Section CONFIG_SECTION_DB

Database engine configuration, retention, and storage tiers

Section CONFIG_SECTION_DIRECTORIES

System directory paths for configuration, logs, cache, etc.

Section CONFIG_SECTION_DISKSPACE

Disk space monitoring and exclusion settings

Section CONFIG_SECTION_ENV_VARS

Environment variables used by Netdata

Section CONFIG_SECTION_GETIFADDRS

FreeBSD network interface monitoring settings

Section CONFIG_SECTION_GETMNTINFO

FreeBSD mount point monitoring settings

Section CONFIG_SECTION_GLOBAL

Global system-wide configuration settings

Section CONFIG_SECTION_HEALTH

Health monitoring and alerting settings

Section CONFIG_SECTION_KERN_DEVSTAT

FreeBSD kernel device statistics monitoring for disk I/O performance

Section CONFIG_SECTION_LOGS

Logging configuration and debugging settings

Section CONFIG_SECTION_PLUGINS

Plugin management and control configuration

Section CONFIG_SECTION_PLUGIN_PROC_DISKSTATS

Disk I/O statistics monitoring from /proc/diskstats

Section CONFIG_SECTION_PLUGIN_PROC_DRM

Direct Rendering Manager (DRM) monitoring for GPU statistics

Section CONFIG_SECTION_PLUGIN_PROC_INTERRUPTS

CPU interrupt monitoring from /proc/interrupts

Section CONFIG_SECTION_PLUGIN_PROC_LOADAVG

System load average and process count monitoring from /proc/loadavg

Section CONFIG_SECTION_PLUGIN_PROC_MEMINFO

System memory statistics monitoring from /proc/meminfo

Section CONFIG_SECTION_PLUGIN_PROC_NETDEV

Network interface statistics monitoring from /proc/net/dev

Section CONFIG_SECTION_PLUGIN_PROC_NETSTAT

Advanced network statistics monitoring from /proc/net/netstat

Section CONFIG_SECTION_PLUGIN_PROC_NETWIRELESS

Linux wireless network interface monitoring configuration from /proc/net/wireless

Section CONFIG_SECTION_PLUGIN_PROC_NET_IPVS

IPVS (IP Virtual Server) load balancer monitoring configuration for Linux kernel-based load balancing

Section CONFIG_SECTION_PLUGIN_PROC_NFS

NFS (Network File System) client statistics monitoring configuration from /proc/net/rpc/nfs

Section CONFIG_SECTION_PLUGIN_PROC_PAGETYPEINFO

Memory page type and fragmentation monitoring from /proc/pagetypeinfo

Section CONFIG_SECTION_PLUGIN_PROC_PRESSURE

Linux kernel Pressure Stall Information (PSI) monitoring from /proc/pressure

Section CONFIG_SECTION_PLUGIN_SYS_CLASS_INFINIBAND

InfiniBand network monitoring configuration

Section CONFIG_SECTION_PULSE

Netdata Agent internal pulse monitoring threads configuration

Section CONFIG_SECTION_REGISTRY

Netdata Agent Registry configuration for tracking dashboard usage and URLs across multiple Netdata agents

Section CONFIG_SECTION_SQLITE

SQLite database engine configuration for Netdata's metadata and metrics storage

Section CONFIG_SECTION_STATSD

StatsD collector configuration for receiving and processing metrics from external applications via UDP and TCP

Section CONFIG_SECTION_TIMEX

Timex plugin configuration for monitoring system clock synchronization and time offset metrics

Section CONFIG_SECTION_WEB

Web server and dashboard configuration

Section CONFIG_SECTION_WEBRTC

WebRTC configuration for real-time communication features

Section HTTPD_CONFIG_SECTION

h2o HTTP server configuration for alternative high-performance web server implementation

Section buf

Windows plugin network interface monitoring configuration. The actual section name is dynamically generated as plugin:proc:/proc/net/dev:INTERFACE_NAME where INTERFACE_NAME is the network interface.

Section buffer

InfiniBand/OmniPath device-specific monitoring configuration. The actual section name is dynamically generated as plugin:proc:/sys/class/infiniband:DEVICE_NAME where DEVICE_NAME is the InfiniBand device name.

Section instance_name

Exporting connector instance configuration

Section section

Generic configuration section placeholder used in command-line tools

Section section_name

Database connection configuration section for external database drivers and connectors

Section st->config_section

Static thread configuration section. The actual section name is dynamically set from the thread's config_section field (e.g., CONFIG_SECTION_PLUGINS, CONFIG_SECTION_PULSE).

Section string2str(cd->id)

External collector plugin configuration section. The actual section name is dynamically generated from the collector ID.

Section struct config *root

Generic configuration section parameter. Used in inicfg API functions where the section name is passed as a parameter to functions like inicfg_get(), inicfg_set(), etc.

Section var_name

Disk I/O and network interface monitoring configuration for device-specific metrics

Section plugin:cgroups

Control groups (cgroups) monitoring plugin configuration

Section plugin:freebsd

FreeBSD system monitoring plugin configuration

Section [plugin:PLUGIN_NAME:MODULE]

FreeBSD/macOS firewall monitoring module configuration

Section [plugin:PLUGIN_NAME:MODULE]

IPv4 ICMP monitoring module configuration

Section [plugin:PLUGIN_NAME:MODULE]

IPv4 protocol monitoring module configuration

Section [plugin:PLUGIN_NAME:MODULE]

TCP protocol monitoring module configuration

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for UDP protocol monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for IPv6 ICMP monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for IPv6 protocol monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for FreeBSD kernel network dispatch monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for system processes and memory monitoring

Section plugin:idlejitter

CPU idle jitter monitoring plugin configuration

Section plugin:macos

macOS system monitoring plugin configuration

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for network interface and disk monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for system resource monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for comprehensive network protocol monitoring

Section plugin:proc

Linux /proc filesystem monitoring plugin configuration

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for file and directory monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for RAID array monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for NFS server monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for SCTP protocol monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for IPv4 socket and connection monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for IPv6 protocol and multicast monitoring

Section plugin:proc:/proc/net/sockstat

Network socket statistics monitoring configuration

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for IPv6 socket statistics monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for network softirq statistics monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for netfilter connection tracking monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for SYNPROXY DDoS mitigation monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for system interrupts monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for comprehensive CPU statistics monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for generic system file monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for kernel statistics monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for hardware statistics monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for periodic statistics monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for process statistics monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for memory management monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for PCIe monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for power supply and battery monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for thermal monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for hardware monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for NUMA statistics monitoring

Section plugin:proc:/sys/fs/btrfs

Btrfs filesystem monitoring configuration

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for Kernel Same-page Merging (KSM) monitoring

Section [plugin:PLUGIN_NAME:MODULE]

Plugin-specific configuration section for System V IPC monitoring

Section plugin:tc

Linux Traffic Control (tc) QoS monitoring plugin configuration

Section plugin:windows

Windows system monitoring plugin configuration

Configuration: stream.conf

Handle: stream_config

Section CONFIG_SECTION_STREAM

Streaming configuration for parent-child node relationships

Section api_key

API key specific configuration for streaming receivers

Section machine_guid

Per-machine streaming configuration section where machine_guid is replaced with the actual GUID of a specific child node

Configuration: cloud.conf

Handle: cloud_config

Section CONFIG_SECTION_GLOBAL

Global cloud connectivity configuration settings

Configuration: exporting.conf

Handle: exporting_config

Section CONFIG_SECTION_EXPORTING

Data export and external system integration

Configuration: claim.conf

Handle: claim_config

Section CONFIG_SECTION_GLOBAL

Global cloud claiming configuration settings

Configuration: ebpf.conf

Handle: collector_config

Section EBPF_GLOBAL_SECTION

eBPF collector global settings

Section EBPF_PROGRAMS_SECTION

eBPF program enable/disable configuration

Section NETDATA_EBPF_IPC_SECTION

eBPF Inter-Process Communication monitoring configuration

Configuration: cfg.conf

Handle: cfg

Section EBPF_GLOBAL_SECTION

eBPF collector global settings

Section EBPF_NETWORK_VIEWER_SECTION

eBPF network monitoring specific settings

Configuration: config.conf

Handle: config

Configuration: ebpf_filesystem.conf

Handle: fs_config

Section NETDATA_FILESYSTEM_CONFIG_NAME

Filesystem monitoring configuration

Configuration: modules->cfg.conf

Handle: modules->cfg

Section EBPF_GLOBAL_SECTION

eBPF collector global settings

Configuration: ebpf_socket.conf

Handle: socket_config

Section EBPF_NETWORK_VIEWER_SECTION

eBPF network monitoring specific settings

Configuration: sockets->config.conf

Handle: sockets->config

Section sockets->config_section

Web server socket configuration section for API and dashboard access endpoints

Configuration: ebpf_sync.conf

Handle: sync_config

Section NETDATA_SYNC_CONFIG_NAME

eBPF sync syscall monitoring configuration

Configuration: tmp_config.conf

Handle: tmp_config

Section section

Generic configuration section placeholder used in command-line tools

Section temp + offset + 1

Dynamically generated section name (internal use)