Jump to content

alche

Members
  • Content count

    35
  • Joined

  • Last visited

Community Reputation

0 Neutral

About alche

  • Rank
    Newbie
  1. alche

    Retro8 Log Analyser

    Download the Runtime or the Source Code file from the Lintburger Software Page. New in Version 1.2.2 (Sep 29, 2010) Made more compatible with Retrospect 8.2 Log format, especially date time parsing. Compiled as a Filemaker 11 Runtime. Source Code still works with Filemaker 10. Charting: Integrated the Date display on the main chart webviewer so you don't have to syncro-scroll the graph with the date labels. Executive Events List View: Added a Summary Only view, with a percentage of Total summary calculation, to allow you to more easily figure out which Machines are eating up what amounts of data. Created an Applescript Applet to automate the process of getting Log Data from Retrospect to the Filemaker Database. Cron the launching of "Automate Import Runtime.app" to make it super automatic. May not work if you have a locked screensaver running on your machine. Source Code provided as a .scpt file, in case you want to make modifications. Other minor bug fixes and enhancements. Remember: to import your old data into the new file or Runtime, pull down the "Scripts" menu and select the "Import from an Older Copy of Retro8LogAnalyser" command. Let me know if there's any problems with the new version.
  2. alche

    Retro8 Log Analyser

    I think 1.2.1 has some problems with Retro 8.2. I've attached a beta of RetroLogAnalyser 1.2.2. I'm not quite done testing it fully yet, but it should be ok. Give it a try. (This version requires you to have Filemaker 10 or 11.) I'll be posting the official update soon, with the Filemaker Runtime so that you don't need to own Filemaker, but this will hopefully tide you over.
  3. alche

    Retro8 Log Analyser

    Hi John, The problem isn't FileMaker's ability to import on a recurring basis (that can be done in a number of different ways). The problem is that the RetroLog.utx file, where all the log data is stored, is incomprehensible to me. It's filled with what appear to be variables that only make sense to the RetroConsole App, in conjunction with a Server configuration. I can't parse this file. I have to rely on the "interpreted" output of this file, which is currently only available by using the Show Log command from within the RetroConsole app. 2 ways around this: 1. Retro Engineers do something that allows RetroServer to output a plain text log file using the built in scheduling engine, preferably in a coherent delimited format. (Currently, I have to read the log data almost as if it were a story.) 2. You could write an Applescript that does the following: Launch Retro Console wait issue a CMD-L wait CMD-A CMD-C Launch RetroLogAnalyser wait issue a CMD-1 wait CMD-V ENTER wait ENTER Tie it to a crontab on a computer that's running all the time (without screensaver) and you've got Automation.
  4. alche

    Retro8 Log Analyser

    Sorry about that. Typo. It's fixed now.
  5. alche

    Retro8 Log Analyser

    Version 1.2.1 is out. It addresses the issue of when the International System Preference is not set to use US formats by embedding the US format in the Filemaker Pro database file (effectively ignoring your International setting). This is necessary due to the fact that Retro Log Data uses dates that are always mm/dd/yyyy. I believe this should address the issues posted above without requiring user intervention. Please let me know. There's a couple of other minor tweaks and fixes as well. Download from Lintburger Software Page Cheers, Paul
  6. alche

    Retro8 Log Analyser

    That's strange. Can you tell me which screen you are seeing this in? My logs are being correctly interpreted, as far as I can see. Might also be useful to know what Date & Time settings you are using in System Preferences>>International>>Formats.
  7. alche

    Retro8 Log Analyser

    Try the "Generate Machine Records" script under the Scripts menu. Will automatically generate Chart records for all the Machines it can find in the Exec Events table. Otherwise, yes, you have to create records manually for Machines. Figured some people with large lists of machines might not want automatic here. And, agreed about the copy/paste, but sadly can't do anything about it at this point (see my post above). Cheers, PF
  8. alche

    Retro8 Log Analyser

    Thanks! As for taking directly from the server log file, I did try, but the operations_log.utx is much less readable to the layperson. It contains what appears to be variable placeholders and some raw code that I can't quite grasp. If a future version of Retro8 wrote the readable log file out to a directory somewhere (which would be specifiable in a preference setting), then I could easily just suck in the new data into the Analyser without forcing anyone to copy/paste, and without needing to do any date parsing to figure out where the log overlap was. I would simply keep track of the last line processed and only import data from there. The copy paste method isn't the end of the world, but it can introduce problems. A few weeks ago I deleted several SVN directories from my web server, apparently mid-backup. The Retro Log promptly filled up with around 20,000 lines of file errors. The next morning, i did my usual copy paste and it buggered up my log processor. I have my Log Display set to 2000 lines and so it wasn't making it anywere near the start of the previous nights backups, which kinda screwed everything up. (Luckily, there's the "Delete from last Import" script to deal with these problems). I had to change my Retro Log pref to view 30,000 lines, copy/paste, then swich my pref back to the usual 2000 lines. If I we were looking at a static file instead, I wouldn't have had this problem, and I could make the Analyser process the logs unattended on a timed basis, and even send emails. (Of course, this would introduce the problem of having a log file of unlimited size eating up drive space. Mind you, I haven't seen operations_log.utx rotate, or clip early entries, so this may already be the case.) Until then it's CMD-L, CMD-A, CMD-C, CMD-TAB, CMD-1, CMD-V. Actually, a bigger problem is data inaccuracy in the log file. The CMD-L reports data sizes in GB/MB/KB as needed. This introduces rounding errors when compounding lots of log lines and trying to add them up--not a huge problem but there might be up to a GB of error after a lot of executions. Worse than that is when Retrospect crashes mid-execution. I had this happen over the weekend. Nothing from the execution made it into the operations_log.utx file at all. But my backup disk had 15GB more than the day before. The catalog had the data, but the log buffer didn't get written out before the crash occurred. So what would be really nice would be a way to extract raw columnar data from the catalogue(s), on a timed basis. Or if Retro wrote out the columnar data for each catalogue as it was updated. Anyway, I'm working on making the charts more flexible for version 1.3, plus a few other odds and ends.
  9. alche

    Retro8 Log Analyser

    New in Version 1.2 (Dec 4 2009) Charting: Added Machine Charting. Allows you to chart the growth of backups over time for each machine, by Media Set and Date Range. Charting: Option-Click "Generate" button to automatically update the chart to the current date and move the ceiling if necessary. Shift-Click to Generate charts for a found set of records with the same parameters. Option-Shift-Click to update a Found Set of Charts. Charting: Improvements allow for proper printing of charts Added List Views for Exec Events and Charts Improvements in automatic log line deduplication; a dialog now shows you where the log line processing will start after deduplicating Other minor bug fixes and enhancements You can import data from Version 1.1. Download the new version, launch it, pull down the "Scripts" menu and choose the "Import from an Older Copy of Retro8LogAnalyser". Download from Lintburger Software Page Machine Charting Screenshot:
  10. alche

    Retro8 Log Analyser

    I've updated Retro8LogAnalyser to version 1.1 The new version allows you to mindlessly paste data from the Retrospect Log window without having to worry if it overlaps data you previously pasted in. Should make life a little easier. It will automatically keep track of the last timestamp in the log data. The next time you paste in data, it will clear the pasted data up to that last timestamp, leaving only the new log lines to process. I've also added an update engine that allows you to upgrade to future versions without having to reprocess all your data again. This won't work with the data in 1.0, but will work when I release future versions. A few other bug fixes. Can be downloaded from the Lintburger Software Page Cheers, Paul
  11. alche

    Retro8 Log Analyser

    Thanks for the delete tip Russ.
  12. alche

    Retro8 Log Analyser

    Whoops. Another double post. Can an admin delete the other post of this topic, please.
  13. I've spent the last week developing a Filemaker 10 based log analysis program for Retro8. It works pretty well, and I've prettified it and made it suitable for public consumption. Can be downloaded from here: my website (lintburger.com) The idea was to get a more systematic idea of what's going on with my backups, so summaries, running totals, and counts of errors and throughput are the goal here. There's even a chart function. Free to use, free to modify. Screenshots and more details are on software page. Hope you find it useful. Cheers, Paul Fabris
  14. Attached are the 2 most recent CrashReport Logs from this particular incident. Note: I tried creating a whole new Media Set just for this one user in case there was something corrupt in the Media Set I was previously trying to backup to. Made no difference. New Media Set, manual Backup action. 10 seconds into the backup RetroEngine crashes.
  15. I think you guys did a good job in the latest update. A lot of the usability problems of Console have been addressed and it seems to be a lot more stable, a lot more usable, and a lot less prone to chewing up CPU cycles, and so on. Scripts seem to keep remember their settings now. Unlocking media sets doesn't bring my computer and the RetroEngine to their knees. In short, I feel I can finally rely on it, and use it like a proper application. So thanks for the long list of fixes. I'd still like to see a few minor User Interface improvements though: 1. Past Backups: a) This area is useless unless you first go to Media Sets and unlock something. Can we not have it so that the list is populated with the list of past backups without unlocking? I would think Unlocking should only be necessary to Browse or Restore from a Media Set. It would be useful to be able to export the data in past backups as a CSV or TAB file to process my own backup summaries. Bonus: the ability to schedule dumps of this information so I can automate the process of summarizing my backups and monitoring my data loads. 2. Need a Tags view. Tagging is the only way to make arbitrary groups of Sources for backup scripts. It would be nice to see a Tags view where I could see what tags I have, and more importantly, which sources are associated with the tag. 3. Reordering Tagged Items. It would be useful to rearrange the order in which tagged items get backed up. This could be a global arrangement, in the Tags View, that would be honoured by the scripts. 4. Email Notifications. Could use some configurability here. The emails currently are only useful to know when a script finished: "Script: Daily-9PM Date: 9/17/2009 Script "Daily-9PM" completed with 28 errors" How about total data backed up, number of clients backed up, an option to list the errors, and the per client data tally, and the amount of space remaining on the Media Set? This is all extremely useful information when juggling hard drives. 5. Size of the bottom window pane should be resizable. Scrolling through those long lists in 13 line increments is painful. 6. Speed still needs work. I'm still not seeing the backup speeds (even local disk to disk) that I used to see in 6.1 on much slower hardware. (I'm all HD based, not waiting for tapes here). It seems a bit better in 8.1.125, but still not as fast as it needs to be. Still takes me 3 solid days to do a from scratch backup of my network, and it's around 700GB on a Gigabit LAN (250 GB of which are actually local to the Retro Server). Local Volume performance can get up to around 480MB/min (only 8MB/sec). Network performance tops out at 250MB/min (4MB/sec -- not too bad) on my fastest clients, but most clients are still doing a paltry 48MB/min on Copy. Takes forever. Thanks for listening!
×