Best practices with Items and Triggers

[WebGreg]

Hi

Many items and triggers can appear on a given host. If you have a lot of hosts, you may be flooded with messages. What is your approach to this topic?

1. Do you leave everything or turn off everything unnecessary? For example, on one of the hosts I have a reported problem: "GoogleUpdaterService134.0.6985.0 is not running (startup type automatic)" Which basically doesn't really interest me. Do you turn off such things? Or, for example, disk monitoring - do you leave only a few basic information, or do you prefer to see literally every possible parameter that is available?
2. If you limit the amount of information - how? I can turn it off or remove it. If I turn it off for Item, the trigger will not fire even when it is turned on. Do you just turn it off or delete it? A couple or just a trigger? Only Item?
3. From what I noticed, although it is related to "Windows services discovery", changing it (e.g. disabling it) only works for a given host, and not globally on all hosts using "Windows services discovery", right?
4. All services are detected in Windows - do you leave it or clear it for clarity?

[Brambo]

1: that one comes from zabbix agent template which has include/ exclude regex macro to fine tune it to your working scenario.
2. depends if it's created by LLD or it's a template trigger or only host trigger. Trigger will only potentially fire if the trigger is enabled. When enabled depending on the conditions of the item(s) it can fire.
3. You can change template defaults on host level. When you have changed it on host level it's remembered on host level. If you want it on all host where you didn't do a manual override then change it in the template.
4. See point 1, in our own situation I have fine-tuned it to only show the services of our own software products as VM responsibility is that of the customer and so are the defaults windows services

[WebGreg]

4. See point 1, in our own situation I have fine-tuned it to only show the services of our own software products as VM responsibility is that of the customer and so are the defaults windows services

And this is valuable information. However, I am in a situation where I am responsible for both. On the one hand, I don't want to be triggered by various events very often, but on the other hand, limiting information only to key services raises my concerns - sometimes another service may cause the entire system to operate unstable.
Thank you for your answer Brambo . If anyone else has any thoughts, please feel free to join

[Brambo]

WebGreg don't be limited to your own thinking. Example the default discovery of services uses $Macro with matches and doesn't match and the Windows service discovery rule.
You could for example create additional macro for high priority services (or low or both) and create an additional rule where you make higher/lower priority triggers based on that. (don't forget to edit the existing discovery rule to filter out those new values for the new discovery)
You can really fine-tune it if you want to, but it's good to start slowly and notice what changes do.

[WebGreg]

Brambo As you rightly noticed - slowly. And that's what I do. I'm definitely not at the stage of creating my own macros. I rely on the predefined ones. So it's not about whether I can have more items - it's more about whether I can have less. And here I also know - yes, I can. I'm asking more - is it worth having less? This is a common disease of novices - they immediately start everything they can

An example is XDR - the system can trigger thousands of times a day. Recently I added exceptions, but again - if the intruder uses this particular attack vector, XDR will not fulfill its role. I asked how others do it and... they do not add exceptions, and they refer to the logs when an incident is recorded in order to analyze it. In my opinion, this is not entirely a good approach, because XDR is also supposed to have a preventive effect. But it is physically impossible to handle so many events, and then XDR does not fulfill its role too.
Right balance is important. I wonder what it looks like in the case of Zabbix.

[Brambo]

I don't know this XDR process but if it returns a certain value in good scenario let's say always 10 and it differs when something bad happend (a higher or lower value). But you don't want to trigger on 1 value then maybe trend functions are the way to approach it. OR if the value stays high/ low for a certain amount of time then you can do lets say AVG function for x time.
You could also combine it with lets say a logrt item which updates value on a certain regex hit in a log file/eventlog.
And you can even do this across multiple hosts. I wont say it's easy to setup but I have never run into something I couldn't build. But sometimes it did take a lot of trial and error to find the correct way.

[WebGreg]

In XDR you basically (in my opinion) have to check every entry. In this case, it triggers, for example, the execution of a script - you need to check what was included in this script. Sometimes the script is the same, but maybe someone without permission is using it. The trend won't help much here. Especially the attacker can use a specific procedure (script) only once to elevate privileges.

Today in Zabbix I disabled the "link down" triggers on the switch. I left only critical interfaces. In this situation the trend could be interesting - if, I see that an interface is down several dozen times a day, then something bad is happening there. Now I haven't this information.