WEBVTT

0:00:02.940000 --> 0:00:07.440000
 In this video, I'm going to take just
 a few minutes to talk about the

0:00:07.440000 --> 0:00:11.820000
 idea of monitoring activity
 across subscriptions.

0:00:11.820000 --> 0:00:16.420000
 And really what I'm going to do is go
 in and briefly cover kind of concept

0:00:16.420000 --> 0:00:19.320000
 behind this and what are
 some options for it.

0:00:19.320000 --> 0:00:26.480000
 And then I'm going to go in and demonstrate
 how you can set up cross subscription

0:00:26.480000 --> 0:00:29.880000
 monitoring. And that's going to be what I
 like to call cooking show demonstration

0:00:29.880000 --> 0:00:33.300000
 because it's already all set up.

0:00:33.300000 --> 0:00:35.920000
 But I'm going to walk you through the
 process that I went through to get

0:00:35.920000 --> 0:00:39.720000
 there. And then finally I want to just
 jump back and take a look at some

0:00:39.720000 --> 0:00:46.260000
 of the takeaways of monitoring your
 activity across subscriptions.

0:00:46.260000 --> 0:00:50.420000
 So let's go ahead and let's just dive
 right in and talk about the options

0:00:50.420000 --> 0:00:55.980000
 that we have for monitoring multiple
 subscriptions starting with why we

0:00:55.980000 --> 0:00:59.380000
 might have multiple subscriptions in
 the first place and what that might

0:00:59.380000 --> 0:01:07.340000
 look like. All right, let's say
 that I've got the following.

0:01:07.340000 --> 0:01:15.440000
 I've got my Azure AD tenant and
 I've got my subscription.

0:01:15.440000 --> 0:01:17.300000
 Nice and simple.

0:01:17.300000 --> 0:01:19.240000
 Label these out.

0:01:19.240000 --> 0:01:27.520000
 Azure AD and subscription.

0:01:27.520000 --> 0:01:35.240000
 I'm just going to say sub a for reasons
 that will become apparent shortly.

0:01:35.240000 --> 0:01:39.420000
 Now this is going to be easy from
 a monitoring standpoint, right?

0:01:39.420000 --> 0:01:41.700000
 Simple company one subscription
 everything's there.

0:01:41.700000 --> 0:01:46.760000
 But as we go along, we realize
 that we're doing a lot of work.

0:01:46.760000 --> 0:01:52.060000
 Development. A lot of
 workload development.

0:01:52.060000 --> 0:01:55.540000
 And so we don't necessarily want to
 do all our testing and everything

0:01:55.540000 --> 0:01:57.080000
 else in that subscription.

0:01:57.080000 --> 0:02:01.080000
 So then we create a
 new subscription.

0:02:01.080000 --> 0:02:05.860000
 Which we will call.

0:02:05.860000 --> 0:02:16.400000
 Sub test. Okay, but then we
 also bring on a new client.

0:02:16.400000 --> 0:02:22.240000
 And we're managing their
 Azure resources.

0:02:22.240000 --> 0:02:27.260000
 And so then we end up with sub B.

0:02:27.260000 --> 0:02:32.340000
 Right now all of these
 are attached.

0:02:32.340000 --> 0:02:40.680000
 To my Azure AD. The Azure AD is the
 primary tenant for all of those.

0:02:40.680000 --> 0:02:42.620000
 So all the users and
 everything else.

0:02:42.620000 --> 0:02:51.680000
 Now the thing is we know that we have
 various ways of monitoring whether

0:02:51.680000 --> 0:02:58.860000
 it's at the blade level or whether
 it's at the Azure monitor level or

0:02:58.860000 --> 0:03:06.620000
 even with sending things to a workspace,
 a log analytics workspace, right?

0:03:06.620000 --> 0:03:07.660000
 And so we can do over there.

0:03:07.660000 --> 0:03:14.280000
 We have sub B. But then as we are building
 more and more, this starts

