Hi, Are we using the same handler we publish data to DAS (AFAIU the events go through CEP before publishing to DAS)?
If so I have a small doubt if we can cover the following scenario as the synapse response handlers are executed before the outSequence of the API. 1. Backend returns an invalid payload with 200 OK 2. But at the gateway when sending it to the client it fails. May be its trying to build the payload at the outSequence and fails. Now actually the API has been failed to respond to the client but i'm afraid it is tracked by our events sent to CEP. Thanks, Malintha On Thu, Mar 3, 2016 at 11:10 PM, Nirmal Fernando <nir...@wso2.com> wrote: > +1 for API Availability Dashboard. > > On Thu, Mar 3, 2016 at 10:03 PM, Janaka Ranabahu <jan...@wso2.com> wrote: > >> Hi Maheshakya, >> >> On Thu, Mar 3, 2016 at 4:30 PM, Maheshakya Wijewardena < >> mahesha...@wso2.com> wrote: >> >>> 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. >>> >> I believe we agreed not to call this API Health monitoring as we can not >> guarantee the health of the API using only these values. Instead we opted >> to call this as something like API Availability. >> >> Lets finalize a new name for this as well. IMO, we should be calling this >> as "API Availability". >> WDYT? >> >> Thanks, >> Janaka >> >> >>> >>> 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 < >>> mahesha...@wso2.com> 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 < >>>> mahesha...@wso2.com> 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 >>>>> mahesha...@wso2.com >>>>> +94711228855 >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Pruthuvi Maheshakya Wijewardena >>>> mahesha...@wso2.com >>>> +94711228855 >>>> >>>> >>>> >>> >>> >>> -- >>> Pruthuvi Maheshakya Wijewardena >>> mahesha...@wso2.com >>> +94711228855 >>> >>> >>> >> >> >> -- >> *Janaka Ranabahu* >> Associate Technical Lead, WSO2 Inc. >> http://wso2.com >> >> >> *E-mail: jan...@wso2.com <http://wso2.com>**M: **+94 718370861 >> <%2B94%20718370861>* >> >> Lean . Enterprise . Middleware >> > > > > -- > > Thanks & regards, > Nirmal > > Team Lead - WSO2 Machine Learner > Associate Technical Lead - Data Technologies Team, WSO2 Inc. > Mobile: +94715779733 > Blog: http://nirmalfdo.blogspot.com/ > > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Malintha Amarasinghe Software Engineer *WSO2, Inc. - lean | enterprise | middleware* http://wso2.com/ Mobile : +94 712383306
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
