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
#CustomerIntent: As an operator, I want to configure MQTT broker so that I can control MQTT client interactions.
11
+
#CustomerIntent: As an operator, I want to configure an MQTT broker so that I can control MQTT client interactions.
12
12
---
13
13
14
14
# Configure broker MQTT client options
15
15
16
16
> [!IMPORTANT]
17
-
> This setting requires modifying the Broker resource and can only be configured at initial deployment time using the Azure CLI or Azure Portal. A new deployment is required if Broker configuration changes are needed. To learn more, see [Customize default Broker](./overview-broker.md#customize-default-broker).
17
+
> This setting requires that you modify the Broker resource. It's configured only at initial deployment by using the Azure CLI or the Azure portal. A new deployment is required if Broker configuration changes are needed. To learn more, see [Customize default Broker](./overview-broker.md#customize-default-broker).
18
18
19
-
The broker advanced client options control how the broker interacts with MQTT clients. These settings, negotiated between the broker and the client during connection, include session expiry, message expiry, receive maximum, and keep alive. The only setting specific to Azure IoT Operations is the [subscriber queue limit](#subscriber-queue-limit).
19
+
The MQTT broker advanced client options control how the broker interacts with MQTT clients. These settings, negotiated between the broker and the client during connection, include session expiry, message expiry, receive maximum, and keep alive. The only setting specific to Azure IoT Operations is the [subscriber queue limit](#subscriber-queue-limit).
20
20
21
-
The complete list of available settings is found at[ClientConfig](/rest/api/iotoperations/broker/create-or-update#clientconfig) API reference.
21
+
For the complete list of available settings, see the[ClientConfig](/rest/api/iotoperations/broker/create-or-update#clientconfig) API reference.
22
22
23
-
In many scenarios, the default client settings are sufficient. To override the default client settings for the broker, edit the `advanced.clients` section in the Broker resource. Currently, this override is only supported using the `--broker-config-file` flag when you deploy the Azure IoT Operations using the `az iot ops create` command.
23
+
In many scenarios, the default client settings are sufficient. To override the default client settings for the MQTT broker, edit the `advanced.clients` section in the Broker resource. Currently, this override is supported only by using the `--broker-config-file` flag when you deploy IoT Operations by using the `az iot ops create` command.
24
24
25
-
To get started, prepare a Broker config file in JSON format, like the following example:
25
+
To get started, prepare a Broker configuration file in JSON format, like the following example:
26
26
27
27
28
28
```json
@@ -42,7 +42,7 @@ To get started, prepare a Broker config file in JSON format, like the following
42
42
}
43
43
```
44
44
45
-
Then, deploy Azure IoT Operations using the `az iot ops create` command with the `--broker-config-file` flag, like the following command (other parameters omitted for brevity):
45
+
Then, deploy IoT Operations by using the `az iot ops create` command with the `--broker-config-file` flag, like the following command. (Other parameters are omitted for brevity.)
46
46
47
47
```azurecli
48
48
az iot ops create ... --broker-config-file <FILE>.json
@@ -52,39 +52,37 @@ To learn more, see [Azure CLI support for advanced MQTT broker configuration](ht
52
52
53
53
## Subscriber queue limit
54
54
55
-
The MQTT broker keeps a queue for each subscriber with QoS 1 messages waiting to be delivered. Messages are added to this queue when received from the publisher and removed once delivered and acknowledged by the subscriber with a `PUBACK`. If messages arrive faster than the subscriber can acknowledge them, or if the subscriber is offline with a persistent session, the queue can grow large.
55
+
The MQTT broker keeps a queue for each subscriber with QoS 1 messages waiting to be delivered. Messages are added to this queue when they're received from the publisher. They're removed after they're delivered and acknowledged by the subscriber with a PUBACK message. If messages arrive faster than the subscriber can acknowledge them, or if the subscriber is offline with a persistent session, the queue can grow large.
56
56
57
-
The broker can [buffer these messages to disk](./howto-disk-backed-message-buffer.md) to save memory, but this might not always be enough. The disk buffer might not be set up, or it could be full due to other subscribers. Therefore, the subscriber queue limit helps prevent the broker from using too much memory for a single subscriber.
57
+
The MQTT broker can [buffer these messages to disk](./howto-disk-backed-message-buffer.md) to save memory, but this tactic might not always be enough. The disk buffer might not be set up, or it could be full because of other subscribers. Therefore, the subscriber queue limit helps prevent the broker from using too much memory for a single subscriber.
58
58
59
59
The subscriber queue limit has two settings:
60
60
61
61
-**Length**: The maximum number of messages that can be queued for a single subscriber. If the queue is full and a new message arrives, the broker drops the message based on the configured strategy.
62
-
63
62
-**Strategy**: The strategy to use when the queue is full. The two strategies are:
64
63
65
-
-**None**: Messages aren't dropped [unless the session expires](#session-expiry), and the queue can grow indefinitely. This is the default behavior.
66
-
64
+
-**None**: Messages aren't dropped [unless the session expires](#session-expiry), and the queue can grow indefinitely. This behavior is the default.
67
65
-**DropOldest**: The oldest message in the queue is dropped.
68
66
69
-
The limit only applies to the subscriber's outgoing queue, which holds messages that haven't been assigned packet IDs because the in-flight queue is full. This limit doesn't apply to the in-flight queue.
67
+
The limit applies only to the subscriber's outgoing queue, which holds messages that haven't been assigned packet IDs because the in-flight queue is full. This limit doesn't apply to the in-flight queue.
70
68
71
-
Since the limit is applied per [backend partition](./howto-configure-availability-scale.md#backend-chain), the broker can't guarantee the total number of outgoing messages for a subscriber across the entire cluster. For example, setting the length to 10,000 doesn't mean the subscriber will receive at most 10,000 messages. Instead, it could receive up to `10,000 * number of partitions * number of backend workers` messages.
69
+
Because the limit is applied per [backend partition](./howto-configure-availability-scale.md#backend-chain), the MQTT broker can't guarantee the total number of outgoing messages for a subscriber across the entire cluster. For example, setting the length to 10,000 doesn't mean the subscriber receives at most 10,000 messages. Instead, it could receive up to `10,000 * number of partitions * number of backend workers` messages.
72
70
73
71
### Slow subscribers
74
72
75
-
A slow subscriber is one that can't keep up with the incoming message rate. This can occur if the subscriber processes messages slowly, is disconnected, or is offline. The subscriber queue limit helps prevent a slow subscriber from consuming too much memory.
73
+
A slow subscriber is one that can't keep up with the incoming message rate. This problem can occur if the subscriber processes messages slowly, is disconnected, or is offline. The subscriber queue limit helps prevent a slow subscriber from consuming too much memory.
76
74
77
75
### Message expiry
78
76
79
-
The `maxMessageExpirySeconds` setting controls how long a message can stay in the queue before it expires. If a message stays in the queue longer than the maximum expiry time, it is marked as expired. However, expired messages are only discarded when they reach the beginning of the queue. This passive expiry mechanism helps manage memory usage by ensuring that old messages are eventually removed.
77
+
The `maxMessageExpirySeconds` setting controls how long a message can stay in the queue before it expires. If a message stays in the queue longer than the maximum expiry time, it's marked as expired. However, expired messages are discarded only when they reach the beginning of the queue. This passive expiry mechanism helps manage memory usage by ensuring that old messages are eventually removed.
80
78
81
79
### Session expiry
82
80
83
-
The `maxSessionExpirySeconds` setting works with the subscriber queue limit to ensure that messages aren't kept in the queue indefinitely. If a session expires, all messages in the queue for that session are dropped. This helps prevent offline subscribers from using too much memory by eventually clearing the entire queue.
81
+
The `maxSessionExpirySeconds` setting works with the subscriber queue limit to ensure that messages aren't kept in the queue indefinitely. If a session expires, all messages in the queue for that session are dropped. This practice helps prevent offline subscribers from using too much memory by eventually clearing the entire queue.
84
82
85
83
Both message expiry and session expiry are important for managing slow and offline subscribers and ensuring efficient memory usage.
86
84
87
-
## Next steps
85
+
## Related content
88
86
89
87
-[Configure listeners for the MQTT broker](./howto-configure-brokerlistener.md)
90
-
-[Test connectivity to the broker](./howto-test-connection.md)
88
+
-[Test connectivity to the MQTT broker](./howto-test-connection.md)
#CustomerIntent: As an operator, I want to configure MQTT broker so that I can encrypt internal communication and data.
11
+
#CustomerIntent: As an operator, I want to configure an MQTT broker so that I can encrypt internal communication and data.
12
12
---
13
13
14
14
# Configure encryption of broker internal traffic and internal certificates
15
15
16
-
Ensuring the security of internal communications within your infrastructure is important for maintaining data integrity and confidentiality. You can configure the MQTT broker to encrypt internal traffic and data. Encryption certificates are automatically managed using credential manager.
16
+
Ensuring the security of internal communications within your infrastructure is important to maintain data integrity and confidentiality. You can configure the MQTT broker to encrypt internal traffic and data. Encryption certificates are automatically managed by using the credential manager.
17
17
18
18
## Encrypt internal traffic
19
19
20
20
> [!IMPORTANT]
21
-
> This setting requires modifying the Broker resource and can only be configured at initial deployment time using the Azure CLI or Azure Portal. A new deployment is required if Broker configuration changes are needed. To learn more, see [Customize default Broker](./overview-broker.md#customize-default-broker).
21
+
> This setting requires that you modify the Broker resource. It's configured only at initial deployment by using the Azure CLI or the Azure portal. A new deployment is required if Broker configuration changes are needed. To learn more, see [Customize default Broker](./overview-broker.md#customize-default-broker).
22
22
23
23
The **encrypt internal traffic** feature is used to encrypt the internal traffic in transit between the MQTT broker frontend and backend pods. It's enabled by default when you deploy Azure IoT Operations.
24
24
25
-
To disable encryption, modify the `advanced.encryptInternalTraffic` setting in the Broker resource. This can only be done using the `--broker-config-file` flag during the deployment of Azure IoT Operations with the `az iot ops create` command.
25
+
To disable encryption, modify the `advanced.encryptInternalTraffic` setting in the Broker resource. You can do this step only by using the `--broker-config-file` flag during the deployment of IoT Operations with the `az iot ops create` command.
26
26
27
27
> [!CAUTION]
28
-
> Disabling encryption can improve MQTT broker performance. However, to protect against security threats like man-in-the-middle attacks, we strongly recommend keeping this setting enabled. Only disable encryption in controlled non-production environments for testing.
28
+
> Disabling encryption can improve MQTT broker performance. To protect against security threats like man-in-the-middle attacks, we strongly recommend that you keep this setting enabled. Disable encryption only in controlled nonproduction environments for testing.
29
29
30
30
```json
31
31
{
@@ -35,17 +35,17 @@ To disable encryption, modify the `advanced.encryptInternalTraffic` setting in t
35
35
}
36
36
```
37
37
38
-
Then, deploy Azure IoT Operations using the `az iot ops create` command with the `--broker-config-file` flag, like the following command (other parameters omitted for brevity):
38
+
Then, deploy IoT Operations by using the `az iot ops create` command with the `--broker-config-file` flag, like the following command. (Other parameters are omitted for brevity.)
39
39
40
40
```azurecli
41
41
az iot ops create ... --broker-config-file <FILE>.json
42
42
```
43
43
44
44
## Internal certificates
45
45
46
-
When encryption is enabled, the broker uses cert-manager to generate and manage the certificates used for encrypting the internal traffic. Cert-manager automatically renews certificates when they expire. You can configure the certificate settings, like duration, when to renew, and private key algorithm in the Broker resource. Currently, changing the certificate settings are only supported using the `--broker-config-file` flag when you deploy the Azure IoT Operations using the `az iot ops create` command.
46
+
When encryption is enabled, the MQTT broker uses cert-manager to generate and manage the certificates used for encrypting the internal traffic. Cert-manager automatically renews certificates when they expire. You can configure certificate settings like duration, when to renew, and the private key algorithm in the Broker resource. Currently, changing the certificate settings is supported only by using the `--broker-config-file` flag when you deploy IoT Operations by using the `az iot ops create` command.
47
47
48
-
For example, to set the certificate duration to 240 hours, renew before 45 minutes, and private key algorithm to RSA 2048, prepare a Broker config file in JSON format:
48
+
For example, to set the certificate `duration` to 240 hours, the `renewBefore` time to 45 minutes, and the `privateKey``algorithm` to RSA 2048, prepare a Broker configuration file in JSON format:
49
49
50
50
```json
51
51
{
@@ -63,10 +63,10 @@ For example, to set the certificate duration to 240 hours, renew before 45 minut
63
63
}
64
64
```
65
65
66
-
Then, deploy Azure IoT Operations using the `az iot ops create` command with the`--broker-config-file <FILE>.json`.
66
+
Then, deploy IoT Operations by using the `az iot ops create` command with `--broker-config-file <FILE>.json`.
67
67
68
68
To learn more, see [Azure CLI support for advanced MQTT broker configuration](https://aka.ms/aziotops-broker-config) and [Broker examples](/rest/api/iotoperations/broker/create-or-update#examples).
0 commit comments