Let’s continue to cover the innovations of Zabbix 3.4, shall we? This time, we’re going to talk about the use of macros in update intervals and other time periods.
- Couple of Words about Macros
- History Update and Storage Intervals
- Usage Scenarios
- Update Intervals and Collected Data Storage Time
- In Low-Level Discovery
- Where Else?
- So…
Couple of Words about Macros
User macros is a long-established mechanism used in Zabbix ubiquitously, giving the monitoring system the flexibility it needs. In fact, these are variables that you can assign with global visibility, a template or a host. The use of macros is strongly encouraged and recommended, for example in templates, which makes them customizable in other environments for other users.
The user macros look like this, and you probably have met them by now:
{$MACRO}
History Update and Storage Intervals
Zabbix allows you to flexibly configure the metric polling time: each metric can have its own interval.
Updates of each metric can also be “flexible” (see Custom Intervals), and therefore can occur on a specific schedule (“daily at night” or “at 9:00 am on weekdays”).
Similarly, we can determine the history and trend storage time for each item separately.
The fine-tuning like this is not always necessary, so the use of macros gives a couple of new ideas on how to configure these parameters.
Usage Scenarios
Update Intervals and Collected Data Storage Time
First, the metric update intervals (both normal and custom intervals), mentioned above, now support user macros. Secondly, they can be used in the history storage intervals and trends. The result? It looks like this:
Just set the values of these macros globally, and then reassign at the template or host level, if required:
In general, for update intervals, you can create a small global set of macros that are then used by default for all new items, depending on their type and importance. For instance:
This will let you not to waste your time thinking about “I want to collect this metric every 60 or 61 times per second or maybe 5 minutes will suffice?”, but simply use the rules for collecting and storing items that are fixed in global macros on your server and project. Although, perhaps, this option is not for everyone 🙂
In Low-Level Discovery
The macro context is also supported, which can be very useful, for example, with LLD.
Imagine we are collecting network interface traffic on multiple devices. In order not to put a burden onto Zabbix, we would like to do the following:
- key interfaces, trunks and other uplinks — take data every 1 minute, store history for 30 days, and trends — for 1 year.
- the remaining interfaces — poll every 5 minutes, store history for 3 days, and trends — for 1 month.
First, let’s define the global macros {$DELAY_IF}, {$HISTORY_IF}, {$TREND_IF}:
Then we use them in the item prototype of the interface but with the context (in this case it will be the name of the ifName interface):
Then, at the host level, we specify a new macro value with the context for the key interface (for example, we take Gi0/0.114):
Now let’s look at the refresh rate and storage time for the various interfaces in the “Latest Data”. As you can see, our very important Gi0/0.114 now has its own rules of storage and collection:
If we want to change the general interval or increase the polling frequency or the storage time of another interface, we will simply need to reassign the macros at the host level. You won’t need to change the template, prototype and wait for the discovery — everything will apply immediately. In fact, even write permissions to the template are not required.
Where Else?
Macros can now be used in other situations where it is necessary to specify the time or period. For example, in actions:
Or specify the availability time of the engineer for automatic notifications via the macro:
To see the exact list of scenarios where you can apply macros, check out this link.
So…
Let’s conclude! New features of macros in the 3.4 version open a couple of advantageous opportunities: on the one hand — for more fine-tuning (for LLD), and on the other hand — for centralizing and managing the time of polling and storage. By the way, time intervals now support suffixes s,m,h,d,w — a trifle, but pretty useful, isn’t it?
Stay tuned!
P.S. The article is also available in Russian.
P.S.S. Get acquainted with other Zabbix 3.4 features:
Hi,
I collect requests by traversing a log once a minute.
I need to convert these requests into req/s.
I suppose Change per second preprocessing doesn’t fit.
Is there a Zabbix way for that?
I’m not sure I know what number do you have.
If you count a total number of lines in the log every minute – then applyting ‘Change per second’ would give you req/s