The Tivoli Log File Agent operates on UTF-8 data internally, regardless of what the original log data encoding was. This means it needs to convert from your local encoding into UTF-8 each time it reads data from your log. If you happen to know that your log is already in UTF-8, however, you can skip this step. It doesn't save a huge amount, but minimizing the impact of monitoring is always good, and anything you can save is helpful. If your systems are using English, you may think this doesn't affect you. But many English systems, Linux ones in particular, are in fact operating in UTF-8. This is the default on recent versions of both Red Hat and SUSE Linux. You can check on any UNIX or Linux system with the "locale" command. For example, on this Red Hat system:
# head -1 /etc/issueRed Hat Enterprise Linux Server release 5.4 (Tikanga)
You can see that although the system is running in English, it is in fact using UTF-8:
You can instruct the Log File Agent to skip the conversion in this case by adding the following line to the .conf file:
Note that you can also use this for another purpose. Normally the Log File Agent assumes that the files it monitors on a system are in the system's native encoding. However, you can also use the NO_UTF8_CONVERSION setting to indicate to the Log File Agent that the monitored logs are encoded in UTF-8, even if the native encoding is something else. This could arise if you have an application that always writes in UTF-8 regardless of the system encoding. Or perhaps if you have NFS mounted the logs from a UTF-8-native system like Linux and are running the Log File Agent on a different system in a different encoding.