Re: Custom log file

[Marco Ermini]

On 5/10/05, Jan-Henrik Haukeland <address@hidden> wrote:
> I have some comments. First, I strongly encourage you to try and
> refactor the current log implementation. If you have to delete all of
> the old log.c file, that's fine - no problem, but please let's try
> *not* to have two implementations or ways to log in monit. I
> understand that it is easier to bypass the old code, but in the long
> run it is easier for us to maintain one code base for logging and it
> is easier for users to have one way to setup logging.
> 
> Other comments,
> 
[...]
> b) Make the default log format the same as the old format used in
> monit. That is, if no log format was specified, the old format is used.
> c) Drop "set customlog" and use the standard "set logfile" and
> support the syslog keyword
> d) Drop "set customlog format" and use [set logformat "..."] You
> could or probably should have a condensed version like [set logfile /
> var/logs/monit.log and use logformat "..."]
> 
> Both c and d above is based on that we should only have one way to
> setup logging in monit.

I understand your point.

But - :-( - by now I will try to conclude the first part of the work
using a new and different log file. For two reasons: I am finishing
the scheduled days :-( and I think that having a different log file
have a sense too (at last to me).

I need an _applicative_ log file which would _only_ serve to be
watched by OpenView, totally unrelated to straight Monit issues (i.e.
if Monit crashes etc.) and a "Monit" log file which will also register
Monit's issues. This log file it's not related to Monit internal
issues, look at it as an SNMP trap - the sense is that i could write a
file or send SNMP traps, either could be "attached" to OpenView.

i think the future would be the ability to have as many log files as
you want, and configurable as you want, but it's a little too much for
5 working days... :-/


> a) Support syslog, by either using the old code or add new code

This should not be a problem, since I am reusing the old code.


> I can understand why you will want to add a severity and maybe an
> alarmdid to a certain event, as suggested here,

I think that the alarmid is needed in many enterprise environments
since generally the monitoring stations need to match the "raising"
and the "closing" of an alarm. The "auto" keywords would serve to
generate IDs automatically (I am not sure I will succeed to do the
last in time)


> check host localhost with address 127.0.0.1
>     if failed port 80 protocol http then
>        alert and log "message" alarmid 33 severity warning
> 
> This looks OK to me and I cannot see how this could be done better?

As long as it's a matter of changing the syntax and keywords, it's not
a big issue. I could change it later if you come up with a better idea
:-)


> If you, behind the scene go the extra mile and make "log" a real
> event like alert, exec and so on, you will also have (almost)
> implemented this planed feature, http://www.tildeslash.com/monit/doc/
> next.php#21 which would be great :-)

Uh, I never though about it at all :-)

Now I don't have much time to think about it, but for sure in a near
future I will look at it. It's a different approach at the solution I
am implementing, with a different philosophy, I don't look at it as a
solution for me or a "final solution" for what I am doing - it's a
different thing, my approach is what I definitively need - but it
could be useful too and it should not be too difficult to take this
extra mile.

Now I am totally concentrated on concluding my effort (the scheduled
days are almost gone - I will try to do some "volunteer" work but I
can't assure I will have the time); I am trying to spread the Monit
usage on my environment so I maybe I could have some more paid time
later :-)


> Another thing, if "message"
> should be part of this log statement, it should probably also
> override the default message generated by monit when this event is
> logged?

As long as it's a "dedicated" log it's not a problem, when it's a
unique log I think it should. I don't want any other message than the
one I _want_ to generate.


> Other than that, this very looks promising!
> 
> 
> On 10. mai. 2005, at 19.49, Marco Ermini wrote:
> 
> > Sorry for the cross-post. I was not sure which lists was the best
> > to ask...
> >
> > I am implementing the custom log feature for monit. I am doing it very
> > tight to my needs, however since I am doing it, I think is it worth
> > asking if someone wants some different features, or maybe tell me that
> > I am going in the wrong way.
> >
> > I am not changing the "standard" log file; I find it better (for
> > compatibility issues and simplicity, too) to implement a new log file
> > which would be possible to customize.
> >
> > The keywords I programmed were two "set" statements and an extension
> > of the "event" case:
> >
> > 1) set customlog <PATH> (i.e /var/log/custommonit.log)
> >
> > It creates the custom log file in a similar way than the "normal" log
> > file - the only difference is that it cannot be syslog (could it be
> > useful? I don't think so).
> >
> > 2) set customlog format <STRING> (default "%D, %T, %A, %S, %M, %T")
> >
> > The format will use the following substitutions; %D=date, %T=time,
> > %A=alarm-number, %S=severity, %M=message text, %T=event type
> > (suggestions for other substitutions are welcome).
> >
> > Then I added the possibility to specify a custom log for every event
> > which could occurs, to populate the custom log with the appropriate
> > string whichever events occurs. I.e.:
> >
> > check host localhost with address 127.0.0.1
> >    if failed port 80 protocol http then alert log "message" alarmid 33
> > severity warning
> >    if failed port 8080 type tcp then alert else if recovered then
> > unmonitor log "message" alarmid auto severity warning
> >
> > the keywords I added are:
> >
> > log = to be inserted AFTER the "then" statement or "recovered"
> > statement, if present
> >
> > alarmid = Numerical ID which unequivocal identifies an alarm. It will
> > be used to correlate alarm events with clear events (recovers). The
> > alarm and the correspondent clear will have the same ID, only that the
> > clear will have severity=normal. If you specify alarmid=auto monit
> > will use a
> >
> > severity = must be on of the following: NORMAL WARNING MINOR MAJOR
> > CRITICAL FATAL - "normal" should be used to clear an alarm and is
> > automatically used in the case of recover, but monit will not really
> > check whichever severity you choose - this is up to you.
> >
> >
> > Of course it follows the logic of my particular needs (although it
> > should be useful to many people here), but if someone have a request,
> > since I am already digging into the CVS code... just ask :-)
> >
> >
> > Regards.
> > --
> > Marco Ermini
> 
> --
> Jan-Henrik Haukeland
> Mobil +47 97141255
> 
> 


-- 
Marco Ermini
http://www.markoer.org
Dubium sapientiae initium. (Descartes)
address@hidden # mount -t life -o ro /dev/dna /genetic/research
<< This message is for the designated recipient only and may contain
privileged or confidential information. If you have received it in
error, please notify the sender immediately and delete the original.
Any other use of the email by you is prohibited. >>