0:03:14.280000 --> 0:03:15.680000
 to become more complex.

0:03:15.680000 --> 0:03:23.320000
 So what we really want is we really
 want some way to monitor.

0:03:23.320000 --> 0:03:32.500000
 Across these subscriptions.

0:03:32.500000 --> 0:03:41.500000
 Right? And there's a few ways that are
 actually built in that we can do

0:03:41.500000 --> 0:03:49.660000
 this. One, as long as all of the subscriptions
 are associated with the

0:03:49.660000 --> 0:03:55.540000
 same Azure AD. Really the answer
 is simply Azure monitor.

0:03:55.540000 --> 0:04:01.200000
 And I can go in for example look at my
 activity log and view that activity

0:04:01.200000 --> 0:04:14.500000
 log across all of the And I can also
 do things like filter and set up

0:04:14.500000 --> 0:04:16.660000
 management groups and
 lots of things there.

0:04:16.660000 --> 0:04:18.260000
 That's great and that's easy.

0:04:18.260000 --> 0:04:20.640000
 But I'm going to wipe
 all this out.

0:04:20.640000 --> 0:04:25.280000
 Let's say we've got a slightly
 different scenario.

0:04:25.280000 --> 0:04:36.060000
 And what we have is
 more like this.

0:04:36.060000 --> 0:04:38.880000
 All right, we're going to abbreviate
 a little bit here.

0:04:38.880000 --> 0:04:50.660000
 I've got AADA and I've
 got subscription A.

0:04:50.660000 --> 0:04:52.920000
 And you kind of get the idea.

0:04:52.920000 --> 0:04:54.100000
 This is just B and B.

0:04:54.100000 --> 0:04:56.600000
 We'll even go a little
 bit shorter.

0:04:56.600000 --> 0:04:59.760000
 So that's AADB and subscription B.


0:04:59.760000 --> 0:05:06.000000
 And then of course C.

0:05:06.000000 --> 0:05:10.820000
 Should have done something completely
 different but then C.

0:05:10.820000 --> 0:05:18.260000
 Anyways, the idea being that all these
 have their own tenants and lots

0:05:18.260000 --> 0:05:21.060000
 of reasons you may have that
 within a single organization.

0:05:21.060000 --> 0:05:25.500000
 Maybe you've got a subsidiary that's
 been purchased that has their own

0:05:25.500000 --> 0:05:29.320000
 Azure AD and Azure environment.

0:05:29.320000 --> 0:05:33.720000
 And you want to work with that without
 having to move everything between

0:05:33.720000 --> 0:05:37.200000
 subscriptions because that can
 be a little bit painful.

0:05:37.200000 --> 0:05:42.980000
 Or maybe you're a service provider and
 you've got, let's say, maybe some

0:05:42.980000 --> 0:05:48.120000
 kind of medical accounting, medical
 billing or that kind of information

0:05:48.120000 --> 0:05:50.940000
 where everything needs to
 be completely separate.

0:05:50.940000 --> 0:05:54.240000
 And as you get new clients, each one
 of them is really going to get their

0:05:54.240000 --> 0:05:55.340000
 own environment.

0:05:55.340000 --> 0:05:59.900000
 And so there's a number of reasons why
 you might have this kind of disparate

0:05:59.900000 --> 0:06:04.160000
 organization and that sounds bad, but
 it's not necessarily bad at all

0:06:04.160000 --> 0:06:10.700000
 of your data. But now I'm not going
 to be able to simply coalesce all

0:06:10.700000 --> 0:06:14.560000
 these and view all these in
 a single built in interface.

0:06:14.560000 --> 0:06:17.480000
 However, there are some
 things that we can do.

0:06:17.480000 --> 0:06:22.580000
 And what we can do is take advantage
 in particular of Event Hub.

0:06:22.580000 --> 0:06:30.200000
 And so for example, let's say in
 sub A, I create an Event Hub.

0:06:30.200000 --> 0:06:31.540000
 We'll just say EH.

