SPEAKER: After you have launched your APIs on Apigee,
you will want to ensure they are performing as expected
and services are not interrupted.
This is where API monitoring comes in.
It provides near real-time insights
into API traffic and performance to help you quickly diagnose
and solve issues as they arise.
One of the main purposes of API monitoring
is to keep you informed of unusual events
or patterns such as spikes in traffic or latencies.
It enables you to create notification alerts of changes
in API traffic so you can take action before customers are
affected, increase API availability,
reduce the time to diagnose and issue,
use HTTP error codes to speed diagnosis,
and isolate problem areas quickly
by investigating errors, performance, and latency issues
and their source.
It's important to note that API monitoring only retains
data for the last 60 days.
This is because there may be personally identifiable
information contained in your data.
And so it is deleted per the Google privacy policy
after that period.
[THREE TONES]
API monitoring is available in the Navigation bar
under Analytics.
It provides three different views
allowing you to display timelines of recent API traffic
data, display recent treemaps of data,
and investigate using tables of API traffic data,
showing HTTP fault codes by time, status,
and source by proxy.
In each of the views, you have the same options.
You can change the view, select the desired graphs,
and filter by the environment, region,
and/or proxy by using the respective drop-downs.
You can also adjust the period to analyze a particular time
range.
Once you have identified a particular issue,
you can create an alert to be notified of the incident.
More on that later.
Let's continue with our overview.
In the Timeline view, you have graphs showing total traffic
requests during one-minute intervals,
error rates as a percentage of total traffic,
and latency for 50, 90, 95, and 99 percentiles.
You can drill down into each for more details.
By hovering over the graphs, you can see data values
at any point in time.
Data points are measured at one-minute intervals.
The Recent view enables you to view
treemaps of the volume of traffic
by incident, error rate, and latency.
It displays a proxy traffic as blocks
that represent the volume of the traffic by the size of the box.
The color of the block in each graph
indicates the relative sizes of the number
of incidents, error rate, and the maximum 50th percentile
latency.
Clicking on a block displays the distribution in the right pane
by HTTP status codes, fault codes, fault source,
and region.
Hovering over a block displays the proxy name,
total traffic, and error rate.
The Investigate view displays pivot tables of metrics
and attributes for all API traffic
to help you compare activity for different metrics.
By default, the Investigate view displays three tables--
fault code by time, fault code by status code,
and fault source by proxy.
As in the other views, you can select
any combination of tables to aid in your investigation.
There are more tables to choose from in this view.
Selecting a cell with a value shows the distribution
in the pane on the right as it did in the recent view.
You can select the pivot table to change its orientation
to get a different perspective.
Now that we understand the different views,
let's take a quick look at alerts, where you can configure
notifications to be sent to your preferred communication
channels such as email or SMS, et cetera.
Alerts are triggered when a specified event or condition
is met, which are called incidents.
Let's create an alert.
Clicking on the Alert link takes us to the GCP console
where we can figure alerts and notifications.
For example, to set up an alert for high-traffic volume,
you first select Add Condition and then select the resource
type for the target.
Then select a metric such as proxy request,
cumulative request.
Next, select Aggregator as sum and then a period
of one minute.
Clicking Add takes us back to the Wizard
where we can proceed to the next steps.
Select an existing notification channel from the dropdown
and be sure to check mark Notify an incident closure
to know when the alert clears.
Enter a descriptive alert and instructions,
such as a documentation link.
When an incident is fired, you'll get a notification.
And when things return to a healthy state,
you'll get another notification that the incident
has been cleared.
Back in the GCP console, you'll be
able to see the history of incidents
that occurred specifically when they were opened
and when they were closed.
And there you have it.
A quick walkthrough of how to use the power of API monitoring
and how it can keep your API program running smoothly
and your API consumers happy.
If you found this episode helpful, community,
you can subscribe to learn about more of our episodes
on "Getting Started with Apigee's API Management Tool
Set."
Cheers.
[MUSIC PLAYING]