Hi, 11.01.2010 13:23, Richard Hartmann wrote: > Thanks for the fast reply.
You were lucky :-) (And I like to think about monitoring services and systems, too.) > 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) Well, that last point doesn't help here, I think, because in that case you'd still have to manually check the data in Bacula, which makes a central monitoring system rather useless (for this case). >> 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. Ok - that shifts the focus of your original proposal quite a bit, as it implies that the needed fron-end functionality would also be part of such a project. I'm still not convinced the funtcionality should be in Bacula itself, but with the fron-end, it would be complete enough to be usable stand alone. > 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. Well... that's adifficult question. My experience is that the needed building blocks are rather small (some of them even part of Bacula, for example the check_nagios program). Obviously, if the needed templates / documentation were part of all the monitoring solutions in the worls, that would be great, but looking at it from Bacula, integration into a monitoring environment is usually really really simple. > >> 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. The upper level, user view thingie got clarified indeed. Regarding the technical side, I don't think much clarification was necessary :-) > Out of curiosity and because I am not familiar with the project's > internas: Are you developer or an advanced user? I guess "advanced user" fits better than developer. Although I did contribute a bit of code, I wouldn't claim to be part of the core developers team. > I am _not_ trying to imply anything, just want to get a general feeling > of the core community towards my proposal :) Sure... I don't have a problem with that :-) > >> 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. Then you won't have any problems... you might find that you'll have to maintain some upgrade scripts similar to Bacula's catalog schema upgrade scripts, for example if columns change type and you use those for references, but that's a simple thing. Using table names with a prefix that's unlikely to be used by Bacula itself will make things quite safe. >> 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. Ok... if you're willing to do that work yourself - or at least to do a good part of it - I don't see any reason why a set of reasonable patches should be rejected without consideration. I guess you can't expect more ;-) (without in-depth discussion of your proposals first). Regards, Arno > > Thanks, > Richard -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück www.its-lehmann.de ------------------------------------------------------------------------------ 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
