WEBVTT

1
00:00:00.160 --> 00:00:05.320
<v Speaker 1>Welcome back to the deep dive. Okay, imagine your IT infrastructure.

2
00:00:06.280 --> 00:00:10.480
<v Speaker 1>It's like this huge intricate machine, right, thousands of moving parts.

3
00:00:10.880 --> 00:00:13.240
<v Speaker 1>How do you actually keep it running smoothly? How do

4
00:00:13.320 --> 00:00:16.600
<v Speaker 1>you predict problems before they hit and cut through all

5
00:00:16.600 --> 00:00:19.239
<v Speaker 1>that noise, all that data to find what really matters?

6
00:00:19.519 --> 00:00:21.760
<v Speaker 2>Yeah, that's the million dollar question in IT. Isn't it

7
00:00:21.760 --> 00:00:25.879
<v Speaker 2>systems just keep getting more complex and finding those essential

8
00:00:25.920 --> 00:00:29.839
<v Speaker 2>insights doing it efficiently reliably? Oh, that's what every team.

9
00:00:29.640 --> 00:00:32.520
<v Speaker 1>Is chasing, absolutely, and that chase is exactly why we're

10
00:00:32.560 --> 00:00:35.280
<v Speaker 1>diving deep today. We're looking at the ZABIC seven IT

11
00:00:35.600 --> 00:00:38.920
<v Speaker 1>Infrastructure Monitoring Cookbook by Nathan Lifting and Brian van Beekl.

12
00:00:39.079 --> 00:00:42.399
<v Speaker 1>And this isn't just some minor update ZABC seven point ZERLTS.

13
00:00:42.479 --> 00:00:45.640
<v Speaker 1>That's long term support. It brings some really significant quality

14
00:00:45.640 --> 00:00:48.520
<v Speaker 1>of life improvements, plus some cutting edge features building on

15
00:00:48.560 --> 00:00:50.520
<v Speaker 1>what we saw in six point two and six point four.

16
00:00:50.840 --> 00:00:53.159
<v Speaker 2>Right. And what's great about this book, I think, is

17
00:00:53.200 --> 00:00:56.560
<v Speaker 2>how the authors, who are really respected in the Zavik's world,

18
00:00:56.560 --> 00:01:00.159
<v Speaker 2>have made it so practical. It genuinely bridges that gap

19
00:01:00.200 --> 00:01:02.479
<v Speaker 2>between the official docs, which can be a bit dry,

20
00:01:02.840 --> 00:01:05.319
<v Speaker 2>and the real world problems you actually face day to day.

21
00:01:05.719 --> 00:01:09.519
<v Speaker 2>Even Alexei's Ladyshev, the guy who created Zadex, points out

22
00:01:09.519 --> 00:01:12.519
<v Speaker 2>their deep knowledge and hands on experience in the forward.

23
00:01:12.799 --> 00:01:16.159
<v Speaker 2>It really is a cookbook, giving you specific recipes, specific techniques.

24
00:01:16.519 --> 00:01:19.280
<v Speaker 1>Okay, so our mission today is pretty straightforward. We're giving

25
00:01:19.319 --> 00:01:21.719
<v Speaker 1>you a shortcut. We're pulling out the most important stuff

26
00:01:21.760 --> 00:01:24.239
<v Speaker 1>from this book, helping you get up to speed fast

27
00:01:24.319 --> 00:01:27.159
<v Speaker 1>on what Zavic seven can do. We'll focus on what's critical,

28
00:01:27.239 --> 00:01:31.079
<v Speaker 1>what's maybe a bit surprising, and why it actually matters

29
00:01:31.120 --> 00:01:35.719
<v Speaker 1>for you when you're designing, building or maintaining your Zavik setup. Right, then,

30
00:01:35.799 --> 00:01:39.200
<v Speaker 1>let's untack this starting at the beginning, the core bits

31
00:01:39.200 --> 00:01:42.120
<v Speaker 1>of Zavik seven. You've got the Zavic server that's the engine,

32
00:01:42.400 --> 00:01:44.840
<v Speaker 1>the brain's doing all the work. And then there's the

33
00:01:44.840 --> 00:01:47.519
<v Speaker 1>front end that's your UI, how you see and interact

34
00:01:47.519 --> 00:01:49.000
<v Speaker 1>with everything exactly.

35
00:01:49.319 --> 00:01:52.000
<v Speaker 2>And for that front end piece, the book really pushes

36
00:01:52.200 --> 00:01:56.719
<v Speaker 2>NGINX over APATCHE. The main reason speed GNX is generally

37
00:01:56.799 --> 00:01:59.120
<v Speaker 2>quite a bit faster, and that really makes a difference

38
00:01:59.120 --> 00:02:02.280
<v Speaker 2>when you've got lots of people hitting the interface all day. Oh.

39
00:02:02.359 --> 00:02:05.519
<v Speaker 2>In a handtip for getting started, ZABX actually provides really

40
00:02:05.560 --> 00:02:08.199
<v Speaker 2>good setup guides and repo links right on their site,

41
00:02:08.319 --> 00:02:10.879
<v Speaker 2>makes that initial install surprisingly smooth.

42
00:02:11.199 --> 00:02:14.199
<v Speaker 1>Okay, speed and easy setup are gray, But what about reliability?

43
00:02:14.599 --> 00:02:18.560
<v Speaker 1>Making sure zabex itself doesn't fall over. High availability or

44
00:02:18.719 --> 00:02:22.280
<v Speaker 1>HHA for the server seems absolutely key for anyone serious

