Metrics and Diagnostics and Cognitive with containers

 Metrics are numerical values that describe some aspect of a system at a point in time. Metrics are stored in a time series DB. This data store is most effective in analyzing time stamped data. Metrics are suited for alerting and fast detection of issues. They can tell you about system performance. You can combine them with logs to identify the root cause of the issue. 


Diagnostic Settings

You can configure diagnostic settings in your Cognitive Service resource to provide detailed information for diagnostics and auditing. The platform logs and metrics will be sent to a logging destination that you choose when configuring the settings. The available data that can be logged includes audit information, RequestResponse data, and AllMetrics.

Currently, you can have the diagnostic information sent to a Log Analytics workspace, Event Hubs, or Azure Storage. Each diagnostic setting that you configure, can only send data to one destination. If you need to send data to more than one destination, you will need to configure a new diagnostic setting for that destination.

Diagnostic Destinations

Destination

Description

Log Analytics Workspace

Collecting logs and metrics into a Log Analytics workspace allows you to analyze them with other monitoring data collected by Azure Monitor using powerful log queries and also to leverage other Azure Monitor features such as alerts and visualizations.

Event Hubs

Sending logs and metrics to Event Hubs allows you to stream data to external systems such as third-party SIEMs and other log analytics solutions.

Azure Storage

Archiving logs and metrics to an Azure storage account is useful for audit, static analysis, or backup. Compared to Azure Monitor Logs and a Log Analytics workspace, Azure storage is less expensive and logs can be kept there indefinitely.


Logs

Logs contain time-stamped information about changes made to resources. The type of information recorded varies by log source. The log data is organized into records, with different sets of properties for each type of record. The logs can include numeric values such as Azure Monitor metrics, but most include text data rather than numeric values.

The most common type of log entry records an event. Events can occur sporadically rather than at fixed intervals or according to a schedule. Events are created by applications and services, which provide the context for the events. You can store metric data in logs to combine them with other monitoring data for analysis.

You log data from Azure Monitor in a Log Analytics workspace. Azure provides an analysis engine and a rich query language. The logs show the context of any problems and are useful for identifying root causes.


Cognitive Services and Containers

Containers allow you to host Azure Cognitive Services either on-premises or on Azure. For example, if your application uses data in an on-premises SQL Server, you can deploy Cognitive Services in containers on the same network. Now your data can stay on your local network and not move to the cloud. Deploying Cognitive Services in a container on-premises will also decrease the latency between the service and your local data. This can dramatically improve performance because internet bandwidth is not involved.

You can deploy Cognitive Services containers in any container host. For example:

  • A local Docker host

  • An Azure Container Instance (ACI)

  • An Azure Kubernetes Service (AKS) cluster

The ability to run Cognitive Services in a container enables different deployment scenarios that can meet a variety of organizational security policies.

Downloading Cognitive Services containers

There are Docker containers ready for you to use in the Microsoft Container Registry. Each container provides a subset of Cognitive Services functionality. For example, not all features of the Text Analytics service are in a single container. Language detection, translation, and sentiment analysis are each separate container images. However, the setup steps are similar for each container.

For the Text Analytics service, each of the 3 core features maps to a separate image:

Feature

Image

Key Phrase Extraction

mcr.microsoft.com/azure-cognitive-services/keyphrase

Language Detection

mcr.microsoft.com/azure-cognitive-services/language

Sentiment Analysis v3 (English)

mcr.microsoft.com/azure-cognitive-services/sentiment:3.0-en

NOte: Sentiment Analysis supports other languages by replacing the en in the image with the correct language code

You can use the Docker pull command to download container images to work with them directly from your machine. Some of the containers are in a “Gated” public preview state, and you need to explicitly request access to use them. Otherwise the containers are available for anyone to use with their Azure Cognitive Services deployment.

Configuring Cognitive Services container images

All Cognitive Services image requires three settings: billing endpoint, subscription key, and EULA agreement. Some may require additional configuration, so consult the documentation for whichever container you choose.

Required configuration settings for all Cognitive Services containers:

Setting

Description

ApiKey

Key from your deployed Azure Cognitive Service; used for billing.

Billing

Endpoint URI from your deployed Azure Cognitive Service; used for billing.

Eula

Value of accept to state you accept the license for the container.

Consuming Cognitive Services from a Container

After your Cognitive Services container is deployed, applications consume the containerized Cognitive Services endpoint rather than the default Azure endpoint. This means that any data exchanged between the client application and the containerized service is not sent to the Azure resource endpoint. However, the container still needs to be able to connect to the Azure resource endpoint in order to submit usage metrics for billing.

Comments

Popular posts from this blog

Module6: QnA Maker and Module7: Conversational AI and Azure Bot service