Skip to content

Commit a3870f7

Browse files
authored
NLB-5919 Inform users of the new nginxaas.capacity.percentage metric (#247)
1 parent b78bff7 commit a3870f7

File tree

3 files changed

+41
-29
lines changed

3 files changed

+41
-29
lines changed

content/nginxaas-azure/changelog.md

+6
Original file line numberDiff line numberDiff line change
@@ -13,6 +13,12 @@ To see a list of currently active issues, visit the [Known issues]({{< relref "/
1313

1414
To review older entries, visit the [Changelog archive]({{< relref "/nginxaas-azure/changelog-archive" >}}) section.
1515

16+
## March 13, 2025
17+
18+
- {{% icon-resolved %}} **Percentage capacity metric**
19+
20+
We’re introducing the new percentage capacity metric, `nginxaas.capacity.percentage`, which provides a more accurate estimate of your deployment's load compared to the previous 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 use the new percentage capacity metric. The consumed NCUs metric is being deprecated and will be removed in the near future. Please see [Scaling guidance]({{< relref "/nginxaas-azure/quickstart/scaling.md">}}) for more details.
21+
1622
## March 5, 2025
1723

1824
- {{% icon-info %}} **Retirement of Standard Plan**

content/nginxaas-azure/monitoring/metrics-catalog.md

+6-1
Original file line numberDiff line numberDiff line change
@@ -37,13 +37,15 @@ The metrics are categorized by the namespace used in Azure Monitor. The dimensio
3737
| --------------------- | -------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
3838
| 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(s) only. | deployment |
3939
| ncu.requested | | count | The requested number of NCUs during the aggregation interval. Describes the goal state of the system. Available for Standard plans(s) only. | deployment |
40-
| 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(s) only. | deployment |
40+
| nginxaas.capacity.percentage | | count | The percentage of the deployment's total capacity being used. This can be used to guide scaling your workload. See [Scaling Guidance]({{< relref "/nginxaas-azure/quickstart/scaling.md#iterative-approach" >}}) for details. Available for Standard plan(s) only. | deployment |
4141
| 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 |
4242
| 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 |
4343
| 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 |
4444

4545
{{</bootstrap-table>}}
4646

47+
{{< warning >}}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.{{< /warning >}}
48+
4749
### NGINX connections statistics
4850

4951
{{<bootstrap-table "table table-striped table-bordered">}}
@@ -225,6 +227,9 @@ The metrics are categorized by the namespace used in Azure Monitor. The dimensio
225227
| system.interface.packets_sent| interface | count | System Interface Packets Sent. | deployment |
226228
| system.interface.total_bytes| interface | count | System Interface Total Bytes, sum of bytes_sent and bytes_rcvd. | deployment |
227229
| system.interface.egress_throughput| interface | count | System Interface Egress Throughput, i.e. bytes sent per second| deployment |
230+
| system.listener_backlog.max| listen_addr, file_desc | count | The fullness (expressed as a fraction) of the fullest backlog queue. | deployment |
231+
| system.listener_backlog.length| listen_address, file_desc | count | The number of items in a specific backlog queue, labelled by listen address. | deployment |
232+
| system.listener_backlog.queue_limit| listen_address, file_desc | count | The capacity of a specific backlog queue, labelled by listen address. | deployment |
228233

229234
{{</bootstrap-table>}}
230235

content/nginxaas-azure/quickstart/scaling.md

+29-28
Original file line numberDiff line numberDiff line change
@@ -15,12 +15,12 @@ An NGINXaaS deployment can be scaled out to increase the capacity (increasing th
1515

1616
In this document you will learn:
1717

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
2424

2525
## NGINX Capacity Unit (NCU)
2626

@@ -50,11 +50,11 @@ To enable autoscaling using the Azure Portal,
5050

5151
### Scaling rules
5252

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.
5454

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%.
5858

5959
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.
6060

@@ -63,6 +63,7 @@ To avoid creating a loop between scaling rules, NGINXaaS will not apply a scalin
6363
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.
6464

6565
{{<bootstrap-table "table table-striped table-bordered">}}
66+
6667
| **Marketplace Plan** | **Minimum Capacity (NCUs)** | **Maximum Capacity (NCUs)** | **Multiple of** |
6768
|------------------------------|-----------------------------|-----------------------------|----------------------------|
6869
| Standard plan(s) | 10 | 500 | 10 |
@@ -78,51 +79,51 @@ The following table outlines constraints on the specified capacity based on the
7879

7980
NGINXaaS provides metrics for visibility of the current and historical capacity values. These metrics, in the `NGINXaaS Statistics` namespace, include:
8081

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 workload is 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 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.
8888

8989
See the [Metrics Catalog]({{< relref "/nginxaas-azure/monitoring/metrics-catalog.md" >}}) for a reference of all metrics.
9090

9191
{{< note >}}These metrics aren't visible unless enabled, see how to [Enable Monitoring]({{< relref "/nginxaas-azure/monitoring/enable-monitoring.md" >}}) for details.{{< /note >}}
92+
{{< warning >}}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.{{< /warning >}}
9293

9394
## Estimating how many NCUs to provision
9495

9596
To calculate how many NCUs to provision, take the highest value across the parameters that make up an NCU:
9697

97-
* CPU
98-
* Bandwidth
99-
* Concurrent connections
98+
- CPU
99+
- Bandwidth
100+
- Concurrent connections
100101

101102
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.
102103

103104
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).
104105

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.
106+
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.
106107

107108
### Iterative approach
108109

109110
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
111+
- using the [Usage and Cost Estimator]({{< relref "/nginxaas-azure/billing/usage-and-cost-estimator.md" >}})
112+
- compare to a [reference workload](#reference-workloads)
113+
2. Observe the `nginxaas.capacity.percentage` [metric](#metrics) in Azure Monitor of your workload
113114
3. Decide what headroom factor you wish to have
114-
4. Multiply the headroom factor by the consumed NCUs to get the target NCUs.
115+
4. Multiply the headroom factor by the provisioned NCUs to get the target NCUs.
115116
5. [Adjust capacity](#adjusting-capacity) to the target NCUs
116117
6. repeat from step 2 -- it is always good to check back after making a change
117118

118119
*Example*:
119120

120121
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`.
122+
2. I observe that my `nginxaas.capacity.percentage` is currently at `90%`.
122123
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.
124+
4. `90% * 3 = 270%. 2.7 * 20 NCUs = 54 NCUs` 54 NCUs is my target capacity.
124125
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.
126+
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 match the workload.
126127

127128
### Reference workloads
128129

0 commit comments

Comments
 (0)