User Tools

Site Tools


devel:blueprints:servicemon-tool

This is an old revision of the document!


Make Servicemon a Tool

Servicemon is currently hidden away inside SeedDB. Now that a rewrite of SeedDB is being considered, this is a good time to take Servicemon out and make it a separate tool with its own web interface. This will make it more visible to users. The code should also become easier to work with, since it's no longer tied to the rest of SeedDB.

The backend will not need to be rewritten, except to add support for help text.

Web interface

Functionality:

  • status page (new)
  • add service
  • remove service
  • edit service(s)
  • move service to another netbox (new, very easy to implement)
  • help text for checkers (what it does and what packages/programs it requires) and for arguments (where not obvious) (new)

The current interface is a little weird in places. The goal should be to make the new interface as obvious as possible.

Loose ideas:

  • somehow check if each checker has the programs/modules it requires and flag on the web page the ones that don't (aren't usable due to missing dependencies)
  • show/edit services on a specific netbox?
  • put a service “on service” (quickly turn off a service checker without losing service arguments)

Online help

Most checkers and arguments are pretty easy to figure out how to use, but some are decidedly more obscure, such as the RPC checker which takes an optional argument named 'required'.

Adding a checker could look something like this (if you imaging that this is html):

New Dippedutt checker on tjobing.not

  Sends a bunch of DIPP request to a whole subnet over the DAPP protocol, and returns UP if it gets at least one reply.
  
  Requires dippedutt-client 0.92 or higher.

REQUIRED ARGUMENTS:
Mask: [192.168.0.0/16]   IP mask of subnet to spam

OPTIONAL ARGUMENTS:
   Port: [   ]  TCP port
Timeout: [3  ]  (in seconds)

[Save]

Maybe the help text should be on top or to the right. What's important is that it is available when you need it, but out of the way when you don't. (Mouse-over help will not be obvious to users. It should be visible on-screen without any action from the user, if it doesn't clutter the page too much.)

All help text should be stored in the .py file, so each checker is one completely self-contained file.

.descr files

Move everything into the .py file.

The description, required args and optional args of each checker is stored in a .descr file. This file is only used by SeedDB (really?). If the Servicemon web page is rewritten, this information could be moved into the .py file, for example like this:

class DippeduttChecker:
    ...

description = 'Dippedutt'
required = []
optional = []

The module should also contain help text for the checker and for each argument.

from statemon.checker.something import Arg

description = 'Dippedutt'
help = 'Checks a dippedutt using DIPP requests over the DUTT protocol. Requires dippelidapp 1.0   or higher, which must be setuid root.'
required = [Arg('opt', help='')]

Maybe the Arg() bit is a bit verbose, but the help text has to go somewhere, and it allows things like type=int etc. to be added later.

.descr files are only used in Servicemon, so the parser is not used anywhere else. (Or is it?)

devel/blueprints/servicemon-tool.1274354355.txt.gz · Last modified: 2010/05/20 11:19 by olemb