Monitor Concepts

[KampfCaspar]

Hi!

Finding you on news.php.net and then on google code, I want to
congratulate you on the APM project. As I would have great use for an
APM, I would love to participate. Combing through source and pages,
however, I did not find your intention - apart from a view ideas on
Wiki/Todo (which seems uneditable, btw.).

Forgive me, if I use this post to layout my ideas, which might
duplicate or contradict yours (unbeknownst to me). I would be glad if
you told me what you think of those:

I envision a 6 part system:
a) "Collector"
b) "Storer"
c) "Actioner"
d) "Reader"
e) "Distributor"
f) "Management Node"

The first three components run on the monitored machine:

"Collector" is the part within the Engine, that collects the events.
Those could be php errors, exceptions (common php/zend), timeouts (are
simply there) or "manual" events (only work with the collector
implementation, of course). Event information should include
tiimestamp, error information/severity/class, file, line, function,
backtrace and the whole environment. There might arise performance
issues, so "big" data collecting might be configurable.

"Storer" has the task of flushing the event data out as fast as
possible - the process should not be hindered. I presume, different
storers (as sqlite3 in your concept) should be thought of. Those can
be linked statically - and chosen by ini. I don't think dynamic
addition is necessary. The storer, however, should have configurable
"bail out" limits... say an application suddenly throws exceptions by
the ms ;) There is no reason to further load the system with storing.

"Actioner" would DO something upon an event. Those could range from
senting SNMP traps to email alerts to ... incl. escalation. I would
see those as external processes that get started. Of course, starting
processes, configurable limits (see above) are that much more
important. Those external processes don't delay the engine and are
therefore not that time sensitive.

The fourth component is for event evaluation:

The "Reader" searches, sorts and gathers event data from the storage -
There would have to be a (internal) "Reader Variant" for each
"Storer". An event GUI would use the "Reader" to fetch the data and
then display it in a sensible way. Although not mentioned in the name,
certain maintenance tasks - like deleting old data - would have to be
included there, too.

The fifth and sixth component would be used for "multihost"
environments

The "Distributor" would run on the monitored machine and "send" the
collected event data either to a backup host or a central collection.
It could be implemented time-based, load-based or event-based. In
multihost environments, the event data must include the host
identification, of course.

The "Management Nodes" would store the central event collection -
which might be totally different to the individuals host storage
(which is plainly on write performance). Definitions of access to that
storage and data interpretation incl. GUI are on these nodes.
NB: Although the storage might be different to the monitored nodes,
the data format must be the same. I don't see a "Reader" here, as the
data might be mangled for whatever statistical analysis.

Regards
HPO