Now let's talk about the network map. So Brandy was talking about our ability to model the network so that we know what devices are behind what routers. So where we're starting off here is in our Annapolis office, that's this network right here, and you can see some printers and some other stuff that's within the office. And we're focused on this gate box, which is our internet gateway. What I'll do is I'll just move this out here and I'll start to navigate out our internet connection. So as I do that, I'll turn the repulsion up. So this is kind of you want to have a big screen for this kind of stuff. Sure. So here we're walking out. Here we can see the VPN that's on the network. And we're coming out to our colo here. And so you can see we have an understanding of all the path between us and the colo. So if at any point, for instance, this VPN router went down, we wouldn't get 8 million events about all the boxes in the colo. We'd actually get events about just that one router. Is that a mapping that someone manually has to set up? Or how do you establish that network map? It's all done through auto-discovery. So we're discovering the routes on all the devices. We're discovering the interfaces, things like that. Okay. So like if you set up Xenos here, you can just tell it to find the network map and it'll build one for you. And then, I mean, can you like tweak it afterwards? Or how does the modifying of it go? Yeah. On each device, you can actually, we do auto-discovery, but you can also manually edit different parts of the device. So here I'm on a particular device. And I'll show you where we can modify that data we're talking about in one second. But what we have here is kind of the overall status screen on a device. It gives you a view of, it's kind of like the dashboard was, but this is specific to a device.
2:02So we have an event breakdown over here. We have some other components and what their status is. These are probably Windows services. And here you've got the availability of that device, how long it's been up, the production state that we talked about, you know, when it was first seen, last change, and all that kind of stuff. Is this view pretty typical of, like, any device you might look at? I mean, are there other tabs that come up that are relevant to devices, or is it generally, like, things stored out into these categories? Yeah, well, let me, so here, so all kind of interface stuff, I'll talk about OS process monitoring in a second. But if we click here on the hardware, you can see we get the processor information, amount of memory, swap, and even extension cards that are within the system. And, of course, we also collect the software that's installed on the system. And so, kind of walking along here, you've got events about that system. We have, on here, we should see a lot of debug events because they are, we've turned on the collection of the security events from the system. And just to point out here, we're on a Windows device, and we're actually collecting this event information through WMI. Getting it from the event log. And then, finally, if we look at the performance tab, these are general performance statistics that are being collected about the device. And is there a way to, sort of, like, peer into the application performance on the machines? Or do you, sort of, just only track the asset and inventory of them? And, of course, if the applications are sending out events, that would be included. Right. But, like, how far into the application layer of things do you guys typically go? So, let's jump to another device. So, this is a device that's out on the Internet. So, as I said before, we have lots of different ways we can collect information through SNMP, through SSH, through WMI, through JMX.
4:04And we're going to actually be adding VMware's proprietary API to collect information from Virtual Center. But here's the device that's on the Internet. And we're collecting information through SSH. And you can see we get pretty much the same information. Here we're looking at the same OS page as we saw before. If we drill in, we'll see the same statistics being collected, all of this over SSH. And I dropped in here to show you some application monitoring that we're doing. So, here, again, you see, kind of, the OS statistics that we had before. But if I scroll down, here we're collecting MySQL information. And we're getting pretty detailed information about the MySQL database. And then, finally, just kind of walking along the different kinds of application stuff that we can do. Here's a machine running Tomcat. And, again, we have the stats, the normal OS stats. But if we scroll down, we'll see that we have Tomcat information. So, here we've got the number of threads, the CPU time that it's using, some different kinds of Tomcat stats. And if we look back at the templates on this device, you'll see that there's two templates. One for the kind of core metrics that you want to monitor in Tomcat and one for the basic stuff in a device. And a lot of our Zenpacks are templates for monitoring different kinds of applications. Like, we have an Exchange ZenPack. We've got a JBoss ZenPack. So, let's just look at one of our ZenPacks that's for ESX. So, here is a VMware ESX server. And we're collecting information about it similar to what we did before. But this server is actually, it's a device, but it's actually a subclass of device, which is an ESX server. And one of the ways that it's different is it has a list of all the guests that are running on that host, the ESX host.
6:08And, again, we've done this all through auto-discovery. So, here if we look at, if we drill into one of the actual guests, well, you can see we have lots of different stats about the guest just at this kind of summary level. But you can drill in here and see VMware provided statistics about that guest. And, again, we have a template system. So, you can actually, you know, decide for yourself what you want to see. But this is important because when you look at normal OS stats on a guest, they're typically not that accurate because lots of fancy stuff is happening underneath the guest. Like, it's changing the amount of CPU time that one has. So, if you look at CPU utilization, it might not be that accurate. So, you might look here to find that information. But we also link to the actual device. So, you can actually drill in directly to the guest that's running on that server. Okay. Yeah, that makes sense. So, you can peer down all the way into the guest. You can sort of bridge the virtualization gap there, if you will. Exactly. Now, let me drop into our reporting system and we can take a look at that. We have different kinds of reports. Some are kind of tabular summary reports and then we have lots of different graph reports. So, first, if we look at the tabular reports, here's a report that's showing all the software in the system and giving you counts of how many pieces of software we found in the system. So, this is the high-level description of it over here and then the count that's actually there. So, we can actually sort in reverse order by count and see, you know, we've got seven different VMware Linux kernels, for instance. And then, if we drop back up here, we could go into a report that's kind of what people call top ten, usually. But we usually go across the whole thing.
8:09So, it's top in. So, here's every file system that we found in the system and the percentage of utilization. Is there sort of like a reporting API so you could plug other reporting engines in there if you wanted to do just more crazy, wacky, advanced reporting? Exactly, yeah. And, you know, I sound like a broken record, but, of course, you can do that through Zenfax. Right. We have a UI-based, a couple of different UI-based reporting systems. One, back there in device reports where I was, you can make different kinds of reports by, you know, filtering on certain kind of devices and showing different kinds of columns. But another kind of report you can do through the UI is these graph reports. And what they let you do are take the graphs that we've seen throughout the system and put them all into a single page that you can look at. And, again, we use this. This is one of the things that I was talking about that we have sent to us every day. So, if we look here at, like, the gateways report, this is going to be all the graphs from the Annapolis and Austin interface stats. So, you can see, you know, during the day, there's a lot more activity than there is at night. And this brown line here is actually a predictive threshold or an automated threshold. So, when it's actually fired, there's yellow here. And then, you know, when it comes back in line, that's that. And we call this, it's an enterprise feature we call predictive thresholding. Right, so you can get a quick sense of, like, if things are exceeding your baselines of acceptability, if you will. Right. And you don't have to manually configure it. You know, a lot of times you just set a threshold at 95% disk utilization. And this is a little bit easier to do. Right. It's always a nice feature to have that's sort of like the, you can automate the figuring out of your baseline so you can think less, right? Exactly. If you sort of, like, assume that the system was running okay over this period of time.
10:12So, if it's like this in the future, everything's cool. And you just stick to that brown line as it were. So, now I just want to show real quick some of our fancy graph navigation. So, you can actually zoom into different parts of the graph. You can scroll back and forth. And you see, as I'm changing it, all of the graphs in this report are linked together. So, there's kind of a correlated view of all the information you're seeing on one page. Finally, as far as reports go, those are reports that we've grouped together that were defined in different parts of the system. But we have a different kind of report that actually lets you view all of the stuff, or groups of stuff, from lots of different locations. Now, it's probably not the most clear explanation. But here, let me show you. Let me give you an example of it. So, here's a switch. This is our switch in our colo space. And what I'm showing here are all the interfaces on that switch, all grouped together into one graph. So, we don't actually have a graph defined this way anywhere else in the system. You know, there we usually have per interface. But here we have one graph that's a stack graph of everything, every interface on this switch that's active. Yeah. And I don't know, Coté, maybe it's, you know, coming through or maybe it's more obvious. But these are really the reports that I think we think that management usually wants to see, you know, sort of like, hey, show me all my Unix servers. Where's, you know, what's being utilized? What isn't being utilized? What's going on? So, I think it's sort of like, you know, trying to cater to both, you know, kind of audiences, right? The IT guys are going to be in the alerts, right? The management guys are kind of looking at this global view. And that's kind of what these reports kind of are always trying to reinforce. Like, here's your whole, you know, whatever it is. Here's X and here's how it's being utilized. Right. It's just a user is logged into this, right? So, if a user came in and, like, made a report, like, is there a way to sort of share that report with other people? Or is it already assumed? Like, how does, when you create something like that, how does it get spread out to the rest of the users in the system? Well, people can, you know, everybody who has the permission can see that report.
12:13And it's a static URL. So, they can, you could, you know, pass them a URL and they could go view the report. You can print reports out. We have a print view of all the reports. And, again, you can email reports to people. So, if you wanted everybody to see it that way, you could, you know, generate an email and send it to the people that you wanted to see it. I just wanted to show you another interesting part of visualization of the fact that we have this distributed monitor system. So, here we are in enterprise. We have this way of, from the central GUI, managing collectors that are in lots of different locations. So, here's a collector that's local to this Xeno server. But, here we have one that's actually out in a different location. And it allows you to do things like get a list of the demons that are running, what their status is, and you can stop and start them, things like that. So, it's a pretty powerful tool. You can actually deploy a collector through this screen as well. Once you have that collector out there, what are the other sort of management things you can do? Like, do you only manage the collector itself, or can you actually, like, make things happen on the machine with it? So, mostly it's for managing the machine. But, you know, you can do some troubleshooting. Like, here's the log file for one of the demons. You can view its configuration. You can actually modify its configuration. So, different parameters that you need to set could be set through there. But, as far as, like, executing a command remotely, that's not something we do, we allow through the UI. But, we are doing things like, when we do auto discovery, we connect to that remote collector to perform the auto discovery. So, it's not, again, it's not something you have to do from the central box, and you have to do some fancy networking to get to that remote location.
14:13But, the auto discovery actually happens on the remote location. Okay. But, there's not, like, service restarting and things like that? And, you know, like, generalized commands. Yeah, yeah. No, no. I mean, we've focused, a lot of the emphasis is on monitoring and not more on, kind of, changing configurations. There's other tools that are, you know, that do that, like Parrot and CFEngine. But, we do allow you to take corrective action through, you know, an event that happens that kicks off a command line process. Oh, right, right. So, you could actually script, like, automating, fixing things, if you were comfortable with that. Yeah. Based on events. Yeah, that makes sense. And, you can also run commands from the UI. So, here, I'll just run a host command from the UI. So, you can, you could, you know, you could actually, you could do a restart of a remote computer just using a command that you've configured within Xenos. Okay. That's interesting. So, that's a kind of an overview of Xenos. I could talk about some more things, but that kind of gives you a sense of what the system does and the real, the power that it has. Yeah, no. It was a good overview of, like, the primary interfaces there. That's good stuff. Well, was there anything else either of you wanted to add while we're here? I think just to let everybody know, you know, out there that, you know, Xenos Core is available for free download and a very active community out there. So, people that want to, you know, get up and running definitely should go take it out and get involved in the community. I know Eric and, really, the whole Xenos team, we're always looking at that for feedback and how people are doing. So, we definitely want, you know, the more users, the better for us. Absolutely. Well, that sounds good. Well, thanks for taking all this time to show this to us. Well, thank you. Thank you, Kotei. Thank you.