45
00:02:22.280 --> 00:02:25.719
<v Speaker 1>about monitoring. That was a big deal back in ZABC six, right,

46
00:02:26.039 --> 00:02:28.240
<v Speaker 1>and it's still vital in seven. It's all about keeping

47
00:02:28.240 --> 00:02:31.240
<v Speaker 1>your monitoring up even if one server has a problem.

48
00:02:30.919 --> 00:02:33.759
<v Speaker 2>Totally crucial. The idea is basically a split setup. You

49
00:02:33.840 --> 00:02:36.240
<v Speaker 2>keep your database and server node separate. Then you use

50
00:02:36.240 --> 00:02:38.960
<v Speaker 2>a virtual IP of VIP for the cluster nodes, so

51
00:02:39.000 --> 00:02:41.400
<v Speaker 2>if one server node fails, the other just takes over

52
00:02:41.639 --> 00:02:45.120
<v Speaker 2>seamless failover. It really takes Zavik's reliability to the next level,

53
00:02:45.159 --> 00:02:47.879
<v Speaker 2>minimizes those outages, and the book even mentions thinking about

54
00:02:48.000 --> 00:02:50.159
<v Speaker 2>HA for the database too, maybe like a mycycle master

55
00:02:50.240 --> 00:02:52.680
<v Speaker 2>master setup for you know, ultimate peace of mind.

56
00:02:52.759 --> 00:02:57.120
<v Speaker 1>So foundation solid, it's reliable. Next big thing security and

57
00:02:57.319 --> 00:02:59.719
<v Speaker 1>user management. Got to make sure the right people see

58
00:02:59.719 --> 00:03:03.639
<v Speaker 1>the right things. How does Zabix seven handle mastering users

59
00:03:03.680 --> 00:03:04.319
<v Speaker 1>in security?

60
00:03:04.680 --> 00:03:07.199
<v Speaker 2>It's got a pretty structured approach, using user groups and

61
00:03:07.319 --> 00:03:09.879
<v Speaker 2>user roles. Think of user groups for controlling what people

62
00:03:09.919 --> 00:03:13.520
<v Speaker 2>can monitor, like permissions for specific host groups. User roles

63
00:03:13.560 --> 00:03:16.319
<v Speaker 2>control how they interact with zabex their UI access. So

64
00:03:16.319 --> 00:03:19.080
<v Speaker 2>you could have say a user plus role for folks

65
00:03:19.080 --> 00:03:20.840
<v Speaker 2>who just need to read only access but maybe need

66
00:03:20.879 --> 00:03:22.159
<v Speaker 2>to see specific reports more.

67
00:03:22.280 --> 00:03:25.719
<v Speaker 1>Is this basic stuff that granularity sounds essential? Okay? Now,

68
00:03:25.759 --> 00:03:28.080
<v Speaker 1>something that sounds like a huge time saver, especially for

69
00:03:28.120 --> 00:03:32.080
<v Speaker 1>bigger places, advanced authentication and this just in time provisioning

70
00:03:32.159 --> 00:03:35.319
<v Speaker 1>JT right. Lots of companies use external off like SAMO

71
00:03:36.400 --> 00:03:41.159
<v Speaker 1>security search and markup language, or LDA lightweight directory access

72
00:03:41.159 --> 00:03:44.800
<v Speaker 1>protocol things like azured open Lda exactly.

73
00:03:45.199 --> 00:03:48.520
<v Speaker 2>And this is where zabox gets really smart. GIT user provisioning.

74
00:03:48.520 --> 00:03:51.120
<v Speaker 2>It came in six point four better now in seven

75
00:03:51.439 --> 00:03:54.919
<v Speaker 2>automatically creates users in zadas and it gives them the

76
00:03:55.000 --> 00:03:58.639
<v Speaker 2>right permissions based on their info from your ldapp or

77
00:03:58.680 --> 00:04:01.280
<v Speaker 2>SAMILL server. Think about the time that saves, no more

78
00:04:01.280 --> 00:04:05.039
<v Speaker 2>manual setup for every new person. It's a massive workflow boost.

79
00:04:05.439 --> 00:04:07.879
<v Speaker 2>And yeah, it works with the identity providers like Octa

80
00:04:07.960 --> 00:04:10.520
<v Speaker 2>one log in basically anything that speaks SAMI well. The

81
00:04:10.520 --> 00:04:14.159
<v Speaker 2>book also mentions API tokens quickly for scripting and integration.

82
00:04:14.240 --> 00:04:18.120
<v Speaker 2>Important point, there always limit permissions for API users in production.

83
00:04:18.319 --> 00:04:21.959
<v Speaker 1>Security first, okay, zabx is running. Users are managed securely.

84
00:04:22.000 --> 00:04:25.120
<v Speaker 1>Now the core job, how do we actually monitor stuff?

85
00:04:25.199 --> 00:04:27.079
<v Speaker 1>Zabix seven has a whole bunch of ways to do this.

86
00:04:27.160 --> 00:04:29.480
<v Speaker 1>Let's start with the classic, the Zavix agent right.

87
00:04:29.639 --> 00:04:32.759
<v Speaker 2>The agent two main modes, passive and active. Passive means

88
00:04:32.800 --> 00:04:35.160
<v Speaker 2>the server asks the agent for data. Active means the

89
00:04:35.160 --> 00:04:37.040
<v Speaker 2>agent collects data and sends it to the server. The

90
00:04:37.120 --> 00:04:39.439
<v Speaker 2>key thing. Active mode is often way more efficient. It