0:06:31.540000 --> 0:06:35.280000
 And this could be done
 across the board.

0:06:35.280000 --> 0:06:39.160000
 I create an Event Hub in
 an Event Hub namespace.

0:06:39.160000 --> 0:06:44.200000
 And what I have is I have things
 reporting into that Event Hub.

0:06:44.200000 --> 0:06:48.700000
 Remember, if you've watched other videos,
 when you look at diagnostics,

0:06:48.700000 --> 0:06:54.380000
 now for most of your resources, you've
 got that advanced diagnostic, the

0:06:54.380000 --> 0:06:58.020000
 new diagnostic environment, where you
 can say, I want the diagnostic data

0:06:58.020000 --> 0:07:00.440000
 to go directly to an Event Hub.

0:07:00.440000 --> 0:07:04.400000
 I can also set that up at the
 overall subscription level.

0:07:04.400000 --> 0:07:08.920000
 I can have the activity log of the
 subscription going to an Event Hub.

0:07:08.920000 --> 0:07:19.580000
 Then what I can do is I can have
 a centralized log analytics.

0:07:19.580000 --> 0:07:21.900000
 Let's draw that in.

0:07:21.900000 --> 0:07:25.140000
 And I can set up logic apps.

0:07:25.140000 --> 0:07:31.680000
 Let's say LA for logic app.

0:07:31.680000 --> 0:07:37.960000
 And a logic app has a trigger where
 it can be triggered by records being

0:07:37.960000 --> 0:07:39.480000
 dropped into Event Hub.

0:07:39.480000 --> 0:07:45.460000
 And it has an action where it can
 write data out to log analytics.

0:07:45.460000 --> 0:07:50.840000
 And to connect up to log analytics,
 all it needs are the workspace ID

0:07:50.840000 --> 0:08:02.680000
 and a key. And because it's a workspace
 ID and a key, and that is the

0:08:02.680000 --> 0:08:09.080000
 security that it uses, it doesn't matter
 where that log analytics is.

0:08:09.080000 --> 0:08:10.720000
 I have LA twice.

0:08:10.720000 --> 0:08:16.500000
 That's a logic app here, which
 is type draw logic in.

0:08:16.500000 --> 0:08:21.220000
 Try not to draw characters too much
 because it starts to look a little

0:08:21.220000 --> 0:08:22.780000
 bit scary when I do.

0:08:22.780000 --> 0:08:26.860000
 But in any case, I've got the logic
 app that's going to take the Event

0:08:26.860000 --> 0:08:31.580000
 Hub data and it's going to drop it
 into a log analytics and it doesn't

0:08:31.580000 --> 0:08:34.200000
 really matter where that
 log analytics is.

0:08:34.200000 --> 0:08:38.680000
 It could be part of the same subscription
 or it could be associated with

0:08:38.680000 --> 0:08:42.640000
 a completely unrelated subscription because
 again, you are authenticating

0:08:42.640000 --> 0:08:48.020000
 into it using the workspace ID and
 key nothing to do with Azure AD.

0:08:48.020000 --> 0:08:53.380000
 And so those are really two different options
 for centralizing your analytics.

0:08:53.380000 --> 0:08:59.080000
 And what I would like to do at this point
 is go ahead and really demonstrate

0:08:59.080000 --> 0:09:03.900000
 that. We're going to take a look
 at cross subscription monitoring.

0:09:03.900000 --> 0:09:07.520000
 First, I'll show you how you can monitor
 cross subscription if you have

0:09:07.520000 --> 0:09:12.200000
 subscriptions that are associated with
 the same Azure AD tenant and how

0:09:12.200000 --> 0:09:13.980000
 you can even filter
 that if you want.

0:09:13.980000 --> 0:09:19.620000
 And then I'll show you how you can
 set up this forwarding of events of

0:09:19.620000 --> 0:09:23.440000
 diagnostic data to
 a log analytics.

