Adding an event to a scheduler is a two-fold process. First find (or create) the time-slot that corresponds to the time we want to run a specific event, then push the event onto the scheduler. - +
The way any event is being run is by having the generic function PROCESS called with the event as argument. In general, events are monitor objects. - +
The scheduler API is fairly limited, consisting of the following functions:
+The current severity-of-fault for any equipment is the maximum of the +severity status for any of its monitors, so in that respect, monitors +are treated equally. The alert-level is a number in the 0-255 range +and if ever set to a lower-than-current value will slowly move towards +the lower value. At the moment, the decay is linear (every time a new +value is set, the alert level will be the maximum of old-5 and new). +
+Each equipment class can have 0 or more default monitors associated +with it. There's a mapping from the equipment class to a list of +monitors that should always exist for that equipment class. +
+Monitors can either be graphing or non-graphing. Only graphing monitor +keep any historical state (beyond "what is my current alert +level"). There's several types of built-in graphin classes, depending +on the expected characteristics of the data the monitor retrieves. +
+The graph classes come in several sub-classes, depending on how they +transfer data fromshorter-term storage to longer-term storage. Each +storage class keeps 300 records and every 12th value added to a +storage-class initiates a transfer of data to longer-term storage. +
+If we have a graphing monitor that stores data every 5 minutes, this +means we'll have data with 5-minute granularity in the short-term +storage, for a maximum of 25 hours of detailed data. Every hour, this +data will also update the medium-term storage, for roughly 12 days +worth of data with hourly granulatity and twice a day, the medium-term +data will be used to populate the long-term storage, where we will +have 150 days worth of data with a rather coarse granularity. This +method is obviously inspired by MRTG and RRDTool. +
+The graph subclasses determine how data is treated as it is shifted +from one storage to another. Looking at this, what's actually being +shifted isn't the "latest 12", it's the "the 12 that are about to be +over-written".
+
| Graph subclass | Behaviour |
|---|---|
| gauge-graph | The transferred value is the median value in the +last 12 time units (actually the mean of the 6th and 7th value, when +the last 12 are sorted in order) |
| meter-graph | The value about to be over-written in the shorter-time storage +is transferred over. This is intended for data sources that are +increasing (like, say, an output byte counters) |
| max-graph | This adds the maximum of the last 12 shorter-time +units to the longer-time storage |
| avg-graph | This averages the 12 oldest records and shifts that +value into the longer-term storage |
+This is then used to make sure that sub-macros can check that they're +in the right context for whatever configuration they +provide. Sub-macros can be defined with the DEFNESTED macro. +
+All config files are loaded in a scrap package.