91
00:04:39.480 --> 00:04:41.360
<v Speaker 2>pushes the load out to the agents. You can use

92
00:04:41.360 --> 00:04:43.800
<v Speaker 2>both at the same time, which gives you flexibility. Plus,

93
00:04:44.000 --> 00:04:47.240
<v Speaker 2>Zavix Agent two adds even more capability, especially for certain

94
00:04:47.279 --> 00:04:48.120
<v Speaker 2>apps and.

95
00:04:48.160 --> 00:04:51.360
<v Speaker 1>For network gear. SNMP's been around forever, but I hear

96
00:04:51.480 --> 00:04:53.040
<v Speaker 1>the old way of polling has had a bit of

97
00:04:53.040 --> 00:04:53.639
<v Speaker 1>an overhaul.

98
00:04:53.759 --> 00:04:56.079
<v Speaker 2>Yeah, the old way still works fine, but since Zabik

99
00:04:56.120 --> 00:04:59.120
<v Speaker 2>six point four there's a much better approach. Zavix can

100
00:04:59.120 --> 00:05:02.319
<v Speaker 2>now use SMMP key bulk queries using the walk item key.

101
00:05:02.519 --> 00:05:05.480
<v Speaker 2>It's way more efficient, puts less strain on your network devices.

102
00:05:05.600 --> 00:05:07.560
<v Speaker 2>You get more data with less impact. Oh and a

103
00:05:07.560 --> 00:05:10.639
<v Speaker 2>big plus and seven point zero asynchronous polling for Agent

104
00:05:10.839 --> 00:05:14.360
<v Speaker 2>HGDP SNMP means Zavix can run tons of checks at

105
00:05:14.399 --> 00:05:17.519
<v Speaker 2>the same time per polar process way more scalable. We

106
00:05:17.560 --> 00:05:20.639
<v Speaker 2>still use OIDs object identifiers like addresses for metrics like

107
00:05:20.639 --> 00:05:22.480
<v Speaker 2>one point three point one point one point one point

108
00:05:22.519 --> 00:05:24.759
<v Speaker 2>two zeros ever two one point four for memory.

109
00:05:24.480 --> 00:05:27.040
<v Speaker 1>Stuff for instance, okay, Agent's sm MP. What about more

110
00:05:27.040 --> 00:05:29.759
<v Speaker 1>specialized things checking specific services, apps, databases?

111
00:05:29.879 --> 00:05:32.199
<v Speaker 2>Zaviks has loads of options there. You've got simple checks

112
00:05:32.279 --> 00:05:35.040
<v Speaker 2>just as an SSH port open stuff like that. Then

113
00:05:35.079 --> 00:05:37.759
<v Speaker 2>there's the Zavix Trapper, which you use as Zavic sender.

114
00:05:38.240 --> 00:05:41.759
<v Speaker 2>Great for customs. Script sending data in calculated independent items

115
00:05:41.800 --> 00:05:44.519
<v Speaker 2>are cool too. You can create new metrics from existing ones,

116
00:05:44.560 --> 00:05:47.319
<v Speaker 2>like average memory use over an hour or pulling one

117
00:05:47.319 --> 00:05:50.079
<v Speaker 2>specific value out of a bigger chunk of data. For

118
00:05:50.199 --> 00:05:53.160
<v Speaker 2>Java apps, there's built in JMX monitoring, perfect for things

119
00:05:53.240 --> 00:05:56.040
<v Speaker 2>like Tomcat. You can even run the Java Gateway bit

120
00:05:56.079 --> 00:05:57.879
<v Speaker 2>on a separate machine if you need to scale it.

121
00:05:58.480 --> 00:06:02.319
<v Speaker 2>Database monitoring uses odp VC open database connectivity, so you

122
00:06:02.360 --> 00:06:05.519
<v Speaker 2>can basically monitor any database that supports it. Just watch

123
00:06:05.600 --> 00:06:09.279
<v Speaker 2>performance sometimes. Agent two also does native monitoring for some

124
00:06:09.399 --> 00:06:12.600
<v Speaker 2>dbs and the HTTP agent lets you monitor websites or

125
00:06:12.600 --> 00:06:16.519
<v Speaker 2>APIs directly grab data from adjasent endpoint, track a version number,

126
00:06:16.639 --> 00:06:17.279
<v Speaker 2>whatever you need.

127
00:06:17.360 --> 00:06:19.480
<v Speaker 1>All right, now for something that sounds really new and

128
00:06:19.959 --> 00:06:23.480
<v Speaker 1>potentially game changing in ZABI seven these browser items. What's

129
00:06:23.519 --> 00:06:24.199
<v Speaker 1>the deal there?

130
00:06:24.480 --> 00:06:26.240
<v Speaker 2>Oh yeah, this is really cool. It's brand new and

131
00:06:26.319 --> 00:06:30.319
<v Speaker 2>zabq seven Basically, it lets you simulate a real user

132
00:06:30.360 --> 00:06:35.360
<v Speaker 2>interacting with a web application. I think navigating pages, clicking buttons,

133
00:06:35.399 --> 00:06:40.120
<v Speaker 2>filling out forms, all automated using JavaScript and Selenium. Why

134
00:06:40.199 --> 00:06:43.199
<v Speaker 2>is it so powerful? Well, it opens up like endless

135
00:06:43.199 --> 00:06:46.959
<v Speaker 2>possibilities for monitoring the actual end user experience. You can

136
00:06:46.959 --> 00:06:50.040
<v Speaker 2>measure things like logging times, or grab specific data from