0:09:23.440000 --> 0:09:24.420000
 It really could be anywhere.

0:09:24.420000 --> 0:09:28.500000
 So let's go ahead and let's
 jump right into that.

0:09:28.500000 --> 0:09:37.980000
 Here I've got my portal and I'm just
 kind of in the blank space of the

0:09:37.980000 --> 0:09:42.240000
 portal here and I'm going
 to go into monitor.

0:09:42.240000 --> 0:09:49.280000
 And within monitor, I am going
 to go to activity log.

0:09:49.280000 --> 0:09:57.040000
 And right away, I have actually activity
 from all three of my current

0:09:57.040000 --> 0:10:02.120000
 subscriptions. All three of these subscriptions
 are associated with the

0:10:02.120000 --> 0:10:04.680000
 same Azure AD tenant.

0:10:04.680000 --> 0:10:06.600000
 They have that as their
 primary tenant.

0:10:06.600000 --> 0:10:10.660000
 And because of that and because I'm
 logged into that tenant, this just

0:10:10.660000 --> 0:10:14.060000
 picks up and it works
 out quite easily.

0:10:14.060000 --> 0:10:15.400000
 Now I can filter this.

0:10:15.400000 --> 0:10:18.600000
 So let's say for example, I only wanted
 things that were in production

0:10:18.600000 --> 0:10:22.120000
 and I can see the only thing that's
 happening in production is that I've

0:10:22.120000 --> 0:10:23.960000
 got an audit policy there.

0:10:23.960000 --> 0:10:26.620000
 I don't have anything
 in development.

0:10:26.620000 --> 0:10:29.700000
 And then I've got some
 demonstrations.

0:10:29.700000 --> 0:10:32.840000
 That's where most everything is of
 course is within the demonstration.

0:10:32.840000 --> 0:10:38.900000
 So that is without even really
 having to work on it.

0:10:38.900000 --> 0:10:46.440000
 That's the kind of functionality that
 I get through my monitor and through

0:10:46.440000 --> 0:10:52.220000
 having these kind of multiple subscriptions
 that are all associated by

0:10:52.220000 --> 0:10:57.440000
 way of their primary
 Azure AD tenant.

0:10:57.440000 --> 0:11:00.380000
 Now, what if however
 I wanted to forward?

0:11:00.380000 --> 0:11:03.380000
 Well, I can actually do
 that at multiple levels.

0:11:03.380000 --> 0:11:10.340000
 And at the highest level, what I can
 do is I can set up that architecture.

0:11:10.340000 --> 0:11:14.640000
 I'm just going to stay here and just
 whiteboard it for just a minute.

0:11:14.640000 --> 0:11:17.980000
 Right. And so the architecture that
 I'm going to have and I'm going to

0:11:17.980000 --> 0:11:21.560000
 set up is that I've
 got a subscription.

0:11:21.560000 --> 0:11:25.740000
 That subscription has
 an activity log.

0:11:25.740000 --> 0:11:38.420000
 I am going to set up that activity
 log to actually forward to an event

0:11:38.420000 --> 0:11:44.380000
 hub. All of this in the
 same subscription.

0:11:44.380000 --> 0:11:50.520000
 Then what I'm going to do is I'm actually
 going to define a logic app.

0:11:50.520000 --> 0:12:00.380000
 That pulls. From that event hub.

0:12:00.380000 --> 0:12:01.480000
 So I've got my subscription.

0:12:01.480000 --> 0:12:03.680000
 I've got the activity
 log, the activity log.

0:12:03.680000 --> 0:12:06.420000
 I'm going to configure to
 drop into the event hub.

0:12:06.420000 --> 0:12:08.920000
 The event hub. I'm going
 to pull from a logic app.

0:12:08.920000 --> 0:12:13.860000
 And again, what that logic app is going
 to end up doing is writing to

0:12:13.860000 --> 0:12:21.960000
 a log analytics workspace that
 is in another subscription.

