Clone this wiki locally
Administering istatd is typically as easy as just setting it up and starting it, and it will take care of itself. As long as it doesn't run out of disk or open files!
There are some built-in functions to make administration of a running system easier if you need specific behaviors.
istatd will record counters about its own behavior in an "istatd" counter tree. You can look at these counters through the web interface, or get the values directly as JSON by directly asking for them with a HTTP GET.
You can telnet to a running istatd server on a port you specify as --admin-port in the configuration or on the command line. Note that this port must be different from the main statistics port, and from the HTTP port. Once you're talking to the admin interface, there will be a few options for you:
- help - display this help
- stats - display stats
- flush - flush all counters
- faketime value - update faked time (for testing)
- purge [maxOld[,maxAge]] - purge old connection info records
- debug [option[,on|off]] - display or toggle debug options
- loglevel [level[,stderrLevel]] - display or change logging verbosity
- quit - disconnect from stat server
All of the above command return with a line starting with "ok" or "huh?" when complete. Lines starting anything else is status information.
During runtime, "stats" may be a good way of getting a few out-of-band statistics for monitoring and alerting. "debug" and "loglevel" allow you to control the amount and content of the log file. "flush" will flush all buffers to disk, and will also re-load any user settings files, which means that you can edit the set of global dashboards on disk, and then issue a flush to reload it, without having to re-start the server. Note that the main istatd.cfg file is not reloaded as part of a flush.
Connected agents list
When using a tree of istatd servers -- typically, each machine will use an istatd agent, and one machine will be a master -- it is useful to know information about how many agents are actually connected, and what version of the software they are running. You can get this information from the "meta" info, through the following URL:
The "*" is actually the same kind of pattern used to match counter names when querying the database, so can be used to implement wildcards.
When a remote host has connected, information about that host is kept forever in RAM. If you are monitoring hosts that will change their name or IP address frequently, this list may eventually grow to be too large to manage. You can purge inactive meta information records using the "purge" command on the admin telnet interface.