>>>>> "Velocet" == Velocet <mathboy@velocet.ca> writes:
Velocet> Not that this cant be done in MySQL (or Postgres, our
Velocet> preference, since Mysql isnt free, and we know Postgres core
Velocet> developpers ;) for eg, but its probably not as flexible as a
Velocet> database thats aware of the inherent structure in the data or
Velocet> its sources.
Well... PostgreSQL is also Object-relational, a step up from
relational --- would could possibly be coearsed to represent the data
in an interesting way.
Velocet> I'll prod him to summarize his ideas here.
... but the real issue are things like 'who monitors the monitor'.
Nocol (as simple as it is) has failure modes. Some of the real
origional ideas of nocol were never realized.
To truly scale, one of the blurbs of the origional nocol documentation
intuited that the design should modularize monitoring of systems such
that distant monitors are atonomous units that report summaries ---
and then monitors further up the food chain monitor the connectivity
to the monitors.
A bigger problem than the data format for the expansion of a
monitoring system is the ability of monitoring systems to consume
virtually infinite amounts of bandwith to perform their task.
More interesting, I think, than contructing some database interface,
is to construct the objects and inter-object communications that
support the information structure of the monitoring system. It is our
goal to monitor millions of datapoints at a high frequency rather than
hundreds or thousands.
To this end, I think that there are producers and consumers of
status. An example of a producer is an snmp variable (abstractly) or
a module in our system that collects snmp variables. A producer of
status, in the abstract sense, has a state (this is the part that
nocol got right) and we are only interested in changes of state.
A consumer of status is something like a database interface or a web
monitor. I think it is important that there be consumers in this path
that do not depend on the database to be functional. Nocol also got
the design for this correct.
A special type of consumer is also a producer. It consumes the state
(and monitors the reachability) of a number of variables and produces
state to an upline consumer. These nodes form the backbone of the
network, allowing it to scale and ensuring that it is easy to
determine the highest order of an emergency (where order is defined as
the point of concern closest to our consumer).
This design would also allow you to contruct network interconnection
nodes that would produce only some of what they consume ---
effectively propogating _some_ network information allowing insight
into neighbouring networks while controling the amount of this
information available (and allowing different views of data to
different people)
You might see that has aspects of the aformentioned SQL design
(indeed, there is nothing wrong with an SQL consumer/producer), but
the design goes beyond the scope in many ways of a relational
database. This is because you don't have a relational network, you
have a graph-like network.
The object design should fit the problem domain, after all.
If you have a look at netgraph (hit Freebsd.org, and search for
netgraph), you'll see some ideas that influence this. An easy
interconnection protocol for producers and consumers would produce a
more flexible and natural system in a graph-like structure (more
closely mirroring and scaling with your network structure) than an SQL
based structure.
Dave.
--
============================================================================
|David Gilbert, Velocet Communications. | Two things can only be |
|Mail: dgilbert@velocet.net | equal if and only if they |
|http://www.velocet.net/~dgilbert | are precisely opposite. |
=========================================================GLO================
|