Hi, We should not connect the microgateways directly with the databases and we should introduce a service layer where all the gateways can connect and push data from time to time. When we are having hundreds of microgateways, we should be able to scale the service layer to handle the load.
>From this admin dashboard, we should focus only on microgateway's stats and not the microservices that are exposed via the microgateways. In the dashboard, we can include the following. 1. Number of microgateways running 2. Health status of each microgateway 3. Up/downtime of each microgateway 4. Request related information As Amila mentioned, most of the details discussed here can be extracted if we are running microgateway in K8s or any container orchestration system. >From this dashboard, we should highlight the facts that are not able to retrieve from those container orchestration systems. (eg: Request related information) Thank you! On Thu, Feb 13, 2020 at 10:23 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? > 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> > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Pubudu Gunatilaka* | Technical Lead | WSO2 Inc. (m) +94774078049 | (w) +94112145345 | (e) [email protected] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
