Fork me on Github

sysdb(7) Manual Page


sysdb - the System DataBase (SysDB)


sysdbd -C /path/to/sysdbd.conf
sysdb -H /path/to/sysdbd.sock


“System DataBase” (SysDB) is a multi-backend system management and inventory collection service. It stores system and inventory information about hardware and software systems. This information is (continuously) collected from various configurable backends (inventory services, monitoring services, etc.) and stored in a graph-like hierarchy of generic objects. The store may be queried through a generic interface independent of the active backends. Object names are canonicalized before they are added to the store to ensure a consistent view of your infrastructure.

The central object type is a host, which generally represents a physical or virtual machine or any other type of physical resource. Hosts, in turn, may reference a list of services which represent any kind of logical resource like a software system. Both, hosts and services, may reference a list of attributes which represent further information about the respective host or service object. For example, attributes may specify static information like a host’s architecture or the software version. A host may also reference a list of metrics which are references to performance data stored about the host. SysDB supports querying the respective time-series from a backend’s data store.

SysDB is made up of several components:


The SysDB daemon acts as the data collection instance and database server. It collects system and inventory information from the backends and aggregates objects retrieved from different backends based on their attributes. This way, it creates a uniform hierarchy of the entire infrastructure.

For details about the SysDB daemon, see its manual page sysdbd(1).


The SysDB client is a terminal-based, interactive shell which may be used to query the SysDB daemon. It connects to a running daemon and then accepts commands from the user, sends them to the server, and displays the results.

For details about the SysDB client, see its manual page sysdb(1). For details about how to query the database, see the specification of the SysDB query language in sysdbql(7).


SysDB’s features are build around a set of concepts which are explained in this section.

Object Store

The central part of SysDB’s database is the object store which stores all objects (hosts, services) known to SysDB. The implementation is provided by a "store" plugin and may be backed by arbitrary data-stores. At least one store plugin has to be loaded to let the daemon do its work.

Hosts and Services

The basic building block of SysDB’s store are host and service objects representing physical and logical resources. Each host is identified by a unique name and each service is identified by a unique pair of a hostname and a service name. All services are assigned to the respective host which is usually interpreted as the service running on that host. In addition, hosts and services may have a list of attributes assigned to them. These are arbitrary key-value pairs providing additional information about the respective object and they may be used to further categorize and identify an object. For example, the mk-livestatus and puppet::store-configs backend plugins provide a list of all hosts and services known to the monitoring system queried through the Check_MK livestatus interface and all hosts will be attributed with all "fact" values known to Puppet. This allows to query hosts based on facts like architecture or LSB information using query commands like LOOKUP (see sysdbql(7)).

Host and service objects are provided and updated by backend plugins and queried from other systems, like inventory databases or monitoring systems.

Hostname Canonicalization

Before storing an object in SysDB’s store, any hostname used to identify the object is canonicalized. This is done by so called "cname" plugins and may be based on arbitrary information derived from the original hostname. This way, hosts provided by different backends may be mapped to the same host in SysDB even if, for example, one backend uses short hostnames while another uses fully qualified domain names (FQDNs). For example, the cname::dns plugin uses reverse DNS queries to resolve a name to its canonical hostname as provided by DNS.

Metrics and Time-Series

A metric identifies performance data about a host. SysDB does not collect or store the actual data but collects information about which metrics are available from backends. It then provides a generic way to fetch time-series data directly from a backend’s data-store. In some cases, this requires additional configuration. For example, the collectd::unixsock plugin provides information about which metrics are available from a collectd instance. Using the TimeseriesBackend and TimeseriesBaseURL configuration options (see sysdbd-collectd-unixsock(5)), SysDB may be told where to fetch time-series data from. The details are automatically managed by the plugin and the timeseries::rrdtool plugin may be used to fetch the data from RRD files managed by collectd. Fetching the data may be done using the TIMESERIES query command (see sysdbql(7)).



SysDB was written by Sebastian "tokkee" Harl <>.

Copyright © 2012-2014 Sebastian "tokkee" Harl <>

This is free software under the terms of the BSD license, see the source for copying conditions. There is NO WARRANTY; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Latest Releases:

» 0.8.0 — 2016-02-25
» 0.7.0 — 2015-02-21
» 0.6.0 — 2014-11-17

[feed]  RSS | Atom




Imprint | Github | Google+ (Community) | Twitter | Facebook