API Health (really more like availability) monitoring

126 views
Skip to first unread message

miqui

unread,
Apr 13, 2021, 8:02:16 AM4/13/21
to API Craft
hi folks,

..so, in some APIs we  add a URI /health (similar to other APIs that use /ping)  to monitor the API... , but i get devs telling me this is not necessary given the API could potentially be hosted in AWS and given the plethora of tools in that cloud platform:


..so, then drop using URI /health and each API team have it with whatever they want to do?

..thanks..
rgds,
miqui


Erik Wilde

unread,
Apr 13, 2021, 8:10:11 AM4/13/21
to api-...@googlegroups.com, miqui
hello miqui.

On 2021-04-13 14:02, miqui wrote:
> ..so, in some APIs we  add a URI /health (similar to other APIs that use
> /ping)  to monitor the API... , but i get devs telling me this is not
> necessary given the API could potentially be hosted in AWS and given the
> plethora of tools in that cloud platform:
>
> https://aws.amazon.com/blogs/mt/monitor-api-gateway-endpoints-with-amazon-cloudwatch-synthetics/
> https://aws.amazon.com/blogs/aws/apigateway-xray/
> https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceLens.html

meh. that's acceptable for a more homogeneous model where you're ok with
depending on whatever your environment provides. it's not so useful if
you look beyond one environment and think about API health in all of
your API landscape.

> ..so, then drop using URI /health and each API team have it with
> whatever they want to do?

if you think API health is important, then treating it as such (and not
saying "everybody roll their own!") might be a good idea. this has been
around for a little while:

https://tools.ietf.org/html/draft-inadarei-api-health-check

hopefully this will be brought into the new IETF HTTP API building
blocks group, as it would be a really useful standard to have. for now,
you can simply take it as inspiration, but it may still change.

cheers,

dret.

ps: also, thanks for the inspiration, i am giving a conference
presentation on standards tomorrow and will add this as a very nice
example!
https://apiconference.net/api-management/api-standards-balancing-chaos-and-rigidity/

--
erik wilde | mailto:erik....@dret.net |
| http://dret.net/netdret |
| http://twitter.com/dret |

RestIsSexy

unread,
Apr 13, 2021, 10:48:46 AM4/13/21
to API Craft
I think it's unnecessary overhead to add ping endpoints into the api design. It is good to have a consistent standard for your monitoring such as newrelic or cloudwatch . 

miqui

unread,
Apr 13, 2021, 12:50:58 PM4/13/21
to API Craft
hi Erik

>>
 it's not so useful if
you look beyond one environment and think about API health in all of
your API landscape.
>>

...exactly...consistency in the org's landscape AFAIK is paramount in their API journey..

>>
ps: also, thanks for the inspiration, i am giving a conference
presentation on standards tomorrow and will add this as a very nice
example!
https://apiconference.net/api-management/api-standards-balancing-chaos-and-rigidity/
>>

.. wish i could be there Erik... thanks for sharing...


>>
>>

..i have been following this one for quite a while.... 

rgds,
Miguel

miqui

unread,
Apr 13, 2021, 12:54:58 PM4/13/21
to API Craft
hi RestlsSexy,

.>>
 It is good to have a consistent standard for your monitoring such as newrelic or cloudwatch .
>>
...and what happens the day you move your API to GCP or Azure ?

what exactly in the case of cloudwatch would you call a standard?.... perhaps cloudwatch settings, configs, etc.. against every API?  (includes private, public, partner) ?

..thanks for sharing..

rgds,
Miguel

Reply all
Reply to author
Forward
0 new messages