+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

Reply via email to