[upbeat music]
>>Thanks for doing an interview with us.
What's up? >>Oh, it's Brad.
>>Again? >>He says there's a problem
with the database server again.
>>OK, so what changed?
>>Well, according to Brad, nothing.
>>Of course it didn't.
You know what, why don't we have SCM on that box?
>>You've met Brad, haven't you?
>>Yeah.
>>How is SCM going to help a user like Brad?
>>It'll help you notice when things in your
environment change unexpectedly.
>>You don't say?
Really? >>Yeah.
Okay I'll start with something simple.
>>All right then.
>>What we're looking at here is a machine
that has had its configurations tracked for a while.
There's a few different things that we can look at.
For example, hardware.
So you can see that we're tracking all sorts of
aspects of the hardware right now.
And some have had a baseline set to say this is normal,
and anything higher or lower I want to know about.
In fact, if we take a look at the hard drive,
the hard drive has had some interesting changes.
Where somebody changed the capacity.
Now, they made it better, right?
You know? >>Yeah.
Yeah no serial number, but
the capacity just got bigger. >>OK, fine.
But the capacity's bigger.
This probably is a case of, you know, automatic
expansion on a virtual disc.
So I'm not 100% sure this is something that
I would worry about per se, but
it is definitely something >>Right.
>>That we'd want to know about, right?
>>Well, it's data.
You know? >>Yes.
>>If you're researching this and especially if
something has gone wrong,
that's a piece of data that'll help you
do the forensics, right?
>>Right. >>You say, oh I can see.
Not only can I see what was changed,
but I know when it was changed.
>>Exactly.
Exactly. And you know, I think some of the other hardware
inputs that are there, whether it's CPU or memory,
might be more interesting.
But the other thing you can do is track software.
Which goes way beyond just installed software,
which we'll talk about in a second.
But also things like operating system updates.
So for example if this machine had some updates
which we've got right here, you can see that
one of the patches was removed.
Which is kind of disturbing to me.
Like why did you remove a patch?
>>Well, you know, it's not uncommon
to roll back a hotfix.
>>OK, fair enough.
But like you said, it's data.
If something is not right, this is input.
A little bit more, normally I would say is that
you can see that patches were added down here later on.
>>See, now they've got
the correct patches installed.
>>You're a good storyteller.
I like this.
And again, just knowing that the change
occurred was important.
But again, another thing is just knowing actual software
that's been installed or removed.
So for example, here we've got software that actually
hasn't been added or removed but it's been upgraded.
So we've got two very important pieces of software.
The SolarWinds Agent and the SolarWinds WPM Player.
And they've both had their versions upgraded from
one version to the next in both cases.
But if something was installed, you'd see that.
The other thing worth mentioning is that
the new way of showing log information
is to remove the unnecessary lines.
So there's 123 lines above and nine lines below.
Nothing changed, so you don't have to see it.
>>Right.
>>This isn't the whole config.
>>No, no, no.
I mean, you want the user to focus
on the changed items, right?
>>Of course. >>We don't need to have
all those unchanged lines there.
>>Right, but there's other things you can track.
For example, here on this system
we've got hardware, software,
but also Folder Content Monitoring is another item here.
So, here they're actually tracking the SCM
demo folder on the C drive to see if anything
in there changes in some way.
For example, if I go look at that first config file, 001,
I can see that it didn't exist on May 5th
and now it does.
>>Right, interesting.
>>Right?
And then also here config number four, interestingly enough,
four did exist on May 5th,
but two lines have changed since then
and one line has been removed.
>>Wow.
>>Yeah, I don't know what this config file
does particularly, but again, if something is going wrong,
this may be the pointer
to tell you that all is not well in Denmark.
>>Well, you know, it's also this thing; this
could've been a proper change.
There could have been a change control process.
Something was deployed.
So in a way, you can think of SCM as this tool
that can help you somewhat validate that
your deployment has worked as expected.
>>Yes, absolutely.
You know, did I know that was gonna change?
Yes, I did.
Fantastic.
And like you said, did it change in the way
that I expected is also something to know.
>>So that's nice.
I like what I see there.
But it really felt to me when I was looking there
it's kind of mostly focused on just server and applications,
but maybe it's a virtual server.
I guess what I'm asking is there any type of
DevOps-y story here?
>>Oh yeah, SCM can totally Dev your Ops.
Before we start, I think it's important that
we lay it on the table that no one is trying
to say that configuration monitoring is gonna
address every single aspect of container monitoring
or DevOps in general or anything like that, right?
>>No, no, not at all.
I mean, configurations are an important part of that,
but it's just one piece.
DevOps is a little more encompassing than
just configuration files.
>>OK, good.
So we're not trying to pull the wool over
anybody's eyes or anything like that.
But I will say as a Linux aficionado,
one of the key aspects of any application,
especially applications running on Linux, are the files.
That the files as they change and go through
different sort of transitional states,
they tell a story of their own.
And I feel like containers are really just files.
So if you track them--
>>No, you know you're being a little,
I think you're oversimplifying what a container is.
>>Maybe.
Maybe just a little bit.
>>But on a more serious note,
a container is going to be a series of
configuration files, right?
So that's the stuff that you really want
to be able to track and be on top of.
And SCM is gonna be able to tell you
yeah, there's something different in the configuration
file for this container or group of containers.
>>Right, now one of the key aspects
of that is dealing with not just configuration files
or a series of lines like a log file is or a registry is,
but files that are actually more structured data.
They're JSON or XML data.
And SCM can handle that in a very particular way.
So I want to illustrate that and then get back
to containers for a minute.
What I've got here is actually the output of
an application called "Pi-Hole."
I've got a few Raspberry Pis at home,
as many many IT folks do.
I use them for a lot of different fun side projects.
One of the side projects is this application
called "Pi-Hole," which captures and then
blocks ads as they come into the house.
Either because they're things I don't want to see
or they're spammy or whatever they are.
And you can pull statistics out of it.
It has an API.
And so you can tell like how many domains
are being blocked, how many DNS queries it's done
and so on and so forth.
And I just want to point out that this right here,
this is the data that it outputs.
Right, like that.
So it looks fairly unstructured but anybody who
knows what JSON looks like knows
that this is actually the format.
And when SCM ingests that and processes it,
it comes out looking like this.
So it understands where blocks begin and end.
And it also understands that if a block moves
up or down, that isn't a change in the log file,
that's just a block moving and that's OK.
So when I get flagged is when something actually changes.
Here the number of DNS queries has changed.
Meanwhile, down at the bottom,
I can tell that, for example,
this block, which is, you know, gravity last updated,
four more lines there,
gravity last updated, file exists, so on and so forth.
And then there's a relative block
which is a sub-block within that and so on.
It understands to nest those and keep the integrity
of those blocks in place.
But meanwhile, also note when something changes.
This isn't, again DevOps-y or container-y,
but it just shows that SCM can handle the structured
file format of XML or JSON.
So that when you get to your containers.
Now what I'm doing is I'm actually monitoring
in this JSON test.
I'm monitoring the folder of all the containers
on a machine I have here in my lab.
So you can see that I've got a variety
of different containers.
Each one is running a different application.
And I've got the config file, the host config,
the host name, host resolver, and so on
in each one of those being tracked.
And there's been some changes.
So for example, I can tell here
that somebody stopped the container.
That's no big deal there, but I can tell
that it was running and then when I looked
at it again and it was not running,
the process ID and all that stuff stopped.
But you can find other more meaningful changes.
For example, here I can tell
that somebody restarted the container.
Someone or something restarted the container.
The process ID changed, the start and finish changed,
and, you know, other elements down below.
And in fact, I could see other things if
I added a mount point, if I added software,
that would show up as well.
>>So I notice you're running MySQL.
>>I'm running MySQL on this one.
MySQL is running.
And just to point out that this container,
the one that stopped, is actually the one
that's running my WordPress instance.
>>Ah, that's what it was.
I figured something was up.
>>Right.
>>So I really like how you're mentioning
the blocks if they move.
Because with the idea of the declarative programming,
which is these ARM templates you're finding in Azure.
Where basically a lot of structure is just being
shared through JSON files.
And you might move things around for whatever reason
but I like how SCM is going to be like
oh, I recognize that that's just a block.
It's the same block as it was before,
so I'm not going to flag that one.
I like it because it's reducing the noise.
>>Right.
Yeah, it's limiting the things
that you're gonna get told about.
On the other hand, the other thing
that I like about this is
that these two containers are actually tightly coupled
and one is now not running
and the other one is running.
Now since you're an Azure person,
what would that say to you as somebody
who's, you know, working with an organization
that has a large number of containers
running and doing things?
>>If one's up and one's down?
>>Yeah.
>>I don't know.
Maybe some patching going on?
Maybe.
>>Sure.
>>Maybe.
>>OK.
I will point out
that this has been down since two days ago.
>>Well, you know, you're the Linux lover.
So this is where you say that's how come
it takes two days to patch a Windows machine.
>>Got it, fair enough.
I was also thinking that my MySQL instance has
been running for two days without anything talking to it.
Possibly.
And that there could be some charges associated with that.
>>Oh yes.
Yes, there will be some charges associated with that.
>>Yeah, so that's kind of an important thing to know.
I know that when we talk about DevOps and containers
a lot of people's minds immediately go to
ephemeral state of containers that you
spin them up and spin them down
and make 100 and then kill them all
you know five minutes later and things like that.
And that's good, that's fine.
But some containers are more persistent than that.
And when you do have persistent containers
and something happens, this is
a great way to know about it.
>>Absolutely.
>>But after all that, I'm still not clear
how SCM is going to address the Brad issue.
>>OK, now the Brad issue is the simple
fact that Brad likes to go inside to that
database server and make a whole bunch of changes.
>>All right.
But it's SQL Server.
So, it's not a registry, it's not a file.
>>Oh, but it could be.
It just depends on what he's trying to change
in order to get his crappy code to work.
Here, let me show you what I mean.
>>OK.
>>So one of the great things about SCM is that
it can also monitor registry keys, right?
And I have here, I've pointed it at the Hkey,
local machine, software, Microsoft, Microsoft SQL Server.
Because for something like a database server,
you might be interested to know if registry
changes are happening.
The great example I like to use
is the backup directory.
That information is stored as part of a registry key.
So SQL Server will read this upon startup, right?
But the thing is, sometimes you think about
hey, if I get access to the database server,
if I can run queries and do it,
you don't even need access to the database.
If you get access to the server, or better yet,
if somebody you know that has access to it
accidentally, with your help,
overwrites that backup directory key,
it might be that you could
redirect those backups somewhere else.
Let's just say it's a bad actor
as we talk about, right? >>Right.
>>Somebody with bad intent.
So they somehow trick an admin into doing whatever
and lo and behold now your backups
are being rerouted somewhere else.
>>Well right, I mean, like a linked directory
to an offshore storage or something.
>>Possibly,
Possibly.
So, it's just a piece of data
you'd like to have and know about
and be aware about if you were a DBA.
Hey, what's changing on my server?
Why did these registry changes happen?
So, SCM has the power to monitor for registry
and I think that's incredibly valuable
for those application servers like
an Exchange server, a database server,
your BizTalk or your SharePoint, right?
>>Yeah.
>>You'll want to know what's really happening
and SCM just makes that really easy.
>>Which is all well and good,
but it still doesn't answer the question
about how we catch someone like Brad
in the act of messing up our day
and then telling us that we did something wrong.
Like, I don't see that here.
>>Well, Brad could have done this.
But, Brad most likely is inside the database doing things.
He's probably one of those Devs that has
a little too much access rights
and is just allowed
to muck with things because he thinks
yeah, things will be better this way,
I read it on a blog post.
But we can do that.
So another way for us to get that done,
is you can output the results of a query to a file, right?
>>Uh huh.
>>And that's what I've done here.
I've simply just done a dump of sysconfig using
I just put it into SQL Agent,
but however you want to run the query,
as long as it outputs to a file,
SCM can do a diff of the file.
So that's what we've done here.
On the left you see the original settings.
And you can see Brad changed the max server memory
from default of two terabytes
to now a default of four gigs.
>>Right because a number that begins with four
is clearly larger than a number that begins with two.
>>The logic of Brad, and the wonder of Brad
never ceases to amaze me. [Leon laughing]
>>But yes, he has made a change here and I've tracked it.
Now configuration changes, it's one of those things
that I think a lot of DBAs recognize the value
of saying you know, I need to know if somebody
has made a change inside of sysconfig, right?
>>Yes.
>>And right now there's no native way to get that
kind of done inside of SQL Server.
You really have to kind of do it for yourself,
monitor it for yourself, sub a trace,
or extend to the vents, however.
But that's something you manually have to do,
but SCM would kind of make that even easier
for you across your entire enterprise, right?
Yeah.
>>That's great.
Well, I'm glad we got that sorted out
before booth duty was over.
>>Hey, this place has Shawarma.
You want some Shawarma?
I want Shawarma.
>>Absolutely. >>Let's go.