 I will be talking about real time monitoring GlastroFace, so myself I am working in red at Bangalore I contribute to GlastroGear application, event safety and other areas and introduction to GlastroFace I think Raghavendra Thalor gave beautiful introduction of the GlastroFace. So I will not go in detail, so it is a scalable network file system, so which has different configurations like distributed replication and different types of volume. So when it is distributed file system where we try to monitor the stuff, so it is very difficult because multiple nodes and it is not real time, so typically we end up polling the system, so we query the status every often like frequently we query the system and try to get the status, so wasting a lot of network bandwidth and it is not real time, still it is not real time even though we poll at 10 second interval or 5 second interval. And some of the status are available through via CLI but not all the statuses like suppose a incident happened in a particular time, we do not know what time it happened like if something goes faulty or some node went down, we do not know what time it went down. So let us assume like this is a typical web interface, maybe like any other you can consider any other project also like overting or the new UI is coming. So in this UI the left side it is showing the list of volumes and how many bricks are up and all those things. So in the top right corner you can see it is updated a minute ago, so we do not know the current status. So unless you start polling, get the status of from like query the status, get the status every 10 second interval. So then you can refresh the same UI more real time but if you do the polling 10 second interval, so you will end up doing like around 8000 network calls per day just to get the status. So even though sometimes even though it is not changed the status is same as previous status but still you have to do the network call and get the current status. So how events API is trying to solve this problem is, so there will be one demon running in all the cluster nodes called events D, so which is a which collects the local events and push it to the external monitoring application via webhook. So in this diagram it is showing like whenever event happens like say volume is created it can be user driven events or it can be asynchronous events like brick going down or split brain is happening or zero application going to faulty. So any other events can be pushed into webhook, so how to enable it, so new demon is available which can be started using any of the system service manager like in this example it is showing system CTL you can use the service cluster events we start enable it and start it, so you check the status it shows the status from all the nodes of the cluster like local host is where we are running this command and other nodes from the cluster it in this example there are only two nodes in the cluster. So webhooks no webhooks are registered it, so that is why it is showing that, so to register a webhook so we can, so in this example it is the 9000 it is listening on the 9000 port and we can test it, so if we test it when we run the test command it shows it is reachable or not from the cluster nodes and if it is reachable successfully then we can add it using webhook add command. So this is one example of how output like how webhooks receive what format it receives like in the when you create a volume called gv1, so it sends immediately sends the notification to the registered webhook as a JSON format as shown in the below, so which includes node ID, node ID is from where the event is originated and the timestamp is Unix timestamp and type of event like is it volume create and we have many other event and the message is which is specific to the particular event, so in this case the new volume is created with the name called gv1, so to show an example so this is a simple prototype which shows list of volumes, so in the below we say we are seeing the terminal we are creating the volume, so that is immediately showing in the UI and other example, so the previous example the volume create example is user driven event, so user is creating the volume so that it is somehow easy to track because it is the command at the end of command we can add the trigger event, so some of the other events like the brick going down here in this example the brick process is getting killed, so that is immediately reflected in the UI, so we added the event push event in the cluster brick demon, so that whenever brick goes down or so even Glastady knows whenever brick goes down, so that can immediately send notifications the webhook, so similar one more example to stop the volume and it immediately shows up in the UI, this is the geo-replication sessions there are multiple sessions two sessions are running here, so when you stop the geo-replication session the event is immediately catch in the webhook and shown in the UI, so geo-replication session again, so whenever a session goes to faulty or in this example it is the worker worker PID is killed, so that causes the worker goes to faulty and it is immediately shown in the UI, so status as of now we have around more than 120 events already covered, split-brain, volume events and geo-replication brick events and many other events recovered like quota events and all, so there are some requests about filtering the events, so if you register a webhook now you receive all the events, so but if you are interested only in some kind of like say, which affects the geo-replication session, so you can filter the events like I need only, I am interested only the geo-replication event, so we can have a filtering mechanism there, so and now it is we have the infrastructure ready and we need to integrate with more external monitoring tools like nageos, overt-engine and many other tools and other requirement is the web UI to see the notification, all the UI which I showed is just a prototype, so we need a standard UI from the Gluster project and the email notification which will send, we can set the alerting mechanism like say if the split-brain happening, so immediately notified to admin, so those kind of notification, so all those things are in plan, so we have to get it done, so and documentation is available in the Gluster Read the Docs website, yeah that is all I think I finished it early, any questions?