0:12:21.960000 --> 0:12:27.260000
 Now, as it happens, the subscription
 I'm writing to happens to be part

0:12:27.260000 --> 0:12:30.700000
 of the same management structure because
 it's associated with the same

0:12:30.700000 --> 0:12:33.580000
 primary Azure AD tenant.

0:12:33.580000 --> 0:12:40.640000
 But this would work really as you
 will see across subscriptions.

0:12:40.640000 --> 0:12:44.240000
 Now, the first thing that I need to
 do is here within the activity log,

0:12:44.240000 --> 0:12:46.000000
 there's pretty easy to do.

0:12:46.000000 --> 0:12:49.080000
 I can just click export
 to event hub.

0:12:49.080000 --> 0:12:54.300000
 And I would check that I want to
 export this to an event hub.

0:12:54.300000 --> 0:13:01.080000
 And then I would select the event
 hub that I want to export this to.

0:13:01.080000 --> 0:13:03.000000
 And I've got a couple
 I created one.

0:13:03.000000 --> 0:13:06.200000
 I've got my standard one
 that runs all the time.

0:13:06.200000 --> 0:13:09.620000
 Event hub. And then I've got my event
 hub that I created specifically

0:13:09.620000 --> 0:13:17.000000
 for this. And so that's all I need
 to do to get my activity log at the

0:13:17.000000 --> 0:13:20.140000
 subscription level pushed
 out to event hub.

0:13:20.140000 --> 0:13:30.660000
 Very simple. Now, the next thing that
 I would do is create a logic app.

0:13:30.660000 --> 0:13:36.580000
 And that's really the big
 part of the secret sauce.

0:13:36.580000 --> 0:13:40.540000
 It is, if you will, the secret sauce
 that makes all of this work.

0:13:40.540000 --> 0:13:46.060000
 And what I'm going to do is I'm going
 to pop in and show you the definition

0:13:46.060000 --> 0:13:47.760000
 of this logic app.

0:13:47.760000 --> 0:13:53.280000
 Now, I will tell you that this definition
 I literally generated directly

0:13:53.280000 --> 0:13:58.300000
 from a Microsoft docs
.marshoff.com.

0:13:58.300000 --> 0:14:01.380000
 Blog page where it goes
 through this process.

0:14:01.380000 --> 0:14:05.340000
 So this is actually, can be a little bit
 complex, but it's very well documented.

0:14:05.340000 --> 0:14:11.040000
 I will say that the documentation as
 of today, when I'm recording this,

0:14:11.040000 --> 0:14:12.320000
 is slightly out of date.

0:14:12.320000 --> 0:14:15.180000
 But you can kind of work
 your way around that.

0:14:15.180000 --> 0:14:21.360000
 Just because it's really hard to keep
 up as the Azure environment continues

0:14:21.360000 --> 0:14:25.340000
 to evolve. In fact, by the time you watch
 this video, it's probably slightly

0:14:25.340000 --> 0:14:27.040000
 different than even what I'm
 going to show you here.

0:14:27.040000 --> 0:14:31.220000
 But there are four primary components
 to this logic app.

0:14:31.220000 --> 0:14:35.740000
 There's the trigger, which is when event
 hubs are available in Event Hub.

0:14:35.740000 --> 0:14:37.640000
 And I added that trigger.

0:14:37.640000 --> 0:14:41.200000
 That flows into parsing
 out the JSON.

0:14:41.200000 --> 0:14:43.740000
 So those event hub events
 are going to be returned.

0:14:43.740000 --> 0:14:48.240000
 Actually, I tell them to return
 them as application JSON.

0:14:48.240000 --> 0:14:51.840000
 Now, what's really important is that
 the event hub name is going to be

0:14:51.840000 --> 0:14:55.200000
 insights dash operational
 dash logs.

0:14:55.200000 --> 0:14:59.960000
 If you, as I did initially, forget
 that it creates its own and try to

0:14:59.960000 --> 0:15:04.420000
 use yours, it's going to be
 frustrating for a while.

