# Monitoring activity in AWS Elemental MediaLive Operations: Monitoring run-time activity You can monitor activity on channels and multiplexes on the AWS Elemental MediaLive console, or using Amazon CloudWatch Events, Amazon CloudWatch Logs, or AWS CloudTrail. **Topics** + [ # Types of activity that can be monitored ](monitor-activity-types.md) + [ # List of alerts for channels ](monitor-activity-types-alerts-channels.md) + [ # Alerts for multiplexes ](monitor-activity-types-alerts-multiplex.md) + [ # Monitoring using the MediaLive console ](monitoring-console-general.md) + [ # Monitoring alerts using the AWS SDKs or API ](monitoring-api.md) + [ # Monitoring a channel or multiplex using Amazon CloudWatch Events ](monitoring-via-cloudwatch.md) + [ # Monitoring channels using Amazon CloudWatch metrics ](monitoring-eml-metrics.md) + [ # Monitoring a channel using Amazon CloudWatch Logs ](monitoring-with-logs.md) + [ # Logging MediaLive API calls with AWS CloudTrail ](logging-using-cloudtrail.md) + [ # Monitoring AWS media services with workflow monitor ](monitor-with-workflow-monitor.md) # Types of activity that can be monitored The following table summarizes the type of MediaLive activity you can monitor, and the service you can use. In the table, read down the first column to find the type of activity you want to monitor, then read across to find the service to use. | Activity | Specific activity | MediaLive console | An AWS SDK or API | CloudWatch events | CloudWatch metrics | CloudWatch logs | CloudTrail events | | --- | --- | --- | --- | --- | --- | --- | --- | | State of channel | Report state of a channel | Yes | Yes | Yes | | Yes | | | State of multiplex | Report state of a multiplex | Yes | Yes | Yes | | Yes | | | Alerts | Generate alerts when a channel or multiplex is running | Yes | Yes | Yes | Yes (count of active alerts) | Yes | | | Alerts | Generate alerts about the state of the cluster, when deploying AWS Elemental MediaLive Anywhere | Yes | Yes | Yes | Yes (count of active alerts) | Yes | | | Metrics | Generate metrics | | | | Yes | | | | Logs for channel and multiplex | Log activity when a channel or multiplex is running | | | | | Yes | | | Logs for schedule | Log active schedule actions | | | | | Yes | | | Logs for API calls | Log API calls, including those performed from the console | | | | | Yes | Yes | The following sections provide details about some of these types of activities. **Topics** + [ # States for channels and multiplexes ](monitor-activity-types-channel.md) + [ # Alerts that MediaLive generates ](monitor-activity-alerts.md) + [ # Metrics that MediaLive generates ](monitor-activity-types-metrics.md) + [ # Logs that MediaLive generates ](monitor-activity-types-logs.md) # States for channels and multiplexes You can monitor the states of MediaLive channels and multiplexes. MediaLive reports the state of all channels. MediaLive turns these states into CloudWatch events with the detailType set to `MediaLive Channel State Change`. For an example of the JSON for these events, see [JSON for a state change event](monitoring-cloudwatch-json-state-change.md). The channel states are the following: + **Creating** + **Deleting** + **Idle**: The channel isn't running. For information about charges that you accrue when a channel is idle, see [Pricing in MediaLive](pricing.md). + **Recovering**: One or both pipelines in the channel failed, but MediaLive is restarting it. + **Running**. + **Starting** + **Stopping** + **Updating**: You changed the [channel class](class-channel-input.md)for a channel. This state is captured on the console but not in [Amazon CloudWatch events](monitoring-via-cloudwatch.md). MediaLive reports the state of all multiplexes. MediaLive turns these states into CloudWatch events with the detailType set to `MediaLive Multiplex State Change`. The multiplex states are the following: + **Creating** + **Deleting** + **Idle**: The multiplex isn't running. For information about charges that you accrue when a multiplex is idle, see [Pricing in MediaLive](pricing.md). + **Recovering**: One or both pipelines in the multiplex failed, but MediaLive is restarting it. + **Running** + **Starting** + **Stopping** # Alerts that MediaLive generates Alerts MediaLive can generate alerts when a channel is running. For a list of alerts, see [List of alerts for channels](monitor-activity-types-alerts-channels.md). You can view the alerts for each channel on the MediaLive console. For more information, see [Alerts tab – Viewing alerts](monitoring-console-general.md#view-alerts). MediaLive turns alerts into CloudWatch events with the detailType set to `MediaLive Channel Alert`. For an example of the JSON for these events, see [JSON for a state change event](monitoring-cloudwatch-json-state-change.md). # Metrics that MediaLive generates Metrics For complete information about MediaLive metrics, see [Monitoring channels using Amazon CloudWatch metrics](monitoring-eml-metrics.md) later in this chapter. # Logs that MediaLive generates Logs For complete information about MediaLive logs, see [Monitoring a channel using Amazon CloudWatch Logs](monitoring-with-logs.md) later in this chapter. # List of alerts for channels Alerts list - channelsMediaLive alerts We have added more alerts to the list of MediaLive alerts. Previously, some alerts were omitted in error.MediaLive alerts The guide now includes a list of the alerts that MediaLive might generate when a channel is running The following table lists the alerts that MediaLive might generate for a channel. You can view these alerts in these ways: + You can view the alerts for each channel on the MediaLive console. For more information, see [Alerts tab – Viewing alerts](monitoring-console-general.md#view-alerts). + You use your preferred AWS SDK or API to monitor alerts about channel activity. For more information, see [Monitoring alerts using the AWS SDKs or API](monitoring-api.md). + MediaLive turns alerts into CloudWatch events with the detailType set to `MediaLive Channel Alert`. For an example of the JSON for these events, see [JSON for a state change event](monitoring-cloudwatch-json-state-change.md). | Alert ID | Alert wording | Description | | --- | --- | --- | | 5002 | Input Image Missing | The channel was configured with a URL to an input image (for example, an avail blanking image). The channel can't access the file. | | 5007 | Initial Probe is Taking Longer Than Expected | The MediaLive pipeline is not yet generating output because it is waiting for an input that it can successfully decode. | | 5008 | Input Resource is Inaccessible | The channel configuration references a resource that MediaLive can't access. The specific resource is identified in the alert. | | 5010 | Input Removed the Active Program | The transport stream program that was in use is no longer present in the input. | | 5012 | SCTE-35 Input Data Could Not Be Processed | MediaLive can't process the SCTE-35 data that is being received. It's possible that the SCTE-35 PTS is not synchronized with the video PTS. | | 5101 | Audio Not Detected | The channel can't decode audio in the source. Either the active input is unavailable, or the active input doesn't contain audio, or the audio is encrypted. | | 5102 | Audio PID Missing | The audio selector for the current input specifies a PID (as the source of the audio), but that PID doesn't exist in the input. | | 5104 | Audio Requires Dolby E Decode | The input requires Dolby E decode, but a Dolby E decode audio track selector was not specified. MediaLive might replace the audio with silence. | | 5201 | Video Not Detected | The channel can't decode the video in the source. Either the active input is unavailable, or the active input doesn't contain video, or the video is encrypted. | | 5202 | Black Video Detected | Black video was detected. MediaLive might have performed an automatic input failover. | | 5301 | HTTP Get Failed | The HTTP Get failed, so retrieval of the asset failed. Perhaps there was a network issue, or the HTTP server had a problem, or the server requires user credentials. | | 5302 | Stopped Receiving UDP Input | A UDP input (which includes RTP, MediaConnect, and Link inputs) did not receive any packets for at least one second. | | 5304 | RTP Header Corruption | The channel is configured to receive an RTP input, but the packets received don't conform to RTP. | | 5305 | RTMP Stream Not Found | The channel is configured to receive an RTMP input, but the specified RTMP stream is not being received. | | 5307 | RTMP Has No Audio/Video | The channel is configured to receive an RTMP input, but the specified RTMP stream is no longer present. | | 5308 | RTMP Disconnected | The channel is configured to receive an RTMP input, but the specified RTMP stream has disconnected. | | 5309 | RTMP Input Connect Failed | The channel is configured to receive an RTMP input but there was a failure to connect to the RTMP URL. | | 5313 | HLS Segments Could Not Be Decrypted | An HLS input could not be decrypted. Check that the key provided for decryption is correct. | | 5314 | Input Double-Publishing Detected | Multiple source IP addresses are sending packets to the same MediaLive input. This situation typically causes decode errors. | | 5315 | Data PID Missing | A transport stream data PID was specified in the channel configuration, but it isn’t available in the input. | | 5316 | Input PTS Behind PCR | A transport stream input contains video and/or audio frames that are arriving too late to decode based on comparison of their PTS (presentation timestamp) to the transport stream PCRs (program clock references). MediaLive might not be able to decode the video or audio. | | 5601 | Input Failed Over | An input has failed and the channel is configured for automatic input failover. MediaLive has switched to the other input. | | 6001 | ESAM HTTP Post Failed | A HTTP Post to the configured ESAM server failed. ESAM is part of the SCTE 35 configuration for the channel. | | 6002 | Failed to Open UDP Socket For Write | The channel failed to open a UDP output connection. | | 6003 | Failed to Write to UDP Socket | The channel failed to write a UDP output packet. | | 6005 | Failed to Create Output File or Socket | The channel failed to create an output file. | | 6006 | Failed to Write to Output | The channel failed to write data to an output. | | 6007 | Failed to Close or Finalize The Output | The channel failed to write data to an output | | 6008 | Failed to Delete Output File | The Channel failed to delete an output file. | | 6010 | Failed HTTP Post Output Request | An HTTP Post to an output failed. | | 6015 | Failed to Get HTTP Output Token | The channel couldn't write to an output because it was unauthorized. For example, an HTTP access returned 401 (Unauthorized) or 403 (Forbidden). | | 6018 | Failed RTMP Connection | The channel is configured to send RTMP output, but was not able to connect to its endpoint | | 6028 | Failed to Validate Certificate Chain When Publishing | An HTTP write failed because the remote server's SSL certificate or SSH fingerprint was deemed not OK. | | 6030 | The Configured TS Muxer Bitrate is Too Low | A transport stream output was configured and the bitrate specified is not sufficient to carry the video, audio, and data that need to be carried within it. The channel includes a transport stream output. The bitrate specified in the output is too low for the combined video, audio, and data. | | 6031 | Timecode Synchronization Threshold Exceeded | The channel was configured with a TimecodeConfiguration SyncThreshold, and the output timecode was resynchronized with the input timecode. | | 6033 | Pipeline is Paused | The MediaLive pipeline has been paused. | | 6035 | Unable to perform requested color space conversion | The channel was unable to perform the configured color space conversion. | | 6036 | Output is Paused | One or more outputs have been paused. | | 6038 | Nielsen Audio Watermarks could not be initialized | Nielsen audio watermarks could not be initialized. | | 6043 | Failed To Upload Thumbnail | Video thumbnails couldn't be uploaded. MediaLive might need access to Amazon S3. | | 6045 | The MQCS score is low for this pipeline | At least one of the outputs in the pipeline has a media quality confidence score (MQCS) that is below the acceptable level. | | 6501 | Large Upload Cache Backlog | The channel maintains a cache of files pending upload that it clears after successful delivery to the output. The cache has more files pending upload to the configured destination than expected, which might indicate a temporary network slowdown between MediaLive and the destination. Or it might indicate that the destination server is slower than expected. | | 6704 | Embedded Timecodes Too Far Apart for Pipeline Locking | Pipelines in the pipeline locking pool have embedded input timecodes that are too far apart for pipeline locking synchronization. This typically occurs when pipelines are receiving content from different input sources or when input sources are not properly synchronized. | | 6707 | Output Configuration Mismatch Detected | Pipelines in the pipeline locking pool have incompatible output configurations and pipeline locking has been disabled. This typically occurs when channels have different output group counts, segment lengths, muxer configurations, or video encoding parameters. Ensure all channels in the pipeline locking pool have identical output configurations. | | 6751 | Unable to Establish Video Alignment on Input Content | MediaLive is unable to synchronize video content across pipelines in the pipeline locking pool using [video aligned locking](pipeline-locking-verify-input.md#pipeline-locking-video-alignment-inputs). This typically occurs when input content differs between pipelines. Ensure that all pipelines in the pool are receiving identical source content. | # Alerts for multiplexes Alerts list - multiplexes The following table lists the alerts that MediaLive might generate for a multiplex. You can view these alerts in these ways: + You can view the alerts for each multiplex on the MediaLive console. For more information, see [Alerts tab – Viewing alerts](monitoring-console-general.md#view-alerts). + You use your preferred AWS SDK or API to monitor alerts about multiplex activity. For more information, see [Monitoring alerts using the AWS SDKs or API](monitoring-api.md). + MediaLive turns alerts into CloudWatch events with the detailType set to `MediaLive Multiplex Alert`. For an example of the JSON for these events, see [JSON for a state change event](monitoring-cloudwatch-json-state-change.md). | Alert ID | Alert wording | Description | | --- | --- | --- | | 7001 | Communication Lost from Encoder | The multiplex is not receiving communication from one or more encoders. | | 7002 | Communication Lost from Multiplex | The encoder is not receiving communication from the multiplex. | | 7003 | Active Encoder Switched for Program | The multiplex has switched to using a different encoder pipeline for the output of a multiplex program. | | 7004 | Active Encoder Sent Fill or Slate Frames | Program \$1\$1multiplex\$1program\$1name\$1 is receiving fill or slate frames from the active encoder. | | 7005 | MPTS Bitrate Overflow | The bitrate for the MPTS is over the limit. The MPTS bitrate is the sum of the bitrate for all of the programs. The problem should resolve itself within a few seconds. | # Monitoring using the MediaLive console Monitor from the console You can monitor the state and health of channels and multiplexes. **Topics** + [ ## Monitoring a channel using the console ](#monitoring-console) + [ ## Monitoring a multiplex using the Console ](#monitoring-multiplex-console) ## Monitoring a channel using the console Monitor a channel You can monitor a channel using the AWS Elemental MediaLive console to view its activity and its current state. **To monitor activity on a channel and its current state** 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Channels**. (For information about the buttons on the page, see [Editing a channel](editing-deleting-channel.md#editing-a-channel), [Starting, stopping, and pausing a channel](starting-stopping-deleting-a-channel.md), and [Creating a channel by cloning](creating-channel-clone.md).) 1. The **Channels** page shows a list of your channels. Each line in the list provides basic information about the channel, including its state. For information about states, see [States for channels and multiplexes](monitor-activity-types-channel.md). 1. To view more details about a channel, choose the name of that channel. The **Channel details** page appears. **Topics** + [ ### Status tab – Viewing status information ](#view-status-info) + [ ### Alerts tab – Viewing alerts ](#view-alerts) + [ ### Handling alerts ](#handle-alerts) + [ ### Destinations pane ](#view-status-details) ### Status tab – Viewing status information For basic status information, look at the **Status** pane. For information about the inputs in the channel, choose the **Details** tab. For detailed information about the status, choose the **Health** tab. This tab provides information for the pipelines in the channel: + Pipeline 0 and pipeline 1, if the channel is set up as a standard channel and therefore has two pipelines + Pipeline 0, if the channel is set up as a single-pipeline channel You can specify the period of time for the health information. ### Alerts tab – Viewing alerts MediaLive generates alerts for a channel when an issue or potential issue occurs in either pipeline in a channel. These alerts are displayed in two ways: + On the right side of the **Status** pane, there is a count of active alerts for each pipeline. + On the **Alerts** tab, details about each alert are displayed. If the alert is still active, the **Cleared** column is blank. If the alert has cleared, the column shows the timestamp for when it cleared. For a list of MediaLive alerts, see [List of alerts for channels](monitor-activity-types-alerts-channels.md). ### Handling alerts When an alert occurs, look at the **Alerts** tab to determine possible causes of the issue. Take steps to resolve the issue. After you resolve the issue, MediaLive automatically clears the alert. If you stop a channel, alerts always automatically clear. ### Destinations pane This pane has three panes: + **Egress endpoints** – This pane shows one line for each pipeline. The **Source IP** is the channel endpoint for this pipeline. The channel endpoint is the egress from the pipeline. From this point, the content goes to the output destinations for each of the output groups in the channel. In a regular channel, this endpoint is in a location that MediaLive manages. In a channel set up for [delivery via your VPC](delivery-out-vpc.md), this endpoint is in your VPC. You are responsible for ensuring that this endpoint is always available to accept the content from the channel pipeline. + **Destinations** – This pane shows one line for each destination. Each output group has one destination line. Each line shows the address of the output in the one or two pipelines in the channel. + **MediaPackage destinations** – This pane shows the channel ID that is the destination for each MediaPackage output group. The channel in MediaPackage has one or two pipelines, mapped to the one or two pipelines in MediaLive. ## Monitoring a multiplex using the Console Monitor a multiplex You can view the activity of your multiplex and its current state. **To monitor activity on a multiplex (MediaLive console)** 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Multiplexes**. 1. The **Multiplexes** page shows a list of your multiplexes. Each line in the list provides basic information about the multiplex, including its state. For information about states, see [States for channels and multiplexes](monitor-activity-types-channel.md). 1. To view more details about a multiplex, choose the name of that multiplex. The **Multiplex details** page appears. **Topics** + [ ### Viewing status information ](#view-status-info) ### Viewing status information The **Multiplex details** page is divided into two panes. The second pane is divided into tabs. #### Details tab The **Details** tab shows the fields that you set when you created the multiplex. It also shows this information that MediaLive assigns: + The ARN of the multiplex. + The ARNs of the two entitlements that MediaLive automatically creates when you create the multiplex. For more information about these entitlements, see [Starting the multiplex](start-multiplex.md). #### Programs tab The **Programs** tab lists the tabs that are in the multiplex. For information about programs, see [Overview of multiplex and MPTS](mpts-general.md). #### Bandwidth monitoring tab The **Bandwidth monitoring **tab shows information about the bandwidth allocation for the multiplex. **To display the information as a bar chart** 1. Choose **Bar chart**. 1. Choose to show the multiplex (all the programs in the multiplex) or a specific program. 1. Choose which pipeline to show. The chart always shows the data for the most recent minute. The chart refreshes every minute. **To display the information as an area chart** 1. Choose **Area chart**. 1. Set the time window. This window sets the size of the x-axis. The window always shows 60 data points. Therefore, a window of 1 hour shows a data point every minute, for example. A window of 1 day shows a data point every 24 minutes. 1. Choose to show the multiplex (all the programs in the multiplex) or a specific program. 1. Choose which pipeline to show. #### Alerts tab MediaLive generates alerts for a multiplex when an issue or potential issue occurs in either pipeline in a multiplex. These alerts are displayed in two ways: + On the right side of the **Status** pane, there is a count of active alerts for each pipeline. + On the **Alerts** tab, details about each alert are displayed. If an alert is still active, the **Cleared** column is blank. If an alert has cleared, the column shows the timestamp for when it cleared. **To handle an alert** 1. When an alert occurs, look at the **Alerts** tab to determine possible causes of the issue. Take steps to resolve the issue. After you resolve the issue, MediaLive automatically clears the alert. The **Cleared** column shows the timestamp for when it cleared. 1. If you stop a channel, alerts always automatically clear. #### Tags Tab For information about tags, see [Tagging resources](tagging.md). # Monitoring alerts using the AWS SDKs or API Monitor alerts with SDK or APIMonitoring activity programatically You can now monitoring alerts using an AWS SDK or API. You can use your preferred AWS SDK or API to monitor alerts about channel activity, multiplex activity, and activity on the nodes in an AWS Elemental MediaLive Anywhere cluster. There is an operation for each resource: + `ListAlerts` for a specific channel, with optional state (SET or CLEARED) filter. The response includes information about the alert, the alert status, and the applicable pipeline. + `ListMultiplexAlerts` for a specific multiplex, with optional state (SET or CLEARED) filter. The response includes information about the alert, the alert status, and the applicable pipeline. + `ListClusterAlerts`, for a specific cluster, with an optional state (SET or CLEARED) filter. The response includes information about the alert, the alert status, and the node and channel that the alert applies to. You can query for alerts from when the alert is first set until the alert has been in a CLEARED state for approximately 5 minutes. ## Tips for ListAlerts and ListMultiplexAlerts The information in the response for channels and multiplexes is the following: + Alert type: A short description, usually 3 to 4 words. + Messages: A long description. + ID: The ID is created when the alert is first set. Note the following: + The ID is a hash of a monotonically increasing count. + Each channel (or multiplex) has its own ID series that increments independently of other series. This means that two channels might each have an alert with the same ID during the same time period, especially if the channels start at close to the same time. Therefore in your code, you should assign a unique identity to each alert by combining the channel ID and alert ID. + The rollover of IDs for one channel (or multiplex) is reset each time the channel (or multiplex) restarts. Keep this in mind when performing a query. ## Tips for ListClusterAlerts The information in the response for clusters is the following: + Alert type: `CLUSTER_NODE_HEALTH` for every type of alert. + Message: A long description, which might include variables that resolve differently in each cluster or in each instance of an alert. + ID: A long description that is often equivalent to the message. # Monitoring a channel or multiplex using Amazon CloudWatch Events Monitor with CloudWatch events MediaLive automatically turns the following information into events in CloudWatch Events: + Reporting on the [state of a channel or multiplex](monitor-activity-types-channel.md). + [Alerts ](monitor-activity-types-alerts-channels.md)generated when a channel is running. You can use Amazon CloudWatch Events to manage these events. For example, you can create event rules and deliver the events in emails or SMS messages. You can deliver events to a number of destinations. This chapter describes how to deliver them through Amazon Simple Notification Service (SNS). For complete information about the options for managing events using Amazon CloudWatch Events, see the [CloudWatch Events User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html). For complete information about using Amazon SNS, see the [SNS Developer Guide](https://docs.aws.amazon.com/sns/latest/dg/welcome.html). Note that events are emitted on a best-effort basis. **Topics** + [ # JSON for a state change event ](monitoring-cloudwatch-json-state-change.md) + [ # JSON for an alert event ](monitoring-cloudwatch-json-alert.md) + [ # Option 1: Send all MediaLive events to an email address ](option-1.md) + [ # Option 2: Send events for specific channels to an email address ](option-2.md) # JSON for a state change event Events that are based on a change of state in a [channel or multiplex](monitor-activity-types-channel.md) are identified by their `detail-type` property: + `MediaLive Channel State Change` for a channel + `MediaLive Multiplex State Change` for a multiplex. **Example** Following is an example of the JSON payload for a state change event. Note the `detail-type` in line 3. ``` { "version": "0", "id": "fbcbbbe3-2541-d4a3-d819-x39f522a8ce", "detail-type": "MediaLive Channel State Change", "source": "aws.medialive", "account": "111122223333", "time": "2023-03-08T18:40:59Z", "region": "us-west-2", "resources": [ "arn:aws:medialive:us-west-2:111122223333:channel:283886" ], "detail": { "channel_arn": "arn:aws:medialive:us-west-2:111122223333:channel:123456", "state": "DELETED", "message": "Deleted channel", "pipelines_running_count": 0 } } ``` # JSON for an alert event Events that are based on [alerts](monitor-activity-types-alerts-channels.md) are identified by their `detail-type` property: + `MediaLive Channel Alert` for a channel + `MediaLive Multiplex Alert` for a multiplex. **Example** Following is an example of the JSON payload for an alert event. Note the `detail-type` in line 3. ``` { "version": "0", "id": "154769fb-9f7c-32a1-6822-26fppppe5a58", "detail-type": "MediaLive Channel Alert", "source": "aws.medialive", "account": "111122223333", "time": "2023-03-08T18:14:25Z", "region": "us-west-2", "resources": [ "arn:aws:medialive:us-west-2:111122223333:channel:123456" ], "detail": { "alarm_state": "CLEARED", "alarm_id": "7ad616bd389832yue90aab1324bffab5b834a", "alert_type": "Failed to Create Output File or Socket", "pipeline": "0", "channel_arn": "arn:aws:medialive:us-west-2:111122223333:channel:123456", "message": "MPEGTS muxer for mediaID [1] unable to open output or stream [https://]." } } ``` # Option 1: Send all MediaLive events to an email address Option 1: Events for all channel This option shows how to set up to send all events to a single email address. The drawback of this setup is that the email account will receive a large volume of emails. Therefore, we recommend that you don't use this setup in a production environment. You must perform the following procedure in each Region where channels or multiplexes are running. ## Create a subscription Step 1: Create a subscription Create a subscription to set up a specific email address so that it automatically receives email notifications when any event occurs in MediaLive. You must identify an email recipient for the emails. In the following procedure, we use the example of "MediaLive\$1alert" as the subject line and "MediaLive" as the sender of the email. We create the subscription using the Amazon Simple Notification Service (Amazon SNS) console. **To create a subscription for email notifications (Amazon SNS console)** 1. Sign in to the AWS Management Console and open the Amazon SNS console at [https://console.aws.amazon.com/sns/v2/home](https://console.aws.amazon.com/sns/v2/home). 1. In the navigation pane, choose **Topics**, and then choose **Create new topic**. 1. In the **Create new topic** dialog box, for **Topic name**, type the name that you want for the subject line of the email, such as **MediaLive\$1alert**. 1. For **Display name**, type the name that you want for the sender of the email, such as **MediaLive**. 1. Choose **Create topic**. 1. Amazon SNS creates the topic and displays the ARN in the list of topics. For example, `arn:aws:sns:us-west-2:111122223333:MediaLive`, where `111122223333` is your AWS account. 1. Copy this ARN to your clipboard. 1. In the navigation pane, choose **Subscriptions**, and then choose **Create subscription**. 1. On the **Subscriptions** page, choose **Create subscription**. 1. In the **Create subscriptions** dialog box, for **Topic ARN**, type or paste the ARN. 1. For **Protocol**, choose **Email**. 1. For **Endpoint**, type the email address of the recipient. You must be able to log on to this email account because Amazon SNS sends a confirmation email to this address. 1. Choose **Create subscription**. Amazon SNS sends a confirmation email to the address that you specified. 1. Log on to that email account, and display the email. Choose the "Confirm subscription" link in the email to enable the subscription. A confirmation window appears in a web browser. You can close this window. ## Create a rule Step 2: Create a rule You now create a rule in Amazon CloudWatch that says, "When CloudWatch receives any event from `aws.medialive`, invoke the specified SNS topic." In other words, you create a rule that sends an email to the subscribed email address. **To create a rule (Amazon CloudWatch console)** 1. Sign in to the AWS Management Console and open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. In the navigation pane, choose **Events**. 1. On the **Welcome to CloudWatch Events** page, choose **Create rule**. 1. On the **Step 1** page, in **Event Source**, choose **Event Pattern**. 1. Change **Build event pattern to match** to **Custom event pattern**. 1. In the box, type the following: ``` { "source": [ "aws.medialive" ] } ``` 1. On the pane on the right, choose **Add target**. 1. Choose **SNS topic**. 1. For **Topic**, choose the topic that you created, for example, **MediaLive\$1alert**. 1. In **Configure input**, choose **Matched event**. 1. Choose **Configure details**. 1. Type a name and optional description, and then choose **Create rule**. Now, whenever an alert occurs in MediaLive, an event will be sent to Amazon CloudWatch. This event will trigger the rule that instructs CloudWatch to send an email to the email address that you specified in the SNS subscription. # Option 2: Send events for specific channels to an email address Option 2: Events for specific channels You can set up a rule to send all events for one or several channels or multiplexes to one email address. You must perform this setup in each Region where channels or multiplexes are running. Create as many subscriptions and rules combinations as you need. Follow the steps for [option 1](option-1.md), with these differences: + When creating the SNS subscription, you might want to add more detail to the topic, for example, **MediaLive\$1notifications\$1channel\$11234567**. + When creating the CloudWatch rule, you create an event pattern that identifies `aws.medialive` as the event source and the ARN for the specific channel or multiplex as the resource within that event source. For example, for a channel create this pattern: ``` { "source": [ "aws.medialive" ], "resources": [ "arn:aws:medialive:us-west-2:111122223333:channel:1234567" ] } ``` The resource is the ARN for the channel or multiplex. You can obtain this ARN from the channels list or multiplexes list on the MediaLive console. The rule for this example says, "When CloudWatch receives any event from `aws.medialive` for channel `1234567`, invoke the specified SNS topic." In other words, the rule triggers an email that is sent to the subscribed email address. You can choose to include more than one channel or multiplex in the resources section, as shown in the following example: ``` "resources": [ "arn:aws:medialive:us-west-2:111122223333:channel:1234567", "arn:aws:medialive:us-west-2:111122223333:channel:2223334" ] ``` # Monitoring channels using Amazon CloudWatch metrics Monitor channels with metricsChannel and multiplex metrics with a 1 second period The CloudWatch metrics for AWS Elemental MediaLive channels and multiplex now support a period as low as 1 second. This enhancement gives you the ability to monitor activity in your channels in real time. You can monitor AWS Elemental MediaLive using Amazon CloudWatch metrics. CloudWatch collects raw data that it receives from MediaLive, and processes it into readable, near real-time metrics that are kept for 15 months. You use CloudWatch to view the metrics. Metrics can help you gain a better perspective about how MediaLive is performing over the short term and long term. You can set alarms that watch for certain thresholds, and send notifications or take actions when those thresholds are met. For more information, see the [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/). **Topics** + [ # Components of a metric ](eml-metrics-gen-info.md) + [ # Pricing to view MediaLive metrics ](eml-metrics-pricing.md) + [ # Viewing metrics ](eml-metrics-view.md) + [ # Alphabetical list of MediaLive metrics ](eml-metrics-alpha-list.md) + [ # Global metrics ](eml-metrics-global.md) + [ # Input metrics ](eml-metrics-input-metrics.md) + [ # MQCS metrics ](eml-metrics-quality-score.md) + [ # Output metrics ](eml-metrics-output-metrics.md) + [ # Pipeline locking metrics ](eml-metrics-output-lock.md) # Components of a metric AWS Elemental MediaLive collects data that is the basis for metrics. It collects these *datapoints* every second and sends them immediately to Amazon CloudWatch. You can use CloudWatch to generate *metrics* for these datapoints. A metric is a collection of datapoints that has had an aggregation (a *statistic*) applied and that has a *period* and a *time range*. For example, you can request the Dropped frames metric as an average (the statistic) for a 1-minute period over 10 minutes (the time range). This result of this request is 10 metrics (because the range divided by the period is 10). ## Statistics MediaLive supports all the statistics offered by CloudWatch. However, some statistics aren't useful for MediaLive metrics. In the description of metrics later in this chapter, we include the recommended statistics for each metric. ## Period All MediaLive metrics have a *high resolution period*, which means that the minimum period is 1 second. ## Time range Each period has a *maximum time range*. For example, if you specify 1 day as the time range, you won't be able to retrieve metrics with a 10 second period. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/medialive/latest/ug/eml-metrics-gen-info.html) Periods don't have a *minimum time range*. But there is a point where the statistic you apply becomes meaningless if you have a low period. For example, assume that you set the period to 1 second. This means that CloudWatch retrieves one datapoint. You can't obtain an average, a minimum or a maximum on one datapoint. However, this doesn't mean that the metric is meaningless. Instead, the metric is for the raw datapoint, with no statistic. ## Maximum storage time Metrics are available for the last 15 months. Make sure that you specify a period that allows the time range that you want. ## Dimensions for MediaLive Each MediaLive metric includes one or two specific sets of dimensions. MediaLive metrics include the following dimensions, from the dimension with the widest scope to the dimension with the narrowest scope. + ChannelID – Identifies a specific channel. + Pipeline – Identifies a specific pipeline. Standard channels have two pipelines (pipeline 0 or pipeline 1). Single-pipeline channels only have pipeline 0. + ActiveInputFailoverLabel – This dimension identifies the currently active input in a failover pair (part of the[ automatic input failover feature](automatic-input-failover.md)). Choose a dimension set that includes this dimension only if your channel implements automatic input failover. If you use this dimension, then the metric shows data only for the active input in the channel. If you don't use this dimension, the metric shows data for both inputs. + OutputGroupName – Identifies a specific output group. + AudioDescriptionName – Identifies a specific audio description (audio encode) among all the outputs of a channel. ## Definition of a running channel Many metrics collect data only when a channel is running. *Running *means that the channel has started. It could be both ingesting and producing output. Or it could be paused, meaning that it is still ingesting but not producing output. Keep in mind that you can view or retrieve metrics when the channel isn't running. The only requirement is that the channel has run in the last 15 months. # Pricing to view MediaLive metrics Pricing There is no charge to view metrics on the [**Health** tab ](eml-metrics-view.md)of the MediaLive console. For information about charges to view metrics on the CloudWatch console or to retrieve metrics using a CloudWatch API, see the [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/). # Viewing metrics You can view some metrics in the MediaLive console. You can view all metrics in the CloudWatch console. You can also retrieve metrics using the CLI, the REST API, or any AWS SDK. On the CloudWatch console, the minimum refresh rate for metrics is 30 seconds. **To view metrics on the MediaLive console** You can view some metrics in the MediaLive console. You can view those metrics for a range from the last hour up to the last week. (To view other metrics or to view historical metrics, you must use the CloudWatch console.) 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Channels**. In the **Channels** page, choose the channel you want. The **Channel details** page appears. 1. Choose the **Health** tab. The metrics that MediaLive supports on this tab appears. 1. Choose the period and time range. For example, **Past 1 day (5 min period)**. **To view metrics using the CloudWatch console** On the CloudWatch console you can view all MediaLive metrics for any range of time — the current metrics or historical metrics. There is a charge to view metrics on the CloudWatch console. 1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. In the navigation pane, choose **Metrics**, then choose **All metrics**. In the bottom half of the page, the **Browse** tab shows cards with names. No cards appear if you are completely new to AWS, and you haven't performed an action that creates metrics in any service. 1. Select the card that is named **AWS/MediaLive**. This card appears only if you have started at least one channel in the last 15 months in the AWS Region that is currently selected for CloudWatch. This card won't appear if have never started a MediaLive channel. In this case, come back to this procedure after you have created and started a channel. (A card named **MediaLive** might appear in the custom namespace section of the page. This card is for the old namespace for MediaLive metrics. The two namespaces became duplicates of each other in September of 2022, so there is no advantage to choosing this card. Always choose **AWS/MediaLive**.) 1. The **Browse** tab in the bottom half of the page now shows dimensions. Choose a metric dimension. For example, choose **Channel ID**. The **Browse** tab now shows a table with one column that shows the chosen dimension (for example, channel IDs) and one column that shows all the metrics. You can sort the table. 1. Select one or more rows. As soon as you select a row, it appears in the graph in the top half of the page. 1. In the bottom half of the page, choose the **Graphed metrics** tab. 1. On the choices on the right of the tab, specify the **Statistic** and the **Period**. When you choose the period, the graph refreshes to show the [maximum time range for that period](eml-metrics-gen-info.md#eml-metrics-about-time-range). If the graph is now empty on the left, you can adjust the timeline in the choices at the top right of the graph. Choose a lower number so that the full space is filled up. For example, change **1w** to **1d**. # Alphabetical list of MediaLive metrics [Active alerts](eml-metrics-global.md#eml-metrics-active-alerts) [Active outputs](eml-metrics-output-metrics.md#eml-metrics-active-outputs) [Complex FRC present](eml-metrics-output-metrics.md#eml-metrics-complex-frc-present) [Channel input error seconds](eml-metrics-input-metrics.md#eml-metrics-input-error-seconds) [Dropped frames](eml-metrics-output-metrics.md#eml-metrics-dropped-frames) [FEC row packets received](eml-metrics-input-metrics.md#eml-metrics-fec-row-received) [FEC column packets received](eml-metrics-input-metrics.md#eml-metrics-fec-col-received) [Fill msec](eml-metrics-output-metrics.md#eml-metrics-fill) [Input loss seconds](eml-metrics-input-metrics.md#eml-metrics-udp-input-loss) [Input timecodes present](eml-metrics-input-metrics.md#eml-metrics-input-timecode) [Input video aligned](eml-metrics-output-lock.md#eml-metrics-input-video-aligned) [Input video frame rate](eml-metrics-input-metrics.md#eml-metrics-input-frate) [Minimum MQCS](eml-metrics-quality-score.md#mqcs-min-mqcs) [MQCS black frame detected](eml-metrics-quality-score.md#mqcs-black-frame) [MQCS continuity counter errors](eml-metrics-quality-score.md#mqcs-continuity-counter) [MQCS fill frame insertions](eml-metrics-quality-score.md#mqcs-fill-frame) [MQCS freeze frame detected](eml-metrics-quality-score.md#mqcs-freeze-frame) [MQCS SVQ](eml-metrics-quality-score.md#mqcs-svq) [MQCS video frame drop](eml-metrics-quality-score.md#mqcs-video-frame-drop) [Network in](eml-metrics-input-metrics.md#eml-metrics-network-in) [Network Out](eml-metrics-output-metrics.md#eml-metrics-network-out) [Output audio level dBFS](eml-metrics-output-metrics.md#eml-metrics-audio-dbfs) [Output audio level LKFS](eml-metrics-output-metrics.md#eml-metrics-audio-lkfs) [Output 4xx errors](eml-metrics-output-metrics.md#eml-metrics-4xx) [Output 5xx errors](eml-metrics-output-metrics.md#eml-metrics-5xx) [Pipelines locked](eml-metrics-output-lock.md#eml-metrics-pipelines-locked) [Primary input active](eml-metrics-input-metrics.md#eml-metrics-primary-active) [RTP packets lost](eml-metrics-input-metrics.md#eml-metrics-packets-lost) [RTP packets received](eml-metrics-input-metrics.md#eml-metrics-packets-received) [RTP packets recovered via FEC](eml-metrics-input-metrics.md#eml-metrics-packets-recovered) [SVQ time](eml-metrics-output-metrics.md#eml-metrics-svq-time) # Global metrics Global metrics relate to general performance and information for AWS Elemental MediaLive. ## Active alerts The total number of alerts that are active. **Details:** + Name: ActiveAlerts + Units: Count + Meaning of zero: There are no active alerts + Meaning of no datapoints: The channel isn’t running + Supported dimension sets: ChannelID, Pipeline + Recommended statistic: Max All the statistics are useful for this metric. # Input metrics Input metrics relate to the video and audio input assets that are presented to MediaLive. **Topics** + [ ## Channel input error seconds ](#eml-metrics-input-error-seconds) + [ ## FEC row packets received ](#eml-metrics-fec-row-received) + [ ## FEC column packets received ](#eml-metrics-fec-col-received) + [ ## Input timecodes present ](#eml-metrics-input-timecode) + [ ## Input video frame rate ](#eml-metrics-input-frate) + [ ## Network in ](#eml-metrics-network-in) + [ ## Primary input active ](#eml-metrics-primary-active) + [ ## RTP packets lost ](#eml-metrics-packets-lost) + [ ## RTP packets received ](#eml-metrics-packets-received) + [ ## RTP packets recovered via FEC ](#eml-metrics-packets-recovered) + [ ## Input loss seconds ](#eml-metrics-udp-input-loss) ## Channel input error seconds The number of seconds in which the channel input contained one or more unrecoverable packets. This metric only applies to channel inputs of type RTP Push or MediaConnect. This metric is useful for monitoring the health of the input. It provides a time-based measurement for packet loss. Follow this guideline: + For a channel that implements automatic input failover, we recommend that you choose the dimension set that includes the ActiveInputFailoverLabel dimension, so that you get data for only one input. + For a channel that doesn't implement automatic input failover, don't include the ActiveInputFailoverLabel dimension set. The metric won't report any data. **Details:** + Name: ChannelInputErrorSeconds + Units: Count. + Meaning of zero: An RTP Push or MediaConnect input was being ingested and no packets were lost. + Meaning of no datapoints: There are no RTP Push or MediaConnect inputs active or being prepared (by the schedule). Or you included the ActiveInputFailoverLabel in a channel that isn't set up for automatic input failover. + Supported dimension sets: ChannelId, Pipeline ActiveInputFailoverLabel, ChannelId, Pipeline + Recommended statistic: Sum. ## FEC row packets received The number of forward error correction (FEC) row packets received on both FEC streams (port 5002 and port 5004). A non-zero value indicates that FEC is functioning. This metric is useful only if the channel has an RTP input that includes FEC. Follow this guideline: + For a channel that implements automatic input failover, we recommend that you choose the dimension set that includes the ActiveInputFailoverLabel dimension, so that you get data for only one input. + For a channel that doesn't implement automatic input failover, don't include the ActiveInputFailoverLabel dimension set. The metric won't report any data. **Details:** + Name: FecRowPacketsReceived + Units: Count. + Meaning of zero: An RTP-with-FEC input was being ingested during the period but no FEC row packets were received. + Meaning of no datapoints: There are no inputs with FEC. Or there are inputs with RTP inputs but none of those inputs are active or being prepared (by the schedule). Or you included the ActiveInputFailoverLabel in a channel that isn't set up for automatic input failover. + Supported dimension sets: ChannelId, Pipeline ActiveInputFailoverLabel, ChannelId, Pipeline + Recommended statistic: Sum. ## FEC column packets received The number of FEC column packets received on both FEC streams (port 5002 and port 5004). A non-zero value indicates that FEC is functioning. This metric is useful only if the channel has an RTP input that includes FEC. Follow this guideline: + For a channel that implements automatic input failover, we recommend that you choose the dimension set that includes the ActiveInputFailoverLabel dimension, so that you get data for only one input. + For a channel that doesn't implement automatic input failover, don't include the ActiveInputFailoverLabel dimension set. The metric won't report any data. **Details:** + Name: FecColumnPacketsReceived + Units: Count. + Meaning of zero: An RTP-with-FEC input was being ingested during the period but no FEC column packets were received. + Meaning of no datapoints: There are no inputs with FEC. Or there are inputs with RTP inputs but none of those inputs are active or being prepared (by the schedule). Or you included the ActiveInputFailoverLabel in a channel that isn't set up for automatic input failover. + Supported dimension sets: ChannelId, Pipeline ActiveInputFailoverLabel, ChannelId, Pipeline + Recommended statistic: Sum. ## Input timecodes present An indicator of whether a pipeline is receiving input that includes embedded timecodes. The embedded timecode might be embedded in the source, or it might be embedded in SMPTE-2038 ancillary data. 0 (false) means it isn’t present. 1 (true) means it is present. An embedded timecode that is inaccurate can cause problems in features that use the timecode. Therefore, it is useful to know whether the timecode that MediaLive is using is an embedded timecode or a system-clock timecode. The timecode that is associated with the input is used in several features: + Input clipping. This feature can use an embedded timecode or another type of timecode. + Generating a timecode in the outputs. This feature can use an embedded timecode or another type of timecode. + Pipeline locking. This feature works only if the input timecode is an embedded timecode; it doesn’t work with a system-clock timecode. For detailed information about timecodes, see [Working with timecodes and timestamps](timecode.md). Follow this guideline: + For a channel that implements automatic input failover, we recommend that you choose the dimension set that includes the ActiveInputFailoverLabel dimension, so that you get data for only one input. + For a channel that doesn't implement automatic input failover, don't include the ActiveInputFailoverLabel dimension set. The metric won't report any data. **Details:** + Name: InputTimecodesPresent + Units: None. + Meaning of zero: False (there is no embedded timecode). + Meaning of no datapoints: The channel is not running, or the channel is running but MediaLive isn’t receiving content (for example, the input is a push input and the upstream system hasn’t started pushing content). Or you included the ActiveInputFailoverLabel in a channel that isn't set up for automatic input failover. + Supported dimension sets: ChannelId, Pipeline ActiveInputFailoverLabel, ChannelId, Pipeline + Recommended Statistic: Minimum or maximum. The other statistics have no meaning. ## Input video frame rate The frame rate of the source video. This metric is an indicator of the health of the input. If the value isn't stable, investigate determine if there are problems with your source,and/or problems in the network between MediaLive and the upstream system. Follow this guideline: + For a channel that implements automatic input failover, we recommend that you choose the dimension set that includes the ActiveInputFailoverLabel dimension, so that you get data for only one input. + For a channel that doesn't implement automatic input failover, don't include the ActiveInputFailoverLabel dimension set. The metric won't report any data. **Details:** + Name: InputVideoFrameRate + Units: Frames per second. + Meaning of zero: The input has been received at some point since the channel started, but no frames were received in the current period. + Meaning of no datapoints: No input has been received since this channel started. Or you included the ActiveInputFailoverLabel in a channel that isn't set up for automatic input failover. + Supported dimension sets: ChannelID, Pipeline ActiveInputFailoverLabel, ChannelId, Pipeline + Recommended statistic: Max. ## Network in The rate of traffic coming into MediaLive. This number includes all traffic received into MediaLive—push inputs, pull inputs, responses from the upstream system of a pull input, responses from the downstream system for any output, and instance traffic such as DNS resolution and NTP. Even when a channel is not ingesting, there will be some traffic. It’s useful to set up to capture the average traffic rate over a long period. Then when you have established the normal rate, change the period to a short time, so that you can easily spot deviations from the normal rate, or collect information about how bursty a channel is. Here are some guidelines on interpreting this metric: + If the rate seems to be normal, then you might infer that the channel is running and successfully ingesting inputs. + If the number is lower than normal, then your channel might be running but without inputs attached. Keep in mind that there are charges for running channels even when they aren’t ingesting input. **Details:** + Name: NetworkIn + Units: Megabits per second. + Meaning of zero: No traffic is being received. + Meaning of no datapoints: The channel is not running. + Supported dimension sets: ChannelId, Pipeline + Recommended statistic: All the statistics are useful for this metric. ## Primary input active An indicator of whether the primary input in an automatic input failover pair is active. A value of 1 means that the primary input is active and is therefore healthy. A value of 0 means that it is inactive. For information about input failover pairs in the automatic input failover feature, see [Implementing automatic input failover](automatic-input-failover.md). This metric is useful if you have set up the automatic input failover feature with the input preference set to Primary Input Preference. The metric doesn’t provide any meaningful data if the input preference is set to Equal Input Preference. **Details:** + Name: PrimaryInputActive + Units: None. + Meaning of zero: False (the primary input is inactive). + Meaning of no datapoints: The channel is not set up for automatic input failure. + Supported dimension sets: ChannelId, Pipeline + Recommended statistic: Minimum (primary input is inactive) or maximum (primary input is active). ## RTP packets lost The number of RTP packets that are lost in the incoming transmission. *Lost *means packets that couldn't be recovered by FEC. This metric only applies to RTP input types. Received packets \$1 Recovered packets \$1 Lost packets = Total expected for the period, if the period and dimensions for the three metrics are set identically for the three metrics. These three RTP packet metrics are useful for monitoring the health of the input transmission. If this metric is non-zero, the first troubleshooting step is to look at the two [FEC metrics](#eml-metrics-fec-row-received), to determine whether FEC is functioning. If FEC is functioning well, the next step is to investigate problems in the upstream network. Follow this guideline: + For a channel that implements automatic input failover, we recommend that you choose the dimension set that includes the ActiveInputFailoverLabel dimension, so that you get data for only one input. + For a channel that doesn't implement automatic input failover, don't include the ActiveInputFailoverLabel dimension set. The metric won't report any data. **Details:** + Name: RtpPacketsLost + Units: Count. + Meaning of zero: An RTP-with-FEC input was being ingested during the period, but no packets were lost. + Meaning of no datapoints: No inputs are ingesting RTP. Or there are RTP inputs but none of those inputs are active or being prepared (by the schedule). Or you included the ActiveInputFailoverLabel in a channel that isn't set up for automatic input failover. + Supported dimension sets: ChannelId, Pipeline ActiveInputFailoverLabel, ChannelId, Pipeline + Recommended statistic: Sum. ## RTP packets received The number of RTP packets received in an RTP input. This number includes the main RTP source (port 5000) and the FEC data (ports 5002 and 5004). This metric only applies to RTP input types. Received packets \$1 Recovered packets \$1 Lost packets = Total expected for the period, if the periods for the three metrics are set identically. These three RTP packet metrics are useful for monitoring the health of the input transmission. Follow this guideline: + For a channel that implements automatic input failover, we recommend that you choose the dimension set that includes the ActiveInputFailoverLabel dimension, so that you get data for only one input. + For a channel that doesn't implement automatic input failover, don't include the ActiveInputFailoverLabel dimension set. The metric won't report any data. **Details:** + Name: RtpPacketsReceived + Unit: Count. + Meaning of zero: An RTP-with-FEC input was being ingested during the period, but no packets were received. + Meaning of no datapoints: No inputs are ingesting RTP. Or there are inputs with RTP inputs but none of those inputs are active or being prepared (by the schedule). Or you included the ActiveInputFailoverLabel in a channel that isn't set up for automatic input failover. + Supported dimension sets: ChannelId, Pipeline ActiveInputFailoverLabel, ChannelId, Pipeline + Recommended statistic: Sum. ## RTP packets recovered via FEC The number of RTP packets recovered via FEC. This metric only applies to RTP input types. Received packets \$1 Recovered packets \$1 Lost packets = Total expected for the period, if the periods for the three metrics are set identically. These three RTP packet metrics are useful for monitoring the health of the input transmission. Follow this guideline: + For a channel that implements automatic input failover, we recommend that you choose the dimension set that includes the ActiveInputFailoverLabel dimension, so that you get data for only one input. + For a channel that doesn't implement automatic input failover, don't include the ActiveInputFailoverLabel dimension set. The metric won't report any data. **Details:** + Name: RtpPacketsRecoveredViaFec + Units: Count. + Meaning of zero: An RTP-with-FEC input was being ingested during the period, but no packets were recovered. + Meaning of no datapoints: No inputs are ingesting RTP. Or there are inputs with RTP inputs but none of those inputs are active or being prepared (by the schedule). Or you included the ActiveInputFailoverLabel in a channel that isn't set up for automatic input failover. + Supported dimension sets: ChannelId, Pipeline ActiveInputFailoverLabel, ChannelId, Pipeline + Recommended statistic: Sum. ## Input loss seconds The number of seconds (the *input loss period*) for which the channel has not received packets from the source of an RTP or MediaConnect input. Each datapoint has a value between 0 and 10 seconds. This metric is useful for monitoring the health of the input transmission. You should look at the datapoints over several 10-second windows. + Consistent values of 0 (all packets received) – This pattern tells you that the input is healthy. + Consistent values of 10 (no packets received) – This pattern tells you that the input is not healthy. + A range of values starting at 0 and ending at 0 – This pattern tells you the input was not healthy but that it has recovered. For example, 0,2,10,10,5,10,6,2,0,0,0. + A range of values that don’t return to 0 – This pattern tells you that the input is not healthy. For example, 0,10,9,2,8,3,10,10,8,2. Also follow this guideline: + For a channel that implements automatic input failover, we recommend that you choose the dimension set that includes the ActiveInputFailoverLabel dimension, so that you get data for only one input. + For a channel that doesn't implement automatic input failover, don't include the ActiveInputFailoverLabel dimension set. The metric won't report any data. **Details:** + Name: InputLossSeconds + Units: Seconds. + Meaning of zero: There was no input loss. + Meaning of no datapoints: No inputs are ingesting RTP. Or there are inputs with RTP inputs but none of those inputs are active or being prepared (by the schedule). Or you included the ActiveInputFailoverLabel in a channel that isn't set up for automatic input failover. + Supported dimension sets: ChannelId, Pipeline ActiveInputFailoverLabel, ChannelId, Pipeline + Recommended statistic: Sum. # MQCS metrics MQCS metrics The metrics section now includes information about all metrics relating to MQCS (media quality confidence score). MQCS metrics relate to the media quality confidence score that MediaLive generates for specific outputs. For more information about MQCS, see [Working with MQCS](mqcs.md). **Topics** + [ ## Minimum MQCS ](#mqcs-min-mqcs) + [ ## MQCS black frame detected ](#mqcs-black-frame) + [ ## MQCS continuity counter errors ](#mqcs-continuity-counter) + [ ## MQCS fill frame insertions ](#mqcs-fill-frame) + [ ## MQCS freeze frame detected ](#mqcs-freeze-frame) + [ ## MQCS SVQ ](#mqcs-svq) + [ ## MQCS video frame drop ](#mqcs-video-frame-drop) ## Minimum MQCS The minimum media quality confidence score (MQCS) in the period. MQCS is a value from 0 to 100, with 0 being the lowest quality. The quality of the source directly affects the quality of each output encode that MediaLive sends to the downstream packager. The quality score is an amalgamation of the individual scores of each video and audio encode. + Name: MinMQCS + Units: None + Meaning of no datapoints: The channel doesn’t have any output groups in which MediaLive is generating an MQCS. For example, the channel doesn’t have any CMAF Ingest output groups. + Meaning of zero: At least one encode in at least one output has a quality score of 0. + Supported dimension sets: ChannelD, Pipeline, OutputGroupName + Recommended statistic: Minimum, which identifies the lowest quality score during the period. ## MQCS black frame detected The black frame portion of the MQCS (media quality confidence score). This portion is calculated as follows: The input has transmitted one or more sequential video frames that are valid but black. The score gets lower as long as the problem persists. As soon as MediaLive receives one frame without this problem, the score reverts to 100. + Name: MqcsBlackFrameDetected + Units: None + Meaning of no datapoints: The channel doesn’t have any output groups in which MediaLive is generating an MQCS. For example, the channel doesn’t have any CMAF Ingest output groups. + Meaning of zero: At least one encode in at least one output has a quality score of 0. + Supported dimension sets: ChannelD, Pipeline + Recommended statistic: Minimum, which identifies the lowest quality score during the period. ## MQCS continuity counter errors The continuity counter errors portion of the MQCS (media quality confidence score). This portion is calculated as follows: The input has transmitted one or more sequential segments that contain continuity errors. The score gets lower as long as the problem persists. As soon as MediaLive receives one frame without this problem, the score reverts to 100. + Name: MqcsContinuityCounterErrors + Units: Percentage + Meaning of no datapoints: The channel doesn’t have any output groups in which MediaLive is generating an MQCS. For example, the channel doesn’t have any CMAF Ingest output groups. + Meaning of zero: At least one encode in at least one output has a quality score of 0. + Supported dimension sets: ChannelD, Pipeline + Recommended statistic: Minimum, which identifies the lowest quality score during the period. ## MQCS fill frame insertions The black frame portion of the MQCS (media quality confidence score). This portion is calculated as follows: The input has transmitted one or more sequential video frames that are "fill frames". The score gets lower as long as the problem persists. As soon as MediaLive receives one frame without this problem, the score reverts to 100. + Name: dd + Units: None + Meaning of no datapoints: The channel doesn’t have any output groups in which MediaLive is generating an MQCS. For example, the channel doesn’t have any CMAF Ingest output groups. + Meaning of zero: At least one encode in at least one output has a quality score of 0. + Supported dimension sets: ChannelD, Pipeline + Recommended statistic: Minimum, which identifies the lowest quality score during the period. ## MQCS freeze frame detected The freeze frame portion of the MQCS (media quality confidence score). This portion is calculated as follows: The input has transmitted one or more sequential video frames that are valid but frozen. The score gets lower as long as the problem persists. As soon as MediaLive receives one non-frozen frame, the score reverts to 100. + Name: MqcsFreezeFrameDetected + Units: None + Meaning of no datapoints: The channel doesn’t have any output groups in which MediaLive is generating an MQCS. For example, the channel doesn’t have any CMAF Ingest output groups. + Meaning of zero: At least one encode in at least one output has a quality score of 0. + Supported dimension sets: ChannelD, Pipeline + Recommended statistic: Minimum, which identifies the lowest quality score during the period. ## MQCS SVQ The black frame portion of the MQCS (media quality confidence score). This portion is calculated as follows: The input has transmitted one or more sequential video frames that are affected by an SVQ (speed versus quality) problem. The score gets lower as long as the problem persists. As soon as MediaLive receives one frame without this problem, the score reverts to 100. + Name: dd + Units: None + Meaning of no datapoints: The channel doesn’t have any output groups in which MediaLive is generating an MQCS. For example, the channel doesn’t have any CMAF Ingest output groups. + Meaning of zero: At least one encode in at least one output has a quality score of 0. + Supported dimension sets: ChannelD, Pipeline + Recommended statistic: Minimum, which identifies the lowest quality score during the period. ## MQCS video frame drop The black frame portion of the MQCS (media quality confidence score). This portion is calculated as follows: The input has transmitted one or more sequential segments that contain dropped frames. The score gets lower as long as the problem persists. As soon as MediaLive receives one segment without dropped frames, the score reverts to 100. + Name: dd + Units: None + Meaning of no datapoints: The channel doesn’t have any output groups in which MediaLive is generating an MQCS. For example, the channel doesn’t have any CMAF Ingest output groups. + Meaning of zero: At least one encode in at least one output has a quality score of 0. + Supported dimension sets: ChannelD, Pipeline + Recommended statistic: Minimum, which identifies the lowest quality score during the period. # Output metrics New metrics The guide now includes information about the Dropped Frames metric and the SVQ Time metric. Output metrics relate to the video and audio assets that have been processed by MediaLive as an output. **Topics** + [ ## Active outputs ](#eml-metrics-active-outputs) + [ ## Dropped frames ](#eml-metrics-dropped-frames) + [ ## Fill msec ](#eml-metrics-fill) + [ ## Output audio level dBFS ](#eml-metrics-audio-dbfs) + [ ## Output audio level LKFS ](#eml-metrics-audio-lkfs) + [ ## Network Out ](#eml-metrics-network-out) + [ ## Output 4xx errors ](#eml-metrics-4xx) + [ ## Output 5xx errors ](#eml-metrics-5xx) + [ ## SVQ time ](#eml-metrics-svq-time) + [ ## Complex FRC present ](#eml-metrics-complex-frc-present) ## Active outputs The number of outputs that are being produced and successfully written to the destination. **Details:** + Name: ActiveOutputs + Units: Count. + Meaning of zero: None of the outputs are successfully being written to their destinations. If the outputs are configured to pause on input loss (according to the **Input loss action **setting for the output group), that behavior might be intentional. + Meaning of no datapoints: The channel isn’t generating output audio (it might still be starting or waiting for initial input). + Supported dimension sets: OutputGroupName, ChannelId, Pipeline + Recommended statistic: Minimum, which helps you identify situations when one or more outputs is not being produced. ## Dropped frames The number of input frames that MediaLive has dropped in the period. A value of 0 is expected and indicates that MediaLive is processing incoming frames in real time. A value other than 0 indicates that the encoder can't process the incoming video fast enough to keep up with real time. **Details** + Name: DroppedFrames + Units: Count + Meaning of zero: The encoder hasn't had to drop frames. + Meaning of no datapoints: The channel isn’t producing output. This means that it isn’t running, or that it is running but it is initializing, or waiting for initial input, or paused. + Supported dimensions sets: Pipeline, Region + Recommended statistic: Sum. ## Fill msec The current length of time (the *fill period*) during which MediaLive has filled the video output with fill frames. The fill period starts when the pipeline does not receive content from the input within the* expected time.* The *expected time *is based on the input frame rate. The fine points of the fill frame behavior are controlled by the input loss behavior fields in the channel configuration. For information about these fields, see [Global configuration – input loss behavior](creating-a-channel-step3.md#input-loss-behavior). A value of 0 means that fill frames aren't being used. A non-zero value means that fill frames are being used and that the input is unhealthy. The count is capped at 60,000 milliseconds (1 minute), which means that after the cap, the metric will be 60,000 until it drops to zero. Use this metric as follows: + If you have automatic input failover enabled – This metric typically shows zero all the time, even when there is a failover. The channel fails over to the other input immediately, which means that there is no need for MediaLive to use fill frames. + If you don’t have automatic input failover enabled – A non-zero value indicates that the input has failed, has been disrupted, or isn't keeping up with real time. **Details:** + Name: FillMsec + Units: Count. + Meaning of zero: The input is healthy and the output contains the expected video (rather than fill frames). + Meaning of no datapoints: The channel isn’t producing output, which means that it isn’t running. Or that it is running but it is initializing, or waiting for initial input, or paused. + Supported dimension sets: ChannelId, Pipeline + Recommended statistic: Maximum, to capture the capped count when fill frames are being used. ## Output audio level dBFS The output audio level in decibels relative to full scale (dBFS). **Details:** + Name: OutputAudioLevelDbfs + Units: Count. + Meaning of zero: The output audio level is 0 dBFS. + Meaning of no datapoints: The channel isn’t generating output audio (it might still be starting or waiting for initial input). + Supported dimension sets: AudioDescriptionName, ChannelId, Pipeline + Recommended statistic: Minimum or maximum, which identify the lowest and highest audio level during the period. ## Output audio level LKFS The output audio level in loudness, K-weighted, relative to full scale (LKFS). **Details:** + Name: OutputAudioLevelLkfs + Units: Count. + Meaning of zero: Output audio level is 0 LFKS. + Meaning of no datapoints: The channel isn’t generating output audio (it might still be starting or waiting for initial input). + Supported dimension sets: AudioDescriptionName, ChannelId, Pipeline + Recommended statistic: Minimum or maximum, which identify the lowest and highest audio level during the period. ## Network Out The rate of traffic out of MediaLive. This number includes all traffic sent from MediaLive — the media output, HTTP GET requests for pull inputs, NTP traffic, and DNS traffic. Even when a channel is not delivering output, there will be some traffic. **Details:** + Name: NetworkOut + Units: Megabits per second. + Meaning of zero: No traffic is being sent. + Meaning of no datapoints: The channel is not running. + Supported dimension sets: ChannelId, Pipeline + Recommended statistic: Average. ## Output 4xx errors The number of 4xx HTTP errors that have been received from the destination while delivering output. **Details:** + Name: Output4xxErrors + Units: Count. + Meaning of zero: The output is being delivered over HTTP and there are no errors. + Meaning of no datapoints: The output is not being delivered to the destination over HTTP. Or the channel is not running. + Supported dimension sets: OutputGroupName, ChannelId, Pipeline + Recommended statistic: Sum. ## Output 5xx errors The number of 5xx HTTP errors that have been received from the destination while delivering output. **Details:** + Name: Output5xxErrors + Units: Count. + Meaning of zero: The output is being delivered over HTTP and there are no errors. + Meaning of no datapoints: The output is not being delivered to the destination over HTTP. Or the channel is not running. + Supported dimension sets: OutputGroupName, ChannelId, Pipeline + Recommended statistic: Sum. ## SVQ time The percentage of time that MediaLive has had to reduce quality optimizations in order to emit output in real time. SVQ stands for speed versus quality. Any encoding task must balance emitting output in real time against a desire to produce the best quality possible. But sometimes MediaLive must reduce quality in order to encode fast enough to keep up with real time. **Details** + Name: SvqTime + Units: Percent + Meaning of zero: MediaLive hasn't had to reduce quality in order to produce output in real time. + Meaning of no datapoints: The channel isn’t producing output. This means that it isn’t running, or that it is running but it is initializing, or waiting for initial input, or paused. + Supported dimensions sets: Pipeline, Region + Recommended statistic: Max. ## Complex FRC present An indicator of whether complex FRC (framerate conversion) is present on a pipeline. Framerate conversion is considered complex if one of these statements is true: + The output framerate is NOT a whole number multiple of the input framerate. + The input framerate is NOT a whole number multiple of the output framerate. Following are examples of complex framerates: + Input FPS is 59.94, output FPS is 60. + Input FPS is 45, output FPS is 60. + Input FPS is 29.97 FPS, output FPS is 23.978. **Details** + Name: ComplexFrcPresent + Units: Not applicable. + Meaning of zero: MediaLive is not performing complex framerate conversion. + Meaning of no datapoints: The channel isn’t producing output. This means that it isn’t running, or that it is running but it is initializing, or waiting for initial input, or paused. + Supported dimensions sets: ChannelId, Pipeline + Recommended statistic: Max. # Pipeline locking metrics Pipeline locking metrics relate to the synchronization of MediaLive pipelines. **Topics** + [ ## Pipelines locked ](#eml-metrics-pipelines-locked) + [ ## Input video aligned ](#eml-metrics-input-video-aligned) ## Pipelines locked An indicator of whether the two pipelines are synchronized with each other. MediaLive uses [pipeline locking](pipeline-lock.md) to ensure that the two pipelines are synchronized with each other. The metric applies only to [output types that support pipeline locking](pipeline-lock.md). In addition, the metric applies only to the following channel configurations: + Standard channels that are configured for standard pipeline locking. + Standard channels and single-pipeline channels that are configured for epoch locking. + Single-pipeline channels using linked channels. If the metric applies, then a value of 1 means that all the eligible pairs of pipelines are synchronized. A value of 0 means that at least one pair of eligible pipelines is not synchronized. **Note** This metric also applies when you have enabled [video aligned locking](pipeline-locking-verify-input.md#pipeline-locking-video-alignment-inputs). Video aligned locking is an advanced configuration option that uses visual signature comparison instead of embedded timecodes for synchronization. The PipelinesLocked metric reports the same synchronization status regardless of whether standard pipeline locking or video aligned locking is in use. If the metric doesn't apply, the metric is always 0. **Details:** + Name: PipelinesLocked + Units: Not applicable. + Meaning of zero: False (the eligible pipelines are not synchronized). + Meaning of no data points: The channel is not running. + Supported dimension sets: ChannelId, Pipeline + Recommended statistic: Minimum (Value is 0). ## Input video aligned Indicates whether video aligned locking has successfully aligned the input video content between pipelines in the same pipeline locking pool. In a video aligned locking pool, one pipeline serves as the reference and will always show a value of 1 for this metric. All other pipelines will only show 1 when they are successfully aligned with the reference pipeline. Here are some guidelines on interpreting this metric: + A value of 1 means that pipeline is successfully aligned with the reference pipeline. If the metric shows a value of 0, this indicates that video alignment could not be established with the reference pipeline in the pipeline locking pool. This may be due to: + Content mismatch between input sources + Input loss + Content that frequently loops + If the metric frequently transitions between 0 and 1, this suggests intermittent alignment issues that should be investigated. **Details:** + Name: InputVideoAligned + Units: Not applicable. + Meaning of zero: False (Video alignment cannot be established or has been lost). + Meaning of no datapoints: Video aligned locking is not configured, or the pipeline has not processed any video frames since the channel started. + Supported dimension sets: ChannelId, Pipeline + Recommended statistic: Minimum # Monitoring a channel using Amazon CloudWatch Logs CloudWatch Logs MediaLive produces channel logs that contain detailed information about activity in a channel. The logs provide a sequential description of activity that occurs in the channel. These logs can be useful when the information in alerts ([Monitoring a channel or multiplex using Amazon CloudWatch Events](monitoring-via-cloudwatch.md)) does not provide enough information to resolve an issue on the channel. **Topics** + [ # About channel logs ](monitoring-logs-about.md) + [ # Enabling channel encoder logs ](enabling-disabling-logs.md) + [ # Working with logs ](working-with-logs.md) # About channel logs MediaLive produces channel logs that contain detailed information about activity in a channel. The logs provide a sequential description of activity that occurs in the channel. These logs can be useful when the information in alerts ([Monitoring a channel or multiplex using Amazon CloudWatch Events](monitoring-via-cloudwatch.md)) does not provide enough information to resolve an issue on the channel. There are two sets of channel logs: + Channel encoder logs. You must [enable ](enabling-disabling-logs.md)these logs. + Channel as-run logs. MediaLive always produces these logs. ## Comparison of types of logs **Features that are the same in both types of logs** Both types of logs are sent to Amazon CloudWatch Logs. You can use the standard features of CloudWatch Logs to view and manage the logs. For more information, see [Amazon CloudWatch Logs User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html). **Features that are different in the two types of logs** The following table describes the differences between channel encoder logs and channel as-run logs. | | Encoder logs | As-run logs | | --- | --- | --- | | Trigger for creation | You must [enable these logs ](enabling-disabling-logs.md)in order for MediaLive to produce them. | MediaLive always produces these logs. | | Level of detail | You can set a logging level to control the detail collected. | You can't change the logging level. | | Cost | There is a cost for these logs, as part of your charges for Amazon CloudWatch Logs. See [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/). Remember to [remove the logs](working-with-logs.md#manage-log-storage) after you delete the channel. | These logs are free. | | CloudWatch log stream | The log stream is named after the ARN/pipeline. | The log stream is named after the ARN/pipeline with \$1as\$1run appended to the name. | | Automation | You should not automate any processing based on the wording in these logs because that wording is subject to change.(By comparison, you can automate based on the wording in alerts, which are accessed using CloudWatch Events, because the wording of alerts does not change.) | You can automate based on the wording in these logs. | # Enabling channel encoder logs You enable channel encoder logs for an individual channel on the MediaLive console. You enable logging and set the logging level (error, warning, info, or debug) on a per channel basis. The channel must be idle in order to enable or disable logging. You don't need to enable as-run logs. MediaLive always produces these logs. **To enable a channel encoder log (MediaLive console)** 1. If you are a returning user of MediaLive, check with your administrator that your deployment has been set up in AWS IAM to support channel logs. 1. Your administrator might instruct you to update the `MediaLiveAccessRole` permission in one of the channels. If you are given this instruction, you must [edit a channel](editing-deleting-channel.md#editing-a-channel) (choose any idle channel), [display the **Channel and input details** page](role-and-remember-arn.md), and choose the **Update** button. When the role is updated in one channel, the change applies to all channels. 1. To enable encoder logs in a new channel, set up logging during [creation](creating-channel-scratch.md). To enable encoder logs in an existing channel, [edit the channel](editing-deleting-channel.md#editing-a-channel); this channel must be idle. In both cases, on the **General settings** page, in the **Channel logging** section, choose **Logging**. Choose a level other than **DISABLED**. For more information, see [Logging](creating-a-channel-step3.md#channel-logging). 1. You or an administrator can also go into CloudWatch Logs and set an expiry date for the logs. ## Disabling channel encoder logs You disable the capture of encoder-related logging information for an individual channel on the MediaLive console. Edit the channel, and on the **General settings** page, on the **Channel logging** section, choose **Logging**. Set the level to **DISABLED**. # Working with logs You view both encoder logs and as-run logs on the CloudWatch Logs console, in the same way that you view logs for any service. You don't have to set up the logs, logging groups, or log streams on the CloudWatch Logs console because MediaLive automatically sets them up for you. + Log group – The log group is always the following: **ElementalMediaLive**. + Log stream –The log stream is named as follows: + Encoder logs – named after the ARN/pipeline. + As-run logs – named after the ARN/pipeline with `_as_run` appended. For example: `arn_aws_medialive_us-west-2_111122223333_channel_5106412_0` `arn_aws_medialive_us-west-2_111122223333_channel_5106412_0_as_run` Where `5106412` is the channel ID and `0` is the pipeline. ## Content of encoder logs The logs are in JSON format: ``` { "encoder_pipeline": 0, "severity": "I", "timestamp": "2018-05-21T16:36:41.650318", "channel_arn": "arn:aws:medialive:us-west-2:111122223333:channel:5106412", "logger_name": "", "message": "Probing input media..." }, . . . ] ``` The data is the following: + `encoder_pipeline`: `0` or `1` (if the channel is set up as a [standard channel](channel-class.md) and therefore has two pipelines). + `severity`: A letter. The logging level (which you set when you enable logging) controls which severities could appear in logs. For more information, see [Log Levels and Verbosities](#log-levels). + `timestamp`: The time in ISO 8601 format: yyyy - mm - dd T hh : mm : ss : decimal fraction of second. + `channel_arn`: The ARN plus the channel ID. In the preceding example, the channel has ID `5106412`. + `logger_name`: This might be blank or might specify a name that ties a series of related messages together. + `message`: The message. Remember that the wording is subject to change, so you should not automate against it. ## Log levels and verbosities for encoder logs To use this table, find a level in the first column then read across to identify the message severities that will appear in the logs with this logging level. | Level | Debug messages | Info messages | Warning messages | Critical messages | Fatal messages | | --- | --- | --- | --- | --- | --- | | DEBUG | Yes | Yes | Yes | Yes | Yes | | INFO | | Yes | Yes | Yes | Yes | | WARNING | | | Yes | Yes | Yes | | ERROR | | | | Yes | Yes | ## Managing log storage When you delete a channel, the associated logs remain in CloudWatch Logs. You will continue to be charged for their storage until you delete them. To delete logs, change the log data retention. All the data that is older than the retention setting that you specify will be deleted. For more information, see [Amazon CloudWatch Logs User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html). The **Log group **for the logs is **ElementalMediaLive**. # Logging MediaLive API calls with AWS CloudTrail CloudTrail logging AWS Elemental MediaLive is integrated with AWS CloudTrail, CloudTrail is service that provides a record of actions taken by a user, role, or an AWS service. CloudTrail captures all API calls for MediaLive as events. The calls captured include calls from the MediaLive console and code calls to the MediaLive API operations. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for MediaLive. If you don't configure a trail, you can still view the most recent events in the CloudTrail console in **Event history**. Using the information collected by CloudTrail, you can determine the request that was made to MediaLive, the IP address from which the request was made, who made the request, when it was made, and additional details. To learn more about CloudTrail, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/). ## MediaLive information in CloudTrail CloudTrail is enabled on your AWS account when you create the account. When activity occurs in MediaLive, that activity is recorded in a CloudTrail event along with other AWS service events in **Event history**. You can view, search, and download recent events in your AWS account. For more information, see [Viewing Events with CloudTrail Event History](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html). For an ongoing record of events in your AWS account, including events for MediaLive, create a trail. A *trail* enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all AWS Regions. The trail logs events from all Regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see the following: + [Overview for Creating a Trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) + [CloudTrail Supported Services and Integrations](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations) + [Configuring Amazon SNS Notifications for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html) + [Receiving CloudTrail Log Files from Multiple Regions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) and [Receiving CloudTrail Log Files from Multiple Accounts](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html) All MediaLive actions are logged by CloudTrail and are documented in the https://docs.aws.amazon.com/medialive/latest/apireference/. Every event or log entry contains information about who generated the request. The identity information helps you determine the following: + Whether the request was made with root or AWS Identity and Access Management (IAM) user credentials. + Whether the request was made with temporary security credentials for a role or federated user. + Whether the request was made by another AWS service. For more information, see the [CloudTrail userIdentity Element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html). ## Understanding MediaLive log file entries A trail is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An event represents a single request from any source and includes information about the requested action, the date and time of the action, request parameters, and so on. CloudTrail log files aren't an ordered stack trace of the public API calls, so they don't appear in any specific order. The following example shows a CloudTrail log entry. The example shows the entry for one API call. The call is made by the identity that is specified in `userIdentity`, in this case a user with the user name `santosp`. The call was a `CreateInput` operation coming from the AWS CLI (as specified in `userAgent`) running on a computer with the IP address 203.0.113.33: ``` { “eventVersion”: “1.05", “userIdentity”: { “type”: “IAMUser”, “principalId”: “AIDACKCEVSQ6C2EXAMPLE”, “arn”: “arn:aws:iam::111122223333:user/santosp”, “accountId”: “111122223333”, “accessKeyId”: “AKIAOSFODNN7EXAMPLE”, “userName”: “santosp” }, “eventTime”: “2019-01-17T21:21:17Z”, “eventSource”: “medialive.amazonaws.com”, “eventName”: “CreateInput”, “awsRegion”: “us-west-2”, “sourceIPAddress”: “203.0.113.33”, “userAgent”: “aws-cli/1.16.86 Python/2.7.15 Darwin/17.7.0 botocore/1.12.76”, “requestParameters”: { “mediaConnectFlows”: [], “inputSecurityGroups”: [ “9999999” ], “sources”: [], “roleArn”: “MediaLiveAccessRole”, “requestId”: “1111aaaa-9604-4459-a160-46a28ae166", “name”: “live-studio-feed”, “type”: “RTP_PUSH”, } }, “responseElements”: { “input”: { “arn”: “arn:aws:medialive:us-west-2:111122223333:input:7780651”, “id”: “7780651”, “name”: “live-studio-feed”, “type”: “RTP_PUSH”, “sources”: [], “destinations”: [ { “url”: “rtp://198.51.100.10:1935”, “ip”: “198.51.100.10:1935”, “port”: “1935” }, { “url”: “rtp://192.0.2.131:1935”, “ip”: “192.0.2.131:1935”, “port”: “1935” } ], “mediaConnectFlows”: [], “state”: “DETACHED”, “attachedChannels”: [], “securityGroups”: [ “9999999” ], “roleArn”: “” } }, “requestID”: “d2f882ac-1a9d-11e9-a0e5-afe6a8c88993”, “eventID”: “ebbe0290-7a1b-4053-a219-367404e0fe96”, “readOnly”: false, “eventType”: “AwsApiCall”, “recipientAccountId”: “111122223333" } ``` # Monitoring AWS media services with workflow monitor Workflow monitorWorkflow monitor Analyze AWS media services and create signal maps, visualizations of the media workflow, between those services. Use the signal maps to generate monitoring alarms and notifications using CloudWatch, EventBridge, and CloudFormation. Workflow monitor is a tool for the discovery, visualization, and monitoring of AWS media workflows. Workflow monitor is available in the AWS console and API. You can use workflow monitor to discover and create visual mappings of your workflow's resources, called *signal maps*. You can create and manage Amazon CloudWatch alarm and Amazon EventBridge rule templates to monitor the mapped resources. The monitoring templates you create are transformed into deployable AWS CloudFormation templates to allow repeatability. AWS recommended alarm templates provide predefined best-practice monitoring. **Discover** Utilize signal maps to automatically discover interconnected AWS resources associated with your media workflow. Discovery can begin at any supported service resource and creates an end-to-end mapping of the workflow. Signal maps can be used as stand-alone visualization tools or enhanced with monitoring templates. ![\[Workflow monitor discovery components.\]](http://docs.aws.amazon.com/medialive/latest/ug/images/workflowmonitor-discovery.png) **Monitor** You can create custom CloudWatch alarm and EventBridge rule templates to monitor the health and status of your media workflows. Best practice alarm templates are available to import into your workflow monitor environment. You can use the best practice alarm templates as they are, or edit them to better fit your workflow. Any templates you create are transformed into CloudFormation templates for repeatable deployment. ![\[Workflow monitor monitoring components.\]](http://docs.aws.amazon.com/medialive/latest/ug/images/workflowmonitor-monitoring.png) **Note** There is no direct cost for using workflow monitor. However, there are costs associated with the resources created and used to monitor your workflow. When monitoring is deployed, Amazon CloudWatch and Amazon EventBridge resources are created. When using the AWS Management Console, prior to deploying monitoring to a signal map, you will be notified of how many resources will be created. For more information about pricing, see: [CloudWatch pricing](https://aws.amazon.com/cloudwatch/pricing/) and [EventBridge pricing](https://aws.amazon.com/eventbridge/pricing/). Workflow monitor uses AWS CloudFormation templates to deploy the CloudWatch and EventBridge resources. These templates are stored in a standard class Amazon Simple Storage Service bucket that is created on your behalf, by workflow monitor, during the deployment process and will incur object storage and recall charges. For more information about pricing, see: [Amazon S3 pricing](https://aws.amazon.com/s3/pricing/). Previews generated in the workflow monitor signal map for AWS Elemental MediaPackage channels are delivered from the MediaPackage Origin Endpoint and will incur Data Transfer Out charges. For pricing, see: [MediaPackage pricing](https://aws.amazon.com/mediapackage/pricing/). ## Components of workflow monitor Workflow monitor has four major components: + CloudWatch alarm templates - Define the conditions you would like to monitor using CloudWatch. You can create your own alarm templates, or import predefined templates created by AWS. For more information, see: [CloudWatch alarm groups and templates for monitoring your AWS media workflow](monitor-with-workflow-monitor-configure-alarms.md) + EventBridge rule templates - Define how EventBridge sends notifications when an alarm is triggered. For more information, see: [EventBridge rule groups and templates for monitoring your AWS media workflow](monitor-with-workflow-monitor-configure-notifications.md) + Signal maps - Use an automated process to create AWS Elemental workflow maps using existing AWS resources. The signal maps can be used to discover resources in your workflow and deploy monitoring to those resources. For more information, see: [Workflow monitor signal maps](monitor-with-workflow-monitor-configure-signal-maps.md) + Overview - The overview page allows you to directly monitor the status of multiple signal maps from one location. Review metrics, logs, and alarms for your workflows. For more information, see: [Workflow monitor overview](monitor-with-workflow-monitor-operate-overview.md) ## Supported services Workflow monitor supports automatic discovery and signal mapping of resources associated with the following services: + AWS Elemental MediaConnect + AWS Elemental MediaLive + AWS Elemental MediaPackage + AWS Elemental MediaTailor + Amazon S3 + Amazon CloudFront **Topics** + [ ## Components of workflow monitor ](#monitor-with-workflow-monitor-components) + [ ## Supported services ](#monitor-with-workflow-monitor-supported-services) + [ # Configuring workflow monitor to monitor AWS media services ](monitor-with-workflow-monitor-configure.md) + [ # Using workflow monitor ](monitor-with-workflow-monitor-operate.md) # Configuring workflow monitor to monitor AWS media services Configuring workflow monitor To setup workflow monitor for the first time; you create the alarm and event templates, and discover signal maps that are used to monitor your media workflows. The following guide contains the steps necessary to setup both Administrator and Operator level IAM roles, create workflow monitor resources, and deploy monitoring to your workflows. **Topics** + [ # Getting started with workflow monitor ](monitor-with-workflow-monitor-configure-getting-started.md) + [ # Workflow monitor groups and templates ](monitor-with-workflow-monitor-configure-templates.md) + [ # Workflow monitor signal maps ](monitor-with-workflow-monitor-configure-signal-maps.md) + [ # Workflow monitor quotas ](monitor-with-workflow-monitor-configure-quotas.md) # Getting started with workflow monitor Getting started The following steps provide a basic overview of using workflow monitor for the first time. 1. Setup workflow monitor IAM permissions for administrator and operator level roles: [Workflow monitor IAM policies](monitor-with-workflow-monitor-configure-getting-started-IAM.md) 1. Build alarm templates or import predefined templates created by AWS: [CloudWatch alarms](monitor-with-workflow-monitor-configure-alarms.md) 1. Build notification events that will be delivered by EventBridge: [EventBridge rules ](monitor-with-workflow-monitor-configure-notifications.md) 1. Discover signal maps using your existing AWS Elemental resources: [Signal maps ](monitor-with-workflow-monitor-configure-signal-maps.md) 1. Attach the alarm templates and notification rules to your signal map: [Attaching templates](monitor-with-workflow-monitor-configure-signal-maps-attach.md) 1. Deploy the templates to begin monitoring the signal map: [Deploying monitoring templates](monitor-with-workflow-monitor-configure-deploy.md) 1. Monitor and review your workflow monitor resources using the overview section of the AWS console: [Overview](monitor-with-workflow-monitor-operate-overview.md) ![\[The individual steps of setting up workflow monitor. Begin by creating the IAM roles. Next, create templates for alarms and events. Next, discover a signal map and attach your templates to the map. After a signal map has templates attached, the templates must be deployed. The final step is monitoring using the templates and overview resources.\]](http://docs.aws.amazon.com/medialive/latest/ug/images/workflowmonitor-overview-steps.png) # Workflow monitor IAM policies Workflow monitor IAM policies Workflow monitor interacts with multiple AWS services to create signal maps, build CloudWatch and EventBridge resources, and CloudFormation templates. Because workflow monitor interacts with a wide range of services, specific AWS Identity and Access Management (IAM) policies must be assigned for these services. The following examples indicate the necessary IAM policies for both administrator and operator IAM roles. ## Administrator IAM policy The following example policy is for an administrator-level workflow monitor IAM policy. This role allows for the creation and management of workflow monitor resources and the supported service resources that interact with workflow monitor. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudwatch:List*", "cloudwatch:Describe*", "cloudwatch:Get*", "cloudwatch:PutAnomalyDetector", "cloudwatch:PutMetricData", "cloudwatch:PutMetricAlarm", "cloudwatch:PutCompositeAlarm", "cloudwatch:PutDashboard", "cloudwatch:DeleteAlarms", "cloudwatch:DeleteAnomalyDetector", "cloudwatch:DeleteDashboards", "cloudwatch:TagResource", "cloudwatch:UntagResource" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "cloudformation:List*", "cloudformation:Describe*", "cloudformation:CreateStack", "cloudformation:UpdateStack", "cloudformation:DeleteStack", "cloudformation:TagResource", "cloudformation:UntagResource" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "cloudfront:List*", "cloudfront:Get*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:DescribeNetworkInterfaces" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "events:List*", "events:Describe*", "events:CreateEventBus", "events:PutRule", "events:PutTargets", "events:EnableRule", "events:DisableRule", "events:DeleteRule", "events:RemoveTargets", "events:TagResource", "events:UntagResource" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "logs:Describe*", "logs:Get*", "logs:TagLogGroup", "logs:TagResource", "logs:UntagLogGroup", "logs:UntagResource" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "mediaconnect:List*", "mediaconnect:Describe*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "medialive:*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "mediapackage:List*", "mediapackage:Describe*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "mediapackagev2:List*", "mediapackagev2:Get*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "mediapackage-vod:List*", "mediapackage-vod:Describe*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "mediatailor:List*", "mediatailor:Describe*", "mediatailor:Get*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "resource-groups:ListGroups", "resource-groups:GetGroup", "resource-groups:GetTags", "resource-groups:GetGroupQuery", "resource-groups:GetGroupConfiguration", "resource-groups:CreateGroup", "resource-groups:UngroupResources", "resource-groups:GroupResources", "resource-groups:DeleteGroup", "resource-groups:UpdateGroupQuery", "resource-groups:UpdateGroup", "resource-groups:Tag", "resource-groups:Untag" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:*" ], "Resource": "arn:aws:s3:::workflow-monitor-templates*" }, { "Effect": "Allow", "Action": [ "sns:TagResource", "sns:UntagResource" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "tag:Get*", "tag:Describe*", "tag:TagResources", "tag:UntagResources" ], "Resource": "*" } ] } ``` ------ ## Operator IAM policy The following example policy is for an operator-level workflow monitor IAM policy. This role allows for limited and read-only access to the workflow monitor resources and the supported service resources that interact with workflow monitor. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudwatch:List*", "cloudwatch:Describe*", "cloudwatch:Get*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "cloudformation:List*", "cloudformation:Describe*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "cloudfront:List*", "cloudfront:Get*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:DescribeNetworkInterfaces" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "events:List*", "events:Describe*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "logs:Describe*", "logs:Get*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "mediaconnect:List*", "mediaconnect:Describe*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "medialive:List*", "medialive:Get*", "medialive:Describe*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "mediapackage:List*", "mediapackage:Describe*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "mediapackagev2:List*", "mediapackagev2:Get*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "mediapackage-vod:List*", "mediapackage-vod:Describe*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "mediatailor:List*", "mediatailor:Describe*", "mediatailor:Get*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": "arn:aws:s3:::workflow-monitor-templates*" }, { "Effect": "Allow", "Action": [ "tag:Get*", "tag:Describe*" ], "Resource": "*" } ] } ``` ------ # Workflow monitor groups and templates Templates Before you can deploy workflow monitoring to a signal map, you must create the groups and templates for CloudWatch alarms and EventBridge notifications. The CloudWatch templates define what scenarios and thresholds will be used to trigger the alarms. The EventBridge templates will determine how these alarms are reported to you. If you only want mappings of your connected resources and do not want to use the monitoring template capabilities of workflow monitor, signal maps can be used without CloudWatch and EventBridge templates. For more information about using signal maps, see: [Signal maps ](monitor-with-workflow-monitor-configure-signal-maps.md) **Topics** + [ # CloudWatch alarm groups and templates for monitoring your AWS media workflow ](monitor-with-workflow-monitor-configure-alarms.md) + [ # EventBridge rule groups and templates for monitoring your AWS media workflow ](monitor-with-workflow-monitor-configure-notifications.md) # CloudWatch alarm groups and templates for monitoring your AWS media workflow CloudWatch alarms Workflow monitor alarms allow you to use existing CloudWatch metrics as the foundation of alarms for your signal maps. You can create an alarm template group to sort and classify the types of alarming that is important to your workflow. Within each alarm template group, you create alarm templates with specific CloudWatch metrics and parameters that you want to monitor. You can create your own alarm templates or import recommended alarm templates created by AWS. After creating an alarm template group and alarm templates within that group, you can attach one or more of these alarm template groups to a signal map. You must create an alarm template group first. After you have created an alarm template group, you can create your own templates or use recommended templates created by AWS. If you want to create your own alarm templates, continue on this page. For more information about importing recommended templates, see: [Recommended templates](monitor-with-workflow-monitor-configure-alarms-recommended-templates.md) This section covers the creation of CloudWatch alarms using workflow monitor. For more information about how the CloudWatch service handles alarms and details of the alarm components, see: [Using CloudWatch alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) in the *Amazon CloudWatch User Guide* ## Creating alarm template groups Alarm template groups allow you to sort and classify the types of alarms that are important to your workflow. **To create an alarm template group** 1. From the workflow monitor console's navigation pane, select **CloudWatch alarm templates**. 1. Select **Create alarm template group**. 1. Give the alarm template group a unique **Group name** and optional **Description**. 1. Select **Create**, You will be taken to the newly created alarm template group's details page. ## Creating alarm templates You can create alarm templates with the CloudWatch metrics and parameters that you want to monitor. **To create an alarm template** 1. From the alarm template group's details page, select **Create alarm template**. 1. Give the alarm template a unique **Template name** and optional **Description**. 1. In the **Choose metric** section: 1. Select a **Target Resource Type**. The target resource type is a resource for the respective service, such as a channel for MediaLive and MediaPackage or a flow for MediaConnect. 1. Select a **Metric Name**. This is the CloudWatch metric that acts as the foundation for the alarm. The list of metrics will change depending on the selected **Target Resource Type**. 1. In the **Alarm settings** section: **Note** For more information about how the CloudWatch service handles alarms and details of the alarm components, see: [Using CloudWatch alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) in the *Amazon CloudWatch User Guide* 1. Select the **Statistic**. This is a value such as a **Sum** or an **Average** that will be used to monitor the metric. 1. Select the **Comparison Operator**. This field references the **Threshold** that you set in the next step. 1. Set a **Threshold**. This is a numeric value that the **Comparison Operator** uses to determine greater than, less than, or equal to status. 1. Set a **Period**. This is a time value, in seconds. The **Period** is the length of time that the **Statistic**, **Comparison Operator**, and **Threshold** interact to determine if the alarm gets triggered. 1. Set the **Datapoints**. This value determines how many datapoints are needed to trigger the alarm. 1. Select how to **Treat Missing Data**. This selection determines how this alarm reacts to missing data. 1. Select **Create** to complete the process. An example of a completed alarm template could have the following parameters: A MediaConnect flow **Target Resource Type** is monitored for the Disconnections **Metric Name**. The **Statistic** value is set to Sum with a **Comparison Operator** of "greater than or equal to" and a **Threshold** of 10. The **Period** is set to 60 seconds, and only requires 1 out of 1 **Datapoints**. **Treat Missing Data** is set to "ignore." The result of these settings is: workflow monitor will monitor for disconnections on the flow. If 10 or more disconnections occur within 60 seconds, the alarm will be triggered. 10 or more disconnections in 60 seconds only needs to happen one time for the alarm to be triggered. # Recommended alarm templates for monitoring your AWS media workflow Recommended templates Workflow monitor's recommended templates are a curated selection of AWS Elemental service metrics with predefined alarm settings appropriate for the metric. If you do not want to create customized alarm templates, recommended templates provide you with best-practice monitoring templates that are created by AWS. Workflow monitor contains recommended template groups for each supported service. These groups are designed to apply best-practice monitoring to specific types of workflows. Each template group contains a curated selection of alarms configured from service-specific metrics. For example, a recommended template group for a MediaLive multiplex workflow will have a different set of preconfigured metrics than a MediaConnect CDI workflow. **To use recommended alarm templates** 1. Follow the steps to [create an alarm template group](monitor-with-workflow-monitor-configure-alarms.md#monitor-with-workflow-monitor-alarms-groups-create), or select an existing one. 1. In the **Alarm templates** section, select **Import**. You will need to import the AWS recommended templates into your template group. 1. Use the **CloudWatch alarm template groups** dropdown to select an AWS recommended group. These groups contain curated alarms for specific services. 1. Select the templates to import using the check boxes. Each template will list its metrics, preconfigured monitoring values, and provide a description of the metric. When you are done selecting templates, select the **Add** button. 1. The selected templates will move to the **Alarm template(s) to import** section. Review your choices and select **Import**. 1. After the import is complete, the selected templates will be added to the template group. If you want to add more templates, repeat the import process. 1. Imported templates can be customized after import. Alarm settings can be modified to fit your alarming needs. # EventBridge rule groups and templates for monitoring your AWS media workflow EventBridge rules CloudWatch uses Amazon EventBridge rules to send notifications. You begin by creating an event template group. In that event template group, you create event templates that determine what conditions create a notification and who is notified. This section covers the creation of EventBridge rules using workflow monitor. For more information about how the EventBridge service uses rules, see: [EventBridge rules](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html) in the *Amazon EventBridge User Guide* ## Creating event template groups Event template groups allow you to sort and classify events based on your use case. **To create an event template group** 1. From the workflow monitor console's navigation pane, select **EventBridge rule templates**. 1. Select **Create event template group**. 1. Give the alarm template group a unique **Group name** and optional **Description**. 1. Select **Create**, You will be taken to the newly created alarm template group's details page. ## Creating event templates You can send notifications based on event templates you create. **To create an event template** 1. From the event template group's details page, select **Create event template**. 1. Give the event template a unique **Template name** and optional **Description**. 1. In the **Rule settings** section: 1. Select an **Event type**. When selecting an event type, you can choose between several events created by AWS or select **Signal map active alarm** to use an alarm created by an alarm template. 1. Select a **Target service**. This determines how you would like to be notified of this event. You can select Amazon Simple Notification Service or CloudWatch logs. 1. After selecting a target service, select a **Target**. This will be a Amazon SNS topic or a CloudWatch log group, depending on your target service selection. 1. Select **Create** to complete the process. # Workflow monitor signal maps Signal maps Signal maps are visual mappings of AWS resources in your media workflow. You can use workflow monitor to start the signal map discovery on any of the supported resource types. During the discovery process, workflow monitor will automatically and recursively map all connected AWS resources. After the signal map has been created, you can use the workflow monitor console to do things like deploy monitoring templates, view metrics, and view details of the mapped resources. **Topics** + [ # Creating signal maps for AWS media workflows ](monitor-with-workflow-monitor-configure-signal-maps-create.md) + [ # Viewing signal maps of AWS media workflows ](monitor-with-workflow-monitor-configure-signal-maps-view.md) + [ # Attaching alarm and event templates to the signal map of your AWS media workflow ](monitor-with-workflow-monitor-configure-signal-maps-attach.md) + [ # Deploying templates to the signal map of your AWS media workflow ](monitor-with-workflow-monitor-configure-deploy.md) + [ # Updating the signal map of your AWS media workflow ](monitor-with-workflow-monitor-configure-signal-maps-update.md) + [ # Deleting the signal map of your AWS media workflow ](monitor-with-workflow-monitor-configure-signal-maps-delete.md) # Creating signal maps for AWS media workflows Creating signal maps You can use workflow monitor signal maps to create a visual mapping of all connected AWS resources in your media workflow. **To create a signal map** 1. From the workflow monitor console's navigation pane, select **Signal maps**. 1. Select **Create signal map**. 1. Give the signal map a **Name** and **Description**. 1. In the **Discover new signal map** section, resources in the current account and selected region are displayed. Select a resource to begin signal map discovery. The selected resource will be the starting point for discovery. 1. Select **Create**. Allow a few moments for the discovery process to complete. After the process is complete, you will be presented with the new signal map. **Note** Previews generated in the workflow monitor signal map for AWS Elemental MediaPackage channels are delivered from the MediaPackage Origin Endpoint and will incur Data Transfer Out charges. For pricing, see: [MediaPackage pricing](https://aws.amazon.com/mediapackage/pricing/). # Viewing signal maps of AWS media workflows Viewing signal maps Workflow monitor signal maps allow you to see a visual mapping of all connected AWS resources in your media workflow. **Signal map views** After selecting a signal map, you have two views that can be used to monitor or configure the signal map. **Monitor signal map** and **Configure signal map** is a context-sensitive button found in the upper-right of the signal map console section. If you select the signal map using the **Signal maps** section of the navigation pane, your signal map will be displayed in the configuration view. The configuration view allows you to make changes to the template groups attached to this signal map, deploy the attached templates, and view the basic details and tags of the signal map. If you select the signal map using the **Overview** section of the navigation pane, your signal map will be displayed in monitoring view. The monitoring view displays the CloudWatch alarms, EventBridge rules, alerts, logs, and metrics for this signal map. The view can be changed at any time by selecting the **Monitor/Configure signal map** button in the upper-right. The configuration view requires administrator-level IAM permissions. Required IAM permissions can be viewed here: [Workflow monitor IAM policies](monitor-with-workflow-monitor-configure-getting-started-IAM.md) **Navigating the signal map** A signal map will contain nodes for every supported AWS resource discovered by workflow monitor. Certain resources, such as MediaLive channels and MediaPackage endpoints can display thumbnail previews of the content, if thumbnail previews are available. Selecting a resource node, and selecting **View selected resource details** from the **Actions** dropdown menu will take you to the associated service's details page. For example, selecting a MediaLive channel and selecting **View selected resource details** will open the MediaLive console's details page for that channel. Selecting a resource node will filter the list of active alarms to only that node. If you select the resource's **Target ARN** in the active alarm, you will be taken to the associated service's details page, with the selected resource open. # Attaching alarm and event templates to the signal map of your AWS media workflow Attaching templates After you have created alarm and event templates, you need to attach these to a signal map. Any of the alarm and event templates you have created can be attached to any discovered signal maps. **To attach alarm and event templates to your signal map** 1. From the workflow monitor console's navigation pane, select **Signal maps** and select the signal map you want to work with. 1. In the upper-right of the signal map page, in the **CloudWatch alarm template groups** tab, select **Attach CloudWatch alarm template groups**. 1. In the new section that opens, choose all of the alarm template groups that you want to apply to this signal map, then select **Add**. This will cause the selected alarm template groups to move to the **Attached CloudWatch alarm template groups** section. 1. Selecting **Save** will save your changes and return you to the signal map page. 1. At the right of the signal map page, select the **EventBridge rule template groups** tab then select **Attach EventBridge rule template groups**. 1. In the new section that opens, choose all of the event template groups that you want to apply to this signal map, then select **Add**. This will cause the selected rule template groups to move to the **Attached EventBridge rule template groups** section. 1. Selecting **Save** will save your changes and return you to the signal map page. 1. You have assigned CloudWatch alarm and EventBridge rule templates to the signal map, but the monitoring is not yet deployed. The next section will cover the deployment of the monitoring resources. # Deploying templates to the signal map of your AWS media workflow Deploying monitoring templates After you have attached the alarm and event templates to your signal map, you must deploy the monitoring. Until the deployment is complete, the monitoring of your signal map will not be active. Workflow monitor will only deploy alarms that are relevant to the selected signal map. For example, the attached alarm template group might contain alarms for multiple services, such as MediaLive, MediaPackage, and MediaConnect. If the selected signal map only contains MediaLive resources, no MediaPackage or MediaConnect alarms will be deployed. **To deploy the monitoring templates** 1. After attaching alarm and event template groups to your signal map and saving your changes, select **Deploy monitor** in the **Actions** dropdown menu. 1. You will be asked to confirm the deployment and presented with the number of CloudWatch and EventBridge resources that will be created. If you would like to proceed, select **Deploy**. **Note** There is no direct cost for using workflow monitor. However, there are costs associated with the resources created and used to monitor your workflow. When monitoring is deployed, Amazon CloudWatch and Amazon EventBridge resources are created. When using the AWS Management Console, prior to deploying monitoring to a signal map, you will be notified of how many resources will be created. For more information about pricing, see: [CloudWatch pricing](https://aws.amazon.com/cloudwatch/pricing/) and [EventBridge pricing](https://aws.amazon.com/eventbridge/pricing/). Workflow monitor uses AWS CloudFormation templates to deploy the CloudWatch and EventBridge resources. These templates are stored in a standard class Amazon Simple Storage Service bucket that is created on your behalf, by workflow monitor, during the deployment process and will incur object storage and recall charges. For more information about pricing, see: [Amazon S3 pricing](https://aws.amazon.com/s3/pricing/). 1. The status of the deployment is displayed next to the name of the signal map. The deployment status is also visible in the **Stacks** section of the CloudFormation console. After a few moments of resource creation and deployment, your signal map monitoring will begin. # Updating the signal map of your AWS media workflow Updating signal maps If a change is made to your workflow, you might need to rediscover the signal map and redeploy monitoring resources. Workflow monitor is a visualization and monitoring tool that does not have the ability to make any changes to your workflow. Signal maps represent a point-in-time visualization of your workflow. In the event that you add, remove, or significantly modify parts of your media workflow, we recommend that you rediscover the signal map. If you have monitoring resources attached to the signal map, we recommend you redeploy monitoring after the rediscovery process. **To rediscover a signal map** 1. From the workflow monitor console's navigation pane, select **Signal maps** and select the signal map you want to work with. 1. Verify that you are in the **Configure signal map** view. For more information about changing views, see: [Viewing signal maps ](monitor-with-workflow-monitor-configure-signal-maps-view.md) 1. In the upper-right of the signal map page, select the **Actions** dropdown menu. Select **Rediscover**. 1. You will be presented with the rediscovery screen. Select a resource that is a part of the workflow you are rediscovering. Select the **Rediscover** button. 1. The signal map will be rebuilt according to the current workflow. If you need to redeploy monitoring resources, stay on this signal map's page. Any previously attached monitoring templates will remain attached, but will need to be redeployed. **To redeploy monitoring templates after a signal map rediscovery** 1. After the rediscovery, you will be directed to the updated signal map. To redeploy the monitoring templates, select **Deploy monitor** from the **Actions** dropdown menu. 1. You will be asked to confirm the deployment and presented with the number of any CloudWatch and EventBridge resources that will be created. If you would like to proceed, select **Deploy**. 1. The status of the deployment is displayed next to the name of the signal map. After a few moments of resource creation and deployment, your signal map monitoring will begin. # Deleting the signal map of your AWS media workflow Deleting signal maps If you not longer need a signal map, it can be deleted. If you have monitoring templates deployed on the signal map, the deletion process will ask you to delete any CloudWatch and EventBridge resources that have been deployed to this signal map. Deleting the deployed resources does not affect the templates that created them. This resource deletion is to ensure that you do not have CloudWatch and EventBridge resources that are deployed but not used. **To delete a signal map** 1. From the workflow monitor console's navigation pane, select **Signal maps** and select the radio button next to the signal map you want to delete. 1. Select the **Delete** button. You will be asked to confirm the deletion of the monitoring resources. Select **Delete** to begin the monitoring resource deletion process. 1. The **Monitor deployment** column will display the current status. When the status has changed to **DELETE\$1COMPLETE**, select the **Delete** button again. 1. You will be asked to confirm deletion of the signal map. Select **Delete** to proceed and delete the signal map. # Workflow monitor quotas Quotas The following section contains quotas for workflow monitor resources. Each quota is on a "per account" basis. If you need to increase a quota for your account, you can use the [AWS Service Quotas console](https://console.aws.amazon.com/servicequotas/home) to request an increase, unless otherwise noted in the following table. **Quotas** | Resource type | Quota | | --- | --- | | CloudWatch alarm template groups | 20 | | CloudWatch alarm templates | 200 | | EventBridge rule template groups | 20 | | EventBridge rule templates | 200 | | Signal maps | 30 | | Signal maps: CloudWatch alarm template groups attached to a single signal map | 5You cannot increase this quota. | | Signal maps: EventBridge rule template groups attached to a single signal map | 5You cannot increase this quota. | # Using workflow monitor Using workflow monitor Use the **overview** and **signal maps** sections of the workflow monitor console to review the current status of the workflows and any associated alarms, metrics, and logs. **Topics** + [ # Workflow monitor overview ](monitor-with-workflow-monitor-operate-overview.md) + [ # Overview logs and metrics for workflow monitor ](monitor-with-workflow-monitor-operate-logs-metrics.md) + [ # Using workflow monitor signal maps ](monitor-with-workflow-monitor-operate-signal-maps.md) # Workflow monitor overview Overview The **Overview** section of the workflow monitor console is a dashboard that provides at-a-glance information about your signal maps. In the overview section, you can see the current state of each signal map's monitoring, as well as CloudWatch metrics and any associated CloudWatch logs. You can select any signal map to be taken to that signal maps console page. **Overview filtering** Using the **Search** bar in the overview section, you can filter the list of signal maps using context sensitive constraints. After selecting the search bar, you will be presented with a list of **Properties** to filter by. Selecting a property will present **Operators** such as Equals, Contains, Does not equal, and Does not contain. Selecting an operator will create a list of resources from the selected property type. Selecting one of these resources will cause the signal map list to only display signal maps that fit the constraint you defined. # Overview logs and metrics for workflow monitor Logs and metrics To view CloudWatch metrics and logs for a signal map, select the radio button next to the name of the signal map. A tabbed interface for both metrics and logs will appear beneath the signal map list. **CloudWatch Metrics** CloudWatch metrics for the selected signal map will be context-sensitive and only display metrics associated with the services used in that signal maps workflow. You can use the on-screen metrics tools to customize the displayed metric periods and time ranges. **CloudWatch Logs ** If you associated a CloudWatch log group with the signal map, that group will be displayed here. # Using workflow monitor signal maps Using signal maps From the **overview** section of the console, you can select a specific signal map to view more information about that signal map and its attached monitoring resources. After selecting a signal map, you will be presented with the signal map and a number of tabbed section containing more information: + CloudWatch alarms + EventBridge rules + AWS Elemental alerts + Metrics + Logs + Basic details **Navigating the signal map** A signal map will contain nodes for every supported AWS resource discovered by workflow monitor. Certain resources, such as MediaLive channels and MediaPackage endpoints can display thumbnail previews of the content, if thumbnail previews are available. Selecting a resource node, and selecting **View selected resource details** from the **Actions** dropdown menu will take you to the associated service's details page. For example, selecting a MediaLive channel and selecting **View selected resource details** will open the MediaLive console's details page for that channel. Selecting a resource node will filter the list of active alarms to only that node. If you select the resource's **Target ARN** in the active alarm, you will be taken to the associated service's details page, with the selected resource open.