For an admin, isn't it be useful for them to check these information via dashboards of particular container orchestration platform? If we need to differentiate, we need to have some kind of agent running that pushes information that provide more information about the services. Also may be graph like a view as in AppDynamics which shows the stats will be much useful. We need to first come up with data and information which we can show in the dashboard and whether it provide more insights.
On Thu, Feb 13, 2020 at 12:02 PM Kavindi Gunasinghe <[email protected]> wrote: > > > 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> > > > > -- *Harsha Kumara* Technical Lead, WSO2 Inc. Mobile: +94775505618 Email: [email protected] Blog: harshcreationz.blogspot.com GET INTEGRATION AGILE Integration Agility for Digitally Driven Business
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
