Hi, Due to the potential security issues and complexity issues arose in the discussions among APIM analytics team members, we have decided to get rid of the separate Java client for API health monitoring. Instead, this will be implemented as CEP execution plans like other APIM analytics tasks. The following information will be extracted from the APIM event streams.
1. API request count frequency. 2. API response time 3. API response error codes The criteria to categorize healthy/unhealthy scenario is as follows: 1. If the API request count frequency gets lower than the 90th percentile of the overall, that API is not healthy within the given period of time. 2. If the API response times get higher than 90th percentile of the overall, that API is not healthy within the given period of time. 3. If the API response contains error codes (given in configuration, eg: 5xx, 4xx, that API is not healthy within the given period of time. If an API is stated as no healthy, the reason will be provided (one or more of the above three). Best regards. On Tue, Mar 1, 2016 at 10:07 AM, Maheshakya Wijewardena <[email protected] > wrote: > Hi, > > We have decided not to include the HTTP methods that affects the backends > of APIs, such as POST, DELETE since the health checker should not cause any > differences in the backend. > > Best regards. > > On Tue, Feb 23, 2016 at 10:53 AM, Maheshakya Wijewardena < > [email protected]> wrote: > >> Hi, >> >> We have discussed (APIM team and analytics team) and came to a decision >> to implement the health monitor for APIM as a separate Java client. The >> following diagram depicts the architecture of the health monitor. >> >> >> >> >> - Health checker incorporates the full life cycle of an API, >> therefore it is located outside the firewall and can be viewed by the >> admin >> of the APIM. >> - This client consumes quota from the whole API, therefore the client >> needs to manage it. >> - This Java client will ping (call API methods from the client) the >> APIs periodically (hourly, daily, weekly) and tracks the status codes of >> the responses. >> - For each API, there will be a separate thread spawned and that >> thread will keep track of that API. >> - This information will be published to DAS inside the firewall using >> HTTPS protocal. >> - Based on the status code, a status will be reported as one of the >> following (These are to be decided): >> 1. Healthy - 2xx >> 2. Some problems occurred during the time period - 4xx >> 3. Failures reported - 5xx >> - Following configuration information will be given the the health >> monitor using a yaml file: >> - APIM credentials: >> - APIM username >> - APIM password >> - APIM configuration info: >> - APIM host >> - APIM port >> - Application name >> - Application tier >> - Application key type >> - Application key validity time (default -1, infinitely valid) >> - Information of APIs: >> - API name >> - API url >> - API version >> - API provider >> - API tier >> - API parameters (if available) >> - API payload (if available) >> - DAS creadentials: >> - DAS username >> - DAS password >> - DAS configuration info: >> - DAS receiver url >> - An email notification can be configured to be sent when a >> failure is reported for an API. >> >> WDYT? >> >> Best regards. >> >> References: >> >> [1] API metrics: http://apimetrics.io/check-api-health/ >> -- >> Pruthuvi Maheshakya Wijewardena >> [email protected] >> +94711228855 >> >> >> > > > -- > Pruthuvi Maheshakya Wijewardena > [email protected] > +94711228855 > > > -- Pruthuvi Maheshakya Wijewardena [email protected] +94711228855
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
