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-monitor/logs/monitor-workspace.md
+33-34Lines changed: 33 additions & 34 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,9 +23,9 @@ The **_LogOperation** function returns the columns in the following table.
23
23
|:---|:---|
24
24
| TimeGenerated | Time that the incident occurred in UTC. |
25
25
| Category | Operation category group. Can be used to filter on types of operations and help create more precise system auditing and alerts. See the section below for a list of categories. |
26
-
| Operation | Description of the operation type. This can indicate one of the Log Analytics limits, type of operation, or part of a process. |
27
-
| Level | Severity level of the issue:<br>- Info: No specific attention needed.<br>- Warning: Process was not completed as expected, and attention is needed.<br>- Error: Process failed and urgent attention is needed.
28
-
| Detail | Detailed description of the operation include specific error message if it exists. |
26
+
| Operation | Description of the operation type. The operation can indicate that one of the Log Analytics limits was reached, a backend process related issue, or any other service message. |
27
+
| Level | Severity level of the issue:<br>- Info: No specific attention needed.<br>- Warning: Process was not completed as expected, and attention is needed.<br>- Error: Process failed, attention needed.
28
+
| Detail | Detailed description of the operation, includes the specific error message. |
29
29
|_ResourceId | Resource ID of the Azure resource related to the operation. |
30
30
| Computer | Computer name if the operation is related to an Azure Monitor agent. |
31
31
| CorrelationId | Used to group consecutive related operations. |
@@ -37,86 +37,85 @@ The following table describes the categories from the _LogOperation function.
37
37
38
38
| Category | Description |
39
39
|:---|:---|
40
-
| Ingestion | Operations that are part of the data ingestion process. See below for more details. |
40
+
| Ingestion | Operations that are part of the data ingestion process. |
41
41
| Agent | Indicates an issue with agent installation. |
42
42
| Data collection | Operations related to data collections processes. |
43
43
| Solution targeting | Operation of type *ConfigurationScope* was processed. |
44
44
| Assessment solution | An assessment process was executed. |
45
45
46
46
47
47
### Ingestion
48
-
Ingestion operations are issues that occurred during data ingestion including notification about reaching the Azure Log Analytics workspace limits. Error conditions in this category might suggest data loss, so they are particularly important to monitor. The table below provides details on these operations. See [Azure Monitor service limits](../service-limits.md#log-analytics-workspaces) for service limits for Log Analytics workspaces.
48
+
Ingestion operations are issues that occurred during data ingestion including notification about reaching the Azure Log Analytics workspace limits. Error conditions in this category might suggest data loss, so they are important to monitor. The table below provides details on these operations. See [Azure Monitor service limits](../service-limits.md#log-analytics-workspaces) for service limits for Log Analytics workspaces.
49
49
50
50
51
-
#### Operation: Data collection Stopped
52
-
Data collection stopped due to daily limit reached.
51
+
#### Operation: Data collection stopped
52
+
Data collection stopped due to reaching the daily limit.
53
53
54
-
In the past 7 Days you have reached your ingestion daily limit; this is either due to your workspace being in the free tier or that you have set a daily ingestion limit.
54
+
In the past 7 Days, the daily ingestion limit was reached; the limit reached is either due to your workspace being in the free tier or that you have set a daily ingestion limit.
55
55
Note, after reaching the set limit, your data collection will automatically stop for the day and will resume only during the next collection day.
56
56
57
57
Recommended Actions:
58
58
* Check _LogOperation table for collection stopped and collection resumed events.</br>
59
59
`_LogOperation | where TimeGenerated >= ago(7d) | where Category == "Ingestion" | where Operation has "Data collection"`
60
-
*[Create an alert](./manage-cost-storage.md#alert-when-daily-cap-reached) on "Data collection stopped" Operation event, this will allow you to get notified when the limit is reached.
61
-
* Reaching the daily limit is not recommended, as this will result in data loss, you might want to either check why the limit is reached, you can use the ‘workspace insights’ blade to review your usage patterns and try to reduce them.
60
+
*[Create an alert](./manage-cost-storage.md#alert-when-daily-cap-reached) on "Data collection stopped" Operation event, this alert will allow you to get notified when the limit is reached.
61
+
* Reaching the daily limit is not recommended and will result in data loss, you might want to either check why the limit is reached, you can use the ‘workspace insights’ blade to review your usage patterns and try to reduce them.
62
62
Or, you can decide to ([increase your daily ingestion limit](./manage-cost-storage.md#manage-your-maximum-daily-data-volume) \ [change the pricing tier](./manage-cost-storage.md#changing-pricing-tier) to one that will suite your ingestion pattern).
63
-
* As mentioned, data ingestion will resume during the start of the next day, you can also monitor this event by [Create an alert](./manage-cost-storage.md#alert-when-daily-cap-reached) on "Data collection resumed" Operation event, this will allow you to get notified when the limit is reached.
63
+
* As mentioned, data ingestion will resume during the start of the next day, you can also monitor this event by [Create an alert](./manage-cost-storage.md#alert-when-daily-cap-reached) on "Data collection resumed" Operation event, this alert will allow you to get notified when the limit is reached.
64
64
65
65
#### Operation: Ingestion rate
66
66
Ingestion rate limit approaching\passed the limit.
67
67
68
-
Your ingestion rate has passed the 80%; at this point there is not issue. Please note, data collected exceeding the threshold will be dropped. </br>
68
+
Your ingestion rate has passed the 80%; at this point there is not issue. Note, data collected exceeding the threshold will be dropped. </br>
69
69
70
70
Recommended Actions:
71
71
* Check _LogOperation table for ingestion rate event
72
72
`_LogOperation | where TimeGenerated >= ago(7d) | where Category == "Ingestion" | where Operation has "Ingestion rate"`
73
73
Note: Operation table in the workspace every 6 hours while the threshold continues to be exceeded.
74
-
*[Create an alert](./manage-cost-storage.md#alert-when-daily-cap-reached) on "Data collection stopped" Operation even, this will allow you to get notified when the limit is reached.
75
-
* We recommend making sure you do not exceed the ingestion rate limit, as this will result in data loss.
74
+
*[Create an alert](./manage-cost-storage.md#alert-when-daily-cap-reached) on "Data collection stopped" Operation event, this alert will allow you to get notified when the limit is reached.
75
+
* We recommend making sure not to exceed the ingestion rate limit, reaching the limit will result in data loss.
76
76
77
-
You might want to either check why the limit is reached, you can use the workspace insights blade to review your usage patterns and try to reduce them.
78
-
For further information:
79
-
[Azure Monitor service limits](../service-limits.md#data-ingestion-volume-rate)
77
+
You might want to either check why the limit is reached, you can use the workspace insights blade to review your usage patterns and try to reduce them.</br>
78
+
For further information: </br>
79
+
[Azure Monitor service limits](../service-limits.md#data-ingestion-volume-rate)</br>
80
80
[Manage usage and costs for Azure Monitor Logs](./manage-cost-storage.md#alert-when-daily-cap-reached)
81
81
82
82
83
83
#### Operation: Maximum table column count
84
-
Custom fields has reached the limit.
84
+
Custom fields count have reached the limit.
85
85
86
86
Recommended Actions:
87
-
For custom tables, you can move to [Parsing the data](./parse-text.md) in queries,
88
-
If for any reason this is not possible, please proceed with case creation and request to increase the filed limit for this specific table.
87
+
For custom tables, you can move to [Parsing the data](./parse-text.md) in queries.
89
88
90
89
#### Operation: Field content validation
91
-
One of the fields of the data being ingested had more than 32Kb in size, so it got truncated.
90
+
One of the fields of the data being ingested had more than 32 Kb in size, so it got truncated.
92
91
93
-
Log Analytics limits ingested fields size to 32Kb, larger size fields will be trimmed to 32Kb. We don’t recommend sending fields larger then 32Kb as the trim process might remove important information.
92
+
Log Analytics limits ingested fields size to 32 Kb, larger size fields will be trimmed to 32 Kb. We don’t recommend sending fields larger than 32 Kb as the trim process might remove important information.
94
93
95
94
Recommended Actions:
96
95
Check the source of the affected data type:
97
-
* If the data is being sent thru the HTTP Data Collector API, you will need to change your code\script to split the data before it’s ingested.
98
-
* In case it’s a custom log, collected from a Log Analytics agent, then you’ll to change the logging settings of the application\tool to prevent this.
99
-
* For any other data type, please raise a support case.
96
+
* If the data is being sent through the HTTP Data Collector API, you will need to change your code\script to split the data before it’s ingested.
97
+
* In case it’s a custom log, collected from a Log Analytics agent, then you’ll need to change the logging settings of the application\tool to resolve this issue.
98
+
* For any other data type, a support case should be raised.
100
99
</br>Read more: [Azure Monitor service limits](../service-limits.md#data-ingestion-volume-rate)
101
100
102
-
### Data Collection
103
-
#### Operation: Azure Activity Log Collection
101
+
### Data collection
102
+
#### Operation: Azure Activity Log collection
104
103
Description: In some situations, like moving a subscription to a different tenant, the Azure Activity logs might stop flowing in into the workspace. In those situations, we need to reconnect the subscription following the process described in this article.
105
104
106
105
Recommended Actions:
107
-
* If the subscription mentioned on the warning message no longer exists, please navigate to the ‘Azure Activity log’ blade under ‘Workspace Data Sources’, select the relevant subscription and finally select the ‘Disconnect’ button.
106
+
* If the subscription mentioned on the warning message no longer exists, navigate to the ‘Azure Activity log’ blade under ‘Workspace Data Sources’, select the relevant subscription, and finally select the ‘Disconnect’ button.
108
107
* If you no longer have access to the subscription mentioned on the warning message:
109
-
* If you no longer want to collect logs from this subscription, then please follow the same actions as step 1
110
-
* If you still want to collect logs from this subscription, then please follow the same actions as step 1, contact the subscription owner to verify and fix your permissions and re-enable activity log collection
111
-
* If you need to enable or re-enable activity log collection, we strongly recommend that you switch to the new collection method that leverages diagnostic settings, as it includes: [Azure Activity log](../essentials/activity-log.md#send-to-log-analytics-workspace)
108
+
* If you no longer want to collect logs from this subscription, then follow the same actions as step 1
109
+
* If you still want to collect logs from this subscription, then follow the same actions as step 1, contact the subscription owner to verify, and fix your permissions and re-enable activity log collection
110
+
* If you need to enable or re-enable activity log collection, we strongly recommend that you switch to the new collection method that applies diagnostic settings, as it includes: [Azure Activity log](../essentials/activity-log.md#send-to-log-analytics-workspace)
112
111
113
112
### Agent
114
113
#### Operation: Linux Agent
115
114
Config settings on the portal have changed.
116
115
117
116
Recommended Action
118
-
This issue is raised in case there is an issue for the Agent to retrieve the new config settings,
119
-
To mitigate this, you will need to reinstall the agent.
117
+
This issue is raised in case there is an issue for the Agent to retrieve the new config settings.
118
+
To mitigate this issue, you will need to reinstall the agent.
120
119
Check _LogOperation table for agent event.</br>
121
120
122
121
`_LogOperation | where TimeGenerated >= ago(6h) | where Category == "Agent" | where Operation == "Linux Agent" | distinct _ResourceId`
@@ -127,7 +126,7 @@ To mitigate the issue, you will need to reinstall the Agents listed.
127
126
128
127
129
128
## Alert rules
130
-
Use [log query alerts](../alerts/alerts-log-query.md) in Azure Monitor to be proactively notified when an issue is detected in your Log Analytics workspace. You should use a strategy that allows you to respond in a timely manner to issues while minimizing your costs. Your subscription is charged for each alert rule with a cost depending on the frequency that it's evaluated.
129
+
Use [log query alerts](../alerts/alerts-log-query.md) in Azure Monitor to be proactively notified when an issue is detected in your Log Analytics workspace. Use a strategy that allows you to respond in a timely manner to issues while minimizing your costs. Your subscription is charged for each alert rule with a cost depending on the frequency that it's evaluated.
131
130
132
131
A recommended strategy is to start with two alert rules based on the level of the issue. Use a short frequency such as every 5 minutes for Errors and a longer frequency such as 24 hours for Warnings. Since Errors indicate potential data loss, you want to respond to them quickly to minimize any loss. Warnings typically indicate an issue that does not require immediate attention, so you can review them daily.
0 commit comments