Arno Lehmann wrote:
> Hello,
> 
> 11.01.2010 11:47, Richard Hartmann wrote:
>> Hi all,
>>
>> we are deploying Bacula on more and more hosts and up to now, we like
>> what we see :)
>>
>> We added some functionality around Bacula in order customize it. Amongst
>> others, we created trigger for our monitoring solution that inform us of
>> any failed jobs.
> 
> I wonder why you needed additional Bacula functionality here - the 
> messages resource (or a run after job script) is quite good for 
> passing job status to, for example, Nagios.
> 
>> Trying to keep relevant data as close to the original source as
>> possible, I am lacking a system to ACK failed jobs. I.e. I need a
>> mechanism to store the information that someone looked at a specific
>> backup job and decided that it's OK (or at least, that it is being
>> handled).
>>
>> To achieve this end, I can imagine several solutions:
>>
>> 1) Add a field timestamp field called 'ManualVerification' to the Job
>>    table. If set to non-NULL, it means that someone verified the job
>>    at this specific date.
>>
>> 2) Add a BOOL and a timestamp, analogous to the above (this less
>>    implicit data storage might appeal to some people)
>>
>> 3) Add a table JobState with the fields
>>    JobId (foreign key)
>>    Type (ENUM; ACKJobFailure, ACKJobWarning, ...)
>>    Name (text; of the person verifying, maybe a proper foreign key to a
>>     new Table called User)
>>    Timestamp (timestamp)
>>    Comment (text)
> 
> I really don't think that Bacula should have that functionality. 
> First, ack'ing job problems is rather useless inside Bacula IMO - or 
> do you want to mark failed jobs as ok afterwards?
> 
> Instead, I think a system-wide monitoring solution (probably linked to 
> a ticketing system) is the right place to track issues, fixes, notices 
> of that kind. Not only are there such system available, but trying to 
> keep monitoring and state acknowledgement as close to the source as 
> possible sounds like you'll have to extend most of the software you 
> use, too. I don't think that's an investment that will pay back.

The external ticketing system sounds very good to me for this solution. 
  Far less risk of breaking something.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to