Developers are provided access to analytics information regarding their own usage of APIs through the Developer portal on their profile page by clicking on the Analytics button.

This is a subset of the full data provided by the Publisher portal. In the Publisher portal, access to the organization's API usage information is via the Analytics link on the side menu.

When opened, a summary page is shown containing a roll-up of information in other sections including API by API usage.

Clicking on Usage in the navigation tab shows the overall usage and bandwidth information for the API instance along with an indication on where calls originated. The information is further broken down by API.

Usage information can be used to show where and how often certain APIs are called. This can be helpful when considering scale out of services that an organization provides.

The Health tab provides information around items such as Status codes and Cache usage. Status codes can give an indication on whether a lot of requests are coming through as unauthenticated (401) or if there are any server errors (500).

Looking for codes that are an exception can help understand when things are going wrong.

Another way of monitoring your API is to log information about calls received to EventHub.

EventHub is part of Azure Service Bus and allows massive ingestion of data, and it is discussed later in the book. Once data has been ingested into EventHub, it can be processed by a number of services, for instance, Azure Stream Analytics or Azure Functions, or can be processed by an Event Processor Host running within an Azure Web Job.

In order to log to EventHub, the API Management instance needs to have a logger added pointing to the EventHub and a policy added to those products or APIs that need to be logged. There is not a way to do this through the Publisher portal, so this needs to be performed through the API Management REST API. To use the REST API, it must first be enabled within the Publisher portal because it is disabled by default. This is performed via the Security page.

Like many other Azure services, access via the REST API is secured by shared access signatures. These can be generated programmatically, but for convenience, the token can also be manually created using the Access Token information within the Security | API page, setting a future date and time so the signature expires.

Once generated, the token can be used with API tools to call the API Management REST API, the URL of which is displayed in the Access Token information. For the purpose of this discussion, we will use Postman ( https://www.getpostman.com/), which is a Google Chrome application.

In this case, we will create a logger named eventhublogger, so we need to set the correct URL for the REST API and configure a number of headers. We set the URL to the following:

https://<APIM Instance Name>.management.azure-api.net/loggers/<LoggerName>?api-version=2014-02-14-preview 

We need to set an Authorization header to the value created when we manually generated the access token and the Content-Type to application/json.

To create the logger, we need to call PUT against the URL passing in a body that contains the configuration information for the EventHub we have created to receive the inbound API request information.

The format of the body that needs to be posted is:

{ 
  "type" : "AzureEventHub", 
  "description" : "<LOGGER DESCRIPTION>", 
  "credentials" : { 
    "name" : "<EVENT HUB NAME>", 
    "connectionString" : "<EVENT HUB CONNECTION STRING>" 
    } 
} 

When executed, an HTTP response of 201 indicates that the logger was successfully created.

Lastly, we ensure the data is logged to EventHub by configuring a policy that applies to either a product or an API. Policies were discussed in depth earlier in the chapter, so in this case, we will show only the policy that needs to be applied.

In this case, we are applying the policy to the Unlimited product and to the ProductApi API across all operations. The policy needs to be configured by setting logger-id to the name of the logger created through the REST API; in our case, this was eventhublogger.

Once saved, information about calls to the API will be logged directly to EventHub and can be processed as required. For instance, we can create an Azure Function that is triggered when a message is received on the EventHub. Azure Functions are described in detail in a later chapter, but it is useful to test that the logger is working correctly.

For details on creating an Azure Function, refer to Chapter 7, Azure Functions in Logic Apps. In this case, we just create a very basic function that reads messages and outputs the information to the function Logs window.

As can be seen within the Logs window, when a message is received on the EventHub, the Azure Function picks up the message for further processing if required. In the earlier example, the following information can be seen:

Date:                7/23/2016 9:10:37 AM 
Service Name:        sunnyelectricals.azure-api.net 
RequestId:           fec00577-9b17-4390-a85a-42eb913f36bd 
IP Address:          <Client IP Address> 
Operation:           Products_GetProducts