Tracking your apis are performing as expected

Hi Experts,

I have a requirement wherein I have to track/monitor all the apis in my organization. In case of abnormal behavior I have to generate service now ticket. This is part of Automating the monitoring process. I am aware of the utility at "test.apigee.com" which is not sufficing the requirement here as we have to create test for each and every api that we create.

At present I am exploring the "analytics api" but couldn't find one which is meeting the requirements. Below is the requirement that analytics api should meet:

1. Lookup all the apis in an organization. Reply back with apis for which timeout is more than 20 secs.

2. Reply back with apis which are not reachable.

3. Replyback with apis for which backend is down.

Thank you,

Ashwini

1 3 322
3 REPLIES 3

Hi @Ashwini Rai

1. There is a way to find RESPONSE TIME for an API in the Analytics data. But that is not the same as "timeout". A Response time of 20 seconds may or may not indicate a timeout. This documentation page suggests an Analytics query like this to examine response time:

/stats/apiproxy?select=avg(total_response_time)

You will need to run that query repeatedly, regularly, and then parse the output, to determine which APIs are exhibiting a 20s response time.

2. You want to find Which APIs are not reachable. There's no way to know which APIs are not reachable without trying to reach them. Apigee Analytics cannot track such errors. Think about it: if a client cannot reach Apigee Edge, then... Apigee Edge will not be contacted, and therefore there's no way the Apigee Analytics will be able to record data about that error. Apigee Edge will be unaware. This problem is the one test.apigee.com solves - it tries to reach your APIs from outside of Apigee Edge. There are other systems and tools that can do the same. The general category is called "endpoint health monitoring". You said Apigee Test is insufficient because "we have to create a new test for each API we create." That's true of any endpoint monitoring system, I think.

3. You also want to find Which backends are down . Apigee Analytics can tell you about target errors, including which backends exhibit 500-class errors indicating "the backend is down". For this case I'd suggest starting with this analytics query:

GET /stats/apiproxy?select=sum(target_error)

You may also want to try something like

GET /stats/target_url?select=sum(target_error)

Consult the documentation page for full info on the options there.

Thanks Dino point 1 and 3 are meeting the requirements, can you advise something for point 2. Our only concern is that we don't want to create test for each and every new api that we deploy as we are looking to "automate" the monitoring process.

Yes, I understand. I don't know of a way to avoid that, as it is necessary to have healthchecks be satisfied by the proxy itself as well as by the backend. It requires some design and implementation at each layer.

There may be some best practices that can be suggested by our consulting field . I would like to invite some others to weigh in and offer suggestions. @Christin Brown @Christin and @zzz_srichardson@apigee.com @steve richardson @Greg Kuelgen