 Hi Red Hat Developers, this is Jason with the Red Hat Developers Program here at DevZone at Summit 2017. We're here with James Murnin from Red Hat and he's going to be talking about application health monitoring from the inside out. Oh, going to take a quick tour on a couple of real world scenarios that we've encountered over the years in the Red Hat mobile team. My name is James Murnin, I'm the CTO of Red Hat Mobile. So today we're going to look at how you can introduce additional monitoring of the health of an application that comes from within the application itself. So let's get started. So this is Bob, Bob is sad. Bob is sad because his application that's been in production for some time keeps giving performance issues and the support team are getting a hard time from the customers because they can't quite track down the source of the issue and they're escalating the Bob maybe at weekends and stuff and having him call it a weekends which makes him feel sad. So Bob had introduced a form of a live check on his application which is working fine but what has been discovered is that just because an application is running that doesn't actually mean that it's working correctly. There may be some malfunction in the code itself and that's not going to be detected by your classic port probe or your ping check or your live check. So from there what he's added into the system is what we call a health endpoint. So this is a RESTful API just like many of the other features of the application itself and he's added some additional information here to return a status code whether the application is okay or in a critical state. Now having done that that works fine and there is some internal logic that's used by Bob's application to determine which state it should return. Well if the internal logic of the application is able to make that decision and form a decision on whether something is okay or critical well then why not surface a little bit more of that information through the RESTful endpoint itself and provide that to the user so they can understand. In addition you could make a link to a support document which provides some instructions on the top two or three reasons why this might happen and what the corrective actions could be if it were to happen to you and by surfacing that information to the support teams then they could go a long way towards diagnosing the issue themselves and maybe not have to escalate the bar about weekends so taking it from there they then went and introduced some additional status codes because not all status codes are created equally and they had a conversation with the customer early in the the planning stages of the application and it devised a number of scenarios under which the alert could be deemed as a warning condition so if you had an application that was maybe a flight an airline application that was able to provide some weather information perhaps it's not the most mission critical thing at weekends to be calling somebody out just because the weather feature is not working in the applications that might return a warning condition but similarly so if your flight booking system where customers will book a flight which will be a source of revenue to that organization if that was something that wasn't working well then that may be deemed as a critical situation in which case you may want to warrant a call out but it's good to have that conversation with the customer that you're going to agree ahead of time what the conditions under which a warning will be issued and a critical and that also helps the customer have the greater understanding of what the support the scope of the support arrangement could be and what they can expect when certain failure scenarios occur so taking it on from there then what Bob did is he decided well in order to form the decision on whether the status should be okay warning or critical there may be some other systems or services upon which the application depends and critically some of those systems may not be one that Bob is operationally responsible for so there could be some customer backend system that he's dependent on and maybe that's the source of the problem well if the application health endpoint has deemed that to be the case well why not surface that information in the health point itself and return it to the support team so similarly by taking a layer of abstraction down and creating an array of the various reasons why something may be in a particular condition and you can see here that the flight booking system is in a critical state and that is the dominant status that governs the overall status of the health endpoint itself and again the amount of information you can include here can vary it depends on what suits you could easily add the URL of the endpoint in question that was the result of the issue as it deems to be in the customer's backend network and again you can have documentation support documentation links pertinence each of the different dependent systems within the health endpoint so summing up the benefits of doing this way is for for the developer and for the customer so for the developer you automatically get a mechanism to have an acceptance test framework as well as a regression test for any future ones that's absolutely critical for most customers to know that they have a regression test it's a very simple and pragmatic way to do it but also by using a standard JSON format like this that's restful within the application you get a sense of consistency where you can easily incorporate that same format into many of our other applications and your support team will probably thank you for that because once they get used to the data format used by one application then if the customer phones up with an issue with another application the format return is going to be very consistent and familiar to them and they should get used to knowing what to do about it and that gives you a sense of reusability as well and of course for Bob there's less call outs hopefully at the end of this exercise because the tier one support team should be able to handle many of the issues far in advance of needing to call Bob for the customer one of the intrinsic benefits here is that if you have the health endpoint in place and they're monitoring it throughout the user acceptance testing phase of your project and there is a dependency from your application to the customer's backend it could be the case that monitoring on its own and that stress test and could expose some deficiencies in the customer's backend systems maybe they're not ready for the load that's going to come from an application if it's going to go viral or if it's going to be a mobile application for example it also gives the customer a sense of proactive monitoring versus the reactive one in previous times and that has a trust issue associated with as well where increased trust in Red Hat or in the application provider generally and ultimately the end goal here is to provide increased levels of service to those customers and if you can be more proactive and help the support team to solve more issues earlier in the process then the customer should experience increased service levels from that so that makes Bob happy. So some references to follow up on one of our engineers Evan Shortus has open sourced Node.js module that gives you a lot of this functionality out of the box so the link is there for him to see and if you'd like to know more about Red Hat mobile please check out our link on redhat.com forward slash mobile and could I also have a shameless plug towards a new mobile cost assessment tool that you can check out in your Kobious free time as well. Thank you very much for your time.