Let's start with the agent daemon parameters. For the parameters that're also available for other daemons, we'll discuss their relevance to all of the daemons here:

• PidFile: This is common to all daemons. They write the PID of the main process in this file. The default configuration files use /tmp for simplicity's sake. In production systems, this should be set to the distribution recommended location.
• LogType: This is common to all daemons and can be a file, syslog, or console. The default is file and, in that case, the LogFile parameter determines where the logs are written. The syslog value directs the daemon to log to syslog, and the console parameter tells it to log the messages to stdout.
• LogFile: This is common to all daemons. Log data is written to this file when LogType is set to file. The default configuration files use /tmp for simplicity's sake. In production systems, this should be set to the distribution-recommended location.
• LogFileSize: This is common to all daemons. When logging to a file, if the file size exceeds this number of megabytes, move it to file.0 (for example, zabbix_agentd.log.0) and log to a new file. Only one such move is performed (that is, there's never zabbix_agentd.log.1).
• DebugLevel: This is common to all daemons and specifies how much logging information to provide, starting with 0 (nearly nothing) and ending with 5 (a lot). It's probably best to run at DebugLevel 3 normally, and use something higher for debugging. For example, starting with DebugLevel 4, all server and proxy database queries are logged. At DebugLevel 5, two extra things are currently logged:
  • Received pages for web monitoring
  • Received raw data for VMware monitoring

• SourceIP: This is common to all daemons. If the system has multiple interfaces, outgoing connections will use the specified address. Note that not all connections will obey this parameter; for example, the backend database connections on the server or proxy won't.
• EnableRemoteCommands: This determines whether the system.run item should allow running commands. It's disabled by default.
• LogRemoteCommands: If EnableRemoteCommands is enabled, this parameter allows us to log all of the received commands. Unless system.run is used to retrieve data, it's probably a good idea to enable logging of the remote commands.
• Server: This is also available for the Zabbix proxy, but not for the Zabbix server. It's a comma-delimited list of IP addresses or host names the agent should accept connections from. It's only relevant for passive items, zabbix_get, and other incoming connections.
• ListenPort: This is common to all daemons and specifies the port to listen on.
• ListenIP: This is common to all daemons and specifies the IP address to listen on—it could also be a comma-delimited list of addresses.
• StartAgents: This is the number of processes to start that are responsible for incoming connection handling. If it's a very resource-starved system, it might be a good idea to reduce this. If this agent is expected to get lots of queries for passive items, increase this number. Note that it has nothing to do with the collector or active check processes; their numbers can't be directly changed. If set to 0, the agent will stop listening to incoming connections. This could be better security-wise, but could also make debugging much harder.
• ServerActive: This is the list of servers and ports to connect to for active checks. It follows the syntax of server:port, with multiple entries delimited by commas. If not set, no active checks are processed. We discussed this functionality in Chapter 3, Monitoring with Zabbix Agents and Basic Protocols.
• Hostname: This is also available for the Zabbix proxy, but not for the Zabbix server. If specified, the exact string will be sent to the Zabbix server as the host name for this system.
• HostnameItem: If Hostname isn't specified but HostnameItem is, the value in this parameter will be interpreted as an item key and the result of the evaluation will be sent to the server as the host name for this system.
• HostMetadata: This is an exact string to be sent to the server; used in active agent auto-registration.
• HostMetadataItem: If HostMetadata isn't specified but HostMetadataItem is, the value in this parameter will be interpreted as an item key and the result of the evaluation will be sent to the server as the host metadata to be used in active agent auto-registration.
• RefreshActiveChecks: This specifies how often the agent should connect to the server and ask for active items. It's set to two minutes by default. If active checks aren't used at all, it means a useless connection every two minutes from each agent; it's best not to set ServerActive at all in such a case.
• BufferSend: Active agents will send values every BufferSend seconds—by default, every five seconds. This allows us to reduce the number of network connections if multiple values are collected within a five-second window.
• BufferSize: This is a buffer to hold the values for active items. By default, it's set to 100 values. This is an in-memory buffer; don't set it too large if memory usage is a concern. The buffer is actually split in half if there's at least one log-monitoring item-one half is used for normal values, the other for log entries. If the buffer is full, new normal values will result in the dropping of older normal values, but it won't affect log entries. If the log entry part of the buffer is full, log file processing stops, but no entries are dropped there. If there're log items only and no normal items, half of the buffer is still reserved for normal entries. If there're only normal items, the whole buffer is used for them until at least one log item is added.
• MaxLinesPerSecond: This is the default maximum number of lines of log items that should be sent to the server. We discussed this in Chapter 10, Advanced Item Monitoring.
• Alias: This is a way to set an alias for an item key. While usable on all platforms, we discussed it in Chapter 22, Monitoring Windows. This parameter can also be used to create two LLD rules with the same key, even if the key itself doesn't accept parameters. One rule could use the original key, another the key that's aliased.
• Timeout: This is common to all daemons. It specifies the timeout for running commands, making connections, and so on. Since Zabbix 3.0, it has a default of three on agents and four on the server and proxy. This could affect userparameters, for example; a script that takes more than a few seconds would time out. It's highly suggested not to increase the timeout on the server side; if we have to handle many values every second, it's not good to have a server process wait on a single script that long. If you have such a script that takes a long time to return the value, consider using zabbix_sender instead, as discussed in Chapter 10, Advanced Item Monitoring.
• AllowRoot: By default, Zabbix daemons, if started as root, try to drop the privileges to a user specified in the User parameter (refer to the next point). If the User parameter isn't specified, the outcome depends on this parameter. If it's set to 0, startup fails. If it's set to 1, the daemon starts as the root user.
• User: This is common to all daemons. If daemons are started as the root user and AllowRoot is set to 0, try to change to the user specified in this parameter. This is set to zabbix by default.
• Include: This is common to all daemons. It allows you to include individual or multiple configuration files. We discussed this feature in Chapter 10, Advanced Item Monitoring. Note that files are included sequentially as if literally included in the location where the Include directive appeared. Also keep in mind that, if specified more than once, most parameters will override all previous occurrences; that is, the last option with the same name wins.
• UnsafeUserParameters: By default, a subset of characters is disallowed to be passed as parameters to userparameter keys. If enabled, this option will allow anything to be passed and is essentially equivalent to EnableRemoteCommands—the originally prohibited symbols make it simple to gain shell access. See the default configuration file for a full list of symbols this parameter would allow.
• UserParameter: This allows us to extend agents by adding custom item keys to it. We discussed this in quite a lot of detail and configured some user parameters in Chapter 10, Advanced Item Monitoring. This parameter may be specified multiple times as long the item key is unique; that's a way to add multiple user parameters.
• LoadModulePath: This is common to all daemons. It specifies a path to load modules, written in the C language. This is an advanced way to extend Zabbix daemons that's a bit out of scope for this book. Refer to the Zabbix manual for more details.
• LoadModule: This is common to all daemons. Multiple entries of this parameter may be specified for individual .so files to load inside the LoadModulePath directory.