Should I even ask?
He's been like this since we shot the promo for this episode.
Okay, so we can finally show them how to manage when choosing the web-based interface, right? Okay get out the laptop, we're going to start the demo. You guys are going to love this. You can manage alerts…
No. Hold on a second, hold on a second. There's a couple of things we have to do first. We have to do introductions and we have to set up the show.
Okay, fine, fine, fine. Welcome, Lawrence, Patrick, me. Lab.solarwinds.com. Chat box. Okay, so we're good to go now, right? You can just get out the laptop and we can get started.
Sit, stay, good geek. Hi, I'm Patrick Hubbard.
And I'm Lawrence Garvin.
And I'm Leon Adato, and welcome to SolarWinds Lab where we're going to talk about the amazing new web based alerting in 11.5. For starters, there's a separation of the scope from the alert trigger, so you can get directly-- and you can put that in a resource--
Bad geek! No cookie.
Yeah or session tokens or GUIDs or HDP kit responses or nothing.
Hey, you said GUID.
So obviously, we're going to be talking about NPM 11.5 in this episode.
Is that even out yet?
Yeah, well it's in RC and actually, the official version should be on the street shortly and, of course, you'll just go to the customer portal and download that as soon as it's ready. And while the web-based alerts interface, I agree, is pretty amazing and you guys have been wanting it for a long time, and we're going to show you how to use it in dev, it's not the only one. So we actually thought we'd have a special guest go ahead and come on in with us today to talk about some of the other product features, based on the suggestions that you guys had in the forum that made it into this episode.
That's right, so please welcome the manager for the Orion Platform, Rob Hock. [Futuristic music]
Rob how's it going? I don't think I've seen you since THWACKcamp.
I'm quite sure I have no idea what you're talking about. It's great to be on the new set, and I recognize this guy. You know you didn't have to camp outside my cube for two weeks? You can pull dev builds anytime you want now.
Oh yeah, well I was just, I was all caught up in the excitement.
So besides alerting, what else in new in 11.5, Rob?
Well as you know, with NPM 11 we focused on the quality of the experience dashboard. But we've been working on a host of other really helpful features that we're going to be shipping in 11.5.
Yeah, I think one of the things was the team took the topology mapping logic, you kind of kicked it up a notch, and you're now doing automated dependency mapping with that.
So is this like parent child relationship detection?
Correct. So with automated dependency mapping, we're going to be creating on- to-one parent-child relationships using our L2, L3, and now trace route information.
And they've certainly heard me talk about portal a time or two.
Okay, but in this release we're actually integrating NPM and the customer portal into one view--looks like this! [Sound effect]
And this is actually part of Orion Core, which is shared between NPM, SAM, NCM, IPAM, UDT, NTA, VNQM…
Partridge in a pear tree.
That as well. Another feature users have asked us for time and again is global search.
Yeah or maybe they've asked it three or four times.
That is entirely possible. So that's why we made it available as a tech preview. So check out the NPM forum on THWACK to find out more about that.
Cool. I think from the system side, they probably get a lot out of that capacity usage view.
Yeah, and I think you guys have done this demo enough times; you don't need me around for it. So I'll take off.
But you are setting up the SAM lab, and I understand that you've got AppInsight for IIS working.
Oh. Now all of a sudden, another AppInsight module is more interesting than alerting?
Oh no, no, no.
Yeah, that's kind of what I thought. Okay, so we'll be back in a bit.
All right let's start with how to use capacity forecasting.
I need more cowbell.
Okay. It's warm in here; I'm going to lose this. [Sound effect]
All right, we'll check out capacity forecasting. So you'll see on Node Details, we have some new resources available for capacity forecasting. So we have overall Node Capacity Forecasting, which will do CPU, memory, interface, volume. What's really cool about this is not just 95th percentile or trend over time, but actually time run out. How long do I have before I run out of interface? So do I need to upgrade my WAN circuit? When do I need to add more disk to my array? Whatever the case may be. And we provide run out charts and alerting out of the box as well. So, we can alert you 30, 60, 90 days out. That's user configurable, to alert you before something goes wrong.
So this is taking all of the trending and statistics and doing high-level analysis on it as well. So that, again, it's going to let you know when you hitting the bottom based on your usage. It's not using some canned algorithm or anything. Precisely. So we actually have two different methods of determining that, so one based on peak and the other one based on average. So let's say for critical WAN circuits where you're interested in avoiding peaks at business hours let's say, you can set it to peaks. So you'll do run out based on your peak value versus your average value, which will take into account, basically, your utilization throughout the day.
That's really cool and I know that Lawrence, who was asking about it, is really going to appreciate all the forecasting and all of that. But what's really amazing--
I know, I know Alert Manager.
And it is.
It is, it is, but what I was going to say is that there are three features that have been asked about a lot on THWACK and they were really high up on the feature requests list. And I'm really happy that they made it into this release. That's Duplex Mismatch Detection, the Wireless Heat Maps, and the Custom Poller Mapping.
Mm-hmm, yeah. So you have great taste, let me tell you that. You care to take a look?
I would love to.
All right let's dive in. So some of you may be familiar with managed pollers, introduced a couple of versions back. So previously, we had the ability to essentially override default CPU, memory polling--and we've extended that further with NPM 11.5 to include polling for the Node Details Field. So, anything that would be considered node details, machine type, vendor, IOS version--those sort of things.
Got it. As you can see on the screen, I have done the 'LINUX ate my RAM' adaptor because I wanted a more simple memory adjuster. But what you're saying is that if I didn't want to have a bunch of machines that were all listed as net SMNP, I wanted them to say Ubuntu and you know SUSE and all the rest, that I can actually identify them?
Correct. So this would be a great solution for the unknown node problem. So maybe there's a brand new piece of gear and we haven't had a chance to update our Sys OID database yet. Or maybe it's something custom. Or as you mentioned, maybe it's a custom LINUX distro that you want to be able to identify. So let's go through and just create a sample... poller here. And so we support tagging, authors, so you can import/export as well. If you want to share these on THWACK--so that would be a great thing.
So don't forget to share things on THWACK.
Maybe folks want a copy of your 'LINUX made simple' poller that you just created.
All right. And here we're going to do a simple Sys OID mapping. So we'll come up with something highly custom. So what this is saying is that for any Sys OID that matches this particular value, we are then going to statically define a vendor--which is Foo. Now this is a static string, and that's kind of the more simple case, but you could actually specify an arbitrary OID. So in the case were maybe you have a custom device out there that responds in non-standard ways, you can read in arbitrary fields.
Right, and the nine dot, nine dot, nine dot isn't actually so crazy because on LINUX distributions you can put in your own object IDs and frequently you will have, you know, numbers that are just completely made up. But this gets us around the idea of when people on THWACK ask, you know, "Can I roll my own MIB?" Well, they don't really want to roll their own MIB. Nobody actually wants to roll their own MIB. But what they mean is can I, you know--I know it responds to this number--could I use that?
So if we're asked to inventory and reporting, maybe there's some things that are not standard in your environment and you just want to be able to normalize it so it shows up in the same report, this will do that for you.
And just to be clear, you can group your systems together now based on these other aspects for alerting--you know, for everything else. So that's great.
Correct. And as new devices that match that Sys OID are added to your environment, we'll automatically discover it and add them automatically. Right.
All right. So how about duplex mismatch?
Well let's go over to duplex mismatch. So duplex mismatch will now exist as an out-of-the-box alert, and also brand new resources on the nodes themselves. So the resources will be automatically hidden if there's no duplex mismatch detected.
But if there are, it will pop up. Now, we actually have an algorithm behind how we do duplex mismatching based on topology information--which is pretty much hard. I mean, we know via CDP or LDP whether or not it's full and half on each end-- and that's a definite mismatch. But we also have an algorithm that determines, based on number of late CRC errors and some other interface metrics, whether or not it's a probable duplex mismatch. So, let's imagine that we manage a switch, but we don't manage, maybe, some customer premise equipment. Maybe that's a carrier. But they hard set their end. We don't know that. We have no way of knowing it, but we are seeing a lot of errors on our side. So based on a percentage of the total amount of traffic on the interface, matching certain parameters will trigger a possible duplex mismatch.
I know that's going to be huge for a lot of people. And I'm glad you mentioned that it doesn't show up unless you have a mismatch. I added a whole bunch of devices that I purposely set them, you know. And I actually set it and matched it up again and it wasn't showing up, I thought I had done something wrong. So now that I know that you have to have a mismatch to see it, I'll take no news as good news.
Yep, and those alerts exist out-of-the-box as well. So you can turn them on and you never know what you're going to find in your environment. We have some folks in beta that actually found some issues in their environment, just based on the beta. So it's pretty neat. Duplex mismatches still exist in this day and age.
Right, okay. So finally, we've got wireless heat map. Tell me more about this, what are we trying to do here.
So wireless heat map, brand new in 11.5. Works with Cisco wireless LAN controllers. Used for, potentially, sight survey, looking at the saturation of your radio energy within your building, campus environment, whatever the case may be. Also has built in client location tracking. So let's go into just quickly how we would configure a wireless heat map. We've already done a couple of the steps here, just as not to bore you with my Microsoft Paint rendition. You can use any background you like, traditionally a floor plan. But it's as simple as dragging, dropping your APs onto your map and clicking generate map. Now you can make these maps more accurate potentially by adding signal samples, which will be the known location of a particular client. So if you know that Jim is sitting in his desk right now, you can simply click on where he is, tell us what client's there and go on from there. Or if you really did want to undergo the pain of walking around the office, you could use, let's say, your laptop and walk around the office. That doesn't sound like any fun.
Dowsing for wireless-- it's always a lot of fun.
Yeah, and there are vendors that do it that way. Just, it's pretty painstaking. So instead, we pull the data right off the wireless LAN controller and go from there. So this is quite accurate. In our testing, we found that we're accurate within about three meters or so.
That's amazing, is that, most people have their floor plans already available so importing them is not big deal and you should be mapping your access points there. Not only for the wireless signal but also because when things go out you can actually see on a picture you know which thing has gone out. It serves several purposed I think. Along with knowing that, you know--Why is Mary over in that corner, not getting any signal? Well, now you know.
Correct, or maybe you have a larger campus or hospital where you have a Wi-Fi enabled card that somebody through into a closet and know you need to go find it. This will certainly enable you to do so. So let's look at that in the web. Here we can our signal strength, if we have connected clients. Here in our demo environment we have one. But you'll be able to tell client name either by host name or IP address or whatever that case may be, along with the requisite signals. So when you get that phone call from, you know, the CEO that says, "My wireless signal is very poor, why can't I get online?" But you happen to be across the country. You're able to get that data and be able to troubleshoot that remotely. So very handy. Great timesavings. And data that you're really not going to get any way else.
So I know that duplex mismatch detection has been on the request list and been talked about a lot on THWACK; so I'm glad to see that it made it into this release. And I also know that poller and the wireless upgrades have been talked about a lot on THWACK as well. So remind me, and them also, what is it going to cost overtime to add this in?
Absolutely nothing. As long as you're on active maintenance just download the upgrade from the customer portal. So I guess that leaves us with...
Oh! Web-based alerting. Out of the way! I'm driving this bus. So here we are on the admin page and you'll notice that we know have-- I shouldn't say we now have, it was there before--manage alerts. But it takes you to a completely different screen. So we're just going to set up a whole new alert. You can see I've been playing around with this a little bit, but we're just going to go right through this. You have the name of the alert definition; we're going to call it 'Leon's amazing alert.' And you can put a definition. Is it enabled? You've got the frequency of the alert, which is the same as before. And as we mentioned in previous episodes, if you have an alert that isn't such a big deal that you're going to be checking every 15 minutes, drop this down a little bit. You can save cycles on your poller. I like the custom properties. We've added custom properties for your alerts so that you can do things with those custom properties. Whether it's grouping or reporting or what have you. You also have a limitation category. That means that you have a group; an actually SolarWinds group that you can restrict this alert to, that they're the only ones who can access it in different ways. So those are a couple of new pieces, just on this page.
Now you did skip severity there, so that's also new functionality.
You're right. Okay, so severity; what can we do with severity?
That's user defined anyway. You can't create your own severity levels but you can define the severity level of an alert. So that will be shown on, let's say, the application alert page, different color-coding. You can use this macro potentially, so there's lots of different ways you can use that.
So it almost adds in like Syslog-style functionality in terms of the alert's severity information levels, along with the alerts. So that's nice but this is the boring tab obviously. So we want to get to the really cool stuff, which just like in the 32-bit version, the second tab is where all the magic happens. So it's the same ideas, just the layout has slightly changed in some places. First of all, you've got, you know, what do I want to alert on? This is the same as the drop down from previously. Do you want to alert on a node, or the volume or an interface. We have a couple of extras; there's the agent, which is new to support the DPI agents. I'm just going to keep it with node for right now. And then we get to where the real fun is. The scope of the alert, I just need to talk about this for a second. We've separated the query properties or the elements, so that the scope of the alert,--which boxes are in the group to get the alert-- is different than the trigger. So for example, very simple example is I want a CPU alert. But I only want a CPU alert from my LINUX machines. So the scope is LINUX and maybe it's LINUX in this subnet. Or maybe it's Windows machines from this version. Whatever it is, right? That's your scope. Then you set your trigger properties separately from that and there's a reason for that that I'll get to in a minute that's even more exciting. So I don't want to alert on all objects, I want to alert only on the following objects. That changes my screen very fast I might add. Thank you very much. So, here I want to set my scope values on the node. I want to say where-- let's say the machine type contains the word 'Window.' Now it will give me drop down based on what's in my environment already. So I could pick an actual whole phrase and have an exact match but, you know, I might have other versions later so I'm just going to say, 'Where the node contains Window.' And I want to add another simple comparison. I want to say, 'Where the IP address contains--' and I'm going to say, 'It's part of my 10.199 subnet.' So it's only the Windows boxes in that subnet. Maybe that's my server or subnet or whatever. And now I want to set up the conditions for what the trigger is. So I wouldn't put--for example, I could, I could do where--let's see down here-- where is that? Oh, it's not down here. Because I shouldn't really do...
Because we're saving you from yourself in that regard.
So just to recap there; the scope-- current customers may be very used to putting scope within the trigger condition itself. As you've highlighted, people don't really think about it that way, and like to edit the scope independently. So that's why we broke the scope out and tried to make it easier for people to understand what is they're actually alerting on. So there's the dynamic conditions and then there's the scope itself. And actually, you'll see with 'Show List' there, you can see what specific objects in your environment this scope would apply to.
Answering that age-old question: what's going to make this thing go off?
Right, which things could potentially-- and you just hit on the first place that you can find this, that's really exciting for me. There are four questions that you get asked frequently. And like you said, the age old one is, 'Which boxes does this alert apply to?' So that's what it's going to tell you. Even though it doesn't know that, I'm going to be talking about CPU now. So that's a really big deal. So here is where I would say, 'Where my CPU load-- we're just going to do a simple one-- is greater than or equal to 85.' Okay, fantastic. So there's my condition. And if I were going to leave it there--I'm not-- but if I were to leave it there, it would actually tell me how many devices, right now, have that alert applied to it. But there's a few other things that I have to show here before we go on. There's the 'Condition must exist for' obviously. So I want to say that this condition is more than 10 minutes or, you know, an hour or what have you. But here we get to some advanced options. I want complex conditions. Now I know that in SolarWinds, we've used the words 'advanced' and 'complex' in a lot of different ways. But believe me; this is like the best usage of the word. 'Complex conditions' allows you to say I want to know where Windows machines in the 10.199 subnet have a higher CPU load than 85, and something completely different. Now I want to know about-- we'll say the interface. Now this is an 'and' not an 'or.' So along with these Windows boxes that are 10.199 subnet that have a high CPU, I also want to know where the interface--let's see here...not the description... Okay, so I'm not finding what I want. And I'm happy that is the case because I can go look at all the fields-- you can group by, you know, different kinds of groupings-- whether it's nothing or whatever. So I want the 'Receive utilization' is a 'critical value' or a 'threshold.' So your field picker now is much more robust in terms of--you can find all the different variations without having to guess at them or dumpster dive. There's even a search feature here if you're looking for something particular.
And output preview as well.
Right. And so you can see what particular interface is going to show in a different way. I'm going to actually just set it to a locked critical value and hit 'select.' The interface receive utilization is over-- we're going to say 90% or... I'm going to say either one or the other. We're going to go to, again, 'Browse all fields.' I want the transmit utilization. The transmit value is over 90 also. Okay, so what we have here--and I know it's hard to fit on the screen--I'm going to shrink this down a little bit just to make it work. What we've got is an alert that says that-- first of all the scope; we're talking only about Windows boxes that are in the 10.199 subnet. We're not talking about my routers. We're not talking about my LINUX boxes. Nothing else. That's my scope. And what problem am I looking for? Where we high CPU and also we have high transmit or receive at the same time. This is a machine that is pegged in a very particular way, but we're looking at all of that together. And again--even more so--this condition, the interface condition, must be more than 10 minutes. Fine. But wait until, 'how many objects, at the same time, have met the specified condition and triggered one alert.' So if you know that you get hammered with multiple boxes-- maybe they're load balance, maybe they're grouped together, maybe they're whatever, you can say, "I just want one massive alert for all my boxes." So we've been able to do these really complex things all on one page, and now you can tell why I'm so excited.
So here we have this amazing, wonderful, complicated alert. We're going to go from here, hit 'Next,' and 'Reset.' We've beefed up the resets. So we have 'Reset when the condition is no longer true.' That is probably what most people are going to take most of the time. That's still a really good default. You can also reset this alert automatically after so many minutes. That's especially good if you have a trigger that's you know, based on a cold start or one of those-- or the date is off. You know, those kinds of things. You can say no reset condition. It never resets, trigger each and every time this thing alerts. I just want one ding, ding, ding, ding, ding. I want one every time. Or the opposite. It's going to trigger once; it's never going to trigger again. You know, you might need that. And then you can get into the query-based, create a special condition. Which is exactly the same as the trigger condition. So we're going to leave that alone for now and move on to the next thing: Time of Day. Now, not a lot of alerts have 'time of day' triggers but some do and there's one specific thing that I want to point out. When you add a schedule, the only thing that I want to say here, because this is very similar to the old style, but note this message: That if you 'Need it to span midnight,' you do not need to set up two alerts anymore. You simply say that it starts at nine o'clock at night and starts at two o'clock in the morning and it will know. So you might have got in and asked this a couple of times.
Yeah so spanning midnight, obviously very novel. So saving you from having to duplicate for that problem. But also, you'll notice in the 'time of day,' we have inclusions and exclusions. So that certain multiplicative effect that would exist today in the advanced alert manager-- where you'd have to create individual words for each time range-- so that no longer exists. In fact, to put wheels within wheels here we also support individual time of day schedules for actions, which we'll get to in a little bit.
Right. Okay, and what he was talking about was time schedules-- is 'Add Time Period.' So you can say, "Don't do it from this time to this time." "Do it from this time to that time," or however you want to mix and match. So again very exciting. I'm going to leave this alone though. I'm going to not put in a schedule just for the sake of time, and you guys can play around with it until your hearts content. It is always enabled. Trigger actions. Now before I go any further, the next thing I want to go into is the variables. We really improved the way that you can find and use variables. So here, once again, you get a search box, and you can look for any of the particular-- whether it's about the node or about the interface or about the element that you're trying to get, or the poller-- You can find them much more easily with this interface. You know, you can group by category. So I'm looking for, you know, I have 41 polling engine IDs. The one I want to mention here is--in almost everything there's a URI. There's a URI element. So there's a URI for the polling engine, which we'll check off just for fun. And we'll say that the CPU threshold-- there's a URI for the CPU threshold, and response time. Fine. So there's a URI for all of them. What does that mean? That will insert the URL, the URI. It will insert the web link so that you can put in your message, you know, "CPU is high, click here to see the CPU." "The interface is high, click here." So you can have built in 'click heres' for your messaging. I'm a big stickler for don't send a message if the person getting it isn't going to know what to do with it. So this allows you to embed all of those clicks right there, so they can get right to the troubleshooting piece.
And one thing we should point out for our SWIS geeks out there and I'm sure there's a few...
Patrick isn't here but yes, Patrick is excited off camera, yeah.
So we've actually redone our macro syntax. So all the old macros will still work, but you'll notice actually here in this picker, we have a new syntax for our macros. So that will be well documented. If you're interested in looking at that, it will be updated in our admin guide.
For people who are interested in SWIS and SWICKL. For those people who aren't necessarily interested in Swiss and SWICKL, if you're SQL fans, you can also define a raw SQL variable, if you need to get that. But I will tell you that I was trying to find all my old favorites and they're already in there. So there's very little that you have to do to put things together anymore. So I'm just going to insert this variable and you can see that it puts in each of those. Obviously, you can type those if you need to. So now, we get to add action. What am I going to do about it? I'll admit, although the interface is updated, there's not a lot of differences. There is 'change a custom property,' which is a big deal.
Blasphemy. There's nothing new. Change custom property, custom status, play sounds.
Right. Well we always had play sounds. We always had play sounds; it just played it on the server.
However, with Windows Server 2003, 'play sounds' actually was slightly broken in many regards. So we actually have a new desktop client available. So if you were to configure a new 'play sound' option or 'text to speech' option, you can download the MSI. So there's a link to it right here. I'll jump in right there. So you can actually download the MSI to your desktop and install the notification client, which is super neat. You mean so I'm not going to make the server talk in the server room and scare the guy at two o'clock in the morning?
All I ever used it for was April Fool’s Day once.
No long audio cable coming out of the server room.
Wait! Oh, okay. Got it. All right. Okay. So there are a few new features you're going to want to dig into and some things that look like they're the same but actually work much, much better. So you want to get into that. But I'm going to do a simple one. I'm just going to say send an email because I'm especially proud of this one. Yeah, okay. You give the name of the action. We'll call it 'blahblah.' And who's it going to? Well it's going to go to me. And the message--that's a lot of message. Where'd did that come from, Rob?
You will note we've done our default messages. So they're a lot more verbose than previous.
I might have offered my suggestions on that one.
Yes that is a Leon special alert message right there. So our new default alert messages, which are for new installs; you won't see them on upgrades. But if you are interested as to what Leon's come up with, I'm sure they'll be on THWACK.
Right, so we can talk more about it or you can mention on chat whether you think that we put enough in there or if we have to have more. But, yeah, the messages include a lot more information about when the alert happened and what devices were involved and so on and so forth. So you've got all that there. Which does beg the question, however...
Minor point with SMTP. So we now support backup SMTP servers. So, we had that previously without report scheduler so now you an answer the question: How do I get an alert if my Exchange server goes down? You can specify maybe an external or a backup SMTP server and your alert will still get out.
Fantastic. Cancel out of there. But it does beg the question: What did I do over here with this message displayed? Well that is what previously was called a 'NetPerfMon log.' So happily it's what would I consider to be non-optional. Really, there were too many people who were either not putting that action in or were leaving it with the custom message, which was, "Please put a message here." Which was not helpful. So, by default, you get a message in your message center that tells you something happened. So then you have reset actions on the next screen. We're going to leave that alone now. And finally, you have the summary. Which tells you everything that's going to be happening. And this little box down at the bottom-- this alert would be immediately triggering on zero. For those people, who [clears throat] may have set off 1700 alerts at once-- twice on separate days, this will...
Referenced as the incident. [Laughing]
Right. Really. Leon you can go to the ticket system and close all those tickets. Yeah, so this hopefully will help save you from yourself by telling you that this alert is, perhaps, malformed. It's going to alert on way more than you thought or maybe you want to think about fixing the problems before you set it to go.
Now to expound on that, if indeed this alert were to trigger right now, this would be a yellow warning and you would have a link to view the affected object. So just as we did in the scope selection before, you'll see what would actually be within scope of that alert.
Right. So we have this alert here. I'm just going to hit submit. So going back to your question about, you know, which boxes does this alert apply to, we've created here, on the Node Details page all the alerts that this object can trigger. So on each node you could run a report. And by the way, this object can be embedded in a report as well as on the Node Details page. It will tell you which alerts are going to happen and this is a question that gets asked frequently by team leads, server managers, whatever, you know. "I want to know what's going to wake me up in the morning." Is that new CPU alert that you wrote ever going to do it? No, it's not. Because you have routers and this is a Windows box, or whatever it is. So again, we've really revamped this in ways that make me so excited in so many different ways. And now, hopefully, you can see why I painted my face and everything.
And there is an out-of-the-box report to display pretty much everything that would ever alert and break it out by different objects. So when your boss comes to you and says, "Hey, I need a list of all our alerts--" which previously sounded like a pretty ridiculous task-- now you can just go through and generate that report.
It's fantastic. It's also cool that that's in core and not just in NPM.
Yeah and I get it in SAM too.
Yep, that's correct. NPM added features that all modules can take advantage of--so you're welcome.
Yeah and I mean I've been using NPM pretty much since the beginning of time, well maybe not that long, but a really, really long time. And I can't tell you how nice it is to be able to manage alerts through the web UI.
Yeah definitely. So Rob the development team really packed a lot of stuff into this release. That's good stuff.
They sure did. It helps to get such amazing feedback from our customers as well.
So you're talking about all the folks that are out there on THWACK.
Definitely. I told everyone if there's something that they want to see, just post a feature request on THWACK and then keep an eye on the 'What we're working on' post and see what made the cut.
Yeah, and I'm sure we're going to be showing off a lot of new features and some additional enhancements that are part of 11.5 in future episodes. So make sure you let us know what you want us to focus on. Come by our home page, which is lab.solarwinds.com. Give us ideas about what you want to see, sign up for reminders about upcoming episodes and of course all of our previous episodes are there too. And it was interesting on the chat on the last episode, how many folks were asking for topics that we discovered in previous episodes and it was great to be able to kick those links in there and send them back to look at previous content, like DPI and a couple of the other ones too. So, I think that's about it. We all set?
Well, unless Rob feels like telling us when NPM 11.5 is actually full release.
No sir, we are good to go.
All right then. I'm Patrick Hubbard.
And I'm Lawrence Garvin.
I'm Leon Adato.
And I'm Rob Hock. Thanks for watching SolarWind's Lab.