[AGENT++] Proposal: Explicit save of persistent objects via SNMP

Marek Malowidzki maom_onet at poczta.onet.pl
Wed Oct 20 15:31:41 CEST 2004


I assume that a configuration is just serialized agent MIBs (a data
snapshot). If the idea is different, please skip the rest and explain it to
me ;-).

> Hi Henning,
>
> OK, here is my proposal (PDF and text) which is only slightly
> different from yours:
> http://www.agentpp.com/beta/AGENTPP-CONFIG-MIB.pdf
> http://www.agentpp.com/beta/AGENTPP-CONFIG-MIB.txt
>
> It is much more simple than intermediate versions were, but
> KISS (keep it simple stupid) wins once more ;-)
>
> Future persistent storage formats like XML can be supported
> by this MIB extension too.

Depending on the size of XML libraries, could you also consider a simple CSV
(human readable ASCII) format?

>
> If there are no objections posted on the mailing list, I will start
> development of the MIB's implementation next week. Neverthelles,
> comments and suggestions are still welcome!

Ok, I believe that is_volatile() (as mentioned by Henning) will be used to
specify, which parts of the MIB tree are to be serialized?

Also, I think that user-provided serialize()/deserialize() implementations
will have to take care of all the threading stuff.

What I would see worth considering, is another option for
agentppCfgStorageOperation, restartAndRestore. This would cause the agent to
restart, after calling some internal callback, with the specified
configuration. This proposal is not well-motivated at the moment but I
believe that in some cases it may be easier to simply restart the agent than
re-build shared state on the fly. What do you think?

Logging remarks: for our agent, we have developed a custom logging
facilities which enable the following:
- store logs in a file (no surprise)
- store logs in a memory buffer (cyclic, the oldest logs are rewritten) of a
specified size
- optional save of the buffer onto the disk when agent completes (due to a
signal). This could be done on demand or periodically.

Do you think that any of this functionality would be worth considering for
agentpp-config?

As a small remark: wouldn't it be better to collect the agentppCfgLogLevel*
objects in a table indexed by a message type (no RowStatus, static table)?

Marek




More information about the AGENTPP mailing list