diff --git a/docs/Alerts & Notifications/Notifications/Notifications.mdx b/docs/Alerts & Notifications/Notifications/Notifications.mdx index 7e6d95eb2..be9bb0b17 100644 --- a/docs/Alerts & Notifications/Notifications/Notifications.mdx +++ b/docs/Alerts & Notifications/Notifications/Notifications.mdx @@ -128,6 +128,15 @@ Netdata ships with hundreds of pre-configured alerts. You can also create your o - **[Alerts Configuration Manager](/docs/alerts-&-notifications/creating-alerts-with-the-alerts-configuration-manager)** — Visual UI wizard for creating and editing alerts - **[Manual configuration](/docs/alerts-&-notifications/alert-configuration-reference)** — Edit `health.d/*.conf` files directly for full control over alert syntax +## On-Call Rotations and Escalation + +Netdata does not provide a native on-call rotation, escalation, or shift-scheduling engine. These capabilities are handled by the dedicated incident-management integrations that Netdata delivers alerts to. + +- **From the Agent:** incident-management and incident-response integrations such as [PagerDuty](/docs/alerts-&-notifications/notifications/agent-dispatched-notifications/pagerduty), [Opsgenie](/docs/alerts-&-notifications/notifications/agent-dispatched-notifications/opsgenie), [SIGNL4](/docs/alerts-&-notifications/notifications/agent-dispatched-notifications/signl4), and [ilert](/docs/alerts-&-notifications/notifications/agent-dispatched-notifications/ilert), where you define on-call schedules, escalation policies, and shift rotations. See the full list of [supported Agent integrations](https://learn.netdata.cloud/docs/alerts-&-notifications/notifications/agent-dispatched-notifications). +- **From Cloud:** PagerDuty is available as a [paid-plan notification method](/docs/alerts-&-notifications/notifications/centralized-cloud-notifications/centralized-cloud-notifications-reference#service-classification). + +To use on-call rotations, configure one of these integrations to receive your Netdata alerts, then set up your rotations, escalation policies, and shift schedules inside that service. To change where alerts are sent, see [Notification Methods](#notification-methods) or the [Cloud notification methods](/docs/alerts-&-notifications/notifications/centralized-cloud-notifications/manage-notification-methods) guide. + ## Next Steps - [Set up Cloud Notifications](/docs/alerts-&-notifications/notifications/centralized-cloud-notifications/centralized-cloud-notifications-reference) diff --git a/docs/Collecting Metrics/Collectors/Storage and Filesystems/SMB Server Shares.mdx b/docs/Collecting Metrics/Collectors/Storage and Filesystems/SMB Server Shares.mdx index 6edcf1148..cc4fbdc58 100644 --- a/docs/Collecting Metrics/Collectors/Storage and Filesystems/SMB Server Shares.mdx +++ b/docs/Collecting Metrics/Collectors/Storage and Filesystems/SMB Server Shares.mdx @@ -43,7 +43,7 @@ This collector only supports collecting metrics from a single instance of this i #### Auto-Detection -This collector is disabled by default. When enabled, it automatically detects all available SMB share instances and metrics. +This collector is enabled by default and automatically detects all available SMB share instances and metrics. On systems where the 'SMB Server Shares' object is not available, no SMB metrics are collected. #### Limits diff --git a/docs/Collecting Metrics/StatsD.mdx b/docs/Collecting Metrics/StatsD.mdx index 1793bd123..9e9e67623 100644 --- a/docs/Collecting Metrics/StatsD.mdx +++ b/docs/Collecting Metrics/StatsD.mdx @@ -345,6 +345,40 @@ This structure allows for flexible and powerful metric configuration within Netd - **`update every (flushInterval) = 1s`** - How often StatsD updates Netdata charts - **`decimal detail = 1000`** - Controls decimal precision in gauges and histograms +### Accepting metrics from another machine (LAN/remote host) + +By default, Netdata's StatsD listener binds only to `localhost`, so it accepts metrics from applications running on the **same machine** as the Netdata Agent. To accept metrics from another machine on your network, change the `bind to` setting in the `[statsd]` section of `netdata.conf`. + +1. Open the StatsD configuration: + + ```bash + sudo ./edit-config netdata.conf + ``` + +2. In the `[statsd]` section, set `bind to` to the Netdata host's LAN IP address (for example, `192.168.1.10`): + + ``` + [statsd] + bind to = udp:192.168.1.10:8125 tcp:192.168.1.10:8125 + ``` + + To listen on all interfaces instead of a single IP, bind to `0.0.0.0`: + + ``` + [statsd] + bind to = udp:0.0.0.0:8125 tcp:0.0.0.0:8125 + ``` + +3. [Restart](/docs/netdata-agent/maintenance/service-control) the Agent so the new binding takes effect. + +4. On the sending machine, point your application's StatsD client at the Netdata host's IP address and port `8125`, using either UDP or TCP. For client library examples, see [Using StatsD with Different Languages](#using-statsd-with-different-languages). + +:::warning + +Binding `bind to` to `0.0.0.0` or a routable network interface exposes port `8125` to other hosts on the network. Restrict access with a firewall that only allows connections from your trusted machines, and avoid binding to public-facing interfaces. + +::: + ## StatsD Charts Netdata can visualize StatsD collected metrics in two ways: diff --git a/docs/Dashboards and Charts/Charts.mdx b/docs/Dashboards and Charts/Charts.mdx index 4440cde2e..45986c538 100644 --- a/docs/Dashboards and Charts/Charts.mdx +++ b/docs/Dashboards and Charts/Charts.mdx @@ -78,11 +78,14 @@ A **context** groups charts by metric type and displayed dimensions. Contexts de - `apps.cpu` for **Apps CPU Time** - `apps.mem` for **Apps Real Memory** +- `net.net` for **network Bandwidth** The part before the dot (`.`) is the **type**, while the part after is defined by the chart’s developer or its family. Contexts are also used for alert configurations. +The contexts available on any given node depend on which collectors are enabled and what hardware and software Netdata detects, so there is no fixed universal list. To discover the contexts on your own system, browse the [Metrics tab](/docs/dashboards-and-charts/tabs/metrics) — charts there are grouped into sections by context — open the **Chart info** dialog on any chart to see its context value, or query the `/api/v3/contexts` endpoint programmatically. Each collector documents the metrics and contexts it produces on its integration page, which you can browse through the **Integrations tab** in the dashboard. + ### Families A **family** represents a specific instance of a hardware or software resource that needs its own chart. @@ -187,12 +190,12 @@ The **Group by** dropdown allows you to apply different grouping strategies on t ![Group by dropdown](https://user-images.githubusercontent.com/43294513/235468819-3af5a1d3-8619-48fb-a8b7-8e8b4cf6a8ff.png) -| Grouping Option | Description | -|--------------------|------------------------------------------------------------| +| Grouping Option | Description | +|--------------------|-----------------------------------------------------------------------------------------------------------| | Group by Node | Display each node (hostname) as a separate labeled dimension in the chart legend, with one entry per node | -| Group by Instance | Summarize data by instance with one dimension per instance | -| Group by Dimension | Aggregate data across all nodes by dimension | -| Group by Label | Summarize data based on label values | +| Group by Instance | Summarize data by instance with one dimension per instance | +| Group by Dimension | Aggregate data across all nodes by dimension | +| Group by Label | Summarize data based on label values | :::tip @@ -229,11 +232,11 @@ Each chart has a default aggregation function, which you can adjust as needed: When selecting aggregation functions over time, charts may offer dropdown menus for **Percentiles** and **Trimmed Mean / Median** selection. Below are examples of these dropdowns: -### Percentile Selection Example: +### Percentile Selection Example ![Percentile selection dropdown](https://user-images.githubusercontent.com/70198089/236410299-de5f3367-f3b0-4beb-a73f-a49007c543d4.png) -### Trimmed Mean / Median Selection Example: +### Trimmed Mean / Median Selection Example ![Trimmed Mean or Median selection dropdown](https://user-images.githubusercontent.com/70198089/236410858-74b46af9-280a-4ab2-ad26-5a6aa9403aa8.png) diff --git a/docs/Developer and Contributor Corner/Database Engine.mdx b/docs/Developer and Contributor Corner/Database Engine.mdx index 637f60855..4ce4b484d 100644 --- a/docs/Developer and Contributor Corner/Database Engine.mdx +++ b/docs/Developer and Contributor Corner/Database Engine.mdx @@ -127,6 +127,8 @@ data from lower tiers, so that the aggregation they provide will be accurate. Configuring how the number of tiers and the disk space allocated to each tier is how you can [change how long netdata stores metrics](/docs/netdata-agent/configuration/database#tiers). +For how `update every` controls each tier's granularity and interacts with retention time and disk size, see [Update Every and Tier Granularity](/docs/netdata-agent/configuration/database#update-every-and-tier-granularity). + ### Data loss Until **hot pages** and **dirty pages** are **flushed** to disk, they are at risk (e.g., due to a crash, or diff --git a/docs/Netdata Agent/Configuration/Database.mdx b/docs/Netdata Agent/Configuration/Database.mdx index 40151c69a..22f8de3c3 100644 --- a/docs/Netdata Agent/Configuration/Database.mdx +++ b/docs/Netdata Agent/Configuration/Database.mdx @@ -76,6 +76,21 @@ You can change these limits using [`edit-config`](/docs/netdata-agent/configurat dbengine tier 2 retention time = 2y ``` +### 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: + +| `update every` | Tier 0 | Tier 1 (`×60`) | Tier 2 (`×60×60`) | +|:--------------:|:------:|:--------------:|:-----------------:| +| `1s` (default) | 1s | 60s | 3600s (1 hour) | +| `5s` | 5s | 300s | 18000s (5 hours) | + +Changing `update every` shifts the resolution of every tier proportionally, but the per-tier **retention time** limits (`dbengine tier X retention time`) are wall-clock durations and do **not** change automatically — you do not need to lower retention when you raise `update every`. + +Because a longer `update every` collects fewer samples per unit of time, the same per-tier disk size holds more time of data, so you may optionally reduce `dbengine tier X retention size`. For the full disk-sizing implications, see [Disk Requirements & Retention](/docs/netdata-agent/resource-utilization/disk-&-retention). + +In a Parent-Child setup, each Child streams its own `update every` to the Parent. The Parent stores that Child's metrics at the Child's collection interval, so a Child's `update every` affects only that Child's data granularity on the Parent. The Parent's `[db].update every` applies only to metrics the Parent collects locally. + ### Legacy Configuration
diff --git a/docs/Netdata Agent/Resource Utilization/Disk & Retention.mdx b/docs/Netdata Agent/Resource Utilization/Disk & Retention.mdx index a0829f45d..da6372fdc 100644 --- a/docs/Netdata Agent/Resource Utilization/Disk & Retention.mdx +++ b/docs/Netdata Agent/Resource Utilization/Disk & Retention.mdx @@ -49,6 +49,12 @@ gantt | `tier1` | 60 iterations of `tier0`, so when metrics are collected per-second, this tier is per-minute. | 16 bytes | 6 bytes | | `tier2` | 60 iterations of `tier1`, so when metrics are collected per second, this tier is per-hour. | 16 bytes | 18 bytes | +:::note + +Tier resolution shifts proportionally when you change `[db].update every`, and a longer `update every` lets the same per-tier disk size hold more time of data. See [Update Every and Tier Granularity](/docs/netdata-agent/configuration/database#update-every-and-tier-granularity) for the full mechanics and the Parent-Child behavior. + +::: + ### Default Disk Footprint Netdata Agent metrics storage is limited to 3 GiB by default (configurable), using 1 GiB per tier × 3 tiers. In total, with SQLite databases, alert transitions, and other metadata, expect about 4 GiB of disk usage under normal conditions. The default retention limits are: