Speaker 1: Welcome back to the deep dive. We're here to give
Speaker 1: you that fast track, that real expertise on the industries
Speaker 1: well most critical topics. That's the plan, and today we
Speaker 1: are really diving deep our mission mastering modern IT infrastructure monitoring. Yeah,
Speaker 1: and our guide for this is some really comprehensive material
Speaker 1: compiled from the zabx five IT Infrastructure Monitoring pickbook right
Speaker 1: and for.
Speaker 2: You listening in, the goal here is simple, a complete,
Speaker 2: but you know, fast understanding of zabix five.
Speaker 3: Architecture cutting through the noise exactly.
Speaker 2: We're focusing on the core structure, the advanced ways it
Speaker 2: grabs data and crucially how to scale it. Everything you
Speaker 2: really need for a robust setup.
Speaker 1: And that timing on this couldn't be better really, zabx
Speaker 1: five it's an LTS release, long term support. Companies bet
Speaker 1: their infrastructure health on this for years. So getting these
Speaker 1: fundamentals right right now super critical.
Speaker 2: Absolutely.
Speaker 1: Okay, So let's unpack this a bit. What are the
Speaker 1: absolute foundational bits needed to just make as run and
Speaker 1: maybe more importantly, what's that single essential metric, the one
Speaker 1: thing that tells you if your serious monitoring setup can
Speaker 1: actually handle the load. You're throwing at it.
Speaker 2: Right. Architecturally, zabx needs three core components. They're constantly talking
Speaker 2: three main parts. Yeah, you've got the Zavic server. That's
Speaker 2: the central brain doing the polling, the processing.
Speaker 1: Got it.
Speaker 3: The engine the engine.
Speaker 2: Then the database usually Maria dB, maybe Postgres. Well, that's
Speaker 2: the huge repository for all your time series data. It
Speaker 2: gets big.
Speaker 3: The data store exactly.
Speaker 2: And finally the zabex front end. That's the WebUI you
Speaker 2: interact with, served up by Apache or NGI NX typically.
Speaker 1: So engine, data store, dashboard makes sense. Now, before we
Speaker 1: get into performance, where does a listener actually find all
Speaker 1: these metrics and settings we're about to talk about.
Speaker 2: Good point that dashboard. The front end its structured pretty clearly.
Speaker 2: When you log in, you see these main categories monitoring, inventory, reports,
Speaker 2: configuration and administration. Okay, all the key stuff we'll discuss today.
Speaker 2: It fits neatly into one of those five areas. Makes
Speaker 2: it easier to navigate. Now, that critical metric you asked about,
Speaker 2: the one that governs scale, that's.
Speaker 1: Nvps MVPs new values per second. Why is that number
Speaker 1: so incredibly important in a high volume system?
Speaker 2: Think of MVPs as the ingestion rate. It's the average
Speaker 2: number of new data points, new readings from your items
Speaker 2: that the Zavik server is either receiving or requesting every single.
Speaker 3: Second, per second, wow, per second.
Speaker 2: It is absolutely the single best measure of the load
Speaker 2: on your server, both right now and what you can expect.
Speaker 1: So it predicts the future almost.
Speaker 3: In a way.
Speaker 2: Yes, if you see that MVPs number climbing steadily, staying hi,
Speaker 2: that's your definitive signal. It tells you exactly when and
Speaker 2: how much you need to beef up your server's CPU
Speaker 2: and memory. Right, you ignore nvps at your own peril.
Speaker 1: Basically, Okay, message received. If MVPs is the heartbeat, let's
Speaker 1: talk about what we're actually feeding this engine. Monitoring isn't
Speaker 1: just about pings anymore. You need custom data, sometimes asynchronous stuff.
Speaker 1: How does zabx five give you that flexibility beyond just
Speaker 1: basic checks?
Speaker 2: Well, it starts the agent simple checks, like you know,
Speaker 2: is SSH port twenty two open? Those are still there, sure, But.
Speaker 1: The big shift is to Zavik's Agent two. It's written in.
Speaker 3: Go lang ah go okay, and that.
Speaker 1: Matters because Go natively handles concurrency and asynchronous tasks much better.
Speaker 1: The result a much lighter footprint on resources.
Speaker 2: Which is huge and containerized setups or just large virtual.
Speaker 3: Environments exactly invaluable.
Speaker 2: So that's the tech choice explained. But for really custom
Speaker 2: bespoke data, the sources talk a lot about this trapper mechanism.
Speaker 2: If agent two is so advanced, why do we need
Speaker 2: this separate trapper thing. Isn't that just adding complexity?
Speaker 1: It's a fair pultion. They serve slightly different roles, though
Speaker 1: the agent typically pulls on a set schedule right check
Speaker 1: this every sixty seconds. The trapper is for asynchronous data
Speaker 1: data that maybe comes from some external script on the
Speaker 1: host and you don't know exactly when it'll finish.
Speaker 2: Ah okay, like a long running job.
Speaker 1: Precisely, so, you set up a zabx trapper item on
Speaker 1: the server side. It just waits.
Speaker 2: Then on the host being monitored, you use the ZABC
Speaker 2: sender utility. That utility actively pushes the result, maybe from
Speaker 2: your complex Python script or cron job, straight to the
Speaker 2: server when the result is ready.
Speaker 1: So the server isn't asking, it's just listening for that
Speaker 1: specific data to.
Speaker 2: Arrive, exactly passive listening on the server, active sending from
Speaker 2: the host.
Speaker 1: That makes sense. It's the gateway for data that doesn't
Speaker 1: fit the regular polling schedule. Now here's where it seems
Speaker 1: to get really powerful. Though getting raw data is one thing,
Speaker 1: making it useful is another. Yeah, tell us about this
Speaker 1: preprocessing layer.
Speaker 2: Oh, preprocessing is an absolute game changer. It's data manipulation
Speaker 2: that happens before the value even lands.
Speaker 3: In the database, before storage. Okay, yes, and.
Speaker 2: Its main goal is efficiency. One way is using things
Speaker 2: like dependent.
Speaker 3: Items pendent item.
Speaker 2: Think of it like this. You make one single request
Speaker 2: to get say, a big chunk of status info a
Speaker 2: master item check right, then depend on items. Let you
Speaker 2: pull five specific metrics out of that single chunk of data,
Speaker 2: all for the cost of just one network call one
Speaker 2: interval check.
Speaker 1: Ah. So instead of five separate checks for CPU RAM
Speaker 1: disc uptime, you do one big check and peel off
Speaker 1: the bits.
Speaker 2: You need precisely. It saves a massive amount of overhead
Speaker 2: on the network in the agent.
Speaker 1: Okay, that's clever.
Speaker 2: And often that one big status check it dumps out
Speaker 2: just messy unstructured text. Think of the raw output from
Speaker 2: like if canfig on Linux run via system dot.
Speaker 1: Run yet tons of text?
Speaker 2: This is where what you called the rejecs hack comes in.
Speaker 2: You use preprocessing with a regular expression rejects to.
Speaker 3: Scan that raw text, find the pattern.
Speaker 2: And cleanly extract just the single number you care about,
Speaker 2: like total rx bites for interface ends one ninety two.
Speaker 2: You turn that text chaos into a clean, usable number
Speaker 2: right at the door.
Speaker 1: That's fantastic. It shifts the cleanup work away from the
Speaker 1: network into the server's processing, where it's more efficient. I
Speaker 1: think you remember another database tip related to this, something
Speaker 1: about duplicates.
Speaker 2: Yes, exactly, for values that don't change often, maybe a
Speaker 2: server serial number for a more version, that kind of
Speaker 2: thing that's static mostly right, you use the discard unchanged
Speaker 2: preprocessing step. If zavix gets the same value one hundred
Speaker 2: times in a row, it won't write one hundred identical
Speaker 2: entries into the database.
Speaker 1: Ah, so it just stores the first one and ignores
Speaker 1: the rest until it changes.
Speaker 3: Correct.
Speaker 2: This prevents just pointless bloating of your database over time.
Speaker 2: Super important for long term.
Speaker 1: Health, definitely. Okay, so we've collected and cleaned the data.
Speaker 1: Now we need to act on it. Alerting. We've all
Speaker 1: been there. The flapping alert goes critical then okay, then
Speaker 1: critical fifty times an hour floods your inbox. How does
Speaker 1: Zavix help stop that alert fatigue nightmare?
Speaker 2: The cure for that horror show is the recovery expression.
Speaker 2: Setting a simple trigger is easy CPU usage fifty percent
Speaker 2: trigger an alert.
Speaker 1: Right, and the naive setup recovers as soon as it
Speaker 1: hits forty nine percent.
Speaker 2: Exactly which to flapping. The recovery expression demands stability. You
Speaker 2: define a separate condition for the alert to clear, it
Speaker 2: has to move significantly away from the problem threshold.
Speaker 1: So like trigger a fifty percent, but only recover when
Speaker 1: it's back down to say forty percent.
Speaker 2: Pcisely that the system has to prove its stable and
Speaker 2: well clear of the danger zone before the alarm goes silent.
Speaker 1: That makes the alerts actually meaningful again.
Speaker 2: Nice, absolutely, and organizationally, you need structure too. Use tags
Speaker 2: from day one, AD service SSH or application billing to
Speaker 2: every related trigger so you.
Speaker 1: Can filter and rout alerts properly.
Speaker 2: Yes, and customize your severity levels. Don't stick with the
Speaker 2: defaults like disaster high warning. If your company uses P one,
Speaker 2: P two, P three, change the names in Zavik so
Speaker 2: the alerts immediately make sense in your team's context.
Speaker 1: Good practical tips. Now let's talk scaling. The actual architecture.
Speaker 1: MVPs tells us the load is high. But for medium, large,
Speaker 1: geographically dispersed environments, what's the component that handles spreading out
Speaker 1: that monitoring work.
Speaker 2: That's where zab's proxies come in. They are absolutely essential
Speaker 2: for offloading work from the central ZABK server.
Speaker 1: How do they do that?
Speaker 2: A proxy sits closer to the devices it monitors, maybe
Speaker 2: in a remote data center or a specific network segment.
Speaker 2: It collects data locally, holds on to it, maybe does
Speaker 2: some pre processing.
Speaker 1: Preprocessing can happen on the proxy too.
Speaker 2: Yes, some of it. Then it compresses that data and
Speaker 2: forwards it efficiently back to the main ZABC server. It
Speaker 2: reduces the load on the central server significantly.
Speaker 1: Okay, Now, when deploying these proxies, you've got firewalls, network segmentation.
Speaker 1: Are there different types performance trade offs?
Speaker 3: Yeah?
Speaker 2: There are two main modes, passive and active proxies. We
Speaker 2: strongly strongly recommend active proxies. Why active Two big reasons. First,
Speaker 2: they're generally faster because they proactively push their collected data
Speaker 2: to the server whenever they have new stuff. They don't
Speaker 2: wait to be asked.
Speaker 1: Okay, less latency, right.
Speaker 2: But second, and often more importantly, for network teams, an
Speaker 2: active proxy only needs one outbound connection and initiated from
Speaker 2: the proxy to the server.
Speaker 3: Uh so the proxy calls home exactly.
Speaker 2: Compare that to passive proxies, where the central server has
Speaker 2: to be able to initiate connections to potentially dozens or
Speaker 2: hundreds of proxies. Firewall rule nightmare.
Speaker 1: Definitely simplifying firewall management is a massive win in big companies. Okay,
Speaker 1: Sticking with operational wins, Yeah, let's hit the biggest maintenance
Speaker 1: headache for any monitoring system over time, the database. How
Speaker 1: do we stop it from becoming this unmanageable beast? Yeah?
Speaker 2: The database is always the challenge long term. The bottlenet
Speaker 2: comes from the default Zabas process called the housekeeper.
Speaker 1: Housekeeper sounds helpful, well.
Speaker 2: It tries to be. When data gets old. Say your
Speaker 2: history retention is ninety days, the housekeeper is responsible for
Speaker 2: deleting data older than that.
Speaker 3: Okay, seems necessary, but it deletes.
Speaker 2: That data roe bi row. Imagine millions, maybe billions of
Speaker 2: rows as your database grows into terabytes. This row by
Speaker 2: roe deletion just consumes immense IOCPU. Yeah, it can bring
Speaker 2: your server performance to its knees during cleanup OUCH.
Speaker 1: So relying on the built and cleaner eventually just grinds
Speaker 1: everything to a halt. What's the better way? The advanced solution?
Speaker 2: You absolutely need to move to database native methods. For
Speaker 2: my sqel, that's my Sqel partitioning. For postgrescul it's leveraging
Speaker 2: the timescale dB extension, which brings time series superpowers to.
Speaker 1: Postgross partitioning or timescale deb How do they avoid the
Speaker 1: row by row problem?
Speaker 2: They work with time based chunks instead of deleting individual rows.
Speaker 2: The database is structured so you can just drop an
Speaker 2: entire old partition, say delete all data from March instantly.
Speaker 1: Like throwing away a whole filing cabinet drawer instead of
Speaker 1: shredding each paper inside.
Speaker 2: Exactly that analogy. It's incredibly efficient. The cleanup becomes almost instantaneous,
Speaker 2: freeing up massive resources.
Speaker 1: That sounds like a no brainer from a performance perspective.
Speaker 1: But does switching to partitioning have any functional trade offs
Speaker 1: for the user? Configuring zavig it does.
Speaker 2: Yeah, that's the key planning points. You implement native partitioning
Speaker 2: your history and trend data retention settings often become global
Speaker 2: database parameters. You typically lose the ability to set say
Speaker 2: seven days history for this item, but ninety days for
Speaker 2: that item.
Speaker 1: Ah. So you gain huge efficiency, but lose some of
Speaker 1: that fine grain control over retention per item.
Speaker 2: That's the main trade off. You need to plan your
Speaker 2: retention strategy more globally.
Speaker 1: Got it important consideration? Okay, last, big area hybrid cloud.
Speaker 1: Lots of critical metrics now live in places like AWS,
Speaker 1: cloud Watch or Azure Monitor. How does zabix stay relevant?
Speaker 1: How does it pull data that's behind these proprietary cloud CLIs.
Speaker 2: Zabx uses a really powerful combo here, zabks agent user
Speaker 2: parameters plus the cloud provider's own CLI tools.
Speaker 1: Okay, so you can saw the awcli or the azurecli where.
Speaker 2: Right onto the same machine where the zabs Agent two
Speaker 2: is running. Could be an EC two instance, could be
Speaker 2: on prem machine that needs to query the cloud. Okay,
Speaker 2: then you can figure a user parameter within the Zavik's
Speaker 2: agent confis figuration. This user parameter basically just tells the
Speaker 2: agent run this specific AWSCLI command.
Speaker 1: The agent cs like a secure little proxy to run
Speaker 1: the cloud command locally precisely.
Speaker 2: The agent executes, the command, gets the output, maybe your
Speaker 2: sqsq depth or soupu utilization from cloud watch, and then
Speaker 2: it injects that value straight into Zavix. Like any other metric.
Speaker 1: It collected very flexible. Basically, if you can script it
Speaker 1: on the command line, zax can monitor it.
Speaker 2: That's the power of it. And for containers, Agent two
Speaker 2: makes it even easier. It has native plug ins for
Speaker 2: things like dock or monitoring built right in again thanks
Speaker 2: to that Go architecture.
Speaker 1: Okay, pulling it all together, then, what does this mean
Speaker 1: for you the listener? We've seen Zavix five is well,
Speaker 1: it's clearly robust, super flexible, scalable, designed for way more
Speaker 1: than just simple pings. It handles complex enterprise level stuff.
Speaker 3: Yeah.
Speaker 2: I think the key takeaway is that real control, real scalability.
Speaker 2: It requires planning upfront, especially especially around the database. You
Speaker 2: have to decide on partitioning or timescale dB early, don't
Speaker 2: wait to it hurts, don't wait till it hurts, and
Speaker 2: getting good at that data extraction using preprocessing. That's non
Speaker 2: negotiable if you want to keep your database clean and
Speaker 2: your metrics really trustworthy.
Speaker 1: Fantastic summary. Now, building on that idea, of platform control.
Speaker 1: We talked about how Agent two can execute commands to
Speaker 1: pull data. Yeah, but what about controlling Zavix itself. Here's
Speaker 1: a final thought. Even a user who's locked down to
Speaker 1: the basic Zavis user.
Speaker 2: Role, right, the most basic view only type role usually.
Speaker 1: Exactly they can maybe only see metrics for their own
Speaker 1: couple of hosts. Even that user can potentially execute powerful
Speaker 1: administrative actions, things like enabling or disabling host on maps
Speaker 1: or scheduling system maintenance periods. They can trigger these right
Speaker 1: from the Zavix front end.
Speaker 2: Wait, hang on a basic user doing admin tasks. How
Speaker 2: that sounds like a massive security hole if they don't
Speaker 2: have the actual permissions.
Speaker 1: It sounds like it, but it's actually the ultimate delegation
Speaker 1: power of the ZAVICSAPI. The trick is the script they
Speaker 1: trigger from the frontend. It isn't running with their lowly
Speaker 1: user permissions. Instead, that custom script you've set up is
Speaker 1: configured behind the scenes to use the API credentials of
Speaker 1: a different user, one who does have administrative privileges.
Speaker 2: So the low level user clicks a button, but the
Speaker 2: action is performed via the API using a high privileged
Speaker 2: token or user configured in that script.
Speaker 1: Exactly. It lets you safely delegate very specific, complex administrative
Speaker 1: workflows like putting a server into maintenance for exactly two
Speaker 1: hours starting now, to users who absolutely should not have
Speaker 1: general admin rights to the whole system.
Speaker 3: Wow.
Speaker 2: Okay, that is powerful the API as a controlled delegation mechanism.
Speaker 1: That's the raw, potent and highly customizable power hidden within
Speaker 1: the Zavix API. Food for thought. Definitely thanks for diving
Speaker 1: deep with us today. We really hope you feel better
Speaker 1: equipped now to tackle your infrastructure monitoring challenges using Zavix
Speaker 1: five