137
00:06:50.079 --> 00:06:53.040
<v Speaker 2>a rendered web page that a simple HTTP check could

138
00:06:53.079 --> 00:06:55.079
<v Speaker 2>never see because it doesn't run JavaScript.

139
00:06:55.199 --> 00:06:58.759
<v Speaker 1>Wow, okay, that sounds incredibly useful. Can you give like

140
00:06:59.120 --> 00:06:59.879
<v Speaker 1>a practical exam?

141
00:07:00.319 --> 00:07:03.160
<v Speaker 2>Sure? Imagine setting up a browser item that logs into

142
00:07:03.160 --> 00:07:07.120
<v Speaker 2>your web app, clicks through to say reports than system information,

143
00:07:07.399 --> 00:07:09.600
<v Speaker 2>and then it grabs values right off that page, maybe

144
00:07:09.800 --> 00:07:13.199
<v Speaker 2>required server performance or number of active hosts, stuff like that.

145
00:07:13.240 --> 00:07:15.480
<v Speaker 2>It gives you insight you just couldn't get before. Yeah,

146
00:07:15.519 --> 00:07:17.920
<v Speaker 2>and then to make sense of that raw data, you extract.

147
00:07:18.160 --> 00:07:20.879
<v Speaker 2>You use Zabas's pre processing that lets you clean up

148
00:07:20.959 --> 00:07:23.399
<v Speaker 2>or transform the data before it's stored, like using a

149
00:07:23.439 --> 00:07:25.600
<v Speaker 2>rejex to pull out just the number of bytes received

150
00:07:25.600 --> 00:07:28.800
<v Speaker 2>from network interface output. It turns raw data into useful

151
00:07:28.839 --> 00:07:30.120
<v Speaker 2>metrics you can actually grasp.

152
00:07:30.399 --> 00:07:33.600
<v Speaker 1>Okay, so we're collecting all this amazing data. Browser data included.

153
00:07:34.240 --> 00:07:38.519
<v Speaker 1>Next up making sure we get alerted smartly triggers and

154
00:07:38.639 --> 00:07:42.160
<v Speaker 1>effective notifications. That's key, right, and I hear for people

155
00:07:42.240 --> 00:07:45.079
<v Speaker 1>used to older Zavix, say five point two or before

156
00:07:45.439 --> 00:07:47.319
<v Speaker 1>the trigger syntax change quite a bit.

157
00:07:47.600 --> 00:07:50.279
<v Speaker 2>Yeah, that's a really important point since Saba's five point four.

158
00:07:50.439 --> 00:07:54.360
<v Speaker 2>The syntax is quite different. It's much more cohesive now.

159
00:07:54.360 --> 00:07:56.800
<v Speaker 2>It starts with the function name than the host or

160
00:07:56.920 --> 00:08:00.720
<v Speaker 2>template and brackets and uses forward slashes. It's way clearer

161
00:08:00.759 --> 00:08:03.279
<v Speaker 2>than the old style with colon's and dots, which could

162
00:08:03.319 --> 00:08:06.240
<v Speaker 2>get confusing, especially when item keys also add dots in them.

163
00:08:06.720 --> 00:08:09.319
<v Speaker 1>Makes sense, and beyond just syntax, are there some more

164
00:08:09.360 --> 00:08:12.120
<v Speaker 1>advanced trigger functions now that let you do smarter analysis?

165
00:08:12.519 --> 00:08:16.199
<v Speaker 2>Definitely? There are functions like trendo X. This one uses

166
00:08:16.279 --> 00:08:19.879
<v Speaker 2>trend data that's the hourly average MEN or max instead

167
00:08:19.879 --> 00:08:22.480
<v Speaker 2>of just raw history data points, so is better for

168
00:08:22.600 --> 00:08:25.600
<v Speaker 2>longer term analysis, like looking at average memory use over

169
00:08:25.600 --> 00:08:28.279
<v Speaker 2>a whole week, ignoring little spikes. Then there's time left.

170
00:08:28.439 --> 00:08:31.399
<v Speaker 2>This is really cool. It's predictive. Zabix can actually predict

171
00:08:31.399 --> 00:08:33.720
<v Speaker 2>when a metric like disk space is going to hit

172
00:08:33.759 --> 00:08:37.480
<v Speaker 2>a critical threshold, say predictably full within seven days. Gives

173
00:08:37.519 --> 00:08:39.519
<v Speaker 2>you time to react before it happens, and you could

174
00:08:39.519 --> 00:08:42.440
<v Speaker 2>do time shifting to compare current values to past ones

175
00:08:42.960 --> 00:08:45.600
<v Speaker 2>as things like is memory twenty percent lower now than

176
00:08:45.639 --> 00:08:48.440
<v Speaker 2>last week? It can get complex, but it's super powerful

177
00:08:48.440 --> 00:08:49.360
<v Speaker 2>for spawning trends.

178
00:08:49.480 --> 00:08:53.080
<v Speaker 1>Okay, powerful triggers, but the goal is useful alerts, not

179
00:08:53.200 --> 00:08:55.559
<v Speaker 1>just noise. Right, how do you stop getting spammed?

180
00:08:55.639 --> 00:08:59.879
<v Speaker 2>It's exactly It's about informing, not overwhelming. First you said

181
00:08:59.919 --> 00:09:03.559
<v Speaker 2>up actions like notify zabx admins. Then you pick your

182
00:09:03.559 --> 00:09:07.360
<v Speaker 2>media types email, slack teams, telegram, ops, genie, whatever you use.

