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: [email protected]<mailto:[email protected]>
Web: www.rocketsoftware.com/u2<http://www.rocketsoftware.com/u2>
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
