Zabbix 3.4: Macros at time intervals

    Hey. We continue to cover the innovations of Zabbix 3.4. Today we’ll talk about the use of macros in update intervals and other time periods.



    A few words about macros


    User macros are a long-established mechanism used in Zabbix everywhere and giving the monitoring system the flexibility it needs. These are essentially variables that you can assign with a global level of visibility, pattern, or host. The use of macros is strongly encouraged and recommended, for example in templates, which makes them customizable in other environments and by other users.
    User macros look like this, you've probably already met them:


    {$MACRO}

    Intervals for updating and storing history


    Zabbix allows you to flexibly configure the time taken to poll metrics: each metric can have its own interval.



    Updates to each metric can also be "flexible" (see User Intervals ), which means that they occur according to a specific schedule ("once a day at night" or "at 9:00 a.m. on weekdays").


    Similarly, we can determine how long history and trends are stored for each data item separately.


    Such a subtlety of tuning is far from always necessary, therefore, the use of macros gives a couple of new ideas for setting these parameters.


    Use cases


    Update intervals and duration of storage of collected data


    First, metric update intervals (both regular and user-defined intervals), as discussed above, now support custom macros. Secondly, you can use macros in the intervals for storing history and trends. In the end, it looks like this:



    Just set the values ​​of these macros globally, and then reassign them at the template or host level if necessary:



    In general, for update intervals, you can create a small global set of macros that can then be used by default for all new data items , depending on their type and importance. For instance:



    This will allow you not to spend time thinking each time “I want to collect this metric every 60 or once every 61 seconds? Or maybe once every 5 minutes it will be enough?”, But simply use the rules for collecting and storing elements accepted on your server and project data captured in global macros. Although, perhaps, this option is not suitable for everyone :)


    In low level discovery


    The macro context is also supported , which can be very useful, for example, with LLD .
    Imagine that we collect network interface traffic on multiple devices. In order not to load Zabbix, we would like to do as follows:


    • key interfaces, trunks and other uplinks - take data once every 1 minute, keep a history of 30 days, and trends 1 year.
    • other interfaces - interrogate once every 5 minutes, keep a history of 3 days, and trends 1 month.

    First, define the global macros {$ DELAY_IF}, {$ HISTORY_IF}, {$ TREND_IF}:



    Then we use them in the prototype of the interface data element, but with the context (in this case, it will be the name of the ifName interface):



    Already at the host level, we indicate a new macro value with a context for the key interface (for example, take Gi0 / 0.114):



    Now let's see 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 storage and collection rules:



    If we want to change the total interval or increase the polling frequency or the storage time of another interface, we just need to reassign the macros at the host level. Changing the template, prototype and waiting for detection is not required - everything will apply immediately. In fact, even write access to the template is not required.


    Where else?


    And macros can now be used in other situations where you had to specify the time or period. For example, in the actions:



    or indicate through the macro the engineer’s availability time for automatic notifications:



    An exact list of places where macros can be used can be found here .


    Eventually


    The new macro features in 3.4 open up a couple of good features: on the one hand, for finer tuning (for LLD), and on the other, for centralizing and controlling the time of polling and storage. And by the way, support for the suffixes s, m, h, d, w appeared in time intervals - a trifle, but convenient :)


    See you!


    PS The article is also available on our blog in English.


    Also popular now: