This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
The next post in the series is here.
To start at the beginning, follow this link to the first post.
---------------
Last time we talked about various logs and traces and this week we’ll consider where it all should go. By default, it ends up in a logs directory which can be found in the same folder as the server configuration (server.xml). That’s quite handy and makes it easy to find, but it might not be a good choice.
The main reason is that, obviously, the server needs write access to directory in order to put the logs and traces there. Some folks might not be comfortable having the server able to write into a directory located so close to the server’s own configuration (there’s a security rule that a server shouldn’t be able to write to its own config). You could be careful with permission bits, but it might feel safer to just have anything the server writes be located somewhere else.
There’s also a space consideration. The server.xml and related files aren’t going to be terribly big, but logs and traces can get pretty large. It might be nice to keep the configuration (or configurations for several servers) in a relatively small file system and have a much larger one used for logs and whatnot.
You also might consider where you’re going to put it all relative to the larger file system. Having it tucked away in the logs directory under the server configuration is handy if you’re mostly concerned with that one server (as a developer might be). At a system level you might find it more convenient to have the output of all (or at least a relevant set) of your servers more or less in one place. If you need to send things into support, that might be quite handy.
Oh, how do you go about re-locating all this stuff so it doesn’t just end up in the logs directory? There’s an environment variable called WLP_OUTPUT_DIR that you can set to override the default and tell the server where to put anything it needs to write. You can also set the LOG_DIR environment variable to control just where the logs go. Why?
The logs directory isn’t the only thing that will end up in the output directory. There’s caches and other writeable stuff that goes there too because the server writes to them. You’d want to give read permission to this stuff to anybody that needs to look at logs and such, but restrict write access to the server itself.
The server can be configured to just keep some number of message log and trace files and will delete old ones by itself. If you have some requirement to keep these around for a while you might disable this and do the archiving and deletion from the file system via some automation that would also need write access.
I’ll also point out a warning in the documentation about setting the logDirectory attribute in the server configuration to provide a location for the logs. This only takes affect (effect? I can never remember) after the logging code has read all of its configuration and so some messages may get written to the default location before this kicks in. Better to use the environment variables mentioned earlier to keep everything together.