The approach we used allows us to send one value every time we run zabbix_sender. If we had a script that returned a large number of values, that would be highly inefficient. We can also send multiple values from a file with zabbix_sender. Create a file like this anywhere, for example, in /tmp/:

"A test host" room.persons 4 
"A test host" room.persons 5 
"A test host" room.persons 6 

Each line contains the hostname, item key, and value. This means that any number of hosts and keys can be supplied from a single file.

The flag for supplying the file is -i. Assuming a filename of sender_input.txt, we can run the following:

$ zabbix_sender -z 127.0.0.1 -i /tmp/sender_input.txt 

That should send all three values successfully:

info from server: "processed: 3; failed: 0; total: 3; seconds spent: 0.000087"
sent: 3; skipped: 0; total: 3
  

When sending values from a file, we could still benefit from the agent daemon configuration file:

$ zabbix_sender -c /usr/local/etc/zabbix_agentd.conf -i /tmp/sender_input.txt

In this case, the server address would be taken from the configuration file, while hostnames would still be supplied from the input file. Can we avoid that and get the hostname from the agent daemon configuration file? Yes, that's possible by replacing the hostname in the input file with a dash, like this:

- room.persons 4 
"A test host" room.persons 5 
- room.persons 6 

In this case, the hostname would be taken from the configuration file for the first and the third entry, while still overriding that for the second entry.

When there's a need to send lots of values constantly, we might wish to avoid repeatedly running the zabbix_sender binary. Instead, we could have a process write new entries to a file without closing the file, and then have zabbix_sender read from that file. Unfortunately, by default, values would be sent to the server only when the file is closed—or with every 250 values received. Fortunately, there's also a command-line flag to affect this behavior. The -r flag enables a so-called real-time mode. In this mode, zabbix_sender reads new values from the file and waits for 0.2 seconds. If no new values come in, the obtained values are sent. If more values come in, it waits for 0.2 seconds more, and so on up to one second. If there's a host that's constantly streaming values to the Zabbix server, zabbix_sender would connect to the server once per second at most and send all of the values received in that second in one connection. Yes, in some weird cases, there could be more connections—for example, if we supplied one value every 0.3 seconds exactly.

If sending a huge number of values and using a file could became a performance issue, we could even consider a named pipe in place of the file—although that would be a quite rare occurrence.