Thanks for the fast reply. On Mon, Jan 11, 2010 at 12:33, Arno Lehmann <[email protected]> wrote:
> 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. We are using Zabbix, but in both cases the difference between monitoring from the outside and calling from within Bacula are almost negligible. Though monitoring from the outside has the advantage of being easier to verify as working correctly as I can see more errors types from the outside (Zabbix will nag if it lacks data it wants to collect whereas it _can not_ notice if an outside script fails to inject data for whatever reason) > > 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. We do have a rather sophisticated monitoring stack that is aggregating information, evaluating and forwarding relevant information trough tactical overviews, email, tickets, SMS and automated voice calls so I have that part covered. The reason I think the data storage should be within Bacula's own tables is that this way, bweb and other front-ends might offer this functionality in a single manner which is consistent in the background. I do agree that actual management needs to happen on an upper layer, but I strongly doubt that everyone baking their own basic building blocks helps in the long term. > I doubt that your ideas will be integrated into Baculas core, unless > you come up with very good reasons. In my opinion, your reasons > outlined above, are not good enough - sorry. > [...] > What I recommend to not do is, without consent from the core > developers, modifying existing tables - that could break once the > table layout is changed, and it could break Bacula itself. I hope I could clarify with the above. Out of curiosity and because I am not familiar with the project's internas: Are you developer or an advanced user? I am _not_ trying to imply anything, just want to get a general feeling of the core community towards my proposal :) > Yes and no... if you add tables, that should be no problem. It can > become a problem later, if the catalog is extended, or if an update of > the catalog schema needs to change your extensions, too. This is another reason why I prefer new tables, yes. > Creating tables in the catalog is, thus, surely an option. The > question is if they are located there reasonably... you'd need to have > some interface in Bacula to them to make that the proper choice, i.e. > bcconsole, bweb and bat should be able to manage and present that > data. And that will be much more work than merely extending the catalog. >From how I understand the current front-end model, one size does not fit all, i.e. different front-ends support different data visualization. These changes could grow naturally into the clients in which they make sense. Thanks, Richard ------------------------------------------------------------------------------ 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
