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 Communication Services Call Automation Logs
15
+
# Azure Communication Services Call Automation logs
16
16
17
-
Azure Communication Services offers logging capabilities that you can use to monitor and debug your Communication Services solution. These capabilities can be configured through the Azure portal.
17
+
Azure Communication Services offers logging capabilities that you can use to monitor and debug your Communication Services solution. You configure these capabilities through the Azure portal.
18
18
19
19
## Prerequisites
20
20
21
-
Azure Communication Services provides monitoring and analytics features via [Azure Monitor Logs overview](../../../../azure-monitor/logs/data-platform-logs.md) and [Azure Monitor Metrics](../../../../azure-monitor/essentials/data-platform-metrics.md). Each Azure resource requires its own diagnostic setting, which defines the following criteria:
22
-
* Categories of logs and metric data sent to the destinations defined in the setting. The available categories will vary for different resource types.
23
-
* One or more destinations to send the logs. Current destinations include Log Analytics workspace, Event Hubs, and Azure Storage.
24
-
* A single diagnostic setting can define no more than one of each of the destinations. If you want to send data to more than one of a particular destination type (for example, two different Log Analytics workspaces), then create multiple settings. Each resource can have up to five diagnostic settings.
21
+
Azure Communication Services provides monitoring and analytics features via [Azure Monitor Logs](../../../../azure-monitor/logs/data-platform-logs.md) and [Azure Monitor Metrics](../../../../azure-monitor/essentials/data-platform-metrics.md). Each Azure resource requires its own diagnostic setting, which defines the following criteria:
22
+
23
+
* Categories of log and metric data sent to the destinations that the setting defines. The available categories vary by resource type.
24
+
* One or more destinations to send the logs. Current destinations include Log Analytics workspace, Azure Event Hubs, and Azure Storage.
25
+
26
+
A single diagnostic setting can define no more than one of each destination type. If you want to send data to more than one destination type (for example, two Log Analytics workspaces), create multiple settings. Each resource can have up to five diagnostic settings.
25
27
26
28
> [!IMPORTANT]
27
-
> You must enable a Diagnostic Setting in Azure Monitor to send the log data of your surveys to a Log Analytics workspace, Event Hubs, or an Azure storage account to receive and analyze your survey data. If you do not send call automation data to one of these options your survey data will not be stored and will be lost.
28
-
The following are instructions for configuring your Azure Monitor resource to start creating logs and metrics for your Communications Services. For detailed documentation about using Diagnostic Settings across all Azure resources, see: [Enable logging in Diagnostic Settings](../enable-logging.md)
29
+
> You must enable a diagnostic setting in Azure Monitor to send the log data of your surveys to a Log Analytics workspace, an event hub, or an Azure storage account to receive and analyze your survey data. If you don't send Call Automation data to one of these options, your survey data won't be stored and will be lost.
30
+
31
+
The following instructions configure your Azure Monitor resource to start creating logs and metrics for your Communication Services instance. For detailed documentation about using diagnostic settings across all Azure resources, see [Enable logging in diagnostic settings](../enable-logging.md).
29
32
30
-
> [!NOTE]
31
-
> Under the diagnostic setting name please select “Operation call automation logs” and “Call Automation Events summary logs” to enable the logs for call automation logs.
32
-
33
-
:::image type="content" source="..\media\log-analytics\call-automation-log.png" alt-text="Screenshot of diagnostic settings for call automation.":::
33
+
Under the diagnostic setting name, select **Operation Call Automation Logs** and **Call Automation Events Summary Logs** to enable the logs for Call Automation.
34
34
35
+
:::image type="content" source="..\media\log-analytics\call-automation-log.png" alt-text="Screenshot of diagnostic settings for Call Automation.":::
35
36
36
37
## Resource log categories
37
38
38
39
Communication Services offers the following types of logs that you can enable:
39
40
40
-
***Usage logs** - provides usage data associated with each billed service offering.
41
-
***Call Automation operational logs** - provides operational information on Call Automation API requests. These logs can be used to identify failure points and query all requests made in a call (using Correlation ID or Server Call ID).
42
-
***Call Automation media summary logs** - Provides information about outcome of media operations. These come to the user asynchronously when making media requests using Call Automation APIs. These can be used to help identify failure points and possible patterns on how end users are interacting with your application.
41
+
***Usage logs**: Provide usage data associated with each billed service offering.
42
+
***Call automation operational logs**: Provide operational information on Call Automation API requests. You can use these logs to identify failure points and query all requests made in a call (by using the correlation ID or server call ID).
43
+
***Call Automation media summary logs**: Provide information about the outcome of media operations. These logs come to you asynchronously when you're making media requests by using Call Automation APIs. You can use these logs to help identify failure points and possible patterns on how users interact with your application.
43
44
44
-
## Usage logs schema
45
+
## Usage log schema
45
46
46
47
| Property | Description |
47
48
| ----------------------- | ---------------|
48
-
|`Timestamp`| The timestamp (UTC) of when the log was generated. |
49
+
|`Timestamp`| The time stamp (UTC) of when the log was generated. |
49
50
|`OperationName`| The operation associated with the log record. |
50
-
|`OperationVersion`| The `api-version` associated with the operation, if the operationName was performed using an API. If there's no API that corresponds to this operation, the version represents the version of that operation in case the properties associated with the operation change in the future. |
51
-
|`Category`| The log category of the event. The category is the granularity at which you can enable or disable logs on a particular resource. The properties that appear within the properties blob of an event are the same within a particular log category and resource type. |
52
-
|`CorrelationID`| The ID for correlated events. Can be used to identify correlated events between multiple tables. |
53
-
|`Properties`| Other data applicable to various modes of Communication Services. |
54
-
|`RecordID`| The unique ID for a given usage record. |
55
-
|`UsageType`| The mode of usage. (for example, Chat, PSTN, NAT, etc.)|
56
-
|`UnitType`| The type of unit that usage is based on for a given mode of usage. (for example, minutes, megabytes, messages, etc.). |
51
+
|`OperationVersion`| The `api-version`value associated with the operation, if the `OperationName` operation was performed through an API. If no API corresponds to this operation, the version represents the version of the operation, in case the properties associated with the operation change in the future. |
52
+
|`Category`| The log category of the event. The category is the granularity at which you can enable or disable logs on a resource. The properties that appear within the `properties` blob of an event are the same within a log category and resource type. |
53
+
|`CorrelationID`| The ID for correlated events. You can use it to identify correlated events between multiple tables. |
54
+
|`Properties`| Other data that's applicable to various modes of Communication Services. |
55
+
|`RecordID`| The unique ID for a usage record. |
56
+
|`UsageType`| The mode of usage (for example, Chat, PSTN, or NAT).|
57
+
|`UnitType`| The type of unit that usage is based on for a mode of usage (for example, minutes, megabytes, or messages). |
57
58
|`Quantity`| The number of units used or consumed for this record. |
58
59
59
60
## Call Automation operational logs
60
61
61
62
| Property | Description |
62
63
| -------- | ---------------|
63
-
|`TimeGenerated`| The timestamp (UTC) of when the log was generated. |
64
+
|`TimeGenerated`| The time stamp (UTC) of when the log was generated. |
64
65
|`OperationName`| The operation associated with the log record. |
65
66
|`CorrelationID`| The identifier to identify a call and correlate events for a unique call. |
66
-
|`OperationVersion`| The `api-version` associated with the operation, if the `operationName` was performed using an API. If there's no API that corresponds to this operation, the version represents the version of that operation in case the properties associated with the operation change in the future. |
67
-
|`Category`| The log category of the event. The category is the granularity at which you can enable or disable logs on a particular resource. The properties that appear within the properties blob of an event are the same within a particular log category and resource type. |
67
+
|`OperationVersion`| The `api-version`version associated with the operation, if the `operationName`operation was performed through an API. If no API corresponds to this operation, the version represents the version of the operation, in case the properties associated with the operation change in the future. |
68
+
|`Category`| The log category of the event. The category is the granularity at which you can enable or disable logs on a resource. The properties that appear within the `properties` blob of an event are the same within a log category and resource type. |
68
69
|`ResultType`| The status of the operation. |
69
-
|`ResultSignature`| The sub-status of the operation. If this operation corresponds to a REST API call, this field is the HTTP status code of the corresponding REST call. |
70
+
|`ResultSignature`| The substatus of the operation. If this operation corresponds to a REST API call, this field is the HTTP status code of the corresponding REST call. |
70
71
|`DurationMs`| The duration of the operation in milliseconds. |
71
-
|`CallerIpAddress`| The caller IP address, if the operation corresponds to an API call that would come from an entity with a publicly available IP address. |
72
+
|`CallerIpAddress`| The caller IP address, if the operation corresponds to an API call that comes from an entity with a publicly available IP address. |
72
73
|`Level`| The severity level of the event. |
73
74
|`URI`| The URI of the request. |
74
-
|`CallConnectionId`| ID representing the call connection, if available. This ID is different for each participant and is used to identify their connection to the call. |
75
+
|`CallConnectionId`|The ID that represents the call connection, if available. This ID is different for each participant and is used to identify their connection to the call. |
75
76
|`ServerCallId`| A unique ID to identify a call. |
76
-
|`SDKVersion`| SDK version used for the request. |
77
+
|`SDKVersion`|The SDK version used for the request. |
77
78
|`SDKType`| The SDK type used for the request. |
78
-
|`ParticipantId`| ID to identify the call participant that made the request. |
79
-
|`SubOperationName`|Used to identify the subtype of media operation (play, recognize) |
80
-
|`operationID`|It represents the operation ID used to correlate asynchronous events|
79
+
|`ParticipantId`|The ID to identify the call participant that made the request. |
80
+
|`SubOperationName`|The name that's used to identify the subtype of media operation (play or recognize).|
81
+
|`operationID`|The ID that's used to correlate asynchronous events.|
81
82
82
-
**Examples**
83
+
Here's an example of a Call Automation operational log:
83
84
84
85
```json
85
86
[
@@ -107,27 +108,27 @@ Communication Services offers the following types of logs that you can enable:
107
108
108
109
| Property | Description |
109
110
| -------- | ---------------|
110
-
| `TimeGenerated` | It represents the timestamp (UTC) of the event|
111
-
|`level`| It represents the severity level of the event. Must be one of Informational, Warning, Error, or Critical. |
112
-
|`resourceId`| Represents the resource ID of the resource that emitted the event |
113
-
|`durationMs`| Represents the duration of the operation in milliseconds |
114
-
|`callerIpAddress`| |
115
-
|`correlationId`| Skype Chain ID |
116
-
|`operationName`| The name of the operation represented by this event|
117
-
|`operationVersion`
118
-
| `resultType`| The status of the event. Typical values include Completed, Canceled, Failed|
119
-
| `resultSignature`| The sub-status of the operation. If this operation corresponds to a REST API call, this field is the HTTP status code of the corresponding REST call|
120
-
|`operationId`| It represents the operation ID used to correlate asynchronous events|
121
-
|`recognizePromptSubOperationName`|A subtype of the operation. Potential values: File, TextToSpeech, SSML, etc.|
122
-
| `playInLoop`| True if looping was requested for the Play operation, else otherwise|
123
-
|`playToParticipant`| True if the Play operation had a target. False if it was a play to all operation|
124
-
| `interrupted`| True in case of the prompt being interrupted, false otherwise|
125
-
|`resultCode`|Operation Result Code |
126
-
|`resultSubcode`| Operation Result Subcode |
127
-
|`resultMessage`| Operation result message |
128
-
129
-
130
-
**Examples**
111
+
| `TimeGenerated` | The time stamp (UTC) of the event.|
112
+
|`level`| The severity level of the event. It must be one of `Informational`, `Warning`, `Error`, or `Critical`. |
113
+
|`resourceId` | The ID of the resource that emitted the event. |
114
+
|`durationMs` | The duration of the operation in milliseconds. |
115
+
|`callerIpAddress`| |
116
+
|`correlationId` | The Skype chain ID. |
117
+
|`operationName`| The name of the operation that this event represents.|
118
+
|`operationVersion` | |
119
+
| `resultType`| The status of the event. Typical values include `Completed`, `Canceled`, and `Failed`.|
120
+
| `resultSignature`| The substatus of the operation. If this operation corresponds to a REST API call, this field is the HTTP status code of the corresponding REST call.|
121
+
|`operationId` | The operation ID that's used to correlate asynchronous events.|
122
+
|`recognizePromptSubOperationName` | A subtype of the operation. Potential values include `File`, `TextToSpeech`, and `SSML`.|
123
+
| `playInLoop` | `True` if looping was requested for the play operation. `False` if otherwise.|
124
+
|`playToParticipant` | `True` if the play operation had a target. `False` if it was a play-to-all operation.|
125
+
| `interrupted` | `True` if the prompt is interrupted. `False` if otherwise.|
126
+
|`resultCode` | The result code of the operation. |
127
+
|`resultSubcode` | The result subcode of the operation. |
128
+
|`resultMessage` | The result message of the operation. |
129
+
130
+
Here's an example of a Call Automation media summary log:
131
+
131
132
```json
132
133
[
133
134
{
@@ -147,3 +148,7 @@ Communication Services offers the following types of logs that you can enable:
147
148
}
148
149
149
150
````
151
+
152
+
## Next steps
153
+
154
+
- Learn about the [insights dashboard to monitor Call Automation logs and metrics](/azure/communication-services/concepts/analytics/insights/call-automation-insights).
0 commit comments