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
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
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon 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.
On 30 July 2015 at 00:54, Root, Paul T <Paul.Root at centurylink.com> 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
Thanks Jeremy! Finally got it working OK!
Regards,
Nick Pettefar
On 31 July 2015 at 05:59, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:
On 30 July 2015 at 00:54, Root, Paul T <Paul.Root at centurylink.com> 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
participants (3)
-
jlaidman＠rebel-it.com.au
-
Nick＠pettefar.com
-
Paul.Root＠CenturyLink.com