The two-level configuration model

Configuring a fleet host by host does not scale, and configuring it only globally does not survive contact with reality - there is always one database server that needs a different disk threshold. Servers Sentinel resolves this the way CSS does: defaults cascade, and a local rule overrides one key without replacing the rest.

How the merge works

1. A global template defines the defaults for a configuration kind - collection intervals, thresholds, which collectors are enabled.
2. A server may carry an override: a patch containing only the keys that differ.
3. The agent is served the effective configuration, which is the template deep-merged with the override.

The important consequence is what happens when you edit the template. Because the override is a patch rather than a copy, a host that overrides disk.threshold still receives the new cpu.interval you just set globally. With copy-on-override - the model most tools use - that host would have quietly frozen at the values it had when the exception was created.

A worked example

The global template for the disk collector:

{
  "interval": "60s",
  "warn_percent": 85,
  "critical_percent": 95,
  "ignore_mounts": ["/snap"]
}

The database server, which runs hot on disk by design, overrides one key:

{
  "warn_percent": 92
}

What the agent on that host actually receives:

{
  "interval": "60s",
  "warn_percent": 92,
  "critical_percent": 95,
  "ignore_mounts": ["/snap"]
}

Raise critical_percent to 97 in the template later and this host gets 97 too, while keeping its 92. That is the whole point.

Where to draw the line

• Put anything that describes policy in the template: how often to collect, what counts as too full, which collectors are on.
• Put anything that describes this one machine in the override: a mount point to ignore, a service name that differs, a threshold the workload justifies.
• If you find yourself writing the same override on more than three hosts, it is not an exception - make a server group and template it.