Two other options exist:
1. Point the perf data logs to a named pipe, which is then read (and
flushed) by an external daemon that processes the data
2. Modify Nagios so that at predefined intervals:
a. The perf data log is closed
b. A user-defined command is run (to rotate the log, process perf
data, etc.)
c. The perf data is re-opened
The first option is the cleanest, but it requires another daemon.
The second option is probably a bit more flexible. What are people's
thoughts on this? Should I add option #2 into Nagios 2.0?
On 18 May 2004 at 12:05, Steve Hanselman wrote:
> It sounds the cleanest way, but I don't believe the method currently
> exists, you'd have to add it.
>
> Steve
>
>
> -----Original Message-----
> From: Ben Clewett [mailto:Ben@clewett.org.uk]
> Sent: 18 May 2004 11:54
> To: Steve Hanselman
> Cc: 'Nagios Developers'
> Subject: Re: [Nagios-devel] Deletion of the performance data log
> files.
>
> Steve Hanselman wrote:
>
> > Might be better to send a request that nagios renames the files,
> > then you can process them then delete them?
> >
> > Steve
>
> Yes, sounds like a good idea.
>
> My thoughts were converging towards making Nagios fclose() the file
> after every write. But this would slow Nagios slightly, and there is
> still the very slight risk of a lost line of data. -- But I think your
> method is better.
>
> So, using the standard CGI method of passing a command. My code can
> submit this, wait for the file to appear, and get on with parsing it.
> Nagios would then re-open the original file name and continue to
> write.
>
> Can you see and problems with this method? Does this method already
> exist, or would I have to code it?
>
> Kind regards, Ben
>
>
>
> >
> >
> > -----Original Message-----
> > From: Ben Clewett [mailto:Ben@clewett.org.uk]
> > Sent: 18 May 2004 11:13
> > To: Nagios Developers
> > Subject: [Nagios-devel] Deletion of the performance data log files.
> >
> > Dear group,
> >
> > I have a problem parsing the Nagios performance data and wonder if
> > any member can suggest a solution. These have the default file
> > names 'serviceperf.log' and 'hostperf.log'.
> >
> > I wish to parse and delete these every minute. But I cannot delete
> > them as Nagios holds the file open. Stopping and starting Nagios
> > every minute is not really an option.
> >
> > Really I want to pass a command to Nagios to request the deletion of
> > these files. However, if there is a delay between Nagios getting
> > the command, and Nagios deleting the files, information will be
> > lost. Because my program is sitting waiting for the deletion without
> > parsing.
> >
> > Ideally, I would want Nagios to write to a tmp file, then on getting
> > a command, close the file, move it to the true file, and open up a
> > new tmp file for it's self. Or get Nagios to continuously close the
> > file after every write, making it delete-safe. But this might
> > effect performance??
> >
> > If any member has any ideas, I would be extremely interested.
> >
> > Kind regards, Ben.
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: SourceForge.net Broadband
> > Sign-up now for SourceForge Broadband and get the fastest
> > 6.0/768 connection for only $19.95/mo for the first 3 months!
> > http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> > _______________________________________________
> > Nagios-devel mailing list
> > Nagios-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/lis ... gios-devel
> >
> > The information contained in this email is intended for the personal
> > and
> confidential use
> > of the addressee only. It may also be privileged information. If you
> > are
> not the intended
> > recipient then you are hereby notified that you have received this
> document in error and
> > that any review, distribution or copying of this document is
> > strictly
> prohibited. If you have
> > received this communication in error, please notify Brendata
> > immediately
> on:
> >
> > +44 (0)1268 466100, or email 'technical@brend
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: nagios@nagios.org