[hobbit] Potential bugs, BBSERVERLOGS, alert counter
Henrik Stoerner
henrik at hswn.dk
Thu Feb 17 23:45:13 CET 2005
On Thu, Feb 17, 2005 at 05:42:44PM +0000, David Gore wrote:
>
> It appears that if you change BBSERVERLOGS to something other than what
> you compiled in, Hobbit will fail to listen on port 1984.
Do you mean that it fails to start completely, or just that it doesn't
log the "Setting up network listener on 0.0.0.0:1984" message ?
If the latter, then note that this message is logged in the
hobbitlaunch log-file (it's a bit messy, but hobbitd sets up the
listener port before handling any options about where to log stuff).
And the hobbitlaunch logfile is determined by a commandline option in
starthobbit.sh
> But more importantly, is Hobbit suppose to restart the counter for
> alerts after you restart it? In other words, when I am looking at the
> log file I can clearly see that the counter is reset by watching the
> minduration lines in page.log. Perhaps, I have something serious
> misconfigured?
The duration counter does reset if Hobbit is restarted, at least with
the default setup.
You can change this by having hobbitd_alert save the state of the
active alerts in a file when it shuts down, and restore the state when
it starts up again. The "--checkpoint-file=FILENAME" option for
hobbitd_alert will do that.
The reason why this is not enabled by default is that you can get into
a situation where an alert is active when you shut down Hobbit, but
it's been resolved when Hobbit starts up again. At least until beta-6,
hobbitd_alert would then keep on sending out alerts for a test that
had gone green while Hobbit was off-line, so I turned this checkpoint
option off - which means that after a restart you may get some alerts
that would not appear had Hobbit not been restarted.
But thinking about the changes in how alerts are managed, I believe
it is safe to turn this back on. So if you like, you can try adding
"--checkpoint-file=$BBTMP/alerts.chk" to the hobbitd_alert command in
hobbitlaunch.cfg .
Regards,
Henrik
More information about the Xymon
mailing list