From ea98d9a9e7875cf2dbf16af720da49321438cd86 Mon Sep 17 00:00:00 2001 From: Fotis Voutsas Date: Thu, 2 May 2024 13:52:31 +0300 Subject: Update Netdata subscription plans documentation (#17571) * update the plans doc to reflect plans available * update role base access model * view plan n billing updates * change wording * admin wording * update centralized cloud alerts reference doc * remove misleading plan indication * check links, and format files and tables * Update plans.md * Apply suggestions from code review * simplify language in edited docs, make them simpler to grasp * edits from product * Update alerts-configuration-manager.md * Apply suggestions from code review Co-authored-by: Hugo Valente <82235632+hugovalente-pm@users.noreply.github.com> --------- Co-authored-by: Ilya Mashchenko Co-authored-by: Shyam Sreevalsan Co-authored-by: Hugo Valente <82235632+hugovalente-pm@users.noreply.github.com> --- docs/cloud/alerts-configuration-manager.md | 86 ++++------ docs/cloud/alerts-notifications/notifications.md | 132 ++++------------ docs/cloud/insights/events-feed.md | 79 +++++----- docs/cloud/manage/plans.md | 127 +++------------ docs/cloud/manage/role-based-access.md | 190 +++++++++++------------ docs/cloud/manage/view-plan-billing.md | 159 ++++++------------- docs/monitor/view-active-alerts.md | 9 +- integrations/cloud-authentication/metadata.yaml | 8 +- integrations/cloud-notifications/metadata.yaml | 48 +++--- 9 files changed, 293 insertions(+), 545 deletions(-) diff --git a/docs/cloud/alerts-configuration-manager.md b/docs/cloud/alerts-configuration-manager.md index cedae0eb47..620764c188 100644 --- a/docs/cloud/alerts-configuration-manager.md +++ b/docs/cloud/alerts-configuration-manager.md @@ -1,71 +1,45 @@ # Creating Alerts with Netdata Alerts Configuration Manager -The Netdata Alerts Configuration Manager enables users with [Business subscriptions](https://www.netdata.cloud/pricing/) to create alerts from the Netdata Dashboard with an intuitive user interface. +The Netdata Alerts Configuration Manager enables subscribers to easily set up alerts directly from the Netdata Dashboard. More details on subscriptions can be found [here](https://www.netdata.cloud/pricing/). -## Using Alerts Configuration Manager - -1. Go to the **Metrics** tab and navigate to the chart you want to configure an alert for. - -2. Click the **Alert icon** on the top right corner of the chart. - - -3. The Alert Configuration Manager will open up with the default thresholds. You can modify the configuration as required and the alert definition on the right will be updated dynamically. - - -4. If you want more fine-grained control or access to more advanced settings, enable **Show advanced** - - -5. Copy the alert definition that is generated in the code box and add it to an existing [health configuration file](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#edit-health-configuration-files) or a new custom file under `/etc/netdata/health.d/` on a Parent Agent or a Standalone Child Agent. - - -6. Reload Netdata Alert Health checks `/usr/sbin/netdatacli reload-health` and the new alert is now configured. +## Using the Alerts Configuration Manager +1. Navigate to the **Metrics** tab and select the chart you want to configure for alerts. +2. Click the **Alert icon** in the top right corner of the chart. +3. The Alert Configuration Manager will open, showing the default thresholds. Modify these thresholds as needed, the alert definition on the right will update automatically. +4. For additional settings, toggle **Show advanced**. +5. After configuring the alert, copy the generated alert definition from the code box. Paste this into an existing or new custom health configuration file located at `/etc/netdata/health.d/` on a Parent Agent or a Standalone Child Agent. The guide to edit health configuration files is available [here](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#edit-health-configuration-files). +6. To activate the new alert, run the command `/usr/sbin/netdatacli reload-health`. ## Alerts Configuration Manager Sections -- **Alert Detection Method** - - An alert is triggered whenever a metric crosses a threshold: - - Based on a standard `threshold` - - Based on metric `variance` - - Based on the `anomaly rate` of the metric - +### Alert Detection Method + +An alert is triggered whenever a metric crosses a threshold: -- **Metrics Lookup, Filtering and Formula Section** - +- **Standard Threshold**: Triggered when a metric crosses a predefined value. +- **Metric Variance**: Triggered based on the variance of the metric. +- **Anomaly Rate**: Triggered based on the anomaly rate of the metric. - - **Metrics Lookup**: This is the **Evaluate** line of fields in the modal and it defines the parameters for the database lookup that is needed to get the value that will be compared against the alert definition. It corresponds to the [`lookup`](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-lookup) line of the Alert configuration file. The Alerts Configuration Manager provides a default selection for the lookup and can be modified to suit your requirements. The parameters that can be modified are: - - METHOD (`avg`, `sum`, `min`, `max`, `cv`, `stddev`) - - COMPUTATION (sum of all dimensions or individually for each dimension) - - DIMENSIONS (All dimensions, or a selection of dimensions) - - DURATION (the period in time to run the lookup) - - OPTIONS (`absolute`, `unaligned`, `percentage`, `min2max`) +### Metrics Lookup, Filtering and Formula Section - - **Alert Filtering**: This functionality can be accessed through the **Show advanced** checkbox and it allows for filtering the alert health checks to be run only for specific components of the infrastructure. It helps in achieving a fine-grained configuration for any given alert. - - `HOSTS` / `NODES` - By default all hosts are selected. You can pick nodes from the dropdown list, or enter a wildcard matching a list of hosts that you want the alert health check to run on. This field corresponds to the [`hosts`](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-hosts) line of the Alert configuration file. - - `INSTANCES` - All instances are selected by default. You can pick instances from the dropdown list, or enter a wildcard matching a list of instances that you want the alert health check to run on. This field corresponds to the [`charts`](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-charts) line of the Alert configuration file. - - `CHART LABELS` - All chart labels are selected by default. You can pick a chart label from the dropdown list or enter a wildcard matching a list of chart labels that you want the alert health check to run on. This field corresponds to the [`chart labels`](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-chart-labels) line of the Alert configuration file. - - `OS` - All Operating Systems are selected by default. You can choose which OS(s) an alert health check should run on. This field corresponds to the [`os`](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-os) line of the Alert configuration file. +You can read more about the different options in the [Alerts reference documentation](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md) - - **Formula / Calculation**: This field is available through the **Show advanced** checkbox and it is used to define a formula to be run on top of the `lookup` value. The result of the lookup is available in the `$this` variable, and after the formula is run, the result is also stored in `$this` and can be accessed while setting the alert thresholds. This field corresponds to the [`calc`](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-calc) line of the Alert configuration file. +- **Metrics Lookup**: Adjust the database lookup parameters directly in the UI, including method (`avg`, `sum`, `min`, `max`, etc.), computation style, dimensions, duration, and options like `absolute` or `percentage`. +- **Alert Filtering**: The **show advanced** checkbox allows filtering of alert health checks for specific infrastructure components. Options include selecting hosts, nodes, instances, chart labels, and operating systems. +- **Formula / Calculation**: The **show advanced** checkbox allows defining a formula for the metric value, which is then used to set alert thresholds. -- **Alerting conditions** - - - **Warning and Critical Thresholds**: These fields are used to set the thresholds for the `Warning` and `Critical` alert states, while also having the option to set the condition for the alert to be raised if it is `above` or `below` the given threshold. If the advanced settings are selected, a **formula** option can also be used, to define a custom formula instead of a threshold. These fields correspond to the [`warn` and `crit`](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-lines-warn-and-crit) lines of the Alert configuration file. - - **Recovery Thresholds**: This field is available through the **Show advanced** checkbox, and it is used to set the threshold that the metric value needs to meet to de-escalate from a given severity status, like `Critical to Warning` and from `Warning to Clear`. The logic is appended to the `warn` and `crit` lines of the Alert configuration file and resembles a one-line `IF-THEN-ELSE` clause. - - **Check Interval**: This field is used to define the frequency of the health check for the alert and corresponds to the [`every`](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-every) line of the Alert configuration file. - - **Delay Notifications**: This field is available through the **Show advanced** checkbox and it is used to set delay parameters on notifications for an alert severity `escalation` or `de-escalation`. It corresponds to the [`delay`](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-delay) line of the Alert configuration file. +### Alerting Conditions - - **Agent Specific Options**: These options are only available on the `Netdata Agent` and not honored on `Netdata Cloud`. They can be accessed through the **Show advanced** checkbox. - - - **Repeat Notifications**: This field defines the repeat frequency for the alert notification when the alert is in either `warning` or `critical` status and corresponds to the [`repeat`](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-repeat) line of the Alert configuration file. - - **Send to**: This field is used to define a user role to which the alert notifications will be sent. If set to `silent`, then the alert won't be sent to any role. It corresponds to the [`to`](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-to) line of the Alert configuration file. - - **Custom Exec Script**: This field is used to define a custom script that will be executed when the alert is triggered (but needs to be carefully designed as it needs to call the `health_alarm_notify.sh` module) and corresponds to the [`exec`](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-exec) line of the Alert configuration file. +- **Thresholds**: Set thresholds for warning and critical alert states, specifying whether the alert should trigger above or below these thresholds. Advanced settings allow for custom formulas. + - **Recovery Thresholds**: Set thresholds for downgrading the alert from critical to warning or from warning to clear. +- **Check Interval**: Define how frequently the health check should run. +- **Delay Notifications**: Manage notification delays for alert escalations or de-escalations. +- **Agent Specific Options**: Options exclusive to the Netdata Agent, like repeat notification frequencies and notification recipients. + - **Custom Exec Script**: Define custom scripts to execute when an alert triggers. -- **Alert Name, Description and Summary Section** - +### Alert Name, Description and Summary Section - - **Alert Template Name**: This field uniquely identifies an alert and corresponds to the [`template`](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-alarm-or-template) field of the Alert configuration file. - The Alerts Configuration Manager provides a default name for an Alert template but we recommend you modify this to have a meaningful name for your configured alert. - - **Alert Template Description**: This field provides a brief explanation of the alert and corresponds to the [`info`](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-info) line of the Alert configuration file. - - **Alert Summary**: This field enables the users to create a custom title for the alert notification (via [Notification integrations](https://learn.netdata.cloud/docs/alerting/notifications/centralized-cloud-notifications)) and corresponds to the [`summary`](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-summary) line of the Alert configuration file. +- **Alert Template Name**: Provide a unique name for the alert. +- **Alert Template Description**: Offer a brief explanation of what the alert monitors. +- **Alert Summary**: Create a custom title for alert notifications, which can be integrated with centralized notification systems available [here](https://learn.netdata.cloud/docs/alerting/notifications/centralized-cloud-notifications). diff --git a/docs/cloud/alerts-notifications/notifications.md b/docs/cloud/alerts-notifications/notifications.md index 51d04e38fe..5e1257094c 100644 --- a/docs/cloud/alerts-notifications/notifications.md +++ b/docs/cloud/alerts-notifications/notifications.md @@ -1,130 +1,56 @@ -# Cloud alert notifications +# Centralized Cloud Notifications Reference -import Callout from '@site/src/components/Callout' +Netdata Cloud sends alert notifications for nodes in warning, critical, or unreachable states, ensuring alerts are managed centrally and efficiently. -Netdata Cloud can send centralized alert notifications to your team whenever a node enters a warning, critical, or -unreachable state. By enabling notifications, you ensure no alert, on any node in your infrastructure, goes unnoticed by -you or your team. +## Benefits of Centralized Notifications -Having this information centralized helps you: -* Have a clear view of the health across your infrastructure, seeing all alerts in one place. -* Easily [set up your alert notification process](https://github.com/netdata/netdata/blob/master/docs/cloud/alerts-notifications/manage-notification-methods.md): -methods to use and where to use them, filtering rules, etc. -* Quickly troubleshoot using [Metric Correlations](https://github.com/netdata/netdata/blob/master/docs/cloud/insights/metric-correlations.md) -or [Anomaly Advisor](https://github.com/netdata/netdata/blob/master/docs/dashboard/anomaly-advisor-tab.md) +- Consolidate health status views across all infrastructure in one place. +- Set up and [manage your alert notifications easily](https://github.com/netdata/netdata/blob/master/docs/cloud/alerts-notifications/manage-notification-methods.md). +- Expedite troubleshooting with tools like [Metric Correlations](https://github.com/netdata/netdata/blob/master/docs/cloud/insights/metric-correlations.md) and the [Anomaly Advisor](https://github.com/netdata/netdata/blob/master/docs/dashboard/anomaly-advisor-tab.md). -If a node is getting disconnected often or has many alerts, we protect you and your team from alert fatigue by sending -you a flood protection notification. Getting one of these notifications is a good signal of health or performance issues -on that node. +To avoid notification overload, **flood protection** is triggered when a node frequently disconnects or sends excessive alerts, highlighting potential issues. -Admins must enable alert notifications for their [Space(s)](https://github.com/netdata/netdata/blob/master/docs/cloud/alerts-notifications/manage-notification-methods.md#manage-space-notification-settings). All users in a -Space can then personalize their notifications settings from within their [account -menu](https://github.com/netdata/netdata/blob/master/docs/cloud/alerts-notifications/#manage-user-notification-settings). +Admins must [enable alert notifications](https://github.com/netdata/netdata/blob/master/docs/cloud/alerts-notifications/manage-notification-methods.md#manage-space-notification-settings) for their Space(s). All users can then customize their notification preferences through their [account menu](https://github.com/netdata/netdata/blob/master/docs/cloud/alerts-notifications/#manage-user-notification-settings). - +> **Note** +> +> Centralized alerts in Netdata Cloud are separate from the [Netdata Agent](https://github.com/netdata/netdata/blob/master/docs/monitor/enable-notifications.md) notifications. Alerts must be [configured individually](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md) on each node. -Centralized alert notifications from Netdata Cloud is a independent process from [notifications from -Netdata](https://github.com/netdata/netdata/blob/master/docs/monitor/enable-notifications.md). You can enable one or the other, or both, based on your needs. However, -the alerts you see in Netdata Cloud are based on those streamed from your Netdata-monitoring nodes. If you want to tweak -or add new alert that you see in Netdata Cloud, and receive via centralized alert notifications, you must -[configure](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md) each node's alert watchdog. +## Alert Notifications - +Notifications can be sent via email or through third-party services like PagerDuty or Slack. Admins manage notification settings for the entire Space, while individual users can personalize settings in their profile. -## Alert notifications - -Netdata Cloud can send centralized alert notifications to your team whenever a node enters a warning, critical, or unreachable state. By enabling notifications, -you ensure no alert, on any node in your infrastructure, goes unnoticed by you or your team. - -If a node is getting disconnected often or has many alerts, we protect you and your team from alert fatigue by sending you a flood protection notification. -Getting one of these notifications is a good signal of health or performance issues on that node. - -Alert notifications can be delivered through different methods, these can go from an Email sent from Netdata to the use of a 3rd party tool like PagerDuty. - -Notification methods are classified on two main attributes: -* Service level: Personal or System -* Service classification: Community or Business - -Only administrators are able to manage the space's alert notification settings. -All users in a Space can personalize their notifications settings, for Personal service level notification methods, from within their profile menu. - -> ⚠️ Netdata Cloud supports different notification methods and their availability will depend on the plan you are at. -> For more details check [Service classification](#service-classification) or [netdata.cloud/pricing](https://www.netdata.cloud/pricing). - -### Service level +### Service Level #### Personal -The notifications methods classified as **Personal** are what we consider generic, meaning that these can't have specific rules for them set by the administrators. - -These notifications are sent to the destination of the channel which is a user-specific attribute, e.g. user's e-mail, and the users are the ones that will then be able to -manage what specific configurations they want for the Space / Room(s) and the desired Notification level, they can achieve this from their User Profile page under -**Notifications**. - -One example of such a notification method is the E-mail. +Notifications are sent to user-specific destinations, such as email, which are managed by users under their profile settings. #### System -For **System** notification methods, the destination of the channel will be a target that usually isn't specific to a single user, e.g. slack channel. - -These notification methods allow for fine-grain rule settings to be done by administrators and more than one configuration can exist for them since. You can specify -different targets depending on Rooms or Notification level settings. - -Some examples of such notification methods are: Webhook, PagerDuty, Slack. +These notifications go to general targets like a Slack channel, with admins setting rules for notification targets based on workspace or alert level. -### Service classification +### Service Classification #### Community -Notification methods classified as Community can be used by everyone independent on the plan your space is at. -These are: Email and discord - -#### Pro - -Notification methods classified as Pro are only available for **Pro** and **Business** plans -These are: webhook +Available to all plans, includes basic methods like Email and Discord. #### Business -Notification methods classified as Business are only available for **Business** plans -These are: PagerDuty, Slack, Opsgenie - -## Silencing Alert notifications - -Netdata Cloud provides you a Silencing Rule engine which allows you to mute alert notifications. This muting action is specific to alert state transition notifications, it doesn't include node unreachable state transitions. - -The Silencing Rule engine is flexible and allows you to enter silence rules for the two main entities involved on alert notifications and can be set using different attributes. The main entities you can enter are **Nodes** and **Alerts** which can be used in combination or isolation to target specific needs - see some examples [here](https://github.com/netdata/netdata/blob/master/docs/cloud/alerts-notifications/manage-alert-notification-silencing-rules.md#silencing-rules-examples). - -### Scope definition for Nodes -* **Space:** silencing the space, selecting `All Rooms`, silences all alert state transitions from any node claimed to the space. -* **War Room:** silencing a specific room will silence all alert state transitions from any node in that room. Please note if the node belongs to -another room which isn't silenced it can trigger alert notifications to the users with membership to that other room. -* **Node:** silencing a specific node can be done for the entire space, selecting `All Rooms`, or for specific war room(s). The main difference is -if the node should be silenced for the entire space or just for specific rooms (when specific rooms are selected only users with membership to that room won't receive notifications). +Exclusive to [paid plans](https://github.com/netdata/netdata/blob/master/docs/cloud/manage/plans.md), includes advanced services like PagerDuty and Slack. -### Scope definition for Alerts -* **Alert name:** silencing a specific alert name silences all alert state transitions for that specific alert. -* **Alert context:** silencing a specific alert context will silence all alert state transitions for alerts targeting that chart context, for more details check [alert configuration docs](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-on). -* **Alert role:** silencing a specific alert role will silence all the alert state transitions for alerts that are configured to be specific role recipients, for more details check [alert configuration docs](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#alert-line-to). +## Alert Notification Silencing Rules -Beside the above two main entities there are another two important settings that you can define on a silencing rule: -* Who does the rule affect? **All user** in the space or **Myself** -* When does is to apply? **Immediately** or on a **Schedule** (when setting immediately you can set duration) +Netdata Cloud offers a silencing rule engine to mute alert notifications based on specific conditions related to nodes or alert types. Learn how to manage these settings [here](https://github.com/netdata/netdata/blob/master/docs/cloud/alerts-notifications/manage-alert-notification-silencing-rules.md). -For further help on setting alert notification silencing rules go to [Manage Alert Notification Silencing Rules](https://github.com/netdata/netdata/blob/master/docs/cloud/alerts-notifications/manage-alert-notification-silencing-rules.md). +## Flood Protection -> ⚠️ This feature is only available for [Netdata paid plans](https://github.com/netdata/netdata/edit/master/docs/cloud/manage/plans.md). +If a node repeatedly changes state or fires alerts, flood protection limits notifications to prevent overload. You can still access node details through Netdata Cloud or directly via the local Agent dashboard. -## Flood protection +## Anatomy of an Email Alert Notification -If a node has too many state changes like firing too many alerts or going from reachable to unreachable, Netdata Cloud -enables flood protection. As long as a node is in flood protection mode, Netdata Cloud does not send notifications about -this node. Even with flood protection active, it is possible to access the node directly, either via Netdata Cloud or -the local Agent dashboard at `http://NODE:19999`. - -## Anatomy of an alert notification - -Email alert notifications show the following information: +Email notifications provide comprehensive details: - The Space's name - The node's name @@ -138,10 +64,4 @@ Email alert notifications show the following information: - Threshold for triggering the given alert state - Calculation or database lookups that Netdata uses to compute the value - Source of the alert, including which file you can edit to configure this alert on an individual node - -Email notifications also feature a **Go to Node** button, which takes you directly to the offending chart for that node -within Cloud's embedded dashboards. - -Here's an example email notification for the `ram_available` chart, which is in a critical state: - -![Screenshot of an alert notification email from Netdata Cloud](https://user-images.githubusercontent.com/1153921/87461878-e933c480-c5c3-11ea-870b-affdb0801854.png) +- Direct link to the node’s chart in Cloud dashboards. diff --git a/docs/cloud/insights/events-feed.md b/docs/cloud/insights/events-feed.md index b0cfb3f7d5..1aa0b08a18 100644 --- a/docs/cloud/insights/events-feed.md +++ b/docs/cloud/insights/events-feed.md @@ -10,55 +10,54 @@ At a high-level view, these are the domains from which the Events feed will prov > > Based on your space's plan, different allowances are defined to query past data. -| **Domains of events** | **Community** | **Business** | -| :-- | :-- | :-- | -| **[Auditing events](#auditing-events)** -
Events related to actions done on your Space, e.g. invite user, change user role or change plan.| 4 hours | 90 days | -| **[Topology events](#topology-events)**
Node state transition events, e.g. live or offline.| 4 hours | 14 days | -| **[Alert events](#alert-events)**
Alert state transition events, can be seen as an alert history log.| 4 hours | 90 days | +| **Domains of events** | **Community** | **Homelab** | **Business** | **Enterprise On-Premise** | +|:------------------------------------------------------------------------------------------------------------------------------------------------|:--------------|:------------|:-------------|:--------------------------| +| **[Auditing events](#auditing-events)**

Events related to actions done on your Space, e.g. invite user, change user role or change plan.

| 4 hours | 90 days | 90 days | User dependent | +| **[Topology events](#topology-events)**

Node state transition events, e.g. live or offline.

| 4 hours | 14 days | 14 days | User dependent | +| **[Alert events](#alert-events)**

Alert state transition events, can be seen as an alert history log.

| 4 hours | 90 days | 90 days | User dependent | ### Auditing events -| **Event name** | **Description** | **Example** | -| :-- | :-- | :-- | -| Space Created | The space was created.| Space `Acme Space` was **created** | -| Room Created | A room was created on the Space.| Room `DB Servers` was **created** by `John Doe` | -| Room Deleted | A room was deleted from the Space. | Room `DB servers` was **deleted** by `John Doe` | -| User Invited to Space | A user was invited to join the Space.| User `John Smith` was **invited** to this space by `Alan Doe` | -| User Uninvited from Space | An invitation for a user to join the space was revoked.| User `John Smith` was **uninvited** from this space | -| User Added to Space | A user was added to the Space from an invitation (user accepted the invitation).| User `John Smith` was **added** to this space by invite of `Alan Doe` | -| User Removed from Space | A user was added to the Space from an invitation. | User `John Smith` was **removed** from this space by `Alan Doe` | -| User Added to Room | A user was added to a room on the Space. | User `John Smith` was **added** to room `DB servers` | -| User Removed from Room | A user was removed from a room on the Space. | User `John Smith` was **removed** from room `DB Servers` by `Alan Doe` | -| User Space Properties Changed | The properties of a user on the Space have changed, e.g. change user role | User role for `John Smith` was **changed** to `troubleshooter` by `Alan Doe` | -| Node Added To Room | The node was added to a room on the Space. | Node `ip-xyz.ec2.internal` was **added** to room `DB Servers` by `John Doe` | -| Node Removed To Room | The node was removed from a room on the Space. | Node `ip-xyz.ec2.internal` was **removed** from room `DB Servers` by `John Doe` | -| Silencing Rule Created | A new alert notification silencing rule was created on the Space. | Silencing rule `DB Servers schedule silencing` on rooms `All nodes` and `DB Servers` was **created** by `John Smith` | -| Silencing Rule Changed | An existing alert notification silencing rule was modified on the Space. | Silencing rule `DB Servers schedule silencing` on rooms `All nodes` and `DB Servers` was **changed** by `John Doe` | -| Silencing Rule Deleted | An existing alert notifications silencing rule was removed from the Space. | Silencing rule `DB Servers schedule silencing` on rooms `All nodes` and `DB Servers` was **changed** by `Alan Smith` | -| Space Claiming Token Created | A Space Claiming Token was created. | Claiming Token was created by user `John Doe` | -| Space Claiming Token Revoked | A Space Claiming Token was revoked. | Claiming Token `_OtF2ssjrv` was revoked by user `John Doe` | +| **Event name** | **Description** | **Example** | +|:------------------------------|:---------------------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------| +| Space Created | The space was created. | Space `Acme Space` was **created** | +| Room Created | A room was created on the Space. | Room `DB Servers` was **created** by `John Doe` | +| Room Deleted | A room was deleted from the Space. | Room `DB servers` was **deleted** by `John Doe` | +| User Invited to Space | A user was invited to join the Space. | User `John Smith` was **invited** to this space by `Alan Doe` | +| User Uninvited from Space | An invitation for a user to join the space was revoked. | User `John Smith` was **uninvited** from this space | +| User Added to Space | A user was added to the Space from an invitation (user accepted the invitation). | User `John Smith` was **added** to this space by invite of `Alan Doe` | +| User Removed from Space | A user was added to the Space from an invitation. | User `John Smith` was **removed** from this space by `Alan Doe` | +| User Added to Room | A user was added to a room on the Space. | User `John Smith` was **added** to room `DB servers` | +| User Removed from Room | A user was removed from a room on the Space. | User `John Smith` was **removed** from room `DB Servers` by `Alan Doe` | +| User Space Properties Changed | The properties of a user on the Space have changed, e.g. change user role | User role for `John Smith` was **changed** to `troubleshooter` by `Alan Doe` | +| Node Added To Room | The node was added to a room on the Space. | Node `ip-xyz.ec2.internal` was **added** to room `DB Servers` by `John Doe` | +| Node Removed To Room | The node was removed from a room on the Space. | Node `ip-xyz.ec2.internal` was **removed** from room `DB Servers` by `John Doe` | +| Silencing Rule Created | A new alert notification silencing rule was created on the Space. | Silencing rule `DB Servers schedule silencing` on rooms `All nodes` and `DB Servers` was **created** by `John Smith` | +| Silencing Rule Changed | An existing alert notification silencing rule was modified on the Space. | Silencing rule `DB Servers schedule silencing` on rooms `All nodes` and `DB Servers` was **changed** by `John Doe` | +| Silencing Rule Deleted | An existing alert notifications silencing rule was removed from the Space. | Silencing rule `DB Servers schedule silencing` on rooms `All nodes` and `DB Servers` was **changed** by `Alan Smith` | +| Space Claiming Token Created | A Space Claiming Token was created. | Claiming Token was created by user `John Doe` | +| Space Claiming Token Revoked | A Space Claiming Token was revoked. | Claiming Token `_OtF2ssjrv` was revoked by user `John Doe` | ### Topology events -| **Event name** | **Description** | **Example** | -| :-- | :-- | :-- | -| Node Became Live | The node is collecting and streaming metrics to Cloud.| Node `netdata-k8s-state-xyz` was **live** | -| Node Became Stale | The node is offline and not streaming metrics to Cloud. It can show historical data from a parent node. | Node `ip-xyz.ec2.internal` was **stale** | -| Node Became Offline | The node is offline, not streaming metrics to Cloud and not available in any parent node.| Node `ip-xyz.ec2.internal` was **offline** | -| Node Created | The node is created but it is still `Unseen` on Cloud, didn't establish a successful connection yet.| Node `ip-xyz.ec2.internal` was **created** | -| Node Removed |The node was removed from the Space, for example by using the `Delete` action on the node. This is a soft delete in that the node gets marked as deleted, but retains the association with this space. If it becomes live again, it will be restored (see `Node Restored` below) and reappear in this space as before. | Node `ip-xyz.ec2.internal` was **deleted (soft)** | -| Node Restored | The node was restored. See `Node Removed` above. | Node `ip-xyz.ec2.internal` was **restored** | -| Node Deleted | The node was deleted from the Space. This is a hard delete and no information on the node is retained. | Node `ip-xyz.ec2.internal` was **deleted (hard)** | -| Agent Connected | The agent connected to the Cloud MQTT server (Agent-Cloud Link established).
These events can only be seen on _All nodes_ War Room. | Agent with claim ID `7d87bqs9-cv42-4823-8sd4-3614548850c7` has connected to Cloud. | -| Agent Disconnected | The agent disconnected from the Cloud MQTT server (Agent-Cloud Link severed).
These events can only be seen on _All nodes_ War Room. | Agent with claim ID `7d87bqs9-cv42-4823-8sd4-3614548850c7` has disconnected from Cloud: **Connection Timeout**. | -| Space Statistics | Daily snapshot of space node statistics.
These events can only be seen on _All nodes_ War Room. | Space statistics. Nodes: **22 live**, **21 stale**, **18 removed**, **61 total**. | - +| **Event name** | **Description** | **Example** | +|:--------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------------------------------------------| +| Node Became Live | The node is collecting and streaming metrics to Cloud. | Node `netdata-k8s-state-xyz` was **live** | +| Node Became Stale | The node is offline and not streaming metrics to Cloud. It can show historical data from a parent node. | Node `ip-xyz.ec2.internal` was **stale** | +| Node Became Offline | The node is offline, not streaming metrics to Cloud and not available in any parent node. | Node `ip-xyz.ec2.internal` was **offline** | +| Node Created | The node is created but it is still `Unseen` on Cloud, didn't establish a successful connection yet. | Node `ip-xyz.ec2.internal` was **created** | +| Node Removed | The node was removed from the Space, for example by using the `Delete` action on the node. This is a soft delete in that the node gets marked as deleted, but retains the association with this space. If it becomes live again, it will be restored (see `Node Restored` below) and reappear in this space as before. | Node `ip-xyz.ec2.internal` was **deleted (soft)** | +| Node Restored | The node was restored. See `Node Removed` above. | Node `ip-xyz.ec2.internal` was **restored** | +| Node Deleted | The node was deleted from the Space. This is a hard delete and no information on the node is retained. | Node `ip-xyz.ec2.internal` was **deleted (hard)** | +| Agent Connected | The agent connected to the Cloud MQTT server (Agent-Cloud Link established).
These events can only be seen on _All nodes_ War Room. | Agent with claim ID `7d87bqs9-cv42-4823-8sd4-3614548850c7` has connected to Cloud. | +| Agent Disconnected | The agent disconnected from the Cloud MQTT server (Agent-Cloud Link severed).
These events can only be seen on _All nodes_ War Room. | Agent with claim ID `7d87bqs9-cv42-4823-8sd4-3614548850c7` has disconnected from Cloud: **Connection Timeout**. | +| Space Statistics | Daily snapshot of space node statistics.
These events can only be seen on _All nodes_ War Room. | Space statistics. Nodes: **22 live**, **21 stale**, **18 removed**, **61 total**. | ### Alert events -| **Event name** | **Description** | **Example** | -| :-- | :-- | :-- | -| Node Alert State Changed | These are node alert state transition events and can be seen as an alert history log. You will be able to see transitions to or from any of these states: Cleared, Warning, Critical, Removed, Error or Unknown | Transition to Cleared:
`httpcheck_web_service_bad_status` for `httpcheck_netdata_cloud.request_status` on `netdata-parent-xyz` recovered with value **8.33%**

Transition from Cleared to Warning or Critical:
`httpcheck_web_service_bad_status` for `httpcheck_netdata_cloud.request_status` on `netdata-parent-xyz` was raised to **WARNING** with value **10%**

Transition from Warning to Critical:
`httpcheck_web_service_bad_status` for `httpcheck_netdata_cloud.request_status` on `netdata-parent-xyz` escalated to **CRITICAL** with value **25%**

Transition from Critical to Warning:
`httpcheck_web_service_bad_status` for `httpcheck_netdata_cloud.request_status` on `netdata-parent-xyz` was demoted to **WARNING** with value **10%**

Transition to Removed:
Alert `httpcheck_web_service_bad_status` for `httpcheck_netdata_cloud.request_status` on `netdata-parent-xyz` is no longer available, state can't be assessed.

Transition to Error:
For this alert `httpcheck_web_service_bad_status` related to `httpcheck_netdata_cloud.request_status` on `netdata-parent-xyz` we couldn't calculate the current value ⓘ| +| **Event name** | **Description** | **Example** | +|:-------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Node Alert State Changed | These are node alert state transition events and can be seen as an alert history log. You will be able to see transitions to or from any of these states: Cleared, Warning, Critical, Removed, Error or Unknown | Transition to Cleared:
`httpcheck_web_service_bad_status` for `httpcheck_netdata_cloud.request_status` on `netdata-parent-xyz` recovered with value **8.33%**

Transition from Cleared to Warning or Critical:
`httpcheck_web_service_bad_status` for `httpcheck_netdata_cloud.request_status` on `netdata-parent-xyz` was raised to **WARNING** with value **10%**

Transition from Warning to Critical:
`httpcheck_web_service_bad_status` for `httpcheck_netdata_cloud.request_status` on `netdata-parent-xyz` escalated to **CRITICAL** with value **25%**

Transition from Critical to Warning:
`httpcheck_web_service_bad_status` for `httpcheck_netdata_cloud.request_status` on `netdata-parent-xyz` was demoted to **WARNING** with value **10%**

Transition to Removed:
Alert `httpcheck_web_service_bad_status` for `httpcheck_netdata_cloud.request_status` on `netdata-parent-xyz` is no longer available, state can't be assessed.

Transition to Error:
For this alert `httpcheck_web_service_bad_status` related to `httpcheck_netdata_cloud.request_status` on `netdata-parent-xyz` we couldn't calculate the current value ⓘ | ## Who can access the events? diff --git a/docs/cloud/manage/plans.md b/docs/cloud/manage/plans.md index 9b21575fc2..27a1a1f000 100644 --- a/docs/cloud/manage/plans.md +++ b/docs/cloud/manage/plans.md @@ -1,123 +1,42 @@ -# Netdata Plans +# Netdata Subscription Plans -This page will guide you through the differences between the Community, Pro, Business and Enterprise plans. +This page explains the Netdata subscription plan structure. -At Netdata, we believe in providing free and unrestricted access to high-quality monitoring solutions, and our commitment to this principle will not change. We offer our free SaaS offering - what we call **Community plan** - and Open Source Agent, which features unlimited nodes and users, unlimited metrics, and retention, providing real-time, high-fidelity, out-of-the-box infrastructure monitoring for packaged applications, containers, and operating systems. +## Overview -We also provide paid subscriptions that designed to provide additional features and capabilities for businesses that need tighter and customizable integration of the free monitoring solution to their processes. These are divided into three different plans: **Pro**, **Business**, and **Enterprise**. Each plan will offers a different set of features and capabilities to meet the needs of businesses of different sizes and with different monitoring requirements. +Netdata offers a **Community plan**, a free SaaS and Open Source Agent, while also it offers paid subscriptions — **Homelab**, **Business**, and **Enterprise On-Premise** — providing key business features and unlimited access to your dashboards. -> ### Note -> To not disrupt the existing space user's access rights we will keep them in the **Early Bird** plan. The reason for this is to allow users to -> keep using the legacy **Member** role with the exact same permissions as it has currently. -> -> If you move from the **Early Bird** plan to a paid plan, you will not be able to return to the **Early Bird** plan again. The **Community** free plan will always be available to you, but it does not allow -> you to invite or change users using the Member role. See more details on our [roles and plans](https://github.com/netdata/netdata/blob/master/docs/cloud/manage/role-based-access.md#what-roles-are-available) documentation. +For more info visit the [Netdata Cloud Pricing](https://netdata.cloud/pricing) page. ### Plans -The plan is an attribute that is directly attached to your space(s) and that dictates what capabilities and customizations you have on your space. If you have different spaces you can have different Netdata plans on them. This gives you flexibility to chose what is more adequate for your needs on each of your spaces. - -Netdata Cloud plans, with the exception of Community, work as subscriptions and overall consist of two pricing components: - -* A flat fee component, that is applied on yearly subscriptions for the [comitted-nodes](#committed-nodes) charte (space subscription fee has been waived off) -* An on-demand metered component, that is related to your usage of Netdata which directly links to the [number of nodes you have running](#running-nodes-and-billing) - -Netdata provides two billing frequency options: - -* Monthly - Pay as you go, where we charge both the flat fee and the on-demand component every month -* Yearly - Annual prepayment, where we charge upfront the flat fee and committed amount related to your estimated usage of Netdata (more details [here](#committed-nodes)) - -For more details on the plans and subscription conditions please check . - -#### Running nodes and billing - -The only dynamic variable we consider for billing is the number of concurrently running nodes or agents. We only charge you for your active running nodes, so we don't count: - -* offline nodes -* stale nodes, nodes that are available to query through a Netdata parent agent but are not actively connecting metrics at the moment - -To ensure we don't overcharge you due to sporadic spikes throughout a month or even at a certain point in a day we are: - -* Calculate a daily P90 figure for your running nodes. To achieve that, we take a daily snapshot of your running nodes, and using the node state change events (live, offline) we guarantee that a daily P90 figure is calculated to remove any daily spikes -* On top of the above, we do a running P90 calculation from the start to the end of your billing cycle. Even if you have an yearly billing frequency we keep a monthly subscription linked to that to identify any potential overage over your [committed nodes](#committed-nodes). - -#### Committed nodes - -When you subscribe to an Yearly plan you will need to specify the number of nodes that you will commit to. On these nodes, a discounted price of less 25% than the original cost per node of the plan is applied. This amount will be part of your annual prepayment. - -``` -Node plan discounted price x committed nodes x 12 months -``` - -If, for a given month, your usage is over these committed nodes we will charge the original cost per node for the nodes above the committed number. - -#### Plan changes and credit balance +Each plan is linked to a Space, defining the capabilities and customizations available. Different Spaces can have different plans, offering flexibility based on your needs. -It is ok to change your mind. We allow to change your plan, billing frequency or adjust the committed nodes, on yearly plans, at any time. +Netdata Cloud plans (excluding Community) involve: -To achieve this you can check the [Update plan](https://github.com/netdata/netdata/blob/master/docs/cloud/manage/view-plan-billing.md#update-plan) section. +- A yearly flat fee for [committed nodes](#committed-nodes) +- An on-demand metered component based on the [number of running nodes](#running-nodes-and-billing) -> ⚠️ On a downgrade (going to a new plan with less benefits) or cancellation of an active subscription, please note that you will have all your notification methods configurations active **for a period of 24 hours**. -> After that, any notification methods unavailable in your new plan at that time will be automatically disabled. You can always re-enable them once you move to a paid plan that includes them. +Billing options include monthly (pay-as-you-go) and yearly (annual prepayment). For more details, visit [Netdata Cloud Pricing](https://netdata.cloud/pricing). -> ⚠️ Downgrade or cancellation may affect users in your Space. Please check what roles are available on the [each plans](https://github.com/netdata/netdata/blob/master/docs/cloud/manage/plans.md#areas-impacted-by-plans). Users with unavailable roles on the new plan will immediately have restricted access to the Space. +## Running Nodes and Billing -> ⚠️ Any credit given to you will be available to use on future paid subscriptions with us. It will be available until the **end of the following year**. +Billing is based on the number of active nodes. We do not charge for offline or stale nodes. We calculate daily and running P90 figures to ensure fair billing by smoothing out sporadic spikes in node activity. -### Areas impacted by plans +## Committed Nodes -##### Role-Based Access model +Yearly plans require specifying a number of committed nodes, which receive a discounted rate. Usage above these committed nodes incurs charges at the standard rate. -Depending on the plan associated to your space you will have different roles available: +## Plan Changes and Credit Balance -| **Role** | **Community** | **Pro** | **Business** | **Early Bird** | -| :-- | :--: | :--: | :--: | :--: | -| **Administrators**

Users with this role can control Spaces, War Rooms, Nodes, Users and Billing.

They can also access any War Room in the Space.

| :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | -| **Managers**

Users with this role can manage War Rooms and Users.

They can access any War Room in the Space.

| - | - | :heavy_check_mark: | - | -| **Troubleshooters**

Users with this role can use Netdata to troubleshoot, not manage entities.

They can access any War Room in the Space.

| - | :heavy_check_mark: | :heavy_check_mark: | - | -| **Observers**

Users with this role can only view data in specific War Rooms.

💡 Ideal for restricting your customer's access to their own dedicated rooms.

| - | - | :heavy_check_mark: | - | -| **Billing**

Users with this role can handle billing options and invoices.

| - | - | :heavy_check_mark: | - | -| **Member** ⚠️ Legacy role

Users with this role can create War Rooms and invite other Members.

They can only see the War Rooms they belong to and all Nodes in the All Nodes room.

| - | - | - | :heavy_check_mark: | +You can change your plan, billing frequency, or committed nodes at any time. For guidance, see [updating your plan](https://github.com/netdata/netdata/blob/master/docs/cloud/manage/view-plan-billing.md#update-a-subscription-plan). -For more details check the documentation under [Role-Based Access model](https://github.com/netdata/netdata/blob/master/docs/cloud/manage/role-based-access.md). - -##### Events feed - -The plan you have subscribed on your space will determine the amount of historical data you will be able to query: - -| **Type of events** | **Community** | **Pro** | **Business** | -| :-- | :-- | :-- | :-- | -| **Auditing events** - COMING SOON

Events related to actions done on your Space, e.g. invite user, change user role or create room.

| 4 hours | 7 days | 90 days | -| **Topology events**

Node state transition events, e.g. live or offline.

| 4 hours | 7 days | 14 days | -| **Alert events**

Alert state transition events, can be seen as an alert history log.

| 4 hours | 7 days | 90 days | - -For more details check the documentation under [Events feed](https://github.com/netdata/netdata/blob/master/docs/cloud/insights/events-feed.md). - -##### Notification integrations - -The plan on your space will determine what type of notifications methods will be available to you: - -* **Community** - Email and Discord -* **Pro** - Email, Discord and webhook -* **Business** - Unlimited, this includes Slack, PagerDuty, Opsgenie etc. - -For more details check the documentation under [Alert Notifications](https://github.com/netdata/netdata/blob/master/docs/cloud/alerts-notifications/notifications.md#alert-notifications). - -##### Alert notification silencing rules - -The plan on your space will determine if you are able to add alert notification silencing rules since this feature will only be available for paid plans: **Pro** or **Business**. - -For more details check the documentation under [Alert Notifications](https://github.com/netdata/netdata/blob/master/docs/cloud/alerts-notifications/notifications.md#silencing-alert-notifications). - -### Related Topics - -#### **Related Concepts** - -* [Spaces](https://github.com/netdata/netdata/blob/master/docs/cloud/manage/organize-your-infrastrucutre-invite-your-team.md#netdata-cloud-spaces) -* [Alert Notifications](https://github.com/netdata/netdata/blob/master/docs/cloud/alerts-notifications/notifications.md) -* [Events feed](https://github.com/netdata/netdata/blob/master/docs/cloud/insights/events-feed.md) -* [Role-Based Access model](https://github.com/netdata/netdata/blob/master/docs/cloud/manage/role-based-access.md) +> **Note** +> +> - Changes like downgrades or cancellations keep notification configurations active for 24 hours. After that, any methods not supported by the new plan are disabled. +> - Changes may restrict user access in your Space. Review role availability under [each plan](#areas-that-change-upon-subscription). +> - Any credits are valid until the end of the following year. -#### Related Tasks +## Areas That Change Upon Subscription -* [View Plan & Billing](https://github.com/netdata/netdata/blob/master/docs/cloud/manage/view-plan-billing.md) +Please refer to the [Netdata Cloud Pricing](https://netdata.cloud/pricing) page for more information on what each plan provides. diff --git a/docs/cloud/manage/role-based-access.md b/docs/cloud/manage/role-based-access.md index 4bfb65f2e2..849eecb347 100644 --- a/docs/cloud/manage/role-based-access.md +++ b/docs/cloud/manage/role-based-access.md @@ -7,18 +7,14 @@ Netdata Cloud's role-based-access mechanism allows you to control what functiona With the advent of the paid plans we revamped the roles to cover needs expressed by Netdata users, like providing more limited access to their customers, or being able to join any room. We also aligned the offered roles to the target audience of each plan. The end result is the following: -| **Role** | **Community** | **Pro** | **Business** | **Early Bird** | -| :-- | :--: | :--: | :--: | :--: | -| **Administrators**

Users with this role can control Spaces, War Rooms, Nodes, Users and Billing.

They can also access any War Room in the Space.

| :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | -| **Managers**

Users with this role can manage War Rooms and Users.

They can access any War Room in the Space.

| - | - | :heavy_check_mark: | - | -| **Troubleshooters**

Users with this role can use Netdata to troubleshoot, not manage entities.

They can access any War Room in the Space.

| - | :heavy_check_mark: | :heavy_check_mark: | - | -| **Observers**

Users with this role can only view data in specific War Rooms.

💡 Ideal for restricting your customer's access to their own dedicated rooms.

| - | - | :heavy_check_mark: | - | -| **Billing**

Users with this role can handle billing options and invoices.

| - | - | :heavy_check_mark: | - | -| **Member** ⚠️ Legacy role

Users with this role can create War Rooms and invite other Members.

They can only see the War Rooms they belong to and all Nodes in the All Nodes room.

| - | - | - | :heavy_check_mark: | - -## What happens to the previous Member role? - -We will maintain a Early Bird plan for existing users, which will continue to provide access to the Member role. +| **Role** | **Community** | **Homelab** | **Business** | **Enterprise On-Premise** | +|:-----------------------------------------------------------------------------------------------------------------------------------------------------------