Last I recall, the syslog facility of ONTAP didn't work so well (probably 2-3 years ago) or the granularity was insufficient to make it useful.
It seems ONATP is logging a lot more these days, and the messages file is so full of "crap" (i.e., informational messages) that seeing real problems or security issues requires me to write an external perl script, albeit a simple one, to parse the logs.
If anyone is using etc/syslog.conf, would you please comment on how well or not well it works for you? Maybe include yours if you have a particularly interesting or clever filtering scheme?
And, NetApp, can you please fix this? The second line of these related messages doesn't contain a timestamp. Really fools up anything that expects it:
Sun Nov 12 17:56:50 EST [Java Thread]: TimeDaemon: timed: adjusting time: filer thinks time is Sun Nov 12 17:56:50 EST 2000. Time reported by time server time is Sun Nov 12 17:56:50 EST 2000 (skew -0.071 secs).
Thank you.
Until next time...
The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---
Todd C. Merrill writes: [...]
And, NetApp, can you please fix this? The second line of these related messages doesn't contain a timestamp. Really fools up anything that expects it:
Sun Nov 12 17:56:50 EST [Java Thread]: TimeDaemon: timed: adjusting time: filer thinks time is Sun Nov 12 17:56:50 EST 2000. Time reported by time server time is Sun Nov 12 17:56:50 EST 2000 (skew -0.071 secs).
Not the only one like that. My bete noir is
Thu Nov 16 17:16:17 GMT [de4]: uid 261 tid 1: disk quota exceeded on volume CUS. Additional warnings will be suppressed for 30 minutes or until a quota resize.
We suppress those from the console by raising the level to kern.warning and <everything-else>.info, while keeping *.info for /etc/messages, but that's far from satisfactory.
The timed messages can be turned off by "options timed.log off", and we do -- but what I would prefer is a timed.log.min_jump so that I could see all steps of > 1s (say), but not the smaller deltas.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
On Fri, 17 Nov 2000, Chris Thompson wrote:
The timed messages can be turned off by "options timed.log off", and we do --
I *do* want all the messages I get now, including time changes. I just want to change the buckets they go into, instead of one big bucket.
I guess I'll just have to try it and see what happens! Hopefully, the syslog logging has improved much since last time I played with it.
Until next time...
The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---
Chris Thompson writes:
Not the only one like that. My bete noir is
Thu Nov 16 17:16:17 GMT [de4]: uid 261 tid 1: disk quota exceeded on volume CUS. Additional warnings will be suppressed for 30 minutes or until a quota resize.
We suppress those from the console by raising the level to kern.warning and <everything-else>.info, while keeping *.info for /etc/messages, but that's far from satisfactory.
That one is particularly annoying because of the \n (newline) between the `[...] on volume XXX.' and `Additional warnings will [...]'.
Two things need to be fixed here: 1. The newline has to go. syslogs have a given format and a random string in there because a programmer stuffed up and put a \n in a format string is not acceptable. 2. Maybe the ``Additional warnings will be suppressed'' line needs to have a similar suppression algorithm; I.e, it only appears once per quota resize or 30 minutes ;-)
Mind you, it's better than how it used to be; we used to get 100MB - 300MB per week from /etc/messages because of the quota overflow messages. Now they're around 100-300K (1000x smaller) with that change.