On Wed, 2009-07-29 at 09:42 -0400, Carolyn Beeton wrote:
> I am looking at XX-6051 (sipXsupervisor to alert admin when system
> services can not start) and I am proposing some new alarms.
>
> An alarm will be raised on entry to ConfigTestFailed or ResourceRequired
> state. If the process had blocked in one of these states, then the
> ProcessStarted alarm (at info level, no email) will be generated when
> the process gets to state Running.
>
> Question: should I also create an alarm for ConfigMismatch? I think I
> probably should... I am just concerned that it is a normal part of
> upgrade. How does this sound?
>
> PROCESS_STARTED (info):
> "Process '{0}' recovered from a missing resource or failed configtest.
> Attempting to start the process."
> <resolution>"No action required."
Don't abbreviate - make 'configtest' 'configuration test'.
> PROCESS_CONFIGTEST_FAILED (crit):
> "Process '{0}' failed its configtest."
> <resolution>"Check recent configuration changes. Do not hand-edit
> configuration files. Check logs for more details."
>
> PROCESS_RESOURCE_REQUIRED (warning):
> "Process '{0}' is missing one or more required resources (list
> follows)."
> <resolution>"Wait for a few seconds to see if this is just a normal
> startup sequence. If problem persists, try pressing Send Profiles on
> the server page."
>
> PROCESS_CONFIG_MISMATCH (warning):
> "The configuration data for process '{0}' ({1}) does not match the
> software version ({2})."
> <resolution>"Wait for a few seconds to see if this is just a normal
> startup sequence. If problem persists, try pressing Send Profiles on
> the server page."
In both of the above, I'd suggest changing 'a few seconds' to a 'a
minute or two' just to give sipXconfig some time, and 'try pressing Send
Profiles on the server page' to something like 'select the server and
Send Profiles to refresh the configuration' (I don't like "press" as a
user instruction).
In answer to your original question, I'm not sure about alerting on
these conditions that should be ephemeral... I don't like sending
warnings that we _know_ will happen under perfectly ordinary conditions
about things that should just go away all by themselves. If we could
detect that the conditions are not those where we expect this, then the
warnings would certainly be justified... not sure how to do that.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
