new log files on OpenVMS periodically

[Bo Midberg]

Have finally settled down to review logging activity. Found some logs started 10 years ago when system was installed. Trying to find out which logs that ought to be renewed periodically. So far I've localized the following:

> OperatorLog (sys$errorlog:errlog.sys)

> ErrorLog (sys$manager:operator.log)

> AccountingLog (sys$manager:accountng.dat)

> AuditLog (SYS$COMMON:[SYSMGR]SECURITY.AUDIT$JOURNAL)

> LogFiles-SWS [Secure Web Server] (like apache$specific:[logs]*_log.)

Are these sufficient, or are there still some log files that are recommended to renew?

The procedure to renew differs between these logs, but I think those are well documented.

[abrsvc]

Opinions will vary, but this is usually a local decision.  Many of the clients that I service renew logs on a regular basis based mostly upon the need to review history when a problem occurs.  Large accounting files for example, take a long time to search.  Having smaller files may make searching more complicated by forcing the search to span multiple files, but howoften will these searches be necessary?  Most clients base their schedules on disk space usage and backup times.  I have a few clients that archive the older files on a "log disk".  This removes them from daily backups and keeps hte disk space consumption down while leaving them online and available.

YMMV is hte bottom line.  Set up a system that works for you.

Dan

[Bo Midberg]

Actually, I agree that the renewing of logs depends on the needs to investigate and use the logs in first case, and thereafter regarding space considerations.

Anyhow, that was not the main question. The main question was/is regarding, which additional log files that might be worth to investigate and renew. I'm aware that there might be additional software like database handlers that produce and hopfully maintain their own logs, but my main concerns were/are primarily of the most common logs that the operating system and its normal components provides or might be configured to log.

There are products like CIFS/Samba that also provide logs, but in this case the product itselft has a default philosophy of maximum size on each log file and a maximum of 10 retained retained old log files. The main concerns are not regarding product that by itself maintain the log files.

[Mark_Corcoran]

We roll the log files that you've specifically mentioned, and we also roll application log files.

Some of the log files are archived at the start of a new month into a .ZIP file, but with the last month - to - two months' worth of log files kept in an uncompressed state so that they can still be accessed without the rigmarole of having to unip them first (we also use a specific directory tree naming convention that has [logtype.YYYY.MM_MMM] for storing the uncompressed files, and when they get deleted, for a particular month/year end, the month/year directories are deleted as well;  the .ZIP files are moved from [logtype.YYYY.MM_MMM] directories into [logtype.YYYY] and then [.logtype] depending on the month/year end).

Currently, disk space is not an issue (though keeping the logs for a prolonged period of time (even in compressed format) does add to the amount of time taken to back them up.

Depending on how the systems are used there may be other logs that you need/want to keep, e.g.

1) For "poor-man's session logging", are you forcing user sessions to be recorded using SET HOST/LOG= ???

2) If you have inbound FTP connections, do you take a copy of the TCP/IP stack's FTP daemon log file (I know that in the version of UCX that we use, you have to do a BACKUP /IGNORE=INTERLOCK of FTPD.LOG, but more recent versions and/or other stacks (Multinet TGV, TCPware, Wollongong Pathway) may differ.

3) It's been a while since I've used VAX PSI Access, so I don't recall whether or not it has any similar logs that are worth keeping (obviously, it depends on whether or not you use it), but other "true" layered products supplied by the likes of HP or Oracle (e.g. RDB or "true Oracle") may have similar logs (e.g. is the system used for development, and if so, do you use CMS, and keep a copy of the version/change information?;  what about Pathworks?)

Just my 2p's worth.

Mark

[Mark_Corcoran]

Bad form, following up to my own reply, but it also occurred to me, potentially any SMTP or web server logs (we don't have provide a web server instance, and my recollection is that as we are only acting as an outgoing SMTP client rather than a server, there are no SMTP logs as such (I think that whilst a message hasn't yet been sent, it exists as a temporary file, and for messages that failed to be sent, the temporary file possibly hangs around for a while, but this is effectively the email body (possibly also another file that contains the header information, or destination, effectively an SMTP queue entry).

If you have any other Corba/message queueing application or if you use a scheduler other than plain-vanilla OpenVMS batch, those products may also have their own log files (which, whilst not being "standard" OpenVMS logs in comparison to other OpenVMS systems that don't use them, you might consider to be part of the "base" O/S system).

Mark