root/docs/arch/noitd.xml

Revision 23dea7e00df87480acb58bb3398283c2bb227949, 4.3 kB (checked in by Theo Schlossnagle <jesus@omniti.com>, 3 years ago)

pull docs into master

  • Property mode set to 100644
Line 
1 <?xml version='1.0' encoding='UTF-8' ?>
2 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
3   "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"
4 [
5   <!ENTITY % magic.fixup SYSTEM "http://labs.omniti.com/docbook/ent">
6   %magic.fixup;
7 ]>
8 <chapter id="arch.noitd">
9   <title>noitd</title>
10   <para>
11     <command>noitd</command> is the "scout in the field."  It is responsible
12     for performing service checks and obtaining metric information from services
13     on remote machines.  Typically, one <command>noitd</command> daemon is
14     deployed in each datacenter and is responsible for talking to each machine
15     and collecting service information.
16   </para>
17   <para>
18     The <command>noitd</command> daemon should be positioned in the network
19     topology such that it has direct access to each machine it monitors (same
20     layer 2 segment).  This is a SHOULD, not a MUST.  <command>noitd</command>
21     can be used to monitor remote services as well (such as checking HTTP page
22     load times from one monitoring location to services running in another
23     datacenter).  The direct access is suggested for sensitive services that
24     should not be accessible from outside the network.
25   </para>
26   <para>
27     The <command>noitd</command> daemon provides datafeed services to a
28     <command>stratcond</command> daemon over port 34332 (or another port of
29     your choosing) via an SSL-protected TCP transport.
30   </para>
31   <section id="arch.noitd.design">
32     <title>noitd Design</title>
33     <para>
34       <command>noitd</command> is designed to be high-performance as well as
35       easy to administer.  Clearly, ease of administration is a subjective
36       assessment.  The goal in administration was to make the
37       <command>noitd</command> system as much like a network device as
38       possible.  The methodology and approach to use is very similar to other
39       network devices such as switches and routers.  Telnet access (available
40       over both SSL and non-SSL) provides access to a CLI that allows
41       assessment of operation as well as reconfiguration.  It is designed to
42       make network administrators feel "at home."
43     </para>
44     <para>
45       The performance of <command>noitd</command> is grounded in its use of a
46       hybrid event/thread and careful coding practices to ensure that blocking
47       operations and computationally intensive operations are handled
48       asynchronously to non-blocking operations.
49     </para>
50     <para>
51       The configuration system is entirely XML-based, providing two inheritance
52       paradigms.  The first is provided by simple XML parent-child relationships
53       such that required attributes that are unspecified in leaf nodes are
54       resolved by walking up the element's ancestral stack.  The second model
55       uses an explicit "inherit" attribute that allows for complicated
56       configuration information to be stored elsewhere in the XML tree for
57       readability and maintainability.  All configuration can be performed by
58       the CLI with a router-like syntax, so those uncomfortable with XML can
59       configure the system with equal ability.
60     </para>
61     <para>
62       Checks are loaded into the system dynamically (through shared object
63       loading.) New checks can be authored and added to the system without
64       recompiling the host <command>noitd</command> daemon.  Some modules can
65       be loaded during runtime, but due to security concerns, super-user
66       privileges are dropped after module initialization.  This security
67       feature prevents the correct operation of any module requiring extended
68       privileges for initialization.  Adding such a module to the configuration
69       will require a restart of the <command>noitd</command> process.  The
70       ping_icmp module is an example of a module requiring extended privileges
71       for initialization (the opening of RAW network sockets.)
72     </para>
73     <para>
74       In addition to checks implemented as dynamic objects (ELF or Mach) that
75       are loaded into the system with dlopen() or similar such mechanisms,
76       <command>noitd</command> allows for alternate "loader" implementations. 
77       <command>noitd</command> has a "lua" loader that allows checks to be
78       scripts in the Lua programming language.
79     </para>
80   </section>
81 </chapter>
82 <!--
83 vim:ts=2:sw=2:et:
84 -->
Note: See TracBrowser for help on using the browser.