On Thu, Feb 13, 2020 at 11:44 AM Pubudu Gunatilaka <[email protected]> wrote:
> 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. > Yes there is a service layer on the APIM side to which the MGW push data. The attached swagger is the rough sketch of the service on APIm side. This is not finalized yet > > 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 > We ara planning to include additional data like what are the APIs exposed > by each MGW and what are the resources under the API in the dashboard. > Which can not be viewed from k8s dashboards. That is the main advantags of > this feature. > 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) > Hmm, we do not expose request related details, only expose APIs related details. Request related details can be viewed using analytics and observability. > > 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 > -- *Rajith Roshan* | Associate Technical Lead | WSO2 Inc. (m) +94-717-064-214 | (e) [email protected] <[email protected]> blog: http://www.rajithr.com <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
