@cryptotaxi247 / netdata-1
Code Commits Issues Pulls Sessions CI/CD
master
master
md 157 lines 5.95 KB
Rendered Raw
1 # Node Rule-Based Room Assignment
2
3 You can organize Nodes within Rooms automatically using configurable label-based rules. This feature simplifies infrastructure management by dynamically assigning Nodes to appropriate Rooms based on their host labels, eliminating manual intervention.
4
5 ## How It Works
6
7 Rules automatically assign Nodes to Rooms based on their host labels. When you create a rule, it continuously evaluates all Nodes and assigns them to the appropriate Room when they match your criteria.
8
9 **Rule Evaluation Order:**
10
11 - Exclusion rules are evaluated first
12 - Inclusion rules are evaluated second
13
14 In cases where both an inclusion and exclusion rule match, the exclusion rule takes precedence.
15
16 **Child Node Behavior**
17
18 - Child nodes that are only indirectly connected to Cloud (through a Parent Agent) are no longer automatically added to the same Room as the Parent.
19 - If your workflow depended on this automatic grouping, we recommend setting up Room assignment rules.
20
21 :::tip
22
23 This allows for fine-grained automatic assignment of nodes to Rooms based on hostnames or other host labels.
24
25 :::
26
27 :::important
28
29 - You can use rules with all Rooms except the "All Nodes" Room, as it includes all Nodes by default
30 - You need Node management permissions to create and edit Rules
31 - Rules are evaluated in real-time as labels change
32 - Exclusion rules always override inclusion rules
33
34 :::
35
36 ## Create Your First Rule
37
38 1. **Access Settings**
39 - Click ⚙️ (Room settings)
40 - Select "Nodes" tab
41
42 2. **Create Rule**
43 - Click "Add new Rule"
44 - Select Action (Include/Exclude)
45 - Add clause(s)
46 - Save changes
47
48 ## Rule Structure
49
50 You can build rules with the following elements:
51
52 | Element | Description |
53 |:------------|:--------------------------------------------------------------------------------------------------|
54 | **Action** | Determines whether matching Nodes will be included or excluded from the Room |
55 | **Clauses** | Set of conditions that determine which Nodes match the Rule (all must be satisfied - logical AND) |
56
57 Each clause consists of:
58
59 | Element | Description |
60 |:-------------|:-----------------------------|
61 | **Label** | The host label to check |
62 | **Value** | The comparison method |
63 | **Operator** | The value to compare against |
64
65 **Example Rule Structure:**
66
67 Below is a conceptual representation of a rule that includes all production database Nodes. The structure is shown in YAML format for clarity:
68
69 ```yaml
70 Action: Include
71 Clauses:
72 - Label: environment
73 Operator: equals
74 Value: production
75 - Label: service-type
76 Operator: equals
77 Value: database
78 ```
79
80 ### Comparison Operators
81
82 You can use the following operators to compare label values:
83
84 | Operator | Description |
85 |:------------|:----------------------------------------------------|
86 | equals | Matches the exact value |
87 | starts_with | Matches if the value begins with the specified text |
88 | ends_with | Matches if the value ends with the specified text |
89 | contains | Matches if the text appears anywhere in the value |
90
91 ## Membership Status
92
93 Nodes can have multiple membership types in a Room:
94
95 | Status | Description |
96 |:----------------|:---------------------------|
97 | STATIC | Manually added to the Room |
98 | RULE | Added by matching Rule(s) |
99 | STATIC and RULE | Both manual and Rule-based |
100
101 You can view each Node's membership status in the Room's Nodes table under the "Membership" column.
102
103 :::note
104
105 Group membership can be either STATIC or RULE—these work independently. A node can belong to groups through STATIC assignments (added manually) or through RULE assignments (matched automatically). RULEs cannot override STATIC memberships, and removing a node's STATIC membership does not affect its RULE memberships.
106
107 :::
108
109 <details>
110 <summary><strong>Example: Kubernetes environments</strong></summary><br/>
111
112 If you run multiple environments (such as dev, acc, and prod) in a single Kubernetes cluster, you can use custom host labels and room assignment rules to automatically route each environment's Nodes into separate Rooms.
113
114 ### Step 1 — Set host labels on child Nodes
115
116 Use the Helm chart's `child.configs.netdata.data` override to add a `[host labels]` section to every child Node. Create (or edit) an `override.yml` file:
117
118 ```yaml
119 child:
120 configs:
121 netdata:
122 data: |
123 [host labels]
124 environment = ${CLUSTER_ENV}
125 ```
126
127 Deploy or upgrade with the override:
128
129 ```bash
130 helm upgrade --install -f override.yml netdata netdata/netdata
131 ```
132
133 Set `CLUSTER_ENV` to `dev`, `acc`, or `prod` per cluster (or node pool) via your deployment tooling. For more Helm chart options, see the [Kubernetes installation guide](/packaging/installer/methods/kubernetes.md) and the [Helm chart reference](https://github.com/netdata/helmchart#configuration).
134
135 ### Step 2 — Create one Room per environment
136
137 In Netdata Cloud, create three Rooms — for example **Dev**, **Acc**, and **Prod**.
138
139 ### Step 3 — Create inclusion rules
140
141 In each Room's **Nodes** tab, add an inclusion rule that matches the `environment` host label:
142
143 | Room | Label | Operator | Value |
144 |:-----|:--------------|:---------|:-------|
145 | Dev | `environment` | equals | `dev` |
146 | Acc | `environment` | equals | `acc` |
147 | Prod | `environment` | equals | `prod` |
148
149 Rules are evaluated in real time — as soon as a child Node connects with the matching label, it is assigned to the corresponding Room.
150
151 :::note
152
153 Netdata deploys one child Agent per Kubernetes **node**, not per namespace or workload, and Room assignment rules apply to that child Agent as a whole. This pattern works best when each environment runs on dedicated nodes or node pools. If environments share the same nodes, host-label rules cannot route namespaces on those nodes into different Rooms.
154
155 :::
156
157 </details>