On Thu, Feb 13, 2020 at 10:22 AM Amila De Silva <[email protected]> wrote:
> Hi Kavindi, > > As you have correctly stated, this will be useful while managing large > Microgateway deployments and especially those that run on a pure Ballerina > runtime (without any containers). For deployments that are created on > K8/Docker Swarm we should be able to pull some health/uptime stats from the > underlying framework itself. > > Need to clarify certain points regarding your approach. > > In the Push Method you describe, which party is responsible for pushing > Data? If it's the MicroGateway why does the Admin Dashboard (or let's say > the Node that hosts Admin Dashboard) need to maintain active connections > with individual MGs? > Hi Amila, Thank you for pointing out the active connection issue. As you have mentioned , Microgateway is responsible for pushing Data to the other endpoint. In here the admin portal is not maintaining an active connection with individual MGs as it only acts as a listener for the data, pushed by the MGs. > Maybe you can explain a bit about the two endpoints you mentioned in the > second point. > > Out of the two approaches you propose,DB approach would work better > because; > 1. In a High Available deployment multiple Admin nodes can be running, and > having them pull information from a single database would preserve the > consistency. > 2. Writing and Reading can be separated. > 3. MG nodes won't have to know about different nodes that run Admin > Dashboard (with in memory option, each MG would have to push data to all > Dashboard nodes, to preserve consistency) > 4. DB approach is resilient to failures. > > If we go with the DB approach, depending on how we implement it, we might > also have to think about purging Data. > > On Wed, Feb 12, 2020 at 5:33 PM Kavindi Gunasinghe <[email protected]> > wrote: > >> Hi all, >> >> I am currently working on the first phase of the project creating a >> Management Dashboard for Micro-gateways. >> >> Introduction >> >> The WSO2 API microgateway is a lightweight message processor which is >> used for message security , transport security, routing and other common >> API management services. So that it is important to have a management >> dashboard for these micro gateways to keep track of the micro services. >> >> Issue >> >> Currently up and running micro-gateways can not be monitored from a >> dashboard. When there are plenty of microgateways exposing several >> APIs/microservices , there should be a dashboard available in API manager >> Admin portal in order to know the state and details of these >> micro-gateways. We can use either push or pull method in order to notify >> about the up and running microgateways. >> >> Push Method >> >> Pros : >> >> - >> >> No unnecessary traffic. The data is pushed only when the data becomes >> available. >> - >> >> In this scenario , both endpoints stay idle until some information is >> sent to the admin portal. >> - >> >> The admin portal keeps the connection to the other endpoint (micro >> gateway) constantly active, so get the new information instantly. >> >> >> Cons : >> >> - >> >> Sometimes the data will arrive at an unwanted time when the admin >> portal is not ready for it. However this can be remedied by using a >> dependency constraint. >> >> >> Option 1: >> We can store the data that we receive from the mocrogateways in a >> database and then push those data to be displayed in the Management >> Dashboard. >> >> Option 2: >> >> Otherwise we can keep those data in memory and then push those to be >> displayed in the management dashboard. >> >> >> Solution >> >> We can implement a User Interface(dashboard) in the APIM Admin portal to >> monitor the micro gateways and push or pull (REST API) mechanism support of >> notifying in Micro gateway side. When considering the push and pull method, >> it will be efficient to use the Push method for this due to the above >> mentioned pros and cons. In the dashboard it will be useful to display some >> of the following features. >> >> >> - >> >> Currently up and running microservices >> >> >> >> - >> >> Status of the microservices (up or down) >> >> >> >> - >> >> The uptime of the exposed micro services >> >> >> >> - >> >> Request Counter (No.of requests served , No.of failed requests, >> No.of successful requests) >> >> >> >> - >> >> Request Failure rate >> >> >> >> - >> >> No.of requests per second(Throughput) >> >> >> >> Rough sketch of a dashboard >> >> [image: dashhhhhhhhboard.png] >> I have created a swagger specification for this. Please find it attached >> below. And highly appreciate your thoughts on this $subject. >> >> Thanks! >> >> >> -- >> *Kavindi Gunasinghe* | Intern - Engineering | WSO2 Inc. >> <http://wso2.com/> >> (M)+94 773058210 | (E) [email protected] <[email protected]> >> <https://wso2.com/signature> >> >> >> >> > > -- > *Amila De Silva* > Software Architect | Associate Director, Engineering - WSO2 Inc. > (m) +94 775119302 | (e) [email protected] > <http://wso2.com/signature> > -- *Kavindi Gunasinghe* | Intern - Engineering | WSO2 Inc. <http://wso2.com/> (M)+94 773058210 | (E) [email protected] <[email protected]> <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
