Here is what I collected from postings regarding UniData log and error log placement. Feel free to forward anything I missed. Note - some of the comments strayed into application architecture and log level determination and reporting - beyond the original discussion of log placement. If we make log location configurable, we will have to think thru things like:
- Are these udtconfig settings that are fixed for all users until the UniData daemons are stopped and restarted? - Are these environment variable settings that could vary per user session? (I don't think so). - What happens to one set of logs when the settings are changed and startud is run? Do we remember the old location and migrate the saved_logs to the new location? I'm sure there are many more. Additional comments welcomed, Regards Wally My original posting on 3/15/10 (responding to a general comment): I would be happy to entertain (and formally register) a detailed, coherent proposal for logs, error logs, diagnostic logs - location and management. Do you still want the saved_logs directory concept? (20 or configurable? Iterations saved) What happens at 'startud'? Anything happen at 'stopud'? Is the trunclog command useful? Should the detailed UniBasic run-time error message logging provided by 7.2.0 /usr/ud72/include/msglevelconfig be placed separate from udt.errlog? Should RFS have a separate log for error messages? Should RFS Archiving - have a separate log for offload messages? Client/server debug logs are inconsistent in configuration and activation. What would you propose in this area? Locations must be discoverable by tools that collect information for diagnostics (such as udtdiag). What else am I missing? Whereas I am constantly requesting more usable content of the messages, can we just focus on the overall architecture for this specific proposal? This would be something to be considered by PM for UniData.NEXT and prioritized with the rest of the enhancements. Other venues for proposals such as this are u2-users better and better forum and the UniData CAB (just recently formed by PM). >From Dan McGrath on 3/15/10: Location, if fixed: $UDTHOME/log[s]/server/ $UDTHOME/log[s]/client/ This allows client and server logging to be on separate mount points if the admin desires, without needing the configuration options If configurable, just make the parameter a path relative to $UDTHOME Saved_logs: Yes. Saved_logs is the right concept. Having it either in the log[s] directory or configurable relative to $UDTHOME would be an acceptable option. Trunclog: I do believe it is useful. We have at least 1 application here that would have benefitted from this command. One caveat, however. Having the possibility of log data being lost is not acceptable in a production environment. Maybe instead of 'trunclog' a 'SwitchOutLog' would be better. This would instead to processes that are logging to close there current log file, move it out to the saved_logs directory and open a new one. A slightly more complex solution of writing to a temporary log file while the trunclog/switchoutlog was in process would prevent data loss without causing a system to pause while the logs are processed. RFS: Having RFS logging separate would make any automation of monitoring them easier to tune. If something is considered a separate sub-system, it should either have its own log file, or the log file contents should be structured in a manner where the particular sub-system in question can be found in a consistent manner/location. I cannot really speak about RFS logging however, as we are not running it so I have no idea of the volume of logging data being generated. This isn't a detailed proposal (or perhaps even coherent), as I'm not sure work would be happy with me doing it on the clock, but it is some general ideas on the architecture. >From Steve Romanow on 3/16/10: Nothing prevents us from using syslog right? Ive been thinking about logging a lot lately. Specifically, syslog-ng or rsyslog. Any unix db should log to syslog. >From Bill Haskett on 3/16/10: What's wrong with syslog? We use Windows. I don't have a problem with UD logging to the event log, but many applications log to their own standard area. UD logging needs to be configured, so having that in the same area would be nice too. cross-platform? I suspect, all U2 logging should configure in one location/directory and write to one location/directory. Every logging needs archiving and I understand "@UDTHOME/bin/saved_logs" does that, although "@UDTHOME/logs/saved_logs" would be a better location. It could be nice to have a structure like: @UDTHOME + config + logs + saved_logs ...and one could have an environment variable names @UDTCONF and @UDTLOGS where one could offload these directories somewhere else. >From Susan Lynch on 3/16/10: Just because I have not noticed anyone else responding to your question about the saved_logs, yes, please keep that concept - I, for one, end up checking the saved_logs quite a bit when I get calls after the client has already rebooted in order to get their users working again. I would hate to see all that good data go away! I would think that a configurable number of iterations would be optimal, given that your team would be going in and doing a lot of work here anyway. >From Steve Romanow on 3/17/10: Something that I miss in unidata that I seem to remember from Universe is the rotating log of the last one hundred errors. It has been many years, but that was a nice concise resource for seeing benign things such as typos at ECL, but also had info about distributed files, key problems, etc. >From Doug Averch on 3/22/10: I guess I'm the taker. There is this nice open source product called log4c. It can log to files, syslog or any other destinations. It is modeled after an open source product we use called log4j. It runs on HP, RedHat, Solaris, AIX, and Windows. But since it is open source, you can port it any other platform as well. Perhaps the best part is the logging levels (TRACE, DEBUG, INFO, WARN, ERROR, and FATAL). That adds standard granularity to the logging. Additionally you can reformat the logging into any format you want. You can control the size and the number of logs you want to keep. I pulled this from our log4j configuration on our U2WebLink middleware product: # Loggers log4j.logger.com.u2logic.XLr8U2Interface.U2WebLinkLogger=INFO,U2WebLinkFileA ppender log4j.logger.com.u2logic.XLr8U2Interface.XLr8ReplicatorLogger=INFO,XLr8Repli catorFileAppender log4j.logger.org.quartz=INFO,QuartzSchedulerFileAppender log4j.logger.org.directwebremoting=INFO,DirectWebRemotingFileAppender # # U2WebLink Log File Appender log4j.appender.U2WebLinkFileAppender=org.apache.log4j.RollingFileAppender log4j.appender.U2WebLinkFileAppender.File=logs/U2WebLink.log log4j.appender.U2WebLinkFileAppender.Append=true log4j.appender.U2WebLinkFileAppender.ImmediateFlush=true log4j.appender.U2WebLinkFileAppender.layout=org.apache.log4j.SimpleLayout log4j.appender.U2WebLinkFileAppender.MaxFileSize=1000KB log4j.appender.U2WebLinkFileAppender.MaxBackupIndex=10 What this means is your entire code must be changed to accommodate this new logging structure. Additionally, you could use standard tools for you log analysis instead of writing your own. We use an open source tool in Eclipse to analyze our logs that even allows us to see them live over the internet. Wally Terhune U2 Support Architect Rocket Software 4700 S. Syracuse Street, Suite 400 * Denver, CO 80237 * USA Tel: +1.720.475.8055 Email: wterh...@rs.com<mailto:wterh...@rs.com> Web: www.rocketsoftware.com/u2<http://www.rocketsoftware.com/u2> _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users