183
00:09:07.799 --> 00:09:11.240
<v Speaker 2>The really crucial part is customizing the messages. Keep trigger

184
00:09:11.320 --> 00:09:14.240
<v Speaker 2>names clear and short, don't stuff macros in the name itself.

185
00:09:14.559 --> 00:09:17.600
<v Speaker 2>Then customize the message templates for each media type or

186
00:09:17.639 --> 00:09:19.519
<v Speaker 2>action so you only get the info you actually need

187
00:09:19.559 --> 00:09:21.519
<v Speaker 2>to act on. It means you need to plan your trigger.

188
00:09:21.600 --> 00:09:25.200
<v Speaker 2>Structures and tagging tags became important in ZABK six. Carefully

189
00:09:25.399 --> 00:09:27.639
<v Speaker 2>to keep everything organized and effective.

190
00:09:27.320 --> 00:09:30.120
<v Speaker 1>Right, collect the data, get smart alerts now making it

191
00:09:30.159 --> 00:09:33.879
<v Speaker 1>all visually clear. Visualization ZABAK seems pretty strong here. Starting

192
00:09:33.879 --> 00:09:34.759
<v Speaker 1>with basic graphs.

193
00:09:35.000 --> 00:09:37.639
<v Speaker 2>Yeah, graphs are your bread and butter for showing single

194
00:09:37.679 --> 00:09:41.279
<v Speaker 2>item values over time, uptime, CPU, network, traffic, you name it.

195
00:09:41.799 --> 00:09:45.799
<v Speaker 2>Quick tip, think about colorblind friendly colors. Make them usable

196
00:09:45.799 --> 00:09:49.279
<v Speaker 2>for everyone. Beyond graphs, you've got maps. These are great

197
00:09:49.320 --> 00:09:52.200
<v Speaker 2>for showing how devices connect. And here's a neat trick.

198
00:09:52.759 --> 00:09:55.960
<v Speaker 2>Map labels can show live data like traffic stats and

199
00:09:56.080 --> 00:09:58.600
<v Speaker 2>link colors can change based on trigger, so link goes

200
00:09:58.639 --> 00:10:01.039
<v Speaker 2>red if it's down. You could even set a trigger

201
00:10:01.039 --> 00:10:03.559
<v Speaker 2>for high usage, maybe to spot a d DAS attack early.

202
00:10:03.720 --> 00:10:06.240
<v Speaker 1>And for pulling everything together that big picture of view.

203
00:10:06.399 --> 00:10:07.639
<v Speaker 1>Dashboards are the way to go.

204
00:10:07.919 --> 00:10:11.399
<v Speaker 2>Oh absolutely, dashboards are perfect for consolidating everything you need

205
00:10:11.559 --> 00:10:15.039
<v Speaker 2>for troubleshooting, for daily checks for those big TV screens.

206
00:10:15.039 --> 00:10:18.759
<v Speaker 2>In the NOC, ZABK seven point zero really doubled down

207
00:10:18.799 --> 00:10:21.879
<v Speaker 2>on visualization, adding lots of new widgets. You've got widget

208
00:10:21.960 --> 00:10:25.919
<v Speaker 2>for problems, maps, grafts, specific item values, gauges, pie charts,

209
00:10:26.320 --> 00:10:28.720
<v Speaker 2>loads of options. You can even have multiple pages in

210
00:10:28.759 --> 00:10:31.600
<v Speaker 2>one dashboard, like an overview page and then a detailed

211
00:10:31.639 --> 00:10:36.000
<v Speaker 2>host data page. And speaking of overviews, zabs can automatically

212
00:10:36.039 --> 00:10:39.840
<v Speaker 2>pull inventory data, hardware, software versions, serial numbers. Keeps your

213
00:10:39.840 --> 00:10:42.480
<v Speaker 2>asset list up to date automatically, which leads to another

214
00:10:42.559 --> 00:10:46.120
<v Speaker 2>cool visualization, the geomap widget. It puts your hosts on

215
00:10:46.159 --> 00:10:49.480
<v Speaker 2>a world map showing their status using the latitude longitude

216
00:10:49.519 --> 00:10:51.759
<v Speaker 2>from inventory. Pretty neat addition to your dashboard.

217
00:10:51.919 --> 00:10:54.720
<v Speaker 1>And what about reporting keeping track of the Zabic system

218
00:10:54.720 --> 00:10:56.559
<v Speaker 1>itself and getting regular summaries out?

219
00:10:56.799 --> 00:10:59.720
<v Speaker 2>Yeah, good point. There's a system information report to quickly

220
00:10:59.759 --> 00:11:03.159
<v Speaker 2>check Zavic's own health. The audit log is crucial at

221
00:11:03.200 --> 00:11:07.320
<v Speaker 2>tracks who changed what in Zab's essential for accountability, and

222
00:11:07.440 --> 00:11:10.279
<v Speaker 2>the action log shows if your alert notifications actually went

223
00:11:10.320 --> 00:11:13.759
<v Speaker 2>out successfully. A really popular feature since five point four

224
00:11:13.799 --> 00:11:17.639
<v Speaker 2>actually is scheduled pdf reports. Zabax can take snapshot images

225
00:11:17.639 --> 00:11:19.879
<v Speaker 2>of any dashboard you've built and email it out as

226
00:11:19.879 --> 00:11:23.080
<v Speaker 2>a PDF on a schedule. Super flexible because any cool

227
00:11:23.080 --> 00:11:25.679
<v Speaker 2>new widget they add you can immediately include in your

