[Xymon] trying to monitor non-standard logfile with server client-local.cfg and failing

[Jeremy Laidman]

Glad to see you have it working now.

Yeah, two Xymon servers means the second one's client-local.cfg is used
because it's the one that the client contacts last of all. I've been bitten
by that several times in the past.

J

On Sat, 25 June 2022, 01:42 POLYAK, TIM P, <tp6891 at att.com> wrote:

> Hi,
>
>
>
> What I meant by non standard log file was just not the default
> /var/adm/messages.
>
> Looking at the contents of a different file example /var/adm/6800.log.
>
>
>
> Server client-local.cfg file
>
> [Fully-Qualified-Hostname]
>
> log:/var/adm/messages:10240
>
> file:/var/adm/6800.log
>
> log:/var/adm/6800.log:10240
>
>
>
>
>
> Update I did find my trouble. I was updating 1 of 2 xymon servers
> correctly the test/backup server but I found the primary xymon server was
> over writing my changes in the tmp/logfetch.Fully-Qualified-Hostname.cfg
> after the test/backup server made the changes. I was in a loop where 1
> xymon server made the change and the other xymon server changed it back.
>
>
>
> Thank you for pointing out the xymon server updates the client
> tmp/logfetch.Fully-Qualified-Hostname.cfg when you make changes to the
> servers etc/client-local.cfg
>
>
>
> Thanks
>
> Tim
>
>
>
>
>
>
>
> *From:* Jeremy Laidman <jeremy at laidman.org>
> *Sent:* Wednesday, June 22, 2022 6:53 PM
> *To:* POLYAK, TIM P <tp6891 at att.com>
> *Cc:* xymon at xymon.com
> *Subject:* Re: [Xymon] trying to monitor non-standard logfile with server
> client-local.cfg and failing
>
>
>
> Hi Tim
>
>
>
> On Thu, 23 Jun 2022 at 02:24, POLYAK, TIM P <tp6891 at att.com> wrote:
>
> I am trying to monitor non-standard logfile with server client-local.cfg
> and failing.
>
>
>
> Can you explain how it's non-standard? Are you trying to monitor the
> contents or the attributes of the file? Would a "log:/var/adm/6800.log"
> entry be more suitable for a logfile?
>
>
>
> Here is what I tried so far in the client-local.cfg file
>
> [host=hostname]
>
> file:/var/adm/6800.log
> and
>
> [hostname]
>
> file:/var/adm/6800.log
>
>
>
> The correct format is the latter.
>
>
>
> Firstly, note that it can take something like 10 minutes for log/file
> monitoring to start reporting due to delays in propagating the config to
> the clients, and then for the clients to report back again based on the
> config.
>
> What I would do is look in the $XYMONTMP directory on the client (defined
> in xymonclient.cfg, often /tmp, /var/tmp or /dev/shm) for the temporary
> files created by the client. They will be called logfetch.<hostname>.cfg
> and logfetch.<hostname>.status.
>
> The cfg file is essentially just the [hostname] section from the
> client-local.cfg, retrieved when the client last reported to the server.
>
> The status file has a line for every "file:" entry in the client-local.cfg
> file, and is used to track the logfile position on each run. If you don't
> have any "file:" entries in your client-local.cfg file for a server, it
> might not have a status file.
>
> So, first see if the cfg file is present. If not, your update to
> client-local.cfg might not have been detected by the xymond process on the
> Xymon server. Usually it picks this up by itself, but if not, you could
> restart xymond and see if that helps (again, wait 10 minutes to see
> progress). If the cfg file is present, see if its contents make sense (that
> is, match what's in the client-local.cfg file on the server).
>
> J
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20220625/ae18b6ca/attachment.htm>