diff --git a/docs/Alerts & Notifications/Notifications/Centralized Cloud Notifications/Manage alert notification silencing rules.mdx b/docs/Alerts & Notifications/Notifications/Centralized Cloud Notifications/Manage alert notification silencing rules.mdx index 400ef532c..e85c80101 100644 --- a/docs/Alerts & Notifications/Notifications/Centralized Cloud Notifications/Manage alert notification silencing rules.mdx +++ b/docs/Alerts & Notifications/Notifications/Centralized Cloud Notifications/Manage alert notification silencing rules.mdx @@ -152,6 +152,22 @@ You will see configured Alert notification silencing rules for the space (if you **Immediate**: From now until turned off or until specific duration (start and end date automatically set). **Scheduled**: Specify start and end time when the rule becomes active and inactive (time set according to your browser local timezone). + +**Recurring**: Set a repeating schedule for the rule to activate and deactivate automatically on a defined cadence. Configure: + +- **Starts at**: the date and time of the first occurrence +- **Lasts until**: the end time of the first occurrence (the gap between start and end defines how long each occurrence stays active) +- **Repeat**: the recurrence pattern (e.g. weekly on Friday) +- **Timezone**: the timezone the schedule is anchored to (typically your local one), so the window follows that zone's wall-clock time even across DST changes + +With a recurring rule in place, the rule activates automatically at the configured time, silences notifications for the duration, and deactivates until the next occurrence — no manual toggling needed. + +:::note + +Silencing only suppresses notifications. The alert still evaluates and remains visible in dashboards and alert views, so you don't lose any history. + +::: + ## Step-by-Step Wizards for Common Use Cases @@ -184,6 +200,38 @@ You will see configured Alert notification silencing rules for the space (if you +
+Recurring Weekly Alert Silencing
+ +**Use Case**: An alert fires predictably every week during a known window (e.g. a long-running MySQL job every Friday evening to Saturday morning). + +**Configuration Steps**: + +1. Choose "All users" or "Myself" based on impact +2. Set name: "Weekly MySQL Long-Running Query - Friday Night" +3. **Node Criteria**: + - Rooms: All Rooms (or the specific room containing the node) + - Nodes: [specific node name, e.g. child1]] + - Host Labels: * +4. **Alert Criteria**: + - Alert Name: [exact alert name as it appears in the notification] + - Alert Context: * + - Alert Role: * +5. **Timing**: Recurring + - Starts at: the coming Friday at the time the noise usually begins, e.g. Friday 18:00 + - Lasts until: the following Saturday morning, e.g. Saturday 09:00 + - Repeat: weekly on Friday + - Timezone: your local timezone + +**Validation Checklist**: + +- Node name matches exactly +- Alert name matches exactly as it appears in notifications +- Timezone is set to your local timezone +- Start and end times reflect the correct window + +
+
Team-Specific Alert Silencing
@@ -309,17 +357,20 @@ Before activating any silencing rule, verify: | **Role-Based Control** | Alert role: webmaster | Silence all alerts for specific role | | **Granular Alert Control** | Specific alert + specific node | Targeted silencing for known issues | | **Storage Maintenance** | Alert: disk_space_usage, Instance: specific mount | Maintenance on specific storage volumes | +| **Recurring Weekly Window** | Specific node + specific alert name, Recurring | Predictable weekly alert window (e.g. Friday night job) | ## Detailed Examples Reference -| Rule Name | Rooms | Nodes | Host Label | Alert Name | Alert Context | Alert Instance | Alert Role | Description | -|----------------------------------|--------------------|--------|------------------------|------------------------------------------------|---------------|------------------------|------------|-------------------------------------------------------------------------------------| -| Space silencing | All Rooms | * | * | * | * | * | * | Silences entire space, all nodes, all users. Infrastructure-wide maintenance window | -| DB Servers Rooms | PostgreSQL Servers | * | * | * | * | * | * | Silences nodes in PostgreSQL Servers Room only, not All Nodes Room | -| Node child1 | All Rooms | child1 | * | * | * | * | * | Silences all Alert state transitions for node child1 in all Rooms | -| Production nodes | All Rooms | * | environment:production | * | * | * | * | Silences Alert state transitions for nodes with environment:production label | -| Third party maintenance | All Rooms | * | * | httpcheck_posthog_netdata_cloud.request_status | * | * | * | Silences specific Alert during third-party partner maintenance | -| Intended stress usage on CPU | All Rooms | * | * | * | system.cpu | * | * | Silences specific Alerts across all nodes and their CPU cores | -| Silence role webmaster | All Rooms | * | * | * | * | * | webmaster | Silences all Alerts configured with role webmaster | -| Silence Alert on node | All Rooms | child1 | * | httpcheck_posthog_netdata_cloud.request_status | * | * | * | Silences specific Alert on child1 node | -| Disk Space Alerts on mount point | All Rooms | * | * | disk_space_usage | disk.space | disk_space_opt_baddisk | * | Silences specific Alert instance on all nodes /opt/baddisk | +| Rule Name | Rooms | Nodes | Host Label | Alert Name | Alert Context | Alert Instance | Alert Role | Description | +|----------------------------------|--------------------|---------------|------------------------|------------------------------------------------|---------------|------------------------|------------|-------------------------------------------------------------------------------------| +| Space silencing | All Rooms | * | * | * | * | * | * | Silences entire space, all nodes, all users. Infrastructure-wide maintenance window | +| DB Servers Rooms | PostgreSQL Servers | * | * | * | * | * | * | Silences nodes in PostgreSQL Servers Room only, not All Nodes Room | +| Node child1 | All Rooms | child1 | * | * | * | * | * | Silences all Alert state transitions for node child1 in all Rooms | +| Production nodes | All Rooms | * | environment:production | * | * | * | * | Silences Alert state transitions for nodes with environment:production label | +| Third party maintenance | All Rooms | * | * | httpcheck_posthog_netdata_cloud.request_status | * | * | * | Silences specific Alert during third-party partner maintenance | +| Intended stress usage on CPU | All Rooms | * | * | * | system.cpu | * | * | Silences specific Alerts across all nodes and their CPU cores | +| Silence role webmaster | All Rooms | * | * | * | * | * | webmaster | Silences all Alerts configured with role webmaster | +| Silence Alert on node | All Rooms | child1 | * | httpcheck_posthog_netdata_cloud.request_status | * | * | * | Silences specific Alert on child1 node | +| Disk Space Alerts on mount point | All Rooms | * | * | disk_space_usage | disk.space | disk_space_opt_baddisk | * | Silences specific Alert instance on all nodes /opt/baddisk | +| Weekly recurring window | All Rooms | db-node-1 | * | mysql_10s_slow_queries | * | * | * + | Silences a predictable weekly alert every Friday evening to Saturday morning | diff --git a/docs/Collecting Metrics/Collectors configuration.mdx b/docs/Collecting Metrics/Collectors configuration.mdx index ee36ae0fa..6d9c1bf4f 100644 --- a/docs/Collecting Metrics/Collectors configuration.mdx +++ b/docs/Collecting Metrics/Collectors configuration.mdx @@ -56,7 +56,7 @@ You can modify how often collectors gather metrics to optimize CPU usage. This c ### Global 1. Open `netdata.conf` using [`edit-config`](/docs/netdata-agent/configuration#edit-configuration-files). -2. Set the `update every` value (default is `1`, meaning one-second intervals): +2. Set the `update every` value (default is `1`, meaning one-second intervals). Valid values are 1–3600 seconds; the Agent clamps anything outside this range to the nearest bound and logs a warning: ```text [db] update every = 2 diff --git a/docs/Dashboards and Charts/Charts.mdx b/docs/Dashboards and Charts/Charts.mdx index 45986c538..8bda987bf 100644 --- a/docs/Dashboards and Charts/Charts.mdx +++ b/docs/Dashboards and Charts/Charts.mdx @@ -197,6 +197,16 @@ The **Group by** dropdown allows you to apply different grouping strategies on t | Group by Dimension | Aggregate data across all nodes by dimension | | Group by Label | Summarize data based on label values | +The **Group by** option works together with the [Aggregate Functions dropdown](#aggregate-functions-dropdown). **Group by** decides how time-series are organized into chart lines, while the **Aggregate function** decides how multiple values combine *within* each group. Changing either one can change the number you see, even on the same chart. + +A common case is the network Bandwidth chart (`net.net`). Its dimensions are directional — `received` is displayed as positive and `sent` as negative (opposite signs, on an area chart). With **Group by Dimension**, `received` and `sent` stay as separate lines, so you can read each direction independently. With **Group by Instance**, both directions collapse into a single line per interface. Under the **Sum** aggregate function, the positive `received` and negative `sent` values then add up to a *net* value (received minus sent), not the total traffic — which is why the same interface can show very different numbers under the two groupings. + +:::tip + +To view total traffic on a specific interface, keep **Group by Dimension** and read `received` and `sent` separately — each represents one direction. Use the **Instances** dropdown to filter the chart to a single interface. Avoid using **Sum** to combine dimensions that have opposite signs: it produces a net difference, not a total. + +::: + :::tip To see each node's hostname in the chart legend (the Dimensions Bar at the bottom of the chart), use **Group by Node**. Each node appears as a separate labeled dimension. diff --git a/docs/Netdata AI/MCP/MCP Connections.mdx b/docs/Netdata AI/MCP/MCP Connections.mdx index 92182979e..156d73d07 100644 --- a/docs/Netdata AI/MCP/MCP Connections.mdx +++ b/docs/Netdata AI/MCP/MCP Connections.mdx @@ -32,7 +32,9 @@ This is the reverse of connecting an AI client *to* Netdata. Here, **Netdata rea ![Choose an authentication method](https://raw.githubusercontent.com/netdata/docs-images/refs/heads/master/netdata-cloud/netdata-ai/mcp-connections-auth.png) -4. Provide the required configuration parameters — such as the connection name or account region — then click **Connect & discover tools**. +4. Provide the required configuration parameters — such as the connection name, or your account URL with the provider — then click **Connect & discover tools**. + + An **account URL** is the address you use to reach the provider, including your organization's subdomain. For PagerDuty that is `https://acme.pagerduty.com`, or `https://acme.eu.pagerduty.com` if your account is hosted in the EU. Netdata derives the correct regional endpoint from it, and refuses the connection if the account you authorize with is not the one configured here. ![Connection parameters](https://raw.githubusercontent.com/netdata/docs-images/refs/heads/master/netdata-cloud/netdata-ai/mcp-connections-connection.png) diff --git a/docs/Netdata Agent/Configuration/Database.mdx b/docs/Netdata Agent/Configuration/Database.mdx index 22f8de3c3..49439e999 100644 --- a/docs/Netdata Agent/Configuration/Database.mdx +++ b/docs/Netdata Agent/Configuration/Database.mdx @@ -78,7 +78,7 @@ You can change these limits using [`edit-config`](/docs/netdata-agent/configurat ### Update Every and Tier Granularity -`[db].update every` sets the base data collection interval. Tier 0 stores data at this interval, and every higher tier derives its granularity by multiplying from the tier below it. The per-tier multiplier is `dbengine tier X update every iterations` (`60` by default for each tier above 0), so the effective resolution of a tier is `update every` multiplied by every multiplier below it: +`[db].update every` sets the base data collection interval. It accepts whole-second values in the 1–3600 seconds range; values outside this range are clamped to the nearest bound. Tier 0 stores data at this interval, and every higher tier derives its granularity by multiplying from the tier below it. The per-tier multiplier is `dbengine tier X update every iterations` (`60` by default for each tier above 0), so the effective resolution of a tier is `update every` multiplied by every multiplier below it: | `update every` | Tier 0 | Tier 1 (`×60`) | Tier 2 (`×60×60`) | |:--------------:|:------:|:--------------:|:-----------------:| diff --git a/docs/Welcome to Netdata/Real-time Monitoring.mdx b/docs/Welcome to Netdata/Real-time Monitoring.mdx index 072105f5c..22e71a7ef 100644 --- a/docs/Welcome to Netdata/Real-time Monitoring.mdx +++ b/docs/Welcome to Netdata/Real-time Monitoring.mdx @@ -155,7 +155,7 @@ The shaded boxes show the slices where an event may fall. Because both collectio ### Why One Second is the Ideal Standard - **The Universal Baseline:** 1-second is the native rhythm of universal console tools (`top`, `vmstat`, `iostat`). -- **The Performance Sweet Spot:** Moving to sub-second intervals (e.g., 500ms) often doubles overhead for diminishing returns. One second is highly efficient and universally safe. +- **The Performance Sweet Spot:** Smaller intervals often doubles overhead for diminishing returns. One second is highly efficient and universally safe. - **Sufficient Resolution:** The vast majority of operational anomalies last multiple seconds; 1-second granularity captures them without loss of fidelity. - **Negligible Overhead:** Modern systems handle per-second sampling with ease; collecting a few thousand metrics per second consumes a trivial fraction of a single CPU core's billions of cycles.