228
00:11:25.720 --> 00:11:26.559
<v Speaker 2>PDF reports.

229
00:11:26.879 --> 00:11:31.039
<v Speaker 1>Okay, shifting gears a bit, large environments, dynamic systems automation

230
00:11:31.120 --> 00:11:34.639
<v Speaker 1>and scalability become absolutely critical. How does ZABK seven help there?

231
00:11:34.919 --> 00:11:36.840
<v Speaker 1>Starting with automatically adding new.

232
00:11:36.679 --> 00:11:39.600
<v Speaker 2>Hosts right, this is a huge strength. Zabx has several

233
00:11:39.600 --> 00:11:42.960
<v Speaker 2>ways to do discovery. Network discovery. Let ZABK scan ranges

234
00:11:43.000 --> 00:11:46.639
<v Speaker 2>for new devices using agent checks or SNMP It can

235
00:11:46.720 --> 00:11:50.639
<v Speaker 2>find hosts based on names, services, SNNP results and automatically

236
00:11:50.679 --> 00:11:53.399
<v Speaker 2>add them with the right templates and groups. Then there's

237
00:11:53.480 --> 00:11:56.879
<v Speaker 2>active agent audit registration. This is even more automatic. The

238
00:11:56.919 --> 00:12:00.360
<v Speaker 2>agent basically introduces itself to Zavix, maybe sending some metad data,

239
00:12:00.519 --> 00:12:02.960
<v Speaker 2>and Zavix adds it based on rules you set super

240
00:12:03.000 --> 00:12:06.080
<v Speaker 2>smooth for deploying lots of agents, and you've got low

241
00:12:06.159 --> 00:12:09.399
<v Speaker 2>level discovery LLD. That's for discovering specific things on a host,

242
00:12:09.679 --> 00:12:13.000
<v Speaker 2>like when does performance counters or JMX objects in Java apps,

243
00:12:13.320 --> 00:12:16.279
<v Speaker 2>It finds them and creates the monitoring items automatically. For

244
00:12:16.480 --> 00:12:20.000
<v Speaker 2>sn mpld again, that efficient walk key is used. Grab

245
00:12:20.039 --> 00:12:23.039
<v Speaker 2>bulk data, then use preprocessing to chop it up into

246
00:12:23.039 --> 00:12:23.919
<v Speaker 2>individual items.

247
00:12:24.039 --> 00:12:26.720
<v Speaker 1>That sounds powerful. Now you mentioned something about using custom

248
00:12:26.840 --> 00:12:29.200
<v Speaker 1>Jason with LED that sounds incredibly flexible.

249
00:12:29.399 --> 00:12:32.519
<v Speaker 2>It really is. This shows just how extensible ZABS can be.

250
00:12:33.039 --> 00:12:35.159
<v Speaker 2>You could have an external script, maybe running as a

251
00:12:35.200 --> 00:12:38.720
<v Speaker 2>cron job, generate a JSON file with host info, send

252
00:12:38.720 --> 00:12:43.039
<v Speaker 2>that Jason to Zavix using zabxender, then configure led rules

253
00:12:43.039 --> 00:12:46.360
<v Speaker 2>in Zavix to read that Jason and automatically creator update

254
00:12:46.399 --> 00:12:49.240
<v Speaker 2>hosts and interfaces based on it. It's perfect for integrating

255
00:12:49.240 --> 00:12:53.440
<v Speaker 2>with external inventory systems or cndbs. But when you're talking

256
00:12:53.440 --> 00:12:58.279
<v Speaker 2>true scale, especially across networks, Zavix proxies are essential proxy's right.

257
00:12:58.519 --> 00:13:01.320
<v Speaker 1>They collect data locally and forward it, reducing load on

258
00:13:01.360 --> 00:13:03.720
<v Speaker 1>the main server. I hear they've got some major reliability

259
00:13:03.759 --> 00:13:05.320
<v Speaker 1>upgrades too, huge upgrades.

260
00:13:05.600 --> 00:13:09.440
<v Speaker 2>Proxies themselves collect data remotely, taking load off the central server.

261
00:13:09.720 --> 00:13:12.480
<v Speaker 2>Can be passive or active. But the big news is

262
00:13:12.639 --> 00:13:15.720
<v Speaker 2>proxy high availability and load balancing. Now you can have

263
00:13:15.759 --> 00:13:18.279
<v Speaker 2>a group of proxies working together. They share the load

264
00:13:18.279 --> 00:13:21.519
<v Speaker 2>of monitoring hosts in that location, and if one proxy fails,

265
00:13:21.639 --> 00:13:24.879
<v Speaker 2>the others pick up its workload. For big distributed setups,

266
00:13:24.960 --> 00:13:28.039
<v Speaker 2>this is a massive improvement. Makes Zavix truly enterprise ready

267
00:13:28.080 --> 00:13:29.080
<v Speaker 2>and highly reliable.

268
00:13:29.279 --> 00:13:33.360
<v Speaker 1>Okay, so we've got this potentially huge, automated, scaled out

269
00:13:33.480 --> 00:13:37.120
<v Speaker 1>Zavix setup. How do we maintain it? And keep it secure.

270
00:13:37.440 --> 00:13:39.200
<v Speaker 1>Let's talk maintenance periods. First.

271
00:13:39.720 --> 00:13:41.720
<v Speaker 2>Essential for planned work, you set up windows in the

272
00:13:41.720 --> 00:13:44.720
<v Speaker 2>front end, say every Sunday morning, to stop alerts firing

273
00:13:44.720 --> 00:13:47.559
<v Speaker 2>while you're doing updates. Zavic seven made these much faster

