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
Azure Cosmos DB provides you the list of all the point in time restores for continuous mode that were performed on an Azure Cosmos DB account using [Activity Logs](../azure-monitor/essentials/activity-log.md). Activity logs can be viewed for any Azure Cosmos DB account from the **Activity Logs** page in the Azure portal. The Activity Log shows all the operations that were triggered on the specific account. When a point in time restore is triggered, it shows up as `Restore Database Account` operation on the source account as well as the target account. The Activity Log for the source account can be used to audit restore events, and the activity logs on the target account can be used to get the updates about the progress of the restore.
15
+
Azure Cosmos DB provides you with a list of all point-in-time restores for continuous mode that were performed on an Azure Cosmos DB account using [activity logs](monitor.md#activity-log). Activity logs can be viewed for any Azure Cosmos DB account from the **Activity Logs** page in the Azure portal. The activity log shows all the operations that were triggered on the specific account. When a point-in-time restore is triggered, it shows up as `Restore Database Account` operation on the source account as well as the target account. The activity log for the source account can be used to audit restore events, and the activity logs on the target account can be used to get the updates about the progress of the restore.
16
16
17
17
## Audit the restores that were triggered on a live database account
Copy file name to clipboardExpand all lines: articles/cosmos-db/autoscale-per-partition-region.md
+4-6Lines changed: 4 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -54,14 +54,12 @@ This feature is available for new Azure Cosmos DB accounts. To enable this featu
54
54
55
55
:::image type="content" source="media/autoscale-per-partition-region/enable-feature.png" lightbox="media/autoscale-per-partition-region/enable-feature.png" alt-text="Screenshot of the 'Per Region and Per Partition Autoscale' feature in the Azure portal.":::
56
56
57
-
> [!IMPORTANT]
58
-
> The feature is enabled at the account level, so all containers within the account will automatically have this capability applied. The feature is available for both shared throughput databases and containers with dedicated throughput. Provisioned throughput accounts must switch over to autoscale and then enable this feature, if interested.
59
-
60
-
## Metrics
57
+
> [!IMPORTANT]
58
+
> The feature is enabled at the account level, so all containers within the account will automatically have this capability applied. The feature is available for both shared throughput databases and containers with dedicated throughput. Provisioned throughput accounts must switch over to autoscale and then enable this feature, if interested.
61
59
62
-
Use Azure Monitor to analyze how the new autoscaling is being applied across partitions and regions. Filter to your desired database account and container, then filter or split by the `PhysicalPartitionID` metric. This metric shows all partitions across their various regions.
60
+
1.Use [Azure Monitor metrics](monitor-reference.md#supported-metrics-for-microsoftdocumentdbdatabaseaccounts)to analyze how the new autoscaling is applied across partitions and regions. Filter to your desired database account and container, then filter or split by the `PhysicalPartitionID` metric. This metric shows all partitions across their various regions.
63
61
64
-
Then, use `NormalizedRUConsumption' to see which partitions are scaling indpendently and which regions are scaling independently if applicable. You can use the 'ProvisionedThroughput' metric to see what throughput value is getting emmitted to our billing service.
62
+
Then, use `NormalizedRUConsumption` to see which partitions and regions scale independently. You can use the `ProvisionedThroughput` metric to see what throughput value is emitted to our billing service.
Log Analytics is a tool in the Azure portal that helps you run server diagnostics on your API for Cassandra account. Run log queries from data collected by Azure Monitor Logs and interactively analyze their results. Records retrieved from Log Analytics queries help provide various insights into your data.
16
+
Log Analytics is a tool in the Azure portal that helps you run server diagnostics on your API for Cassandra account.
17
17
18
18
## Prerequisites
19
19
20
-
- Create a [Log Analytics Workspace](../../azure-monitor/logs/quick-create-workspace.md).
- Start [log analytics](../../azure-monitor/logs/log-analytics-overview.md) on your API for Cassandra account.
23
23
24
24
## Use Log Analytics
25
25
After you've completed the log analytics setup, you can begin to explore your logs to gain more insights.
26
26
27
27
### Explore Data Plane Operations
28
-
Use the CDBCassandraRequests table to see data plane operations specifically for your API for Cassandra account. A sample query to see the topN(10) consuming request and get detailed information on each request made.
28
+
Use the [CDBCassandraRequests table](/azure/azure-monitor/reference/tables/cdbcassandrarequests) to see data plane operations specifically for your API for Cassandra account. A sample query to see the topN(10) consuming request and get detailed information on each request made.
| 400 | 8704 | The query is correct but an invalid syntax. |
43
-
| 400 | 8192 | The submitted query has a syntax error. Review your query. |
44
-
| 400 | 8960 | The query is invalid because of some configuration issue. |
45
-
| 401 |8448 | The logged user does not have the right permissions to perform the query. |
46
-
| 403 | 8448 | Forbidden response as the user may not have the necessary permissions to carry out the request. |
47
-
| 404 | 5376 | A non-timeout exception during a write request as a result of response not found. |
48
-
| 405 | 0 | Server-side Cassandra error. The error rarely occurs, open a support ticket. |
49
-
| 408 | 4608 | Timeout during a read request. |
50
-
| 408 | 4352 | Timeout exception during a write serviceRequest. |
51
-
| 409 | 9216 | Attempting to create a keyspace or table that already exist. |
52
-
| 412 | 5376 | Precondition failure. To ensure data integrity, we ensure that the write request based on the read response is true. A non-timeout write request exception is returned. |
53
-
| 413 | 5376 | This non-timeout exception during a write request is because of payload maybe too large. Currently, there is a limit of 2MB per row. |
54
-
| 417 | 9472 | The exception is thrown when a prepared statement is not cached on the server node. It should be transient/non-blocking. |
55
-
| 423 | 5376 | There is a lock because a write request that is currently processing. |
56
-
| 429 | 4097| Overload exception is as a result of RU shortage or high request rate. Probably need more RU to handle the higher volume request. In, native Cassandra this can be interpreted as one of the VMs not having enough CPU. We advise reviewing current data model to ensure that you do not have excessive skews that might be causing hot partitions. |
57
-
| 449 | 5376 | Concurrent execution exception. This occurs to ensure only one write update at a time for a given row. |
58
-
| 500 | 0 | Server cassandraError: something unexpected happened. This indicates a server-side bug. |
59
-
| 503 | 4096 | Service unavailable. |
60
-
|| 256 | This may be because of invalid connection credentials. Please check your connection credentials. |
61
-
|| 10 | A client message triggered protocol violation. An example is query message sent before a startup one has been sent. |
38
+
For a list of error codes and their possible solutions, see [Error codes](../monitor-reference.md#error-codes-for-cassandra).
62
39
63
40
### Troubleshoot Query Consumption
64
-
The CDBPartitionKeyRUConsumption table contains details on request unit (RU) consumption for logical keys in each region within each of their physical partitions.
41
+
The [CDBPartitionKeyRUConsumption table](/azure/azure-monitor/reference/tables/cdbpartitionkeyruconsumption) contains details on request unit (RU) consumption for logical keys in each region within each of their physical partitions.
65
42
66
43
```Kusto
67
44
CDBPartitionKeyRUConsumption
@@ -70,7 +47,7 @@ CDBPartitionKeyRUConsumption
70
47
```
71
48
72
49
### Explore Control Plane Operations
73
-
The CBDControlPlaneRequests table contains details on control plane operations, specifically for API for Cassandra accounts.
50
+
The [CBDControlPlaneRequests table](/azure/azure-monitor/reference/tables/cdbcontrolplanerequests) contains details on control plane operations, specifically for API for Cassandra accounts.
Copy file name to clipboardExpand all lines: articles/cosmos-db/cassandra/monitor-insights.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -49,26 +49,26 @@ Exceeding provisioned throughput could be one of the reasons. Enable [Server Sid
49
49
50
50
51
51
## System and management operations
52
-
The system view helps show metadata requests count by primary partition. It also helps identify throttled requests. The management operation shows the account activities such as creation, deletion, key, network and replication settings. Request volume per status code over a time period.
52
+
The system view helps show metadata requests count by primary partition. It also helps identify throttled requests. The management operation shows the account activities such as creation, deletion, key, network, and replication settings. Request volume per status code over a time period.
53
53
54
54
:::image type="content" source="./media/monitor-insights/metadata-requests-status-code.png" alt-text="Screenshot showing request status code based on metadata.":::
55
55
56
56
- Metric chart for account diagnostic, network and replication settings over a specified period and filtered based on a Keyspace.
57
57
58
-
:::image type="content" source="./media/monitor-insights/diagnostic-network-replication.png" alt-text="Screenshot of diagnostic network replication for a API for Cassandra account.":::
58
+
:::image type="content" source="./media/monitor-insights/diagnostic-network-replication.png" alt-text="Screenshot of diagnostic network replication for a Cassandra account API.":::
59
59
60
60
61
61
- Metric chart to view account key rotation.
62
62
63
63
You can view changes to primary or secondary password for your API for Cassandra account.
64
64
65
-
:::image type="content" source="./media/monitor-insights/cosmos-db-account-key.png" alt-text="Screenshot showing Azure Cosmos DB rotation key for a API for Cassandra account.":::
65
+
:::image type="content" source="./media/monitor-insights/cosmos-db-account-key.png" alt-text="Screenshot showing Azure Cosmos DB rotation key for a Cassandra account API.":::
66
66
67
67
68
68
## Storage
69
69
Storage distribution for raw and index storage. Also a count of documents in the API for Cassandra account.
70
70
71
-
:::image type="content" source="./media/monitor-insights/data-index-usage.png" alt-text="Diagram showing the document count within a API for Cassandra account.":::
71
+
:::image type="content" source="./media/monitor-insights/data-index-usage.png" alt-text="Diagram showing the document count within an API for Cassandra account.":::
72
72
73
73
Maximum request units consumption for an account over a defined time period.
74
74
@@ -89,9 +89,9 @@ The chart below shows if your application’s high RU consumption is because of
89
89
90
90
:::image type="content" source="./media/monitor-insights/normalized-ru-pk-rangeid.png" alt-text="Screenshot showing normalized request unit consumption by partition key range ID.":::
91
91
92
-
The chart below shows a breakdown of requests by different status code. Understand the meaning of the different codes for your [API for Cassandra codes](./error-codes-solution.md).
92
+
The chart below shows a breakdown of requests by different status code. Understand the meaning of the different codes for your [API for Cassandra codes](../monitor-reference.md#error-codes-for-cassandra).
93
93
94
-
:::image type="content" source="./media/monitor-insights/total-request-by-status-code.png" alt-text="Screenshot image of a graph showing the total request by status code for a cassandra api account.":::
94
+
:::image type="content" source="./media/monitor-insights/total-request-by-status-code.png" alt-text="Screenshot image of a graph showing the total request by status code for a Cassandra API account.":::
Copy file name to clipboardExpand all lines: articles/cosmos-db/concepts-limits.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -46,7 +46,7 @@ An Azure Cosmos DB container (or shared throughput database) using manual throug
46
46
47
47
The current and minimum throughput of a container or a database can be retrieved from the Azure portal or the SDKs. For more information, see [Allocate throughput on containers and databases](set-throughput.md).
48
48
49
-
The actual minimum RU/s may vary depending on your account configuration. You can use [Azure Monitor metrics](monitor.md#view-operation-level-metrics-for-azure-cosmos-db) to view the history of provisioned throughput (RU/s) and storage on a resource.
49
+
The actual minimum RU/s might vary depending on your account configuration. You can use [Azure Monitor metrics](monitor.md#analyze-azure-cosmos-db-metrics) to view the history of provisioned throughput (RU/s) and storage on a resource.
50
50
51
51
#### Minimum throughput on container
52
52
@@ -290,9 +290,9 @@ The following table lists the limits specific to MongoDB feature support. Other
290
290
| Maximum execution time for MongoDB operations (for 3.6 and 4.0 server version)| 60 seconds|
291
291
| Maximum level of nesting for embedded objects / arrays on index definitions | 6 |
292
292
| Idle connection timeout for server side connection closure ² | 30 minutes |
293
-
| Time limit for MongoDB shell in the Azure Portal| 120 minutes in a 24hr period |
293
+
| Time limit for MongoDB shell in the Azure portal| 120 minutes in a 24hr period |
294
294
295
-
¹ Large document sizes up to 16 MB require feature enablement in Azure portal. Read the [feature documentation](../cosmos-db/mongodb/feature-support-42.md#data-types) to learn more.
295
+
¹ Large document sizes up to 16 MB require feature enablement in the Azure portal. Read the [feature documentation](../cosmos-db/mongodb/feature-support-42.md#data-types) to learn more.
296
296
297
297
² We recommend that client applications set the idle connection timeout in the driver settings to 2-3 minutes because the [default timeout for Azure LoadBalancer is 4 minutes](../load-balancer/load-balancer-tcp-idle-timeout.md). This timeout ensures that an intermediate load balancer idle doesn't close connections between the client machine and Azure Cosmos DB.
0 commit comments