"msgs" alerts, sending 10240 bytes and line-buffering
On Aug 25, 2015, at 21:05 PM, Adam Goryachev wrote:
On 25/08/15 20:35, Greg Earle wrote:
On Aug 25, 2015, at 1:13 PM, Jeremy Laidman wrote:
You might be right that the message is being clipped. If so, you should see Xymon log messages to that effect.
Thanks Jeremy, where in the logs exactly? Do I grep for "clipped"? :-)
Perhaps add the IGNORE clause to the client-local.cfg message instead. This will cause the messages to be dropped at the client side. Not only can you forget about these messages on the Xymon server, but also you're less likely to have a clipped message. Like so:
[sunos] log:/var/adm/messages:10240 ignore refused connect from itsecurity-scanner.my.do.main
Excellent idea - hadn't thought of th... wait, hang on. The only place I have a "client-local.cfg" file is on my *server*, not on any of my clients.
Ummm, actually this file is only supposed to exist on the server, and when the client connects to report the status, it will also download a copy of it's (section) of the file and apply that for future status updates.
Note: I forget the details, but it can take 15 minutes (3 cycles) before you will see the changes applied/working.
Thanks for clarifying that, Adam. I removed the client-side "client-local.cfg" file and made the suggested changes on the server-side. The incidents of "clipped" messages file text causing red alert triggers have lessened, but I'm not sure they've stopped entirely.
Do I need to restart all of my Solaris clients to pick up this (server-side) change? (viz. "it will also download a copy of it's (section) of the file and apply that for future status updates")
- GregOn 28/08/15 10:00, Greg Earle wrote:
On Aug 25, 2015, at 21:05 PM, Adam Goryachev wrote:
On 25/08/15 20:35, Greg Earle wrote:
On Aug 25, 2015, at 1:13 PM, Jeremy Laidman wrote:
You might be right that the message is being clipped. If so, you should see Xymon log messages to that effect.
Thanks Jeremy, where in the logs exactly? Do I grep for "clipped"? :-)
Perhaps add the IGNORE clause to the client-local.cfg message instead. This will cause the messages to be dropped at the client side. Not only can you forget about these messages on the Xymon server, but also you're less likely to have a clipped message. Like so:
[sunos] log:/var/adm/messages:10240 ignore refused connect from itsecurity-scanner.my.do.main
Excellent idea - hadn't thought of th... wait, hang on. The only place I have a "client-local.cfg" file is on my *server*, not on any of my clients. Ummm, actually this file is only supposed to exist on the server, and when the client connects to report the status, it will also download a copy of it's (section) of the file and apply that for future status updates.
Note: I forget the details, but it can take 15 minutes (3 cycles) before you will see the changes applied/working. Thanks for clarifying that, Adam. I removed the client-side "client-local.cfg" file and made the suggested changes on the server-side. The incidents of "clipped" messages file text causing red alert triggers have lessened, but I'm not sure they've stopped entirely.
Do I need to restart all of my Solaris clients to pick up this (server-side) change? (viz. "it will also download a copy of it's (section) of the file and apply that for future status updates")
No need to restart the client, but you will need to ensure the section you added it to will apply to all the clients you are expecting. Since the server only returns the relevant section to the client, who might be using a different section compared to what you expected..... It should take between 10 minutes and 30 minutes for the change to be applied, if it is taking longer, then something is wrong with the config.
Regards, Adam
-- Adam Goryachev Website Managers www.websitemanagers.com.au
On 28 August 2015 at 10:00, Greg Earle <earle at isolar.dyndns.org> wrote:
Do I need to restart all of my Solaris clients to pick up this (server-side) change? (viz. "it will also download a copy of it's (section) of the file and apply that for future status updates")
No restart required. Each time a client connects to the Xymon server and sends its client data, the server then sends the relevant section in client-local.cfg, and this gets stored on the client in XYMONTMP (typically ~xymon/client/tmp/) in a file called logfetch.$MACHINEDOTS.cfg. Have a look for this file, check its contents, and see if it's what you configured in client-local.cfg. In particular, look for the 10240 value for the "log:" line having being changed, and also any "ignore" qualifier lines you've configured.
As you probably know, the Xymon client runs every 5 minutes. Because the logfetch.*.cfg file is fetched during the client data reporting run, it can take up to 5 minutes for this file to reflect the relevant section in client-local.cfg on the server. This newly fetched file will be actioned on the next client data reporting run, which is 5 minutes later. So changes on the server will be made manifest from 5 to 10 minutes later.
Cheers Jeremy
participants (3)
-
earle＠isolar.DynDNS.ORG
-
jlaidman＠rebel-it.com.au
-
mailinglists＠websitemanagers.com.au