274
00:13:47.679 --> 00:13:49.840
<v Speaker 2>to take effect near instant. They call it because they

275
00:13:49.879 --> 00:13:52.799
<v Speaker 2>can pig cash reloads quicker. You can choose with data collection,

276
00:13:53.039 --> 00:13:56.279
<v Speaker 2>which just suppresses alerts, or no data collection, which stops

277
00:13:56.320 --> 00:13:59.200
<v Speaker 2>everything for that host during maintenance and for upgrades. The

278
00:13:59.240 --> 00:14:02.919
<v Speaker 2>book hammers this back up. First read the release notes carefully.

279
00:14:03.799 --> 00:14:06.200
<v Speaker 2>A key thing for Zavic seven is you must upgrade

280
00:14:06.240 --> 00:14:09.320
<v Speaker 2>the underlying stack. Two PHP needs to be eight point

281
00:14:09.399 --> 00:14:11.840
<v Speaker 2>two or eight point three plus normi dB needs to

282
00:14:11.840 --> 00:14:14.279
<v Speaker 2>be eleven point four plus dep That catches people out.

283
00:14:14.320 --> 00:14:15.799
<v Speaker 2>So the cookbook really helps there and.

284
00:14:15.919 --> 00:14:19.279
<v Speaker 1>Keeping it running smoothly. Performance tuning. What are the common bottlenecks?

285
00:14:19.519 --> 00:14:23.559
<v Speaker 2>Well, you might see Zavis complaining about discoverer processes too busy.

286
00:14:24.399 --> 00:14:26.360
<v Speaker 2>You can usually fix that by tweaking the number of

287
00:14:26.360 --> 00:14:30.000
<v Speaker 2>discoverer processes in the server config file. More processes help

288
00:14:30.039 --> 00:14:33.240
<v Speaker 2>distribute the work, but you're limited by server resources. Obviously,

289
00:14:33.840 --> 00:14:36.559
<v Speaker 2>Sometimes it's just a bag and fig causing the bottleneck. Though,

290
00:14:37.120 --> 00:14:40.879
<v Speaker 2>the Zavix Housekeeper, which cleans up old data, also needs tuning.

291
00:14:41.519 --> 00:14:43.720
<v Speaker 2>Adjusting how often it runs and how much it deletes

292
00:14:43.759 --> 00:14:47.039
<v Speaker 2>per run is important, but the best settings really depend

293
00:14:47.080 --> 00:14:49.799
<v Speaker 2>on your specific setup, how much data you collect and

294
00:14:49.879 --> 00:14:54.399
<v Speaker 2>keep for the database itself, specifically Micequel, the book recommends

295
00:14:54.399 --> 00:14:57.679
<v Speaker 2>a tool called mice call Tuner dot pl. It's an

296
00:14:57.720 --> 00:15:00.679
<v Speaker 2>open source script that analyzes your dB and suggests can

297
00:15:00.720 --> 00:15:03.919
<v Speaker 2>fig changes. But, and this is important, don't just blindly

298
00:15:03.919 --> 00:15:07.200
<v Speaker 2>apply it suggestions. Always research what each parameter does and

299
00:15:07.320 --> 00:15:09.440
<v Speaker 2>understand the implications before changing anything.

300
00:15:10.000 --> 00:15:13.200
<v Speaker 1>And for really big databases where even tuning the Housekeeper

301
00:15:13.240 --> 00:15:14.080
<v Speaker 1>isn't enough.

302
00:15:13.960 --> 00:15:16.399
<v Speaker 2>Right for huge amounts of history and trend data, you

303
00:15:16.480 --> 00:15:19.840
<v Speaker 2>need more advanced techniques. With my sequel, you can use

304
00:15:19.919 --> 00:15:25.000
<v Speaker 2>database partitioning. Zabx supports this. Instead of deleting old data

305
00:15:25.080 --> 00:15:27.639
<v Speaker 2>row by row, which is slow, you just drop entire

306
00:15:27.679 --> 00:15:32.480
<v Speaker 2>old partitions, much much faster for housekeeping. If you're using postcresscool,

307
00:15:32.759 --> 00:15:36.759
<v Speaker 2>zabx supports the timescale DT extension. It's specifically designed for

308
00:15:36.840 --> 00:15:39.440
<v Speaker 2>time series data like zadex generates, and it can give

309
00:15:39.519 --> 00:15:44.120
<v Speaker 2>significant performance boosts on large databases. But beyond performance, security

310
00:15:44.200 --> 00:15:47.799
<v Speaker 2>is critical, especially for the database connection. You absolutely should

311
00:15:47.840 --> 00:15:50.639
<v Speaker 2>encrypt the communication between the Zaba server, the front end,

312
00:15:50.879 --> 00:15:55.200
<v Speaker 2>and the database using SSLTLS certificates like from open SSL.

313
00:15:55.559 --> 00:15:58.440
<v Speaker 2>It adds a vital security layer protecting against data snooping

314
00:15:58.440 --> 00:16:00.600
<v Speaker 2>on the network. It's a bit complex to set up

315
00:16:00.600 --> 00:16:03.960
<v Speaker 2>certificates configs, but essential for production. The book notes that

316
00:16:04.000 --> 00:16:06.799
<v Speaker 2>pretty much all Zavix communication can be encrypted except for

317
00:16:06.840 --> 00:16:10.000
<v Speaker 2>the direct link between the server and front end WebUI itself.

318
00:16:10.159 --> 00:16:13.559
<v Speaker 1>Okay, last big area. Zabx isn't just for on premise

