Table of Contents
noitd is the "scout in the field." It is responsible for performing service checks and obtaining metric information from services on remote machines. Typically, one noitd daemon is deployed in each datacenter and is responsible for talking to each machine and collecting service information.
The noitd daemon should be positioned in the network topology such that it has direct access to each machine it monitors (same layer 2 segment). This is a SHOULD, not a MUST. noitd can be used to monitor remote services as well (such as checking HTTP page load times from one monitoring location to services running in another datacenter). The direct access is suggested for sensitive services that should not be accessible from outside the network.
The noitd daemon provides datafeed services to a stratcond daemon over port 34332 (or another port of your choosing) via an SSL-protected TCP transport.
noitd is designed to be high-performance as well as easy to administer. Clearly, ease of administration is a subjective assessment. The goal in administration was to make the noitd system as much like a network device as possible. The methodology and approach to use is very similar to other network devices such as switches and routers. Telnet access (available over both SSL and non-SSL) provides access to a CLI that allows assessment of operation as well as reconfiguration. It is designed to make network administrators feel "at home."
The performance of noitd is grounded in its use of a hybrid event/thread and careful coding practices to ensure that blocking operations and computationally intensive operations are handled asynchronously to non-blocking operations.
The configuration system is entirely XML-based, providing two inheritance paradigms. The first is provided by simple XML parent-child relationships such that required attributes that are unspecified in leaf nodes are resolved by walking up the element's ancestral stack. The second model uses an explicit "inherit" attribute that allows for complicated configuration information to be stored elsewhere in the XML tree for readability and maintainability. All configuration can be performed by the CLI with a router-like syntax, so those uncomfortable with XML can configure the system with equal ability.
Checks are loaded into the system dynamically (through shared object loading.) New checks can be authored and added to the system without recompiling the host noitd daemon. Some modules can be loaded during runtime, but due to security concerns, super-user privileges are dropped after module initialization. This security feature prevents the correct operation of any module requiring extended privileges for initialization. Adding such a module to the configuration will require a restart of the noitd process. The ping_icmp module is an example of a module requiring extended privileges for initialization (the opening of RAW network sockets.)
In addition to checks implemented as dynamic objects (ELF or Mach) that are loaded into the system with dlopen() or similar such mechanisms, noitd allows for alternate "loader" implementations. noitd has a "lua" loader that allows checks to be scripts in the Lua programming language.