Core File Alerts Problem
list Nick Pettefar
We are using Xymon 4.3.10 to monitor Solaris hosts, mostly Solaris 10. We want to have a Yellow alert when we get a core dump file in /var/core and a Green diamond when there isn't one. Currently the behaviour is erratic with either a white face or a green diamond if there is a core file and a grey square if there isn't one. We have the following in our client-local.cfg file on the Xymon server: [sunos] file:`ls /var/core/core*` and this in the analysis.cfg file for each relevant server: FILE %^/var/core/core.* NOEXIST yellow but it obviously doesn't work! Regards, Nick Pettefar
list Paul Root
I think you want /var/core/core.* in the client-local.cfg It's regex not just wildcard, so you need the . to stand for anything and * is 1 or more. This is what I have: analysis.cfg: FILE %^/core.* YELLOW NOEXIST client-local.cfg:file:`ls /core.*`
▸
-----Original Message-----
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Nick Pettefar
Sent: Wednesday, July 29, 2015 9:27 AM
To: xymon
Subject: [Xymon] Core File Alerts Problem
We are using Xymon 4.3.10 to monitor Solaris hosts, mostly Solaris 10.
We want to have a Yellow alert when we get a core dump file in
/var/core and a Green diamond when there isn't one. Currently the
behaviour is erratic with either a white face or a green diamond if
there is a core file and a grey square if there isn't one. We have
the following in our client-local.cfg file on the Xymon server:
[sunos]
file:`ls /var/core/core*`
and this in the analysis.cfg file for each relevant server:
FILE %^/var/core/core.* NOEXIST yellow
but it obviously doesn't work!
Regards,
Nick Pettefar
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
list Jeremy Laidman
▸
On 30 July 2015 at 00:54, Root, Paul T <user-76fdb6883669@xymon.invalid> wrote:
I think you want /var/core/core.* in the client-local.cfg It's regex not just wildcard, so you need the . to stand for anything and * is 1 or more.
I'm pretty sure it's not a regex for the term in backquotes - the string is simply given to /bin/sh to execute. Can you test yours by creating a core file? I think the real problem is that the NOEXIST test won't even be executed when there are no files, because there's no file to test against. Consider if I wanted to test for the existence of /tmp/badfile, and go yellow if it exists. In client-local.cfg I would have: file:/tmp/badfile In analysis.cfg, I would have: FILE %^/tmp/badfile YELLOW NOEXIST This should work just fine. Now consider if I updated client-local.cfg to look like this: file: Now, what will happen? The Xymon client will have no files to report, and so there will be nothing relevant in the client data. Therefore the entry in analysis.cfg has no filenames to match on, and so won't even try. The fact that there's no filenames to test means that the file check goes blank, reporting that the file check has not been setup yet. By including a backtick expression that gives an empty result, you're producing an outcome that you weren't expecting. I think what might give what you need is something like this: FILE:`ls -d /var/core; ls /var/core/core*` When there are core files, the result of this will be as if you configured: FILE:/var/core FILE:/var/core/core91234 FILE:/var/core/core2244 And the line in analysys.cfg will match two of them, so YELLOW. When there are no core files, the result will be as if you configured: FILE:/var/core And the line in analysis.cfg will not match, so GREEN. It's green rather than clear because there is at least one "[file:]" section in the client data against which the line in analysis.cfg can match. Hope that helps! Cheers Jeremy
list Nick Pettefar
Thanks Jeremy! Finally got it working OK! Regards, Nick Pettefar
▸
On 31 July 2015 at 05:59, Jeremy Laidman <user-71895fb2e44c@xymon.invalid> wrote:On 30 July 2015 at 00:54, Root, Paul T <user-76fdb6883669@xymon.invalid> wrote:I think you want /var/core/core.* in the client-local.cfg It's regex not just wildcard, so you need the . to stand for anything and * is 1 or more.I'm pretty sure it's not a regex for the term in backquotes - the string is simply given to /bin/sh to execute. Can you test yours by creating a core file? I think the real problem is that the NOEXIST test won't even be executed when there are no files, because there's no file to test against. Consider if I wanted to test for the existence of /tmp/badfile, and go yellow if it exists. In client-local.cfg I would have: file:/tmp/badfile In analysis.cfg, I would have: FILE %^/tmp/badfile YELLOW NOEXIST This should work just fine. Now consider if I updated client-local.cfg to look like this: file: Now, what will happen? The Xymon client will have no files to report, and so there will be nothing relevant in the client data. Therefore the entry in analysis.cfg has no filenames to match on, and so won't even try. The fact that there's no filenames to test means that the file check goes blank, reporting that the file check has not been setup yet. By including a backtick expression that gives an empty result, you're producing an outcome that you weren't expecting. I think what might give what you need is something like this: FILE:`ls -d /var/core; ls /var/core/core*` When there are core files, the result of this will be as if you configured: FILE:/var/core FILE:/var/core/core91234 FILE:/var/core/core2244 And the line in analysys.cfg will match two of them, so YELLOW. When there are no core files, the result will be as if you configured: FILE:/var/core And the line in analysis.cfg will not match, so GREEN. It's green rather than clear because there is at least one "[file:]" section in the client data against which the line in analysis.cfg can match. Hope that helps! Cheers Jeremy