Zabbix server daemon parameters

We'll now skip the common parameters we already discussed when looking at the agent daemon configuration file. The remaining ones are as follows:

  • DBHost: This is useful if the backend database is on a different system. Using an IP address is highly recommended here.
  • DBName: This is the database name; we set it in Chapter 1, Getting Started with Zabbix. As the comment explains, it should be set to the database file path when the SQLite backend is used for a proxy.
  • DBSchema: This is the database schema, only useful with PostgreSQL and IBM DB2.
  • DBUser and DBPassword: These are database access credentials. As the comment explains, they're ignored when the SQLite backend is used for a proxy.
  • DBSocket: This is the path to the database socket, if needed. Unless the Zabbix server or proxy is compiled against a different database library than the one available at runtime, you'll likely never need this parameter.
  • DBPort: If connecting to a local or remote database on a nonstandard port, specify it here.
  • HistoryStorageURL: This is the URL to the Elasticsearch storage; remember there's still no official support for Elasticsearch.
  • HistoryStorageTypes: This is a list of what to store in the Elasticsearch DB.
  • HistoryStorageDateIndex: This enables preprocessing of history values in history storage to store values in different indices based on date.
  • ExportDir: This is a directory for real-time export of events, history, and trends in newline-delimited JSON format. If set, it enables real-time export.
  • ExportFileSize: This is the maximum size per export file in bytes.
  • StartPollers: Pollers are internal processes that collect data in various ways. By default, five pollers are started, and this is plenty for tiny installations such as our test setup. In larger installations, it's common to have hundreds of pollers. Notice that there're no separate SNMP pollers; the same processes are responsible for passive agent and SNMP device polling. How to know whether you have enough? Using the internal monitoring, find out the average busy rate. If it's above 70%, just add more pollers. Pollers are responsible for the following:
    • Connecting to passive agents
    • Connecting to SNMP devices
    • Performing simple checks, such as service/port checks
    • Retrieving internal monitoring data
    • Retrieving VMware data from the VMware cache
    • Running external check scripts
  • StartIPMIPollers: This specifies how many processes should be started that poll IPMI devices. We configured this parameter in Chapter 14, Monitoring IPMI devices.
  • StartPreprocessors: This is the number of pre-forked instances of preprocessing workers needed for our preprocessing, such as JSON, XML, and PCRE.
  • StartPollersUnreachable: If a host isn't reachable, it isn't polled by normal pollers anymore; special types called unreachable pollers now deal with that host, including IPMI items. This is done to avoid a situation where a few hosts that time out take up most of the poller time. If there aren't enough unreachable pollers, the worst thing that happens is that hosts that are declared unreachable aren't noticed as being back up as quickly. By default, only one unreachable poller is started. To know whether that's enough, observe their busy rate, especially when there're systems down in the monitored environment.
  • StartTrappers: By default, there're five trappers. As with pollers, monitor their busy rate and add more as needed. Trappers are responsible for receiving incoming connections from the following:
    • Active agents
    • Active proxies
    • zabbix_sender
    • The Zabbix frontend, including server availability check, global scripts, and queue data
  • StartPingers: These processes create temporary files and then call fping against those files to perform ICMP ping checks. If there're lots of ICMP ping items, make sure to check the busy rate of these processes and add more as needed.
  • StartDiscoverers: Discoverers perform network discovery. Discovery happens sequentially for each rule. Even if there're lots of available discoverers, only one at a time works on a single discovery rule. Note that discoverers split up the rules they'll serve; for example, if there're two discovery rules and two discoverers, one discoverer will always work with a particular rule. We discussed network discovery in Chapter 11, Automating Configuration.
  • StartHTTPPollers: These processes are responsible for processing web scenarios. Like discoverers, HTTP pollers split up the web scenarios they will serve. We discussed web monitoring in Chapter 12, Monitoring Web Pages.
  • StartTimers: Timer processes can be quite resource intensive, especially if lots of triggers use time-based functions such as now(). We discussed time-based trigger functions in Chapter 6, Detecting Problems with Triggers. These processes are responsible for the following:
    • Placing hosts in and out of maintenance at second 0 of every minute; this is only done by the first timer process if more than one is started
    • Evaluating all triggers that include at least one time-based trigger function at second 0 and second 30 of every minute
  • StartEscalators: These processes move escalations forward in steps, as discussed in Chapter 7, Acting upon Monitored Conditions. They also run remote commands, if instructed so by action operations.
  • JavaGateway, JavaGatewayPort, and StartJavaPollers: These parameters point at the Java gateway and its port, and tell the server or proxy how many processes should connect to that gateway. Note that they all connect to the same gateway, so the gateway should be able to handle the load if the number of Java pollers is increased. We discussed Java monitoring in Chapter 15, Monitoring Java Applications.
  • StartVMwareCollectors, VMwareFrequency, VMwarePerfFrequency, VMwareCacheSize, and VMwareTimeout: These control the way VMware monitoring works. We discussed these parameters in detail in Chapter 16, Monitoring VMware.
  • SNMPTrapperFile and StartSNMPTrapper: When receiving SNMP traps, we must specify the temporary trap file and whether the SNMP trapper should be started. Note that only one SNMP trapper process may be started. We configured these parameters in Chapter 4, Monitoring SNMP Devices.
  • HousekeepingFrequency: This specifies how often the internal housekeeper process runs or, to be more specific, how long after the previous run finished the next run should start. It's not suggested to change the default interval of one hour; the housekeeper may be disabled as needed for specific data in Administration | General, as discussed earlier in this chapter. The first run of the housekeeper happens 30 minutes after the server or proxy starts. The housekeeper may be manually invoked using the runtime control option.
  • MaxHousekeeperDelete: For deleted items, this specifies how many values per item should be deleted in a single run, with the default being 5,000. For example, if we'd deleted 10 items with 10,000 values each, it would take two housekeeper runs to get rid of all of the values for all items. If an item had a huge number of values, deleting them all in one go could cause database performance issues. Note that this parameter doesn't affect value cleanup for existing items.
  • CacheSize: This is the size of the main configuration cache that holds hosts, items, triggers, and lots of other information. Use of this cache depends on the size of the configuration data, which is influenced by the number of hosts, items, and other entities. Be very proactive with this parameter; if cache usage significantly increases or you plan to add monitoring for lots of new hosts, increase the configuration cache. If the configuration cache is full, the Zabbix server stops.
  • CacheUpdateFrequency: This specifies how often the configuration cache is updated. The default of one minute is fine for most installations, although in large environments it might be a good idea to increase this parameter, as a configuration cache update itself can increase database load.
  • StartDBSyncers: This specifies how many database or history syncers should be started (both names are used interchangeably in various places in Zabbix). These processes are responsible for calculating triggers that reference items, receiving new values, and storing the resulting events and those history values in the database—probably the most database-taxing processes in Zabbix. The default of four database or history syncers should be enough for most environments, although it could be useful to increase for big installations. Be careful with increasing this number; having too many of these can have a negative effect on performance, although you might see that, if their average busy rate decreases, the number of values processed could decrease.
  • HistoryCacheSize: When values are collected, they're first stored in a history cache. History or database syncers take values from this cache, process triggers, and store the values in the database. The history cache getting full usually indicates performance issues; increasing the cache size is unlikely to help. If this cache is full, no new values are inserted into it, but the Zabbix server keeps running.
  • HistoryIndexCacheSize: This cache holds information about the most recent and oldest value for all items in the history cache. It's used to avoid scanning the history cache, which could get rather large. Use of this cache depends on the number of items that collect data. As with the main configuration and trend cache, make sure to have enough room in this cache; if it's full, the Zabbix server will shut down.
  • TrendCacheSize: This cache holds trend information for the current hour for each item—not the current hour per the clock, but the current hour based on the incoming values. That is, the last value that came in for an item determines the current hour value. For example, if values are sent in using zabbix_sender for the hour 09:00-10:00 yesterday, that's the current hour and its trend data is in the trend cache. As soon as the first value for the hour 10:00-11:00 arrives, the trend cache information for that item is written to the database and 10:00-11:00 becomes the new current hour. Use of this cache depends on the amount of items that collect data. As with the main configuration cache, make sure to have enough room in this cache; if it's full, the Zabbix server will shut down.
  • ValueCacheSize: This parameter controls the size of the cache that holds historical values; but as opposed to the history cache, it holds values that're expected to be useful in the future. The values in here aren't meant to be written out to the database, but quite the opposite: values are often read into this cache from the database. The value cache is used when item values are needed for trigger calculation (for example, computing the average value for last 10 minutes), for calculated or aggregate items, for including in notifications, and other purposes. Value cache population can take a while when the server first starts up. If the value cache is full, the Zabbix server will keep running, but its performance will likely degrade. Monitor this cache and increase the size as needed.
  • Timeout: This specifies how long Zabbix waits for the agent, SNMP device, or external check (in seconds).
  • TrapperTimeout: This parameter controls how long trappers spend on communicating with active agents and proxies, as well as zabbix_sender. Being set to the maximum value of five minutes by default, this timeout is highly unlikely to be reached.
  • UnreachablePeriod, UnavailableDelay, and UnreachableDelay: These parameters work together to determine how value retrieval failures should be handled. If value retrieval fails with a network error, the host is considered to be unreachable and is checked every UnreachableDelay seconds (by default, 15). This goes on for UnreachablePeriod seconds (45 by default), and if all checks fail (with the default settings, we end up with four checks), the host is marked unavailable and is checked every UnavailableDelay seconds. Note that, since Zabbix 3.0, if an item fails twice in a row but another item of the same type on the same host succeeds, the failing item is marked unsupported instead. It's probably best to leave these values at the defaults, as changing them could lead to fairly confusing results.
  • AlertScriptsPath: Custom scripts to be called from actions must be placed in the directory specified by this parameter. We configured such a script in Chapter 7, Acting upon Monitored Conditions.
  • ExternalScripts: Scripts that are to be used in external check items must be placed in the directory specified by this parameter. We configured such an item in Chapter 10, Advanced Item Monitoring.
  • FpingLocation and Fping6Location: These parameters should point at the fping binaries for IPv4 and IPv6, if different. The fping utility is required for ICMP checks, which we configured in Chapter 3, Monitoring with Zabbix Agents and Basic Protocols.
  • SSHKeyLocation: If using SSH items with keys, the keys must be placed in the directory specified by this parameter. We configured SSH items in Chapter 10, Advanced Item Monitoring.
  • LogSlowQueries: Normally, SQL queries aren't logged up to DebugLevel 4. This parameter allows us to log all queries that take longer than the number of milliseconds, specified here, at DebugLevel 3. By default, since Zabbix 3.0, any query that takes longer than three seconds is logged. They appear in the log file like this:
13890:20151223:152504.421 slow query: 3.005859 sec, "commit;"
  • TmpDir: This is a temporary directory for any files the Zabbix server or proxy need to store. Currently, it is only used for files that're passed to fping.
  • SSLCertLocation, SSLKeyLocation, and SSLCALocation: These parameters specify where certificates, keys, and certificate authority files will be looked up when the SSL functionality is used with web monitoring.

Again, all of the parameters starting with TLS are relevant for daemon traffic encryption and won't be discussed here.

The available parameters might be slightly different if you have a more recent version of Zabbix. To list the supported parameters in the configuration file you have, the following command could help:

$ grep "### Option" zabbix_agentd.conf

Now, if you get confused about some parameter, what's the first place you should check? If you said or thought: comments in the configuration files themselves, of course, great. If not, go take a look at those comments and remember that the Zabbix team really, really tries hard to make those comments useful and wants you to read them. You will save your own time that way.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.17.5.68