[Article] Generating Insights With WSO2 API Manager Analytics
By Chamin Dias
- 13 Sep, 2016
Table of contents
- Applies to
- Overview of the analytics model in WSO2 API Manager
- Importance of monitoring APIs
- WSO2 API Manager analytics model and using it to generate insights
- Statistics in API Publisher
- Statistics in API Store
- Real-time analytics in admin portal
|WSO2 API Manager||Version 2.0 and above|
|WSO2 API Manager Analytics||Version 2.0 and above|
WSO2 API Manager is an open source, production ready, complete API management solution that’s capable of managing APIs in a scalable and user-friendly manner. It facilitates all stages of the API lifecycle including creating, publishing, subscribing, and monitoring APIs. The statistics/analytics model in WSO2 API Manager is mainly used for monitoring purposes. It provides a variety of options to both API developers and subscribers to monitor, gain accurate knowledge, and understand APIs and API usage.
Overview of the analytics model in WSO2 API Manager
In a production environment, monitoring API usage and other related facts is an important task. It will help organizations to offer a better customer experience while exposing their services in the most optimal manner. Hence, a productive API management solution should be able to provide facilities related to gaining knowledge from API statistics via real-time analysis and batch analysis.
The WSO2 API Manager Analytics model facilitates a wide array of options to monitor API-related activities. These options include monitoring API usage, resource usage, API latency, usage across Geo locations, faulty invocations, and managing real-time alerts related to various aspects. Moreover, it provides a mechanism to analyze logs with its log analyzer as well. This log analyzer provides a live log viewer (with overview analyzing), application error analyzer, access token error analyzer, API deployment statistics analyzer, login error analyzer, and API failure analyzer.
By default, Statistics publishing is disabled in API Manager. To enable and use statistics, users will need WSO2 API Manager and the WSO2 API Manager Analytics pack. Both these products are hosted in the WSO2 API Manager official product distribution page. Please refer to the official documentation of WSO2 API Manager to find more information about configuring API manager statistics.
Here is the big picture of the API Manager + API Manager Analytics model. First, API Manager generates events based on the API Manager invocation pattern and publishes them to all the listening event analyzers via event publishing streams. Next, the analyzer (in this case API Manager Analytics distribution) accumulates the received data and generates the summarized data based on the summarization logic. Finally, this summarized data is retrieved by the API Manager and is presented in the respective API Manager dashboard interface. Details about the different event publishing streams can be found in the official documentation.
Figure 1: Overview of WSO2 API Manager statistics model
API-related statistical data is stored in an H2 database that’s created once analytics is enabled (under default settings). The statistics model in WSO2 API Manager provides the flexibility of using a database of your choice without limiting to the default H2 database. Please find more details about supported databases and the respective configurations in the official documentation, under the “Standard Setup” section.
Importance of monitoring APIs
In today’s competitive business environment, organizations should try to provide a better customer service and use their resources in the most optimal manner. In order to achieve both of the above needs, they must take strategic decisions from time to time based on reliable information sources about resource utilization and user experience. Since most of today’s modern business services are exposed via APIs, it is clear that monitoring is a key role player for an organization to succeed.
WSO2 API Manager analytics model and using it to generate insights
Let’s have a look at how WSO2 API Manager (with analytics enabled) helps to generate insights from its statistics/analytics model.
API Publisher and API Store interfaces provide dashboards for various kinds of API-related statistics. The admin portal of WSO2 API Manager has an alert mechanism based on real-time analysis as well.
Statistics in API Publisher
The API Publisher web interface in WSO2 API Manager consists of various dashboards for statistics/analytics. There are mainly three major statistics sets that are related to APIs, applications, and subscriptions.
These dashboards enable to filter data for a given time period. Moreover, it provides options to choose between viewing all APIs, or if you are an API creator, only APIs you have created.
Published APIs over time
The graph in Figure 2 depicts the published API count over time. This provides options to select a time duration as well. Using this graph, API publisher creators can get an idea about the API publishing pattern with the corresponding API publishing frequency.
Overall API usage (across all versions) is presented here. It has information about subscription count for each API along with the number of API invocations.
Figure 2: API usage graph - across all versions
This graph helps to identify the most invoked APIs in a glance because the size of the circle shown in the graph is a clear visual indication of the API hit count.
API response times
When it comes to displaying the time taken to respond by each API (across all versions), this graph will be useful. It helps to get a clear comparison between API response times in a glance.
Figure 3: API response time graph (across all versions)
At the same time, this graph can be used as an indicator of the API performance (based on response time) as well.
API last access times
If there’s a need to have a look at the last access time for a given API, this table contains the relevant information for that requirement. It provides the information about who (name of the subscriber) invoked a particular API with the time of invoking each API.
Figure 4: API last access times (across all versions)
Usage by resource path
An API might contain several different resources, e.g. a single API may have a GET resource, POST resource and DELETE resource. If API developers/publishers need to to know about the distribution of each resource path usage, this tabular representation will be useful. This table contains data about the usage (i.e. number of hits) for each resource in each API.
Figure 5: Usage by resource path shows the hit count for each API resource
API developers/publishers can use this table to get an idea about the most, least, and average used resources. Depending on the usage, they can allocate bandwidth for each resource in the most optimal manner. Moreover, they can use this information to model the distribution of resource utilization in a single API.
Usage by destination
An API has an endpoint (in a production environment this is the production endpoint). It may change from time to time. The table in Figure 6 shows the number of hits for a given API for different endpoint addresses. API developers and publishers can use this table to identify the most and least used endpoints. They can use the data to model/compare the different endpoint usage ratio as well.
Figure 6: API usage by destination - data about endpoint hits
API usage comparison
This shows the usage distribution of APIs by considering the total hit count for each API (in both tabular and graphical format). API developers and publishers can use this graph to know about the most and least invoked APIs at first sight. Given there’s result filtering too, they can use that to refine and narrow down the result set based on their business need.
Figure 7: API usage comparison is presented in both tabular and graphical formats
API throttled requests
This graph shows the number of successful API hits and number of throttled out requests. It has a stacked view, stream view, and expanded view. This gives a clear picture about the usage comparison between the allowed and throttled out requests. At the same time, this is a representation of API usage by consumers. API publishers can get an idea about the distribution of throttled requests for each API subscription from each application.
Figure 8: API throttled out requests - a clear comparison between allowed and disallowed number of requests
API developers/publishers can take decisions about the API throttle policies (increase or decrease allowed request quota) by analyzing this graph.
Sometimes the actual API backend might not be functioning properly due to various reasons (e.g. backend is down, network issues, etc). Not knowing this, API users (i.e. subscribers) might try to invoke APIs. In that case, it will be a faulty invocation. If faulty invocations happen on a regular basis it means availability of that API does not meet expectations. In such scenarios, faulty invocation data can act as a measurement of API availability.
API latency breakdown
When a subscriber invokes a particular API, the request has to go through several stages. Some of those stages are request mediation, authentication, and throttling.
Figure 9: API latency breakdown graph
If there is a need to analyze the time taken at each of these stages, API publishers can use the API latency breakdown graph (Figure 8). They can analyze this graph to identify the possible causes for abnormal response delays in APIs since this graph provides a clear and understandable view of the duration spent at each stage.
API usage across geo locations
This will be useful for API providers who expose their APIs across the globe using WSO2 API Manager. They can configure the setup to show API usage across geo locations. Once it is configured properly, this will display a perfect overview of the API usage across the globe. Hence, this can be used to identify the locations with maximum potential for making business-related decisions (e.g. identify the best region for promoting a service or an API).
API usage across user agent
A single API can have different subscribers who use different platforms. If API developers need to analyze how their APIs are used across different user agents, they can use the data shown in this graph. This will help them to determine the API usage distribution of each platform/device type (mobiles, PCs, etc.). At the same time, this shows the usage density among different user agents.
Figure 10: API usage across different user agents
App throttled requests
If there is a need to visualize the variation of successful API hits and throttled out requests, this graph can be useful (it shows the data with respect to each API). Moreover, users can select the application that needs to be monitored. It will help to gain knowledge about the applications with the most, least, and average throttled out request ratio since this graph is a representation of the benchmark between allowed and disallowed API hits.
Figure 11: Application throttled out requests
Applications created over time
This is another reflection of the behavior of API subscribers. API developers and publishers can identify the pattern of application creation (with a subscription) by each subscriber. In addition, this graph can display the data related to applications registered by each subscriber (for each API). Hence, it offers a mechanism to identify and compare the subscription pattern of API subscribers.
Figure 12: Application registration graph
API subscription-related statistics
This is a visual representation of the distribution of subscribers among APIs. It provides a clear comparison of the number of subscription between APIs. API developers/publishers can analyze this and know about the APIs that are most popular among the user community.
Figure 13: Overall API subscriptions
Developer signups over time
This represents the variations in the user community. API creators/publishers can use this graph to get an idea on how their strategies have affected the behavior of the API user community as this indicates the ups and downs of the new signups.
Subscriptions created over time
API developers/publishers would like to know about their APIs subscribed to over a given period. To facilitate that requirement, WSO2 API Manager has a graphical representation. First, API publishers should select the name of the API and it will load the graph with the corresponding data. Since this shows the API subscription pattern, it will help them to take necessary action to promote their services (i.e. APIs) and see how it has affected the subscriptions.
Figure 14: API subscription pattern
Statistics in API Store
API store is mainly for API subscribers (i.e. API user community). The WSO2 API Manager analytics model provides some visual representations related to statistics in the API Store as well.
Usage of APIs per application is shown here. API subscribers can view how their applications have been used to invoke different APIs. At the same time, it can be used to compare usage density (with respect to applications) as well.
Figure 15: API usage per each application
Top users per application
Data related to users that have the highest API usage. In other words, users who make the most API invocations per application are shown here.
Figure 16: Top API users
This will be useful when analyzing each resource usage in each API (it shows the respective HTTP verb as well). API subscribers can use this dataset to get an idea about the API resources used along with the name of the application.
Figure 17: API usage with respect to application + resource
This acts as an indication for API subscribers about the availability of APIs. In other words, it shows the details of API invocations that were sent and if to know if the API is not functioning properly due to unavailability of the actual endpoint of the API.
Figure 18: Details on faulty invocations per application
Real-time analytics in admin portal
The admin portal of WSO2 API Manager is the best example to depict the usage of the real-time analytics model. There are two major sections with respect to real-time analysis. These are alert types and log analyzers.
So far in this article, we looked at how batch analysis has been carried out in the API Publisher and the API Store using API manager statistics. The WSO2 API Manager analytics model supports not only batch analysis, but also real-time analysis. The objective of this section is to describe how real-time analysis is used in the admin portal.
Alert management using real-time analytics
The alert management system uses the analytics model in WSO2 API Manager to create alerts for different purposes based on real-time analysis of available data. Sudden failure of one or more API, a sudden increase in the response time of one or more API, and the change in the pattern of API resource access are a few of the addressed scenarios. With this model, it is very easy to get notifications when the required action is triggered.
WSO2 API Manager official documentation has more details about these alert types, how to configure alerts, subscribe to alerts, and view alerts. The alert mechanism of WSO2 API Manager is based on the knowledge derived from the API manager analytics model.
Abnormal response time
This alert will be triggered if there is a sudden increase in the response time of a specific API resource. Slowness of API runtime and slowness of the backend is indicated by this alert.
Abnormal backend time
If there is a sudden increase in the backend time corresponding to a particular API resource, this alert will be triggered. Users can get an idea about the slowness of the backend and take necessary action to address the issue.
Abnormal request counts
This indicates high traffic, suspicious acts or the malfunction of client applications. A sudden drop or spike in the request count within a given time is monitored in this alert type.
Abnormal resource access pattern
Suspicious activities done by one or more users can be identified using this alert type. This alert is triggered when there is a change in the resource access pattern of a user who uses a particular application. Moreover, this alert can be used for auditing purposes as well.
Unseen source IP address
Sometimes, attackers might use different IP addresses for malicious usage of API. This alert type will be helpful to identify such scenarios. The cause for this alert type is either a change in the request source IP for a specific API of an application or if the request comes from an IP used before 30 days (default).
Frequent tier limit hitting (tier crossing)
Depending on the API usage, users might need to subscribe to a higher tier. There are two possible cases related to this. If a particular application is throttled for reaching a subscribed tier limit more than the specified number of times during a defined period (10 times within a day by default) or if a particular user of an application is throttled for reaching a subscribed tier limit of a specific API more than the specified number of times during a defined period (10 times within a day by default) then it indicates the need for a tier upgrade.
Abnormal API usage
Failure of the application that’s using the altered API is indicated here. For a given API, if there is a drastic reduction in API usage by a specific user, this alert will be triggered.
Availability of APIs (health monitoring)
If the response count is below the request count or if the response time is too high or if there are errors on the server side, this alert will be triggered. Overall, this can be used as a measure of API availability and API health.
Analyzing logs with log analyzer
Live log viewer
This helps to view the logs that are currently being generated (when the server is running). It will be updated every 5 seconds. Hence, administrators can instantly monitor what’s happening in the API Manager server.
Overall log analyzer
This page displays the overall statistics for all available types of log events. The log types are INFO, DEBUG, ERROR, WARN, and FATAL. It helps to get an understanding of the overall health of the API Manager server.
This gives a clear picture about each category of errors that have occurred in the system. It facilitates to identify the exception categories that have occurred, compare counts for different exception categories during selected time intervals, check detailed information relating to each exception, etc.
API deployment statistics
When it comes to viewing overall statistics relating to all APIs that are deployed in WSO2 API Manager this will be helpful. It shows what artifacts are added/deleted with the corresponding frequency.
Login errors analyzer
This depicts the overall statistics for login errors that have occurred. It will help administrators to analyze and understand which login errors have occurred and what caused them.
API failure analyzer
Showing the number of API failures is the main task of this. It helps to identify and compare the number of failures for different APIs and identify APIs with the highest number of failures and identify corrective actions.
Access token error analyzer
This analyzer shows detailed statistics relating to access token errors (i.e. information about the access token violations that have taken place during a selected time interval). It shows information related to the API token status, API key status, and logs. Hence it provides a complete view of the errors related to access tokens.
This article focused on how the statistics model of WSO2 API Manager can be used in organizations to generate knowledge about API management. Since WSO2 API Manager is a complete, enterprise-ready solution for managing APIs across the complete API lifecycle, organizations can use this analytics model to take correct decisions related to all aspects of API management at the correct time.
The discussion in this article included an overview of the WSO2 API Manager statistics model, how analytics in API Manager is used to gain knowledge, and the benefits of taking decisions based on reliable statistics related to API management.