Thursday, 14 December 2017

WebSphere Liberty Profile - Customising the Logging

On my current engagement, we had a requirement to trim out ( temporarily ) some information log messages which were "spamming" the console.log of a WebSphere Liberty Profile (WLP) environment.

Firstly, here's some context about WLP logging: -

There are three primary log files for a server:

• console.log - containing the redirected standard output and standard error from the JVM process. This console output is intended for direct human consumption. The console output contains major events and errors if you use the default consoleLogLevel configuration. The console output also contains any messages that are written to the System.out and System.err streams if you use the default copySystemStreams configuration. The console output always contains messages that are written directly by the JVM process, such as -verbose:gc output. This file is created only if the server start command is used, and its location can be altered only by using the LOG_DIR environment variable. For more information, see Administering Liberty from the command line.

• messages.log - containing all messages except trace messages that are written or captured by the logging component. All messages that are written to this file contain additional information such as the message time stamp and the ID of the thread that wrote the message. This file does not contain messages that are written directly by the JVM process.

• trace.log - containing all messages that are written or captured by the product. This file is created only if you enable additional trace. This file does not contain messages that are written directly by the JVM process.

and: -

The console.log file does not have the same level of management as other log files. The only property that you can change is consoleLogLevel.

and: -

consoleLogLevel

This filter controls the granularity of messages that go to the console.log file. The valid values are INFO, AUDIT, WARNING, ERROR, and OFF. By default, the level is AUDIT.
...


As an example, from my own VM ( and this is a TERRIBLE example ), let's say I wanted to suppress this message: -

[AUDIT   ] CWWKS1100A: Authentication did not succeed for user ID appcenteradmin. An invalid user ID or password was specified.

In a default, vanilla, installation of WLP, the default for consoleLogLevel is AUDIT.

If I wanted to turn off ALL logging, I could change that to OFF, but that'd be a daft idea.

Therefore, there's this: -

...
After version 8.5.5.4+ Liberty Profile; added new attribute "hideMessage" to logging element.

You can configure logging element on server.xml file;

<logging hideMessage="WELD-000900" />

The "WELD-000900" messages will redirect to trace.log file.

If you want to add multiple message, you can seperate it with a comma.

<logging hideMessage="WELD-000900, CWWKE0001I" />


so I validated this, by changing server.xml : -

vi /opt/ibm/WebSphere/Liberty/usr/servers/defaultServer/server.xml

and adding: -

        <logging consoleLogLevel="AUDIT"/>
        <logging hideMessage="CWWKS1100A"/>

before the closing </server> directive.

Now I can try/fail to login as many times as I like, and console.log will tell me nothing: -

tail -f /opt/ibm/WebSphere/Liberty/usr/servers/defaultServer/logs/console.log

[AUDIT   ] CWWKS1100A: Authentication did not succeed for user ID adsda. An invalid user ID or password was specified.
[AUDIT   ] CWWKG0016I: Starting server configuration update.
[AUDIT   ] CWWKG0017I: The server configuration was successfully updated in 0.050 seconds.


Note the CWWKG0016I and CWWKG0017I messages; they tell me that the server automatically updated its configuration once I saved the changes to server.xml.

And, of course, I'm going to change it back: -

vi /opt/ibm/WebSphere/Liberty/usr/servers/defaultServer/server.xml

        <logging consoleLogLevel="AUDIT"/>

and now I see all of the bad login messages: -

tail -f /opt/ibm/WebSphere/Liberty/usr/servers/defaultServer/logs/console.log

[AUDIT   ] CWWKS1100A: Authentication did not succeed for user ID adsdas. An invalid user ID or password was specified.
[AUDIT   ] CWWKS1100A: Authentication did not succeed for user ID asdads. An invalid user ID or password was specified.
a[AUDIT   ] CWWKS1100A: Authentication did not succeed for user ID asda. An invalid user ID or password was specified.

No comments:

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...