Let's take a careful look at the emails we received (if you have already deleted them, just send a couple more SNMP traps). The subject and body both mention the trigger name—SNMP trap has arrived on snmptraps. It looks like it was a good idea to include the hostname macro in the trigger name. While there's another solution we will explore right now, a general suggestion is to always include the hostname in the trigger name. Doing so will avoid cases when you receive an alert, but have no idea which host has the problem. For example, if we had omitted the hostname macro from our trigger, the email alerts would have said SNMP trap has arrived.

Another solution is possible in regards to the aforementioned problem; we can use the macro in the action log to help in this particular case.

To proceed, navigate to Configuration | Actions, click on SNMP action, and then the operations tab. In the Name column, change the default subject field contents to the following:

{TRIGGER.STATUS}: {TRIGGER.NAME} on {HOST.NAME} 

The field already contained two macros—{TRIGGER.STATUS} and {TRIGGER.NAME}. The benefit of a macro is evident when we have a single action covering many cases. We don't have to create a myriad of actions to cover every possible situation; instead, we use macros to have the desired information, related to the particular event, replaced. Macro names usually provide a good idea of what a macro does. In this case, we improved the existing subject line, which already contained trigger name and status macros, by adding the hostname macro, though it is still recommended to include the hostname in trigger names.

To confirm your changes, click on Update. Make the trigger change state by sending SNMP traps as before, and then check your email. The subject now includes the hostname. But wait, now the hostname is included twice—what have we done? The subject is now as follows:

PROBLEM: SNMP trap has arrived on snmptraps on snmptraps 

We used the same macro in the trigger name and in the action subject. You should decide where you would like to specify the hostname and always follow that rule.

There's also something else slightly strange in the emails. At the end of the message body, there are a number of lines with UNKNOWN in them:

Received SNMP traps (snmptraps:snmptraps): 192.168.56.11 "Critical Error"   NET-SNMP-MIB::netSnmpExperimental
*UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
*UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*  

Let's look at the corresponding action configuration:

Item values: 
{ITEM.NAME1} ({HOST.NAME1}:{ITEM.KEY1}): {ITEM.VALUE1} 
{ITEM.NAME2} ({HOST.NAME2}:{ITEM.KEY2}): {ITEM.VALUE2} 
{ITEM.NAME3} ({HOST.NAME3}:{ITEM.KEY3}): {ITEM.VALUE3} 

The number that is appended in these macros, such as in {ITEM.NAME1}, is the sequential number of the item in the trigger expression. The trigger that sent the notifications for us referenced a single item only, hence the first reference works, referencing the second and third items fails, and that outputs *UNKNOWN* in the message. The default action is meant to be used as an example; in this case, demonstrating the ability to reference multiple items. If most of your triggers reference only a single item, it might be desirable to remove the second and third lines. At this time, there is no way to conditionally print the item value, if it exists.

Sometimes, the receiver of the message might benefit from additional information that is not directly obtainable from event-related macros. Here, an additional class of macros helps—the ones used in trigger expressions also work for macro contents. Imagine a person managing two servers that both rely on an NFS server, which is known to have performance problems. If the system load on one of these two servers increases enough to fire a trigger, the alert receiver would want to know the load on the second server as well, and also whether the NFS service is running correctly. That would allow them to do a quick evaluation of where the problem most likely lies. If the NFS service is down, or is having performance problems of its own, then the system load on these two servers most likely has risen because of that, and the NFS server admin will have to take care of that. For this person to receive such information, we can add lines such as these to the email body:

CPU load on Another host: {Another host:system.cpu.load.last()} 
NFS service is: {NFS Server:nfs.service.last()} 

Note that there is no built-in NFS service item; you have to create proper hosts and items to be able to reference them like this.

As can be seen in the preceding example, the same syntax is used as in trigger expressions, including the functions that are supported. This also allows the receiver to be informed immediately regarding average load over a period of time by adding a macro such as this:

Average CPU load on Another host for last 10 minutes: {Another host:system.cpu.load.avg(600)} 

You can find a full list of supported macros in the official Zabbix documentation at https://www.zabbix.com/documentation/4.0/manual/appendix/macros/supported_by_location.