0:15:04.420000 --> 0:15:07.500000
 The content type is
 application JSON.

0:15:07.500000 --> 0:15:11.040000
 And then I've got this set for a ridiculously
 short period just because

0:15:11.040000 --> 0:15:13.940000
 that way we can see results.

0:15:13.940000 --> 0:15:20.080000
 You would typically not want to pull
 those every 30 seconds necessarily.

0:15:20.080000 --> 0:15:23.380000
 And then that comes into
 this parse JSON.

0:15:23.380000 --> 0:15:31.240000
 And what that does is it says, OK, in
 comes this kind of not random, but

0:15:31.240000 --> 0:15:35.280000
 anonymous JSON that's coming in.

0:15:35.280000 --> 0:15:36.940000
 My system doesn't know what it is.


0:15:36.940000 --> 0:15:41.040000
 And really, all this is doing is saying,
 OK, I'm going to put this schema.

0:15:41.040000 --> 0:15:43.620000
 This is what that
 JSON should match.

0:15:43.620000 --> 0:15:50.620000
 And again, that schema is pulled directly
 from a blog on doing this.

0:15:50.620000 --> 0:15:52.660000
 And I'll show you that
 blog in just a moment.

0:15:52.660000 --> 0:15:57.660000
 And then the next step is compose,
 which basically just builds it back

0:15:57.660000 --> 0:16:03.400000
 into JSON. Really, the parse and the
 compose parse out and then recompose

0:16:03.400000 --> 0:16:05.940000
 exactly the same object.

0:16:05.940000 --> 0:16:08.520000
 And then it says, OK, we're going
 to go ahead and send that.

0:16:08.520000 --> 0:16:12.320000
 And we're going to send the
 output from that compose.

0:16:12.320000 --> 0:16:16.000000
 I'm going to put it into a
 custom log called a demo.

0:16:16.000000 --> 0:16:18.780000
 The time generated
 field is just time.

0:16:18.780000 --> 0:16:21.760000
 That's one of the fields that's
 coming in from the system.

0:16:21.760000 --> 0:16:25.140000
 And then if I go and
 change connections.

0:16:25.140000 --> 0:16:28.860000
 So right now this is connected
 to log analytics.

0:16:28.860000 --> 0:16:32.600000
 If I add new, I can
 give it a name.

0:16:32.600000 --> 0:16:36.060000
 And then I have the workspace
 key and the workspace ID.

0:16:36.060000 --> 0:16:40.660000
 And if we go and take
 a look at the portal.

0:16:40.660000 --> 0:16:51.060000
 And if I go to log analytics
 workspaces.

0:16:51.060000 --> 0:16:55.580000
 And if I go to my centralized
 log analytics.

0:16:55.580000 --> 0:16:59.100000
 And go to advanced settings.

0:16:59.100000 --> 0:17:01.580000
 I can find the workspace
 ID in the primary key.

0:17:01.580000 --> 0:17:03.380000
 And it doesn't matter
 where this is.

0:17:03.380000 --> 0:17:06.580000
 Because those are the only
 two pieces of information.

0:17:06.580000 --> 0:17:12.160000
 And it truly doesn't matter if they're
 in the same subscription or even

0:17:12.160000 --> 0:17:16.720000
 under the same primary
 Azure AD tenant.

0:17:16.720000 --> 0:17:18.040000
 But we're going to
 leave that alone.

0:17:18.040000 --> 0:17:21.520000
 So those are the four steps
 that this goes through.

0:17:21.520000 --> 0:17:24.320000
 And if I go back, I've already
 got that set up.

0:17:24.320000 --> 0:17:26.760000
 So I have the log analytics.

0:17:26.760000 --> 0:17:33.240000
 I have the logic.

0:17:33.240000 --> 0:17:35.360000
 My activity log goes to event hub.


0:17:35.360000 --> 0:17:38.100000
 Event hub is being pulled
 by this logic app.

0:17:38.100000 --> 0:17:40.900000
 And it's being dropped
 into log analytics.

0:17:40.900000 --> 0:17:44.380000
 And I can actually go and
 look at an execution.

0:17:44.380000 --> 0:17:49.880000
 I can go in and it'll get me
 details as to what happened.

0:17:49.880000 --> 0:17:53.080000
 This is a policy audit.

0:17:53.080000 --> 0:18:03.220000
 And then I could come down,
 see how that got parsed out.

0:18:03.220000 --> 0:18:06.800000
 And I can go to event to a log.

0:18:06.800000 --> 0:18:14.600000
 Now, while I'm in here, that means that
 that data should be sitting over

0:18:14.600000 --> 0:18:17.880000
 here in this log analytics.

0:18:17.880000 --> 0:18:21.500000
 And so what I'm going to do
 is I'm going to go to logs.

0:18:21.500000 --> 0:18:26.420000
 And it's actually really
 pretty simple.

0:18:26.420000 --> 0:18:28.240000
 I go to log management.

0:18:28.240000 --> 0:18:32.020000
 Now, in addition to log management,
 I've got custom logs.

0:18:32.020000 --> 0:18:33.980000
 And it does create a log.

0:18:33.980000 --> 0:18:35.400000
 So there's demo CL.

0:18:35.400000 --> 0:18:38.200000
 I've done an earlier
 one demo activity.

0:18:38.200000 --> 0:18:41.600000
 Now, I can go and view that.

0:18:41.600000 --> 0:18:43.920000
 And it looks like nothing's there.


0:18:43.920000 --> 0:18:47.520000
 And that's because now it doesn't write
 to that, at least not that you

0:18:47.520000 --> 0:18:50.080000
 can record here or query here.

0:18:50.080000 --> 0:18:57.660000
 It actually integrates that information
 directly into the standard activity.

0:18:57.660000 --> 0:19:09.380000
 So if I want to go to, let's see, somewhere
 around here, just go to event,

0:19:09.380000 --> 0:19:17.440000
 why not? That's not the right one.


0:19:17.440000 --> 0:19:18.840000
 I just had this.

0:19:18.840000 --> 0:19:21.640000
 It's always kind of fun
 to try and find these.

0:19:21.640000 --> 0:19:24.540000
 Let's try operation here.

0:19:24.540000 --> 0:19:28.740000
 There we go. Here operations and
 here are a whole bunch of them.

0:19:28.740000 --> 0:19:31.420000
 That sadly failed.

0:19:31.420000 --> 0:19:45.040000
 But if I drill down, this one doesn't
 actually give me a whole lot.

0:19:45.040000 --> 0:19:47.840000
 Access to the subscription
 was lost.

0:19:47.840000 --> 0:19:50.920000
 Well, that's a shame.

0:19:50.920000 --> 0:19:54.500000
 Probably all of those that are
 failed are telling me that.

0:19:54.500000 --> 0:19:56.680000
 These are from a couple days ago.

0:19:56.680000 --> 0:20:00.280000
 All right. Azure Activity
 Log Collection.

0:20:00.280000 --> 0:20:08.120000
 And this is giving me now the log collection
 is coming from my primary

0:20:08.120000 --> 0:20:14.960000
 test log. Now, give me just a moment
 and I will once again find the log

0:20:14.960000 --> 0:20:25.120000
 that will show you some
 actual activity.

0:20:25.120000 --> 0:20:29.880000
 All right. What I'm looking for is
 this Azure Activity that was right

0:20:29.880000 --> 0:20:31.180000
 there the whole time.

0:20:31.180000 --> 0:20:34.060000
 And for some reason, I
 just looked over it.

0:20:34.060000 --> 0:20:37.720000
 Now here is a result
 from Azure Activity.

0:20:37.720000 --> 0:20:44.060000
 And what I want to do is drill down
 a little bit just to show you.

0:20:44.060000 --> 0:20:47.520000
 Go down here. Here's
 resource group.