319
00:16:13.600 --> 00:16:16.039
<v Speaker 1>servers anymore, right, How does it handle cloud stuff in

320
00:16:16.120 --> 00:16:17.799
<v Speaker 1>extending beyond basic monitoring.

321
00:16:18.000 --> 00:16:20.279
<v Speaker 2>Yeah, it's very much cloud aware. Now you can monitor

322
00:16:20.320 --> 00:16:24.519
<v Speaker 2>AWS and Azure directly. For AWS, you typically use HTTP

323
00:16:24.679 --> 00:16:29.080
<v Speaker 2>agents with some JavaScript to call awsapis like cloud Watch.

324
00:16:29.559 --> 00:16:32.919
<v Speaker 2>You can discover and monitor EC two instances, RDS, databases,

325
00:16:33.080 --> 00:16:36.240
<v Speaker 2>S three buckets, lots more. Same idea. For Azure, use

326
00:16:36.279 --> 00:16:40.639
<v Speaker 2>API calls to discover and monitor Azure resources Cosmos, dbseql, VMS,

327
00:16:40.679 --> 00:16:43.080
<v Speaker 2>et cetera. The key thing is these templates and scripts

328
00:16:43.120 --> 00:16:45.440
<v Speaker 2>are just starting points. You can extend them to grab

329
00:16:45.480 --> 00:16:48.600
<v Speaker 2>basically any metric available via the cloud provider's API. Oh

330
00:16:48.600 --> 00:16:51.120
<v Speaker 2>and doctor monitoring is much simpler now too, Using built

331
00:16:51.159 --> 00:16:53.519
<v Speaker 2>in zabx agent two plugins pretty much works out of

332
00:16:53.559 --> 00:16:53.960
<v Speaker 2>the box.

333
00:16:54.080 --> 00:16:56.120
<v Speaker 1>And what if you want to integrate zabex even more

334
00:16:56.120 --> 00:16:58.759
<v Speaker 1>deeply custom scripts interacting with the API.

335
00:16:59.159 --> 00:17:02.919
<v Speaker 2>The ZAVIXAP is your friend here. It's really powerful. You

336
00:17:02.960 --> 00:17:06.799
<v Speaker 2>can script interactions using Python, PowerShell, whatever you like. The

337
00:17:06.839 --> 00:17:10.000
<v Speaker 2>book gives a great practical example using a Python script

338
00:17:10.039 --> 00:17:13.160
<v Speaker 2>to queratey the ZAVISAPI for host names and ips. Then

339
00:17:13.200 --> 00:17:16.119
<v Speaker 2>the script automatically updates the echo's file on a central

340
00:17:16.240 --> 00:17:19.559
<v Speaker 2>jump post so you can easily SSH to any monitored

341
00:17:19.599 --> 00:17:23.960
<v Speaker 2>machine by name Superrandy. Another cool API example a script

342
00:17:24.000 --> 00:17:26.720
<v Speaker 2>that lets you enable or disable monitoring for a host

343
00:17:26.799 --> 00:17:29.920
<v Speaker 2>directly by clicking on it in a zabs map Interactive

344
00:17:29.920 --> 00:17:33.599
<v Speaker 2>control and you often find scripts like these shared in

345
00:17:33.640 --> 00:17:36.400
<v Speaker 2>the Zavix community. It's a very active open source project,

346
00:17:36.559 --> 00:17:38.240
<v Speaker 2>so it's worth exploring what others have built.

347
00:17:38.279 --> 00:17:40.960
<v Speaker 1>Wow. Okay, that was quite the journey through ZABK seven

348
00:17:41.000 --> 00:17:44.119
<v Speaker 1>from the core bits user management, all those monitoring methods

349
00:17:44.279 --> 00:17:48.200
<v Speaker 1>through browser items, smart alert's visualization, automation, scaling, maintenance, security,

350
00:17:48.200 --> 00:17:51.680
<v Speaker 1>cloud covered a lot. This cookbook really does seem packed

351
00:17:51.680 --> 00:17:54.440
<v Speaker 1>with practical advice, and hopefully this deep dive gives you

352
00:17:54.480 --> 00:17:57.359
<v Speaker 1>a solid handle on building robust, insightful monitoring.

353
00:17:57.599 --> 00:18:00.319
<v Speaker 2>Absolutely yeah, you should now have a really good feel

354
00:18:00.400 --> 00:18:03.359
<v Speaker 2>for what zabk seven offers, whether you're just starting out

355
00:18:03.440 --> 00:18:05.400
<v Speaker 2>or looking to get more out of your existing setup.

356
00:18:05.599 --> 00:18:07.960
<v Speaker 2>It's a seriously capable platform, it.

357
00:18:08.000 --> 00:18:11.039
<v Speaker 1>Really seems like it. In a world just drowning in data.

358
00:18:11.119 --> 00:18:13.519
<v Speaker 1>ZABK seven gives you the tools not just to collect it,

359
00:18:13.559 --> 00:18:16.319
<v Speaker 1>but to actually understand it, build a story about your

360
00:18:16.319 --> 00:18:20.759
<v Speaker 1>infrastructure's health, predict problems, maybe even control things directly. So

361
00:18:20.839 --> 00:18:23.960
<v Speaker 1>the question for you is what hidden stories are waiting

362
00:18:23.960 --> 00:18:26.240
<v Speaker 1>in your data and how can zabik seven help you

363
00:18:26.440 --> 00:18:28.240
<v Speaker 1>write a better ending for your system