Skip to content

draft_protocol cap

Jump to bottom
dipohl edited this page Mar 22, 2018 · 1 revision

Server-node protocol extention: Capabilities

Content from Munin Trac Wiki. Was written by janl between 2005-12-28 and 2006-06-16.

This is implemented in 1.4.0.

As the groundwork for supporting multiple graphs pr. plugin (and other future enhancements) and keeping the server and node code fully back and forward compatible (old server working with new node being the most likely) we want to introduce capabilities that the server and node can present to each other.

Any node/server not announcing capabilities will be assumed to be at the 1.2 level of functionality.

The implementation is simple. The server will issue a "cap <capability0> ... <n>" command and the client will respond with it's own capabilities if it understands or a error message if it does not support the command.

New server talking to old node:

> # munin node at lookfar.langfeldt.net
< cap foo bar
> # Unknown command. Try list, nodes, config, fetch, version or quit

New server talking to new node:

> # munin node at lookfar.langfeldt.net
< cap foo bar
> cap gazonk

At this time I'm proposing these capabilities for future work:

  • multigraph: A server capable of receiving multiple graphs from one plugin. A node with multigraph plugins will not offer them (not list it, and not respond to fetch or config) unless the server has announced this capability.
  • spool: A node capable of doing its own plugin execution and spooling the results, see draft_protocol-spool The server will need to issue a special command to fetch spooled measures. This will be the basis of
    • on running plugins very often without overburdening the server
    • retaining results on the node while the server cannot reach it due to network problems
    • enhancing scaling as fetching from a spool will be much quicker than waiting for the plugins to execute syncronously as they do today
  • overlap: A node capable of overapping commands/results to execute more plugins more quickly and simultaneously instead of running one at a time syncronously. This is one step short of a fully spooling-self-scheduling node. A server MUST announce overlap in its capabilites to trigger simultaneous the paralell execution of plugins and then it MUST issue multiple fetch or config commands to the node without waiting for the results.

Upon further consideration the overlap capability seems un-needed when we have the spool one.

Clone this wiki locally