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
Copy file name to clipboardExpand all lines: articles/azure-arc/vmware-vsphere/quick-start-connect-vcenter-to-arc-using-script.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -151,7 +151,7 @@ A typical onboarding that uses the script takes 30 to 60 minutes. During the pro
151
151
After the command finishes running, your setup is complete. You can now use the capabilities of Azure Arc-enabled VMware vSphere.
152
152
153
153
> [!IMPORTANT]
154
-
> After the successful installation of Azure Arc resource bridge, it is recommended to retain a copy of the resource bridge config .yaml files and the kubeconfig file safe and secure in a place that facilitates easy retrieval. These files may be needed later to run a few commands to perform management operations on the resource bridge.
154
+
> After the successful installation of Azure Arc resource bridge, it is recommended to retain a copy of the resource bridge config .yaml files and the kubeconfig file safe and secure in a place that facilitates easy retrieval. These files may be needed later to run a few commands to perform management operations on the resource bridge. You can find the 3 .yaml files (config files) and the kubeconfig file in the same folder where you ran the script.
Add `progressiveLoading` and `progressiveLoadingInitialLayerGroups` to [StyleOptions][StyleOptions] to enable the capability of loading map layers progressively. This feature improves the perceived loading time of the map. For more information, see [2.2.2 release notes](#222-december-15-2022).
22
+
23
+
The preview is available on [npm](https://www.npmjs.com/package/azure-maps-control/v/3.0.0-preview.2) and CDN.
24
+
25
+
- Install [azure-maps-control@next][azure-maps-control] to your dependencies:
26
+
```shell
27
+
npm i azure-maps-control@next
28
+
```
29
+
30
+
- Reference the following CSS and JavaScript in the `<head>` element of an HTML file:
- Fix an issue that the ordering of user layers wasn't preserved after calling `map.layers.move()`.
39
+
40
+
- Fix the inability to disable traffic incidents in [TrafficControlOptions][TrafficControlOptions] when `new atlas.control.TrafficControl({incidents: false})` is used.
41
+
42
+
- Add `.atlas-map` to all css selectors to scope the styles within the map container. The fix prevents the css from accidentally adding unwanted styles to other elements on the page.
This update is the first preview of the upcoming 3.0.0 release. The underlying [maplibre-gl][maplibre-gl] dependency has been upgraded from `1.14` to `3.0.0-pre.1`, offering improvements in stability and performance. The preview is available on [npm](https://www.npmjs.com/package/azure-maps-control/v/3.0.0-preview.1).
49
+
50
+
- Install [azure-maps-control@next][azure-maps-control] to your dependencies:
51
+
```shell
52
+
npm i azure-maps-control@next
53
+
```
54
+
55
+
### Bug fixes
56
+
57
+
- Fix a regression issue that prevents IndoorManager from removing a tileset by using
Add `progressiveLoading` and `progressiveLoadingInitialLayerGroups` to [StyleOptions][StyleOptions] to enable the capability of loading map layers progressively. This feature improves the perceived loading time of the map.
69
+
- `progressiveLoading`
70
+
- Enables progressive loading of map layers.
71
+
- Defaults to `false`.
72
+
- `progressiveLoadingInitialLayerGroups`
73
+
- Specifies the layer groups to load first.
74
+
- Defaults to `["base"]`.
75
+
- Possible values are `base`, `transit`, `labels`, `buildings`, and `labels_places`.
76
+
- Other layer groups are deferred such that the initial layer groups can be loaded first.
77
+
78
+
### Bug fixes
79
+
80
+
- Fix an issue that the ordering of user layers wasn't preserved after calling `map.layers.move()`.
81
+
82
+
- Fix the inability to disable traffic incidents in [TrafficControlOptions][TrafficControlOptions] when `new atlas.control.TrafficControl({incidents: false})` is used.
Copy file name to clipboardExpand all lines: articles/azure-monitor/alerts/alerts-dynamic-thresholds.md
+118-2Lines changed: 118 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -97,13 +97,129 @@ If you have a new resource or missing metric data, Dynamic Thresholds won't trig
97
97
98
98
The system automatically recognizes prolonged outages and removes them from the threshold learning algorithm. As a result, despite prolonged outages, dynamic thresholds understand the data. Service issues are detected with the same sensitivity as before an outage occurred.
99
99
100
+
## The Dynamic Thresholds borders don't seem to fit the data
101
+
102
+
If the behavior of a metric changed recently, the changes won't necessarily be reflected in the Dynamic Threshold borders (upper and lower bounds) immediately. The borders are calculated based on metric data from the last 10 days. When you view the Dynamic Threshold borders for a given metric, look at the metric trend in the last week and not only for recent hours or days.
103
+
104
+
## Why is weekly seasonality not detected by Dynamic Thresholds?
105
+
106
+
To identify weekly seasonality, the Dynamic Thresholds model requires at least three weeks of historical data. When enough historical data is available, any weekly seasonality that exists in the metric data is identified and the model is adjusted accordingly.
107
+
108
+
## Dynamic Thresholds shows a negative lower bound for a metric even though the metric always has positive values
109
+
110
+
When a metric exhibits large fluctuation, Dynamic Thresholds builds a wider model around the metric values. This action can result in the lower border being below zero. Specifically, this scenario can happen when:
111
+
112
+
- The sensitivity is set to low.
113
+
- The median values are close to zero.
114
+
- The metric exhibits an irregular behavior with high variance, which appears as spikes or dips in the data.
115
+
116
+
When the lower bound has a negative value, it's plausible for the metric to reach a zero value given the metric's irregular behavior. Consider choosing a higher sensitivity or a larger **Aggregation granularity (Period)** to make the model less sensitive. Or, use the **Ignore data before** option to exclude a recent irregularity from the historical data used to build the model.
117
+
118
+
## The Dynamic Thresholds alert rule is too noisy or fires too much
119
+
120
+
To reduce the sensitivity of your Dynamic Thresholds alert rule, use one of the following options:
121
+
122
+
-**Threshold sensitivity:** Set the sensitivity to **Low** to be more tolerant for deviations.
123
+
-**Number of violations (under Advanced settings):** Configure the alert rule to trigger only if several deviations occur within a certain period of time. This setting makes the rule less susceptible to transient deviations.
124
+
125
+
## The Dynamic Thresholds alert rule doesn't fire or is not sensitive enough
126
+
127
+
Sometimes an alert rule won't trigger, even when a high sensitivity is configured. This scenario usually happens when the metric's distribution is highly irregular.
128
+
Consider one of the following options:
129
+
130
+
* Move to monitoring a complementary metric that's suitable for your scenario, if applicable. For example, check for changes in success rate rather than failure rate.
131
+
* Try selecting a different value for **Aggregation granularity (Period)**.
132
+
* Check if there was a drastic change in the metric behavior in the last 10 days, for example, an outage. An abrupt change can affect the upper and lower thresholds calculated for the metric and make them broader. Wait for a few days until the outage is no longer taken into the thresholds calculation. Or use the **Ignore data before** option under **Advanced settings**.
133
+
* If your data has weekly seasonality, but not enough history is available for the metric, the calculated thresholds can result in having broad upper and lower bounds. For example, the calculation can treat weekdays and weekends in the same way and build wide borders that don't always fit the data. This issue should resolve itself after enough metric history is available. Then, the correct seasonality will be detected and the calculated thresholds will update accordingly.
134
+
135
+
## Metrics not supported by Dynamic Thresholds
136
+
137
+
Dynamic thresholds are supported for most metrics, but some metrics can't use dynamic thresholds.
138
+
139
+
The following table lists the metrics that aren't supported by Dynamic Thresholds.
Dynamic Thresholds can be applied to most platform and custom metrics in Azure Monitor, and it was also tuned for the common application and infrastructure metrics.
103
219
104
220
The following items are best practices on how to configure alerts on some of these metrics by using Dynamic Thresholds.
105
221
106
-
###Configure dynamic thresholds on virtual machine CPU percentage metrics
222
+
## Configure dynamic thresholds on virtual machine CPU percentage metrics
107
223
108
224
1. In the [Azure portal](https://portal.azure.com), select **Monitor**. The **Monitor** view consolidates all your monitoring settings and data in one view.
109
225
@@ -140,7 +256,7 @@ The following items are best practices on how to configure alerts on some of the
140
256
> [!NOTE]
141
257
> Metric alert rules created through the portal are created in the same resource group as the target resource.
142
258
143
-
###Configure dynamic thresholds on Application Insights HTTP request execution time
259
+
## Configure dynamic thresholds on Application Insights HTTP request execution time
144
260
145
261
1. In the [Azure portal](https://portal.azure.com), select **Monitor**. The **Monitor** view consolidates all your monitoring settings and data in one view.
0 commit comments