Today we're going to take a look at a fun little screencaster demo of Xenos. And we've got two special guests with us today. Would you like to introduce yourself for a special guest? Hi, I'm Eric Dahl. I'm the CTO of Xenos and one of the founders. And second special guest? Hello, I'm Brandon Wichert. I'm the Director of Product Management at Xenos. Before we actually log into the system that we're seeing here, you want to give us just like a quick summary of what it is? Sure. Xenos is a monitoring application. We feel it kind of unites some of the key elements of monitoring. Availability, events, performance management. And we tie that all around a core model that we build through auto-discovery. Okay, so let's go ahead and log into Xenos. So after you log in, you are first taken to what we call the dashboard. So this is a single pane of glass that you can visualize to see everything that's going on within Xenos. It's portlet-based, so you can see we've got several portlets up here. And each one is giving you different kinds of information. So one of the really cool portlets is in the upper left here. We've actually done a mashup with Google Maps. And what this is showing you is geographic distribution of assets in the system. And what you can see here is there's actually links between the different points on the map. And those are actually displaying the WAN connections between the different data centers that you've shown. And you can see there's different colors for each location and for the links. All these links are green, which means they're up. But if there was to be a failure between data centers, that link would actually go red.
2:00So if we actually hover over Annapolis here, we can quickly pull up kind of an event breakdown of what's in that location. And it tells you how many devices there and other things like that. So on the right-hand side here, we have what we call the device issues. And basically, it's a list of devices in the system that have the highest severity issues going on. So you can see kind of the red or the orange. Those are the actual severities of the events behind there. And then the count is telling you the number of events on that device. And we're showing the count of the highest level severity. So there could be other ones below it, other severities underneath. But we'll just give you a count of the highest ones. And so is a device sort of the highest conceptual thing that you guys track? Or, I mean, like, for example, if there was a problem with one of those green lines with the network connection between something, would that show up as sort of a device over there? I mean, I'm just trying to figure out the model that exists. Right. So, I mean, the model is fairly sophisticated. At a tracking level, device is very important. And we see it as kind of the union of an operating system and a piece of hardware. So certainly we track devices, and that's a pretty important part of the model. But we also have events and event rules and services and processes, lots of different elements that make up the system. Certainly links between devices and interfaces, things like that. But device is certainly a core aspect of the system. Yeah, it seems like one of the primary entities that things revolve around. I mean, that is a good distinction. It's the combination of an operating system and hardware, right? And then conceivably those are things that are supporting applications that are running or, you know, or various other functions that's running around in the data center.
4:01Yeah, exactly. So down here on the lower left is a breakdown of some groupings that we allow you to have in the system. This is actually showing business systems, so you can see the impact of your IT infrastructure on your core business functions. And one cool thing about this is all of our groupings in Xenos can be hierarchical. And here we're just showing the top-level hierarchy, but you can actually drill down into each of these to see more and more detailed information. Again, the events are showing up just as they were in the device issues. We show you the color of the highest severity event plus the count of the events within the system. One thing I'll point out here is you see there's testing and training actually are shaded a little differently. And they're muted, that means there's been some acknowledgment of the events, and I'll get into that a little later. Down here in the lower right is the watch list, and you can actually specify particular entities, either groups or actual devices that you want to watch in the system. So here I'm just going to add our mail server. And that could be a group or a device, you know, all the major organization features of Xenos. All right, so that's sort of like instead of having devices only show up when something's wrong, if there's something you want to see, even if it's in a good state, you can customize. You're basically saying, I always want to see these things on the watch list rather than waiting for them to automatically pop up in one of the freak-out boxes. Yep, exactly. So let's reconfigure the dashboard a little bit. This is, like I said, it's widget-based or portlet-based, so you can actually move things around and add different portlets. Here's a list of all the portlets that you can add today, and let's just add production states. So Xenos has the idea of a production state, and basically it's allowing you to say that this computer, it's kind of the life cycle of a computer.
6:04So it could be, for instance, in pre-production or testing or production or even decommissioned. But probably the most used one is maintenance. When you're going to do some work on a computer, you flip it to maintenance mode, and then when you're done, you flip it back. And the different states allow you to control the monitoring in the system. So if something is in maintenance, it will still monitor the device, but events won't actually show up on the dashboard, things like that. So it's a really good way to control how the system is interacting with a particular device. So let me just remove this portlet. Every time I made a change, it gets saved to the database, and each user has their own dashboard. Okay. And can you set up sort of, so dashboards are tied to the user, but are they tied to sort of a role or anything like that? Like, could you have all your, like, DBAs, like, have the same view and the network people have the same view? Or how does that get configured and personalized? Right. No, it's done per user. And so when the user logs in for the first time, there's a default set up, and they can go ahead and rearrange stuff once they get in. Oh, one thing, when I pulled up the list of portlets, I talked about our ZenPack system, the kind of extension mechanism within Xenos. You can actually add new portlets using that extension mechanism. And we've had people in the community who've done different things like show graphs in a portlet or other stuff like that by using that extension mechanism. Right, right. And so, I mean, that is an interesting distinction of ZenPacks versus other sort of, like, throwing together things is they not only extend sort of the things that you can monitor and manage, but they also, like, pull in UI stuff, right? So you can add pretty much anything you want with a ZenPack into the system, it seems. Yeah, exactly. I mean, we could write the rest of Xenos and ZenPacks. You can add new... Not that we are.
8:04Not that we're doing that. That's right. You can add demons, you can add new screens, you can add subclasses of devices, pretty much anything. Is there a way to take these, you know, everyone always enjoys having, like, the knock-level view of things where, I mean, do people use this dashboard to sort of configure, like, a big screen they have on a wall somewhere of just stuff that's constantly updating or... Yeah. Or, like, can you sort of pull off a portlet on its own? Or how do people do that sort of scenario? The way that I've seen, usually, is they'll have maybe one screen showing the dashboard and then another screen showing the event console, which is what we can talk about next. So this is kind of the high-level view. And, you know, a knock could use this, but even a manager might look at this to just see the business systems and what their state is or that plus the location, something like that. But, you know, that kind of high-level manager person probably wouldn't want to see the device issues, for instance. Why don't we check out the event console that you were just talking about? Sure. So the event console is going to be a list of detailed issues within the system. And the event system is one of the key parts of Xenos. And basically, it's an aggregation point for all the messages that are being passed by different monitoring daemons within Xenos. But it's also a place where you can aggregate external events that come in through syslog or SNMP traps or Windows event log or really any other data source that you want to bring into the system. You can even use our Web Services API to bring events into the system. So you could sort of create synthetic events or whatever that you're just inserting into the system. Right. Not even so much that they're synthetic, but you can just make up an event, a format on your own. As long as you can write it to the web service, it'll become an event in Xenos.
10:05Yeah. I mean, you can even add an event through the web UI. So if an administrator kind of wanted to show overall status or something like that about what was going on, they could actually add an event. Why wait for your data center to create problems when you could create them on your own? Exactly. Exactly. So this is the event console, as I said. I'll just show you one feature of Xenos. If this is on, as you're saying, like on a knock, a top-level screen or something, you might move aside the left nav just so you could see more information while you're in the event list. Right. And do you have sort of like filtering stuff you can set up in the UI to kind of like narrow down to only the events you're interested in? Yeah, exactly. So here is kind of a first level of filtering. So we're seeing these are the different potential states that events could be in. And we're looking at basically info and above. If we take it down to just critical, the top-level events, you see it swiped away everything that wasn't read, essentially. So now we've got just the most important things going on in the system. But you can also, if you see these events towards the bottom, they're all pale because they've been acknowledged. And we're showing acknowledged events. But you can also take away acknowledged events. So you're just looking at the things that are current or hot in the system that nobody's actually done anything about. All right. So we've kind of scoped down stuff through those pop-ups. But now you can actually filter kind of like in iTunes. And let's see. We'll type in RRD here. Oops. And it just live searched it down to just that one event. Right. So lots of different ways that you can actually filter the event console. So let me open it back up again. And let's just walk through the lifecycle. So an event comes in. It's in state new. And that's what you see here at the top of the list. And the first thing that an administrator would probably do is they'd acknowledge the event.
12:06So let's go ahead and acknowledge one of these events. Okay. Now it's in the acknowledged state. You know, this is a person's taken responsibility for it. And they can proceed to work on it. So let's look at the event detail screen. And what you see here is at first is all the detailed information that we're tracking about an event. But also you actually have a log, which is going to be everything that's happening on that event as it goes through the lifecycle. So here you can see E-Doll, that's me, and I've acknowledged the event. But you can also continue to have a dialogue about the event within the event log. Just in case there's any doubt. Exactly. So that would kind of be the next thing that would happen. Now there's two kind of possible ways that we could go into the next stage. What we're looking at here are the current events in the system. And the lifecycle, the next part of the lifecycle, is that an event moves into the history. So it's actually not current anymore. It's moved into just an archive, so you can reference it later on. And that can happen by the user. So here the user can select the event and then go to the menu and say, move to history. But a lot of times, events will just clear themselves. So we have a correlation system within Xenos. And like if you have a ping down, or here we have a Windows service browser is down. When that comes back up again, it'll actually clear the event. So automatically. That's interesting. Yeah. So up-down correlation is what we call that. Another cool thing about the event system is we have deduplication. So what that means is, see, this event has happened several times. This, you know, a thousand times in the event window. We break it down so you just see a count of how many times it's actually happened.
14:06Okay. And so are there integrations you have with, like, help desks or service desks for this kind of thing to sort of move these events off and do other process workflows? Right. So we have an integration with Remedy, which when an event comes in, it can generate an email that goes and gets entered into Remedy as a ticket. Right. But another cool thing we have in the event system is basically you can make any where clause against the events, and a command will be executed when that where clause is matched. So with that, you can really do lots of different kinds of integrations from the event system into external systems. And while we're on that, I'll just show you real quick, very similar to that, we have alerting rules, which will, you know, instead of just sending an arbitrary event or kicking an arbitrary event, an alerting rule will actually send out a page or an email when an event matches. You can set delays so it doesn't do it right away, things like that. Right.