You're viewing Apigee Edge documentation.
Go to the
Apigee X documentation. info
Apigee Edge records a wide variety of operational and business data that flows across APIs. The metrics derived from this data are useful for operational monitoring and business monitoring. Using Edge API Analytics, you can, for example, determine which APIs are performing well or poorly, which developers are delivering the highest value traffic, and which apps are causing the most issues for your backend services.
To help access this metrics data easily, Edge exposes a RESTful API. You can use the metrics API when you need to automate certain Analytics functions, such as retrieving metrics periodically using an automation client or script. You can also use the API to build your own visualizations in the form of custom widgets that you can embed in portals or custom apps.
To learn how to use Analytics in the API Edge management UI see API Analytics overview.
About the metrics APIs
Edge provides two metrics APIs:
Get metrics returns metrics for an organization and environment over a period of time, such as an hour, day, or week.
For example, for the previous week you want to obtain:
- The number of policy errors
- The average response time
- The total traffic
Get metrics organized by dimensions returns metrics over a period of time for an org and environment grouped by dimension.
For example, for the previous week you use dimensions to group metrics by API product, API proxy, and developer email to obtain:
- The number of policy errors per API product
- The average response time per API proxy
- The total traffic per developer email
The Get metrics organized by dimensions API supports additional features not supported by the Get metrics API, including:
About metrics API quotas
Edge enforces the following quotas on these calls. The quota is based on the backend system that handles the call:
- Postgres: 40 calls per minute
- BigQuery: 12 calls per minute
Determine the backend system that handles the call by examining the response object.
Every response object contains a metaData property that lists service that handled the call
in the Source property. For example, for Postgres:
{
...
"metaData": {
"errors": [],
"notices": [
"Source:Postgres",
"Table used: xxxxxx.yyyyy",
"query served by:111-222-333"
]
}
}For BigQuery, the Source property is:
"Source:Big Query"
If you exceed the call quota, the API returns an HTTP 429 response.
Getting metrics with the management API
The main difference between the two APIs is that Get metrics returns raw metrics for the entire org and environment, while Get metrics organized by dimensions lets you group metrics by different entity types, such as API product, developer, and app.
The request URL for the Get metrics API is:
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/statsFor the Get metrics organized by dimensions
API, you include an additional resource to the URL after /stats that speciifes the desired dimension:
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/stats/dimensionFor example, to get metrics grouped by API proxy, you'd use the following URL to call the management API:
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/stats/apiproxySpecifying the metrics to return
For both the
Get metrics and the
Get metrics organized by dimensions
APIs you use the select query parameter to specify the metrics
to retrieve, and an optional aggregation function, in the form:
?select=metric
or:
?select=aggFunction(metric)
Where:
- metric specifies the data you want to return. For example,
the number of API requests, cache hits, or policy errors. See metrics
for a table that specifies the metric name to use with the
selectquery parameter. aggFunction specifies the optional aggregation function run against the metric. For example, you can use the following aggregation functions with the processing latency metric:
avg: Returns the average processing latency.min: Returns the minimum processing latency.max: Returns the maximum processing latency.-
sum: Returns the sum of all processing latencies.
Not all metrics support all aggregation functions. The documentation on metrics contains a table that specifies the metric name and the function (
sum,avg,min,max) supported by the metric.
For example, to return the average number of transactions, meaning API proxy requests, per second:
?select=tps
Notice that this example does not require an aggregation function. The next example uses an aggregation function to return the sum of cache hits:
?select=sum(cache_hit)
You can returns multiple metrics for a single API call. To get metrics for the sum of policy errors
and the average request size, set the select query param using a comma-separated
list of metrics:
?select=sum(policy_error),avg(request_size)
Specifying the time period
The metrics API return data for a specified period of time. Use the timeRange
query parameter to specify the time period, in the form:
?timeRange=MM/DD/YYYY%20HH:MM~MM/DD/YYYY%20HH:MM
Notice the %20 before HH:MM. The timeRange parameter
requires a URL-encoded space character before HH:MM, or a + character,
as in: MM/DD/YYYY+HH:MM~MM/DD/YYYY+HH:MM.
For example:
?timeRange=03/01/2018%2000:00~03/30/2018%2023:59
Do not use 24:00 as the time because it wraps around to 00:00. Use 23:59 instead.
Using a delimiter
To separate multiple dimensions in an API call, use a comma (,) as the delimiter.
For example, in the API call
curl https://api.enterprise.apigee.com/v1/o/myorg/e/prod/stats/apis,apps?select=sum(message_count)&timeRange=9/24/2018%2000:00~10/25/2018%2000:00&timeUnit=day
the dimensions apis and apps are separated by ,.
Sample API calls
This section contains examples using the Get metrics and the Get metrics organized by dimensions APIs. See Metrics API examples for additional examples.
Return the total number of calls made to your APIs for one month
To see the total number of calls made to all APIs in your org and environment for one month, use the Get metrics API:
curl -v "https://api.enterprise.apigee.com/v1/o/{org}/e/{env}/stats/?select=sum(message_count)&timeRange=03/01/2018%2000:00~03/31/2018%2023:59" \
-u email:password
Sample Response:
{
"environments": [
{
"metrics": [
{
"name": "sum(message_count)",
"values": [
"7.44944088E8"
]
}
],
"name": "prod"
}
],
...
}Return the total message count per API proxy for two days
In this example, you return metrics for the number of requests received by all API proxies
over a two-day period. The select query param defines the aggregate function sum for the metric
message_count on the dimension apiproxy. The report returns the request message throughput
for all APIs for traffic received between the beginning of 6/20/2018 and the end of 6/21/2018, in
UTC time:
curl https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env}/stats/apiproxy?"select=sum(message_count)&timeRange=06/20/2018%2000:00~06/21/2018%2023:59" \
-u email:password
Sample Response:
{
"environments" : [ {
"dimensions" : [ {
"metrics" : [ {
"name" : "sum(message_count)",
"values" : [ {
"timestamp" : 1498003200000,
"value" : "1100.0"
} ]
} ],
"name" : "target-reroute"
} ],
"name" : "test"
} ]...
}This response indicates that 1100 message were received by one API proxy called 'target-reroute' running in the test environment between the start of 6/20/2018 and the end of 6/21/2018.
To get metrics for other dimensions, specify a different dimension as the URI parameter. For
example, you can specify the developer_app dimension to retrieve metrics for
developer apps. The following API call returns the total throughput (messages received) from any apps
for the specified time interval:
curl https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env}/stats/developer_app?"select=sum(message_count)&timeRange=06/20/2018%2000:00~06/21/2018%2023:59&timeUnit=day" \
-u email:passwordSample Response:
{
"environments": [
{
"dimensions": [
{
"metrics": [
{
"name": "sum(message_count)",
"values": [
{
"timestamp": 1498003200000,
"value": "886.0"
}
]
}
],
"name": "Test-App"
},
{
"metrics": [
{
"name": "sum(message_count)",
"values": [
{
"timestamp": 1498003200000,
"value": "6645.0"
}
]
}
],
"name": "johndoe_app"
},
{
"metrics": [
{
"name": "sum(message_count)",
"values": [
{
"timestamp": 1498003200000,
"value": "1109.0"
}
]
}
],
"name": "marys_app"
}
]...
}Sorting results by relative ranking
Many times when getting metrics, you only want to get results for a subset of the total set of
data. Usually, you need to get the results for the "top 10", for example, the "top 10 slowest
APIs", the "top 10 most active apps". You can do this using the topk query parameter
as part of the request.
For example you may be interested to know who your top developers are, measured by throughput, or what your worst performers (i.e., 'top slowest') target APIs are by latency.
The topk (meaning 'top k' entities) enables reporting on the entities associated
with the highest value for a given metric. This enables you to filter metrics for a list of
entities that exemplify a particular condition. For example, to find which target URL was the
most error prone over the last week, the topk parameter is appended to the request,
with a value of 1:
curl https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env}/stats/target_url?"select=sum(is_error)&timeRange=05/08/2018%2000:00~05/15/2018%2000:00&timeUnit=week&sortby=sum(is_error)&topk=1" \
-u email:password
{
"environments": [
{
"dimensions": [
{
"metrics": [
{
"name": "sum(is_error)",
"values": [
{
"timestamp": 1494201600000,
"value": "12077.0"
}
]
}
],
"name": "http://api.company.com"
}
]...
}The result of this request is a set of metrics that shows that the buggiest target URL is
http://api.company.com.
You can also use the topk parameter to sort for the APIs experiencing the highest
throughput. The following example retrieves metrics on the top ranked API, defined by highest
throughput in the last week:
curl https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env}/stats/apiproxy?"select=sum(message_count)&timeRange=05/08/2018%2000:00~05/15/2018%2000:00&timeUnit=day&sortby=sum(message_count)&sort=DESC&topk=1" \
-u email:password
Sample Response
{
"environments": [
{
"dimensions": [
{
"metrics": [
{
"name": "sum(message_count)",
"values": [
{
"timestamp": 1494720000000,
"value": "5750.0"
},
{
"timestamp": 1494633600000,
"value": "5752.0"
},
{
"timestamp": 1494547200000,
"value": "5747.0"
},
{
"timestamp": 1494460800000,
"value": "5751.0"
},
{
"timestamp": 1494374400000,
"value": "5753.0"
},
{
"timestamp": 1494288000000,
"value": "5751.0"
},
{
"timestamp": 1494201600000,
"value": "5752.0"
}
]
}
],
"name": "testCache"
}
],
"name": "test"
}
]...
}Filtering results
For greater granularity, you can filter results to limit the data returned. When using filters, you must use dimensions as filter properties.
For example, suppose that you need to retrieve a count of errors from backend services
filtered by the HTTP verb of the request. Your goal is find out how many POST and PUT requests
are generating errors per backend service. To do so, you use the dimension
target_url along with the filter request_verb:
curl https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env}/stats/target_url?"select=sum(is_error)&timeRange=05/08/2018%2000:00~05/15/2018%2000:00&timeUnit=week&filter=(request_verb%20in%20'POST','PUT')" \
-u email:password
Sample response:
{
"environments" : [
{
"dimensions" : [
{
"metrics" : [
{
"name" : "sum(is_error)",
"values" : [
{
"timestamp" : 1519516800000,
"value" : "1.0"
}
]
}
],
"name" : "testCache"
}
],
"name" : "test"
}
]...
}Paginating results
In production environments, some request to the Edge analytics API return very large data sets. To make it easy to display large data sets in the context of a UI-based application, the API natively supports pagination.
To paginate results, use the offset and limit query parameters,
along with the sortby sorting parameter to ensure a consistent ordering of
items.
For example, the following request would be likely to return a large data set, since it retrieves metrics for all errors on all APIs in the product environment for the last week.
curl https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env}/stats/apiproxy?"select=sum(is_error)&timeRange=05/08/2018%2000:00~05/15/2018%2000:00&timeUnit=week&sortby=sum(is_error)" \
-u email:password
If your UI-based application can reasonably display 50 results per page, you can set the limit
to 50. Since 0 counts as the first item, the following call returns items 0-49 in descending
order (sort=DESC is the default).
curl https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env}/stats/apiproxy?"select=sum(is_error)&timeRange=05/08/2018%2000:00~05/15/2018%2000:00&timeUnit=week&sortby=sum(is_error)&limit=50&offset=0" \
-u email:password
For the second 'page' of results, use the offset query parameter, as follows. Note that the limit and offset are identical. That's because 0 counts as the first item. With a limit of 50 and an offset of 0, items 0-49 are returned. With an offset of 50, items 50-99 are returned.
curl https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env}/stats/apiproxy?"select=sum(is_error)&timeRange=05/08/2018%2000:00~05/15/2018%2000:00&timeUnit=week&sortby=sum(is_error)&limit=50&offset=50" \
-u email:password