Layer7 API Management

I am writing a simple API URL monitoring job which needs to check each individual APIs are up and running.

And report to customer if not working through email. Issue could be in Layer7 gateway or backend system.

Is there any simple way like “ping” to Layer7 service heath check? Ideally it should be in a position to accept connection, should be able to communicate to backend service positively?

Right now as a work-around, I am invoking each individual L7 API (GET/POST) with credentials to check whether they working end-to-end.

The API Gateway has its own API for providing availability and status to external load balancing and traffic managing applications. You can consume this service to get some fundamental information about the current status of a Gateway or individual nodes in a Gateway cluster. Send an HTTP GET to /ssg/ping over a port that has Ping Services enabled and this service can be consumed.

This service can be accessed in multiple modes. These modes are governed by the pingServlet.mode cluster-wide property which is documented here: Miscellaneous Cluster Properties - CA API Gateway - 8.4 - CA Technologies Documentation

Thanks Eric for your quick reply.

I am using ssg/ping service to check gateway health but my concern is about configured API health.

Last week, gateway log table was full and ssg/ping was responding positively but gateway was unable to process request for individual API as it was not able to write records into log table.

So, now we have decided to monitor individual APIs along with ssg/ping.

Let me know if there is any simple way to monitor individual APIs, and this way we could check whether we are getting response from backend system also.

That state should have prevented the API Gateway from processing requests at all. That behavior would not have been limited to a specific published service. If the Gateway is up and running and can be pinged via the Ping Service then all published services (SOAP, RESTful, or other) are consumable.

Hi,

you may try the internal service WSDM to monitor/analyze the API endpoints.

Assuming that you have published the internal "WSDM QosMetrics Service" with an endpoint of /wsdm/qosmetrics, and also assuming the service that you wish to obtain metrics for has a URI of /atest, then use the following URL;

http://<SSGHost>:8080/wsdm/qosmetrics?serviceuri=/atest

and send the below message;

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:muw="http://docs.oasis-open.org/wsdm/muws1-2.xsd" xmlns:rp="http://docs.oasis-open.org/wsrf/rp-2">

<soapenv:Header/>

<soapenv:Body>

<rp:GetMultipleResourceProperties>

<!--1 or more repetitions:-->

<rp:ResourceProperty>muw:OperationalStatus</rp:ResourceProperty>

<rp:ResourceProperty>muw:NumberOfRequests</rp:ResourceProperty>

<rp:ResourceProperty>muw:NumberOfFailedRequests</rp:ResourceProperty>

<rp:ResourceProperty>muw:NumberOfSuccessfulRequests</rp:ResourceProperty>

<rp:ResourceProperty>muw:ServiceTime</rp:ResourceProperty>

<rp:ResourceProperty>muw:MaxResponseTime</rp:ResourceProperty>

<rp:ResourceProperty>muw:LastResponseTime</rp:ResourceProperty>

<rp:ResourceProperty>muw:Throughput</rp:ResourceProperty>

<rp:ResourceProperty>muw:AvgResponseTime</rp:ResourceProperty>

</rp:GetMultipleResourceProperties>

</soapenv:Body>

</soapenv:Envelope>

This will return metrics in a form as below;

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://www.w3.org/2005/08/addressing">

<soap:Header>

<wsa:Action>http://docs.oasis-open.org/wsrf/rpw-2/GetMultipleResourceProperties/GetMultipleResourcePropertiesResponse</wsa:Action>

<wsa:RelatesTo>null</wsa:RelatesTo>

</soap:Header>

<soap:Body xmlns:mows="http://docs.oasis-open.org/wsdm/mows-2.xsd" xmlns:muws1="http://docs.oasis-open.org/wsdm/muws1-2.xsd" xmlns:muws2="http://docs.oasis-open.org/wsdm/muws2-2.xsd" xmlns:qosm="http://metadata.dod.mil/mdr/ns/netops/esm/qosm" xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2" xmlns:wsrf-rp="http://docs.oasis-open.org/wsrf/rp-2">

<wsrf-rp:GetMultipleResourcePropertiesResponse>

<muws2:OperationalStatus>Available</muws2:OperationalStatus>

<mows:NumberOfRequests Duration="P16694DT0H6M59S" LastUpdated="2015-09-15T00:00:50.000Z" ResetAt="1970-01-01T00:00:00.000Z">38</mows:NumberOfRequests>

<mows:NumberOfFailedRequests Duration="P16694DT0H6M59S" LastUpdated="2015-09-15T00:00:50.000Z" ResetAt="1970-01-01T00:00:00.000Z">33</mows:NumberOfFailedRequests>

<mows:NumberOfSuccessfulRequests Duration="P16694DT0H6M59S" LastUpdated="2015-09-15T00:00:50.000Z" ResetAt="1970-01-01T00:00:00.000Z">5</mows:NumberOfSuccessfulRequests>

<mows:ServiceTime Duration="P16694DT0H6M59S" LastUpdated="2015-09-15T00:00:50.000Z" ResetAt="1970-01-01T00:00:00.000Z">PT0S</mows:ServiceTime>

<mows:MaxResponseTime Duration="P16694DT0H6M59S" LastUpdated="2015-09-15T00:00:50.000Z" ResetAt="1970-01-01T00:00:00.000Z">PT0.042S</mows:MaxResponseTime>

<mows:LastResponseTime Duration="P16694DT0H6M59S" LastUpdated="2015-09-15T00:00:50.000Z" ResetAt="1970-01-01T00:00:00.000Z">PT0.013S</mows:LastResponseTime>

<qosm:Throughput Duration="PT1H" LastUpdated="2015-09-15T00:00:50.000Z" ResetAt="1970-01-01T00:00:00.000Z">0</qosm:Throughput>

<qosm:AvgResponseTime Duration="P16694DT0H6M59S" LastUpdated="2015-09-15T00:00:50.000Z" ResetAt="1970-01-01T00:00:00.000Z">PT0.005S</qosm:AvgResponseTime>

</wsrf-rp:GetMultipleResourcePropertiesResponse>

</soap:Body>

</soap:Envelope>

Is that meet your needs?

For more details about WSDM, please refer to:

https://wiki.ca.com/display/GATEWAY84/Publish+Internal+Service#PublishInternalService-WSDMQosMetricsService

https://wiki.ca.com/display/GATEWAY84/Collect+WSDM+Metrics+Assertion

Regards,

Mark

Thanks Mark. This helps a alot.

I'd rather you didn't recommend use of the WSDM capability. WSDM isn't well suited. There are far better ways using the tactical gateway metrics assertion.

Can you elaborate on "tactical gateway metrics assertion". What is this? How do we use it and get access to it?

Cheers,

https://cawiki.ca.com/display/Tactical/GatewayMetricsAssertion+-+User+Documentation

We need customer names and a Jira ticket in our jira to release this to a customer. For your own investigation, not needed. Speak to Aran White,  the UK senior pre-sales on what Tactical does, or we can talk

Hi Jay,

That URL doesn't work for me. Any other I can try?

Cheers

Sorry about that, it's an internal only link. I mistook the forum. We need to work this via support and your sales team.

You can get access to service metrics through SNMP (ask for the gateway's SNMP package from support). You will get similar metrics as what you can see in the dashboard or as Mark has show before with WSDM.

With any of these methods you will not know about service health until the first request fails though since these are all passive methods. The only way to check end-to-end is using an active method and to send an actual request to your service. You can never be certain if everything is working without running a test of the service itself. Depending on the number of requests your service handles and how easy it is to set up an active test, I would choose one or the other (or both).

Hope that helps.

Regards,

Michiel

I agree with you Michiel.

I would recommend to use a monitoring tool (e.g. PRTG or SiteScope) to make a HTTP call on API regularly via an external route (i.e. so it goes via Layer7). That way you check the availability and routing of APIs every 5s or so and alert if there is a problem.

Also adding a "_health" endpoint on all APIs helps a great deal with monitoring.

Hi James,

Can you please elloborate on the "_health" endpoint? How are you using this endpoint?

Thanks,

Atul Raut

James, are you trying to adding _health in query string and performing checks against API health? Do you have automated restman solution to grab all those service URIs and add _health at the end?

Appreciate your thoughts!