• <1 minute

Azure Media Services Live Monitoring Dashboard open-source release

We are excited to announce the open-source release of the Azure Media Services (AMS) Live Monitoring Dashboard on GitHub. The Live Monitoring Dashboard is a .NET C# web app that enables Azure Media…

We are excited to announce the open-source release of the Azure Media Services (AMS) Live Monitoring Dashboard on GitHub.

The Live Monitoring Dashboard is a .NET C# web app that enables Azure Media Services (AMS) customers to view the health of their channel and origin deployments. The dashboard captures the state of ingest, archive, encode, and origin telemetry entities, enabling customers to quantify the health of their services with low latency. The dashboard supplies data on the incoming data rate for video stream ingestion, dropped data in storage archive, encoding data rate, and origin HTTP error statuses and latencies.

Special thanks to Prakash Duggaraju for his help and contributions to this project.

Dashboard overview

The image below illustrates the account-level view of the Live Monitoring Dashboard. The upper left pane highlights each deployment’s health status with a different status code color. Ingest, archive, origin, and encode telemetry entities are denoted by i, a, o, and e abbreviations respectively. Each color of theindicator summarizes whether an entity is currently impacted. Green denotes healthy, orange indicates mildly impacted, red indicates unhealthy, and gray indicates inactive. You can modify the thresholds for which these flags are raised from the storage account JSON configuration file. From the right pane, you can drill down into the detailed views for each deployment by clicking on the active status squares.

This dashboard is backed by a SQL database that reads telemetry data from your Azure storage account. Our telemetry release announcement blog post details the types of telemetry data supported today. Every 30 seconds all views within the dashboard are automatically refreshed with the latest telemetric data.

Home Page

Channel Detailed View

The channel detailed view provides incoming bitrate, discontinuity count, overlap count, and bitrate ratio data for a given channel. In this view, these fields represent the following:

  • Bitrate: the expected bitrate for a given track and incoming bitrate is the bitrate that the channel receives
  • Discontinuity count: the count of instances where a fragment was missing in the stream
  • Overlap count: the count of instances where the channel receives fragments with the same or overlapping stream timestamp
  • Bitrate ratio: the ratio of incoming bitrate to expected bitrate

Optimally, a channel should have no discontinuities, no overlaps, and a bitrate ratio of one. Flags are set to raise when these dimensions deviate from normal values.

Channel Detailed View

Archive Detailed View

The archive detailed view provides bitrate, dropped fragment count, and dropped fragment rate for the archive entities backing each track. In this view, these fields represent the following:

  • Bitrate: the expected bitrate of the given track
  • Dropped fragment count: the number of fragments dropped in the program
  • Dropped fragment ratio: the number of fragments dropped per minute

Optimally, the dropped fragment count and dropped fragment ratio should be zero.

Archive Detailed View

Origin Detailed View

The origin detailed view provides request count, bytes sent, server latency, end-to-end (E2E) latency, request ratio, bandwidth, and data output utilization ratio for a given origin. In this view, these fields represent the following:

  • Request count: the number of times a client requested data from the origin, categorized by the HTTP status code
  • Bytes sent: the number of bytes returned to the client
  • Server latency: the server latency component for responding to a request
  • End-to-end latency: the total latency for responding to a request
  • Request rate: the number of requests the origin receives per minute
  • Bandwidth: the origin response throughput
  • Request ratio: the percentage of requests for a given HTTP status code
  • Data output utilization ratio: the percentage of maximum throughput that the origin utilizes

Optimally, origin requests should return only HTTP 200 status codes and there should be no failed requests (HTTP 4XX + 5XX – 412). The data out utilization should preferably not exceed 90 – 95% of the maximum available throughput.

Origin Detailed View

Encode Detailed View

The encode detailed view provides the health status for inputs, transcoders, output, and overall health.

Encode Detailed View

Optimally, the encoder detailed view should reflect overall healthy status.

Providing feedback & feature requests

We love to hear from our customers and better understand your needs! To help serve you better, we are always open to feedback, new ideas, and appreciate any bug reports so that we can continue to provide an amazing service with the latest technologies. To request new features, provide ideas or feedback, please submit to User Voice for Azure Media Services. If you have any specific issues, questions, or find any bugs, please post your question or feedback to our forum.