0:20:47.520000 --> 0:20:49.500000
 Doesn't even matter
 what it's doing.

0:20:49.500000 --> 0:20:57.980000
 There's 3509. That resource group is
 not in the same subscription as my

0:20:57.980000 --> 0:21:02.520000
 log analytics. This has been forwarded
 over to this log analytics from

0:21:02.520000 --> 0:21:06.740000
 my demonstration subscription.

0:21:06.740000 --> 0:21:11.680000
 Okay. So it's not a huge payoff other
 than the fact that I'm getting the

0:21:11.680000 --> 0:21:18.620000
 data. It's flowing from one subscription
 through Event Hub, through a

0:21:18.620000 --> 0:21:21.600000
 logic app into a centralized
 log analytics.

0:21:21.600000 --> 0:21:26.720000
 And remember, many of your resources
 now can report their own diagnostics,

0:21:26.720000 --> 0:21:32.360000
 not just at the control plane level,
 not just the activity log, but their

0:21:32.360000 --> 0:21:37.180000
 own diagnostics can be reported directly
 to Event Hub, picked up and flowed

0:21:37.180000 --> 0:21:38.980000
 this way. Right.

0:21:38.980000 --> 0:21:42.780000
 And now what I want to do is just pop
 back over and let's just make sure

0:21:42.780000 --> 0:21:45.680000
 that we're good with
 the takeaways.

0:21:45.680000 --> 0:21:50.260000
 First of all, if you're going to do
 anything with monitoring, anything

0:21:50.260000 --> 0:21:55.560000
 with cross subscription monitoring,
 remember Azure Monitor.

0:21:55.560000 --> 0:21:57.740000
 Azure Monitor really is king.

0:21:57.740000 --> 0:22:02.200000
 If you've got multiple subscriptions
 that share the same Azure AD tenant

0:22:02.200000 --> 0:22:06.080000
 and you have the appropriate rights,
 then you can actually monitor those

0:22:06.080000 --> 0:22:10.180000
 in a combined and integrated
 fashion.

0:22:10.180000 --> 0:22:16.720000
 If not, you saw several times how you
 can really take data and flow it.

0:22:16.720000 --> 0:22:20.700000
 Also, keep in mind the second bullet
 point underneath the Azure Monitor

0:22:20.700000 --> 0:22:29.600000
 comment is that really log, our log analytics
 and Azure Monitor are really

0:22:29.600000 --> 0:22:31.180000
 kind of morphing into one.

0:22:31.180000 --> 0:22:35.460000
 There'll always be some distinctions
 there, but it's something that I'm

0:22:35.460000 --> 0:22:40.340000
 seeing that functionality integrate
 more and more as really time goes

0:22:40.340000 --> 0:22:42.200000
 by within Azure.

0:22:42.200000 --> 0:22:45.320000
 So you definitely want to understand
 what log analytics are.

0:22:45.320000 --> 0:22:49.460000
 They're going to be a key component
 of your monitoring and they do tie

0:22:49.460000 --> 0:22:53.200000
 in very nicely into the Azure
 Monitor environment.

0:22:53.200000 --> 0:22:59.280000
 Now, there is some cost associated with
 log analytics, but it is a very

0:22:59.280000 --> 0:23:01.740000
 minor cost in most cases.

0:23:01.740000 --> 0:23:04.240000
 You want to of course track that and
 there's things you can do to mitigate

0:23:04.240000 --> 0:23:10.040000
 it. But it's frankly pretty hard to do much
 monitoring in the Azure environment

0:23:10.040000 --> 0:23:13.580000
 without having log analytics.

0:23:13.580000 --> 0:23:18.560000
 And finally, if you do have multiple
 subscriptions and you need to flow

0:23:18.560000 --> 0:23:23.880000
 your diagnostic data from one subscription
 to another, remember that basic

0:23:23.880000 --> 0:23:34.840000
 flow of having a event hub
 and having log analytics.