On 2/2/24 09:03, Marco Gaiarin wrote:
Mandi! Bill Arlofski via Bacula-users In chel di` si favelave...I might be able to add this as a feature to my `baculabackupreport.py` Python reporting script - possibly quite easily. The script already has a feature to show jobs that are "always failing" for x number of days. This feature you are asking for is interesting.I've tested it, cool!
Excellent! Glad it is working/useful for you. :)OK, so here's the thing. What I have just completed is a feature that (if it finds anything to report) generates another small auxiliary table at the bottom of the jobs report, like the Summary, Pools, Success rates tables.
It currently works like this: - It internally generates a list of the last time every job name in the catalog has r un successfully. - Then it checks to see which of these last successful runs was more than 31 days ago (default setting) - Then it generates an HTML table listing each Job Id, Job Name, End Time, and number of days ago that End Time was. - It can also be told to skip any Job Names you add the the `last_good_run_skip_lst` variable.- I plan to add one more thing before pushing the changes. Namely I want to add another banner at the top when these jobs are found and the table is created. This should just take a few minutes of cut-n-paste-n-edit and should be pushed tonight. :)
See the screenshot of the new auxiliary table. The new variables at the top of the script (which should not be edited, but added/modified in the config file) are these: ----8<---- # Warn about jobs that have been seen in the catalog, but # have not had a successful run in `last_good_run_days` days # ----------------------------------------------------------warn_on_last_good_run = True # Do we warn about jobs that have not run successfully in last_good_run_days days?
last_good_run_days = 31 # Longest amount of days a job can be missed from running successfully last_good_run_skip_lst = ['Job1', 'Job2'] # Jobs to ignore when processing this `warn_on_last_good_run` feature ----8<---- > Effectively the 'always failing' could suffices, but knowing that failed > because the host was not reachable will be better!Now, there is really no way to represent the reason a job failed into the table as you ask without a few additional pieces in place.
- First, there would need to be some specific, clear, always identifiable text in the catalog's `Log` table- Next it would require yet another "costly" text query, and I had tried for the longest time to avoid these as much as possible. :)
- Third, the text to report a reason why a job failed just wouldn't fit in the HTML table cell and would make a giant mess. I think the new banner warning, and this table will let you know quickly which jobs have not completed is some (configurable) number of days. And, when configured to create an HTML link (gui = True) to the Job log in Baculum, (or BWeb in the enterprise version) it will get you to the reason for the continued failures very quickly.
I've been looking for something to work on for a while now. This might be perfect. :)Don't worry: stay warm, drink water and code slowly! ;-)
hehe Yes, it took a FULL week to be able to function properly since I returned, and to get something done on this. :) Hope this is useful! Best regards, Bill -- Bill Arlofski w...@protonmail.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
