docs/developer-and-contributor-corner/dyncfg.md
:::tip
What You'll Learn
How to integrate Dynamic Configuration into your Netdata plugins and modules to create configurable, user-friendly monitoring solutions.
:::
Dynamic Configuration (DynCfg) enables your plugins and modules to expose their configurations through Netdata's unified interface. Instead of requiring users to manually edit configuration files, they can configure your plugin directly through the Netdata UI.
DynCfg provides a complete configuration management system that handles:
| Feature | What It Does |
|---|---|
| Configuration Registration | Register your plugin's configuration objects with Netdata |
| User Interface Generation | Automatically create UI forms from JSON Schema definitions |
| Configuration Persistence | Save and restore configurations across Netdata agent restarts |
| Validation Pipeline | Route configuration changes back to your plugin for validation |
| Standardized Experience | Provide users with consistent configuration workflows |
:::info
Key Benefits
:::
The system consists of four main parts working together:
graph TB
DM("**DynCfg Manager**
Tracks all configurations
Routes commands between
components")
IPA("**Internal Plugin API**
For modules built into
the Netdata agent")
EPA("**External Plugin API**
For independent plugins
using plugins.d protocol")
WA("**Web API**
Exposes configuration
management to users
and applications")
%% Connections showing data flow
DM <--> IPA
DM <--> EPA
DM <--> WA
%% Style definitions
classDef manager fill:#f9f9f9,stroke:#000000,stroke-width:3px,color:#000000,font-size:16px
classDef api fill:#ffeb3b,stroke:#000000,stroke-width:3px,color:#000000,font-size:16px
classDef web fill:#4caf50,stroke:#000000,stroke-width:3px,color:#000000,font-size:16px
%% Apply styles
class DM manager
class IPA,EPA api
class WA web
Choose the configuration type that matches your use case:
| Type | Use Case | Example |
|---|---|---|
| SINGLE | One standalone configuration | systemd-journal directories |
| TEMPLATE | Blueprint for creating multiple configurations | Nginx collector template |
| JOB | Specific instance created from a template | Individual Nginx server to monitor |
:::tip
Ready to make your plugin configurable through the Netdata UI? Choose your implementation guide and start building!
:::
Are you developing a module built into the Netdata agent?
š Internal DynCfg Implementation Guide
<details> <summary><strong>This guide covers:</strong></summary>Are you developing a standalone plugin that communicates with Netdata using the plugins.d protocol?
š External Plugin DynCfg Implementation Guide
<details> <summary><strong>This guide covers:</strong></summary>Study these real implementations to understand DynCfg patterns:
<details> <summary><strong>Health Alerts System (Internal Module)</strong></summary>The health module manages alert definitions through DynCfg:
src/health/health_dyncfg.cExternal C plugin that manages journal directory configurations:
src/collectors/systemd-journal.plugin/systemd-journal-dyncfg.cGo-based plugin managing multiple data collector configurations:
| Category | Best Practice | Description |
|---|---|---|
| Configuration Design | Use clear ID structure | Follow the component:category:name pattern consistently |
| Choose logical paths | The path parameter affects how configurations appear in the UI | |
| Design intuitive schemas | Include helpful descriptions and examples in your JSON Schema | |
| Validation and Error Handling | Validate thoroughly | Always validate configuration changes before accepting them |
| Provide helpful errors | Give users clear explanations when configurations are rejected | |
| Return appropriate codes | Use correct HTTP status codes for different situations | |
| User Experience | Respect type-action relationships | Different actions behave differently for each configuration type |
| Test your UI | Verify that your JSON Schema generates usable forms | |
| Document your options | Help users understand what each configuration option does |