You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are introducing the new percentage capacity metric `nginxaas.capacity.percentage`, which more accurately estimates the load on your deployment than the old consumed NCUs metric. The new capacity metric expresses the capacity consumed as a percentage of the deployment's total capacity. Please modify any alerts and monitoring on deployment performance to take account of the new percentage capacity metric. The consumed NCUs metric is now on the path to deprecation. Please see [Scaling guidance]({{< relref "/nginxaas-azure/quickstart/scaling.md">}}) for more details.
19
+
14
20
## February 10, 2025
15
21
16
22
- {{% icon-feature %}} **NGINXaaS Load Balancer for Kubernetes is now Generally Available**
| ncu.provisioned || count | The number of successfully provisioned NCUs during the aggregation interval. During scaling events, this may lag behind `ncu.requested` as the system works to achieve the request. Available for Standard plan deployments. | deployment |
37
37
| ncu.requested || count | The requested number of NCUs during the aggregation interval. Describes the goal state of the system. Available for Standard plan deployments. | deployment |
38
-
|ncu.consumed|| count | The estimated number of NCUs used to handle the current traffic. This may burst above the `ncu.provisioned`. This can be used to guide scaling out or in to match your workload. See [Scaling Guidance]({{< relref "/nginxaas-azure/quickstart/scaling.md#iterative-approach" >}}) for details. Available for Standard plan deployments. | deployment |
38
+
|nginxaas.capacity.percentage|| count | The percentage of the deployment's total capacity being used. This may burst above 100%. This can be used to guide scaling out or in to match your workload. See [Scaling Guidance]({{< relref "/nginxaas-azure/quickstart/scaling.md#iterative-approach" >}}) for details. Available for Standard plan deployments. | deployment |
39
39
| system.worker_connections | pid process_name | count | The number of nginx worker connections used on the dataplane. This metric is one of the factors which determines the deployment's consumed NCU value. | deployment |
40
40
| nginxaas.certificates | name status | count | The number of certificates added to the NGINXaaS deployment dimensioned by the name of the certificate and its status. Refer to [Certificate Health]({{< relref "/nginxaas-azure/getting-started/ssl-tls-certificates/overview.md#monitor-certificates" >}}) to learn more about the status dimension. | deployment |
41
41
| nginxaas.maxmind | status | count | The status of any MaxMind license in use for downloading geoip2 databases. Refer to [License Health]({{< relref "/nginxaas-azure/quickstart/geoip2.md#monitoring" >}}) to learn more about the status dimension. | deployment |
42
42
43
43
{{</bootstrap-table>}}
44
44
45
+
{{< note >}}The `ncu.consumed` metric is now deprecated and is on the path to retirement. Please change any alerting on this metric to use the new Capacity Percentage metric.{{< /note >}}
| system.interface.total_bytes| interface | count | System Interface Total Bytes, sum of bytes_sent and bytes_rcvd. | deployment |
225
227
| system.interface.egress_throughput| interface | count | System Interface Egress Throughput, i.e. bytes sent per second| deployment |
228
+
| system.listener_backlog.max| interface | count | The fullness (expressed as a fraction) of the fullest backlog queue for a listen address. | deployment |
229
+
| system.listener_backlog.length| interface | count | The number of items in a specific backlog queue, labelled by listen address. | deployment |
230
+
| system.listener_backlog.queue_limit| interface | count | The capacity of a specific backlog queue, labelled by listen address. | deployment |
Copy file name to clipboardExpand all lines: content/nginxaas-azure/quickstart/scaling.md
+30-28Lines changed: 30 additions & 28 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,12 +15,12 @@ An NGINXaaS deployment can be scaled out to increase the capacity (increasing th
15
15
16
16
In this document you will learn:
17
17
18
-
* What an NGINX Capacity Unit (NCU) is
19
-
* How to manually scale your deployment
20
-
* How to enable autoscaling on your deployment
21
-
* What capacity restrictions apply for your Marketplace plan
22
-
* How to monitor capacity usage
23
-
* How to estimate the amount of capacity to provision
18
+
- What an NGINX Capacity Unit (NCU) is
19
+
- How to manually scale your deployment
20
+
- How to enable autoscaling on your deployment
21
+
- What capacity restrictions apply for your Marketplace plan
22
+
- How to monitor capacity usage
23
+
- How to estimate the amount of capacity to provision
24
24
25
25
## NGINX Capacity Unit (NCU)
26
26
@@ -50,11 +50,11 @@ To enable autoscaling using the Azure Portal,
50
50
51
51
### Scaling rules
52
52
53
-
NGINXaaS automatically adjusts the number of NCUs based on "scaling rules." A scaling rule defines when to scale, what direction to scale, and how much to scale. NGINXaaS will evaluate the following scaling rules, in order, based on consumed and provisioned NCU metrics.
53
+
NGINXaaS automatically adjusts the number of NCUs based on "scaling rules." A scaling rule defines when to scale, what direction to scale, and how much to scale. NGINXaaS will evaluate the following scaling rules, in order, based on the percentage capacity consumed metric and the provisioned NCU metric.
54
54
55
-
-*Moderate Increase Rule*: Over the last 5 minutes, if the average consumed NCUs is greater than or equal to 70% of the average provisioned NCUs, increase capacity by 20%.
56
-
-*Urgent Increase Rule*: Over the last minute, if the number of consumed NCUs is greater than or equal to 85% of the number of provisioned NCUs, increase capacity by 20%.
57
-
-*Decrease Rule*: Over the last 10 minutes, if the average consumed NCUs is less than or equal to 60% of the average provisioned NCUs, decrease capacity by 10%.
55
+
-*Moderate Increase Rule*: Over the last 5 minutes, if the average capacity consumed is greater than or equal to 70% of the average provisioned NCUs, increase capacity by 20%.
56
+
-*Urgent Increase Rule*: Over the last minute, if the capacity consumed is greater than or equal to 85% of the number of provisioned NCUs, increase capacity by 20%.
57
+
-*Decrease Rule*: Over the last 10 minutes, if the average capacity consumed is less than or equal to 60% of the average provisioned NCUs, decrease capacity by 10%.
58
58
59
59
To avoid creating a loop between scaling rules, NGINXaaS will not apply a scaling rule if it predicts that doing so would immediately trigger an opposing rule. For example, if the the "Urgent Increase Rule" is triggered due to a sudden spike in traffic, but the new capacity will cause the "Decrease Rule" to trigger immediately after, the autoscaler will not increase capacity. This prevents the deployment's capacity from increasing and decreasing erratically.
60
60
@@ -63,6 +63,7 @@ To avoid creating a loop between scaling rules, NGINXaaS will not apply a scalin
63
63
The following table outlines constraints on the specified capacity based on the chosen Marketplace plan, including the minimum capacity required for a deployment to be highly available, the maximum capacity, and what value the capacity must be a multiple of. By default, an NGINXaaS for Azure deployment will be created with the corresponding minimum capacity.
@@ -78,51 +79,52 @@ The following table outlines constraints on the specified capacity based on the
78
79
79
80
NGINXaaS provides metrics for visibility of the current and historical capacity values. These metrics, in the `NGINXaaS Statistics` namespace, include:
80
81
81
-
* NCUs Requested: `ncu.requested` -- how many NCUs have been requested using the API. This is the goal state of the system at that point in time.
82
-
* NCUs Provisioned: `ncu.provisioned` -- how many NCUs have been successfully provisioned by the service.
83
-
* This is the basis for [billing]({{< relref "/nginxaas-azure/billing/overview.md" >}}).
84
-
* This may differ from `ncu.requested` temporarily during scale-out/scale-in events or during automatic remediation for a hardware failure.
85
-
* NCUs Consumed: `ncu.consumed` -- how many NCUs the current workloadis using.
86
-
* If this is under 60% of the provisioned capacity, consider scaling in to reduce costs. If this is over 70% of the provisioned capacity, consider scaling out; otherwise, requests may fail or take longer than expected. Alternatively, enable autoscaling, so your deployment can automatically scale based on the consumed and provisioned capacity.
87
-
* This value may burst higher than `ncu.requested` due to variation in provisioned hardware. You will still only be billed for the minimum of `ncu.requested` and `ncu.provisioned`.
82
+
- NCUs Requested: `ncu.requested` -- how many NCUs have been requested using the API. This is the goal state of the system at that point in time.
83
+
- NCUs Provisioned: `ncu.provisioned` -- how many NCUs have been successfully provisioned by the service.
84
+
- This is the basis for [billing]({{< relref "/nginxaas-azure/billing/overview.md" >}}).
85
+
- This may differ from `ncu.requested` temporarily during scale-out/scale-in events or during automatic remediation for a hardware failure.
86
+
- Capacity Percentage: `nginxaas.capacity.percentage` -- the percentage of the current workload's total capacity that is being used.
87
+
- If this is under 60%, consider scaling in to reduce costs. If this is over 70%, consider scaling out; otherwise, requests may fail or take longer than expected. Alternatively, enable autoscaling, so your deployment can automatically scale based on the amount of capacity consumed.
88
+
- This value may burst higher than `ncu.requested` due to variation in provisioned hardware. You will still only be billed for the minimum of `ncu.requested` and `ncu.provisioned`.
88
89
89
90
See the [Metrics Catalog]({{< relref "/nginxaas-azure/monitoring/metrics-catalog.md" >}}) for a reference of all metrics.
90
91
91
92
{{< note >}}These metrics aren't visible unless enabled, see how to [Enable Monitoring]({{< relref "/nginxaas-azure/monitoring/enable-monitoring.md" >}}) for details.{{< /note >}}
93
+
{{< note >}}The NCUs Consumed metric is now deprecated and is on the path to retirement. Please change any alerting on this metric to use the new Capacity Percentage metric.{{< /note >}}
92
94
93
95
## Estimating how many NCUs to provision
94
96
95
97
To calculate how many NCUs to provision, take the highest value across the parameters that make up an NCU:
96
98
97
-
* CPU
98
-
* Bandwidth
99
-
* Concurrent connections
99
+
- CPU
100
+
- Bandwidth
101
+
- Concurrent connections
100
102
101
103
Example 1: "I need to support 2,000 concurrent connections but only 4 Mbps of traffic. I need 52 ACUs." You would need `Max(52/20, 4/60, 2000/400)` = `Max(2.6, 0.07, 5)` = At least 5 NCUs.
102
104
103
105
Example 2: "I don't know any of these yet!" Either start with the minimum and [adjust capacity](#adjusting-capacity) with the [iterative approach](#iterative-approach) described below, or [enable autoscaling](#autoscaling).
104
106
105
-
In addition to the maximum capacity needed, we recommend adding a 10% to 20% buffer of additional NCUs to account for unexpected spikes in traffic. Monitor the [NCUs Consumed metric](#metrics) over time to determine your peak usage levels and adjust your requested capacity accordingly.
107
+
In addition to the maximum capacity needed, we recommend adding a 10% to 20% buffer of additional capacity to account for unexpected spikes in traffic. Monitor the [Percentage Capacity Metric](#metrics) over time to determine your peak usage levels and adjust your requested capacity accordingly.
106
108
107
109
### Iterative approach
108
110
109
111
1. Make an estimate by either:
110
-
* using the [Usage and Cost Estimator]({{< relref "/nginxaas-azure/billing/usage-and-cost-estimator.md" >}})
111
-
* compare to a [reference workload](#reference-workloads)
112
-
2. Observe the `ncu.consumed`[metric](#metrics) in Azure Monitor of your workload
112
+
- using the [Usage and Cost Estimator]({{< relref "/nginxaas-azure/billing/usage-and-cost-estimator.md" >}})
113
+
- compare to a [reference workload](#reference-workloads)
114
+
2. Observe the `nginxaas.capacity.percentage`[metric](#metrics) in Azure Monitor of your workload
113
115
3. Decide what headroom factor you wish to have
114
-
4. Multiply the headroom factor by the consumed NCUs to get the target NCUs.
116
+
4. Multiply the headroom factor by the provisioned NCUs to get the target NCUs.
115
117
5.[Adjust capacity](#adjusting-capacity) to the target NCUs
116
118
6. repeat from step 2 -- it is always good to check back after making a change
117
119
118
120
*Example*:
119
121
120
122
1. I am really unsure what size I needed so I just specified the default capacity, `20NCUs`.
121
-
2. I observe that my `ncu.consumed` is currently at `18NCUs`.
123
+
2. I observe that my `nginxaas.capacity.percentage` is currently at `90%`.
122
124
3. This is early morning, traffic. I think midday traffic could be 3x what it is now.
123
-
4.`18 * 3 = 54` is my target capacity.
125
+
4.`90% * 3 = 270%. 2.7 * 20 NCUs = 54 NCUs` 54 NCUs is my target capacity.
124
126
5. I can see that I need to scale by multiples of 10 so I'm going to scale out to `60NCUs`.
125
-
6. At midday I can see that I overestimated the traffic I would be getting and it was still a busy day. We peaked at `41NCUs`, let me scale in to `50NCUs` to reduce my cost.
127
+
6. At midday I can see that I overestimated the traffic I would be getting and it was still a busy day. We peaked at `68%` of capacity, let me scale in to `50NCUs` to reduce my cost.
0 commit comments