Improving the efficiency of syslogd remote logging functions

While the ability for the z/OS® syslogd to receive remote messages can be very useful, it is important that appropriate planning take place to ensure that the additional remote message traffic that syslogd receives does not create a performance issue or impede the ability for the local z/OS syslogd to perform its processing. The following configuration options can help reduce such risks:

Configure the remote syslogd instances to forward only messages that are important enough to consolidate on the z/OS system. For example, high-volume debug traces should be collected on the local host instead of having them forwarded to a z/OS system. Syslog daemon implementations typically provide the ability to define configuration statements that dictate which type of messages are forwarded to remote hosts. For example, the z/OS syslogd enables you to filter messages based on the facility and priority associated with a message. For more information about the specific configuration of your remote syslogd instances, consult the documentation available for the platform on which the remote syslogd instance is running.
If the remote message traffic that the local z/OS syslogd instance is expected to receive is substantial, consider configuring a network-only instance of syslogd and a local-only instance of syslogd. This helps ensure that the logging of locally generated z/OS syslogd messages is not impacted by high-volume remote message traffic.
When the local z/OS syslogd instance receives a message from a remote syslogd, it determines the disposition of the message based on its own configuration statements. These configuration statements enable you to determine which received messages are of interest and how these messages should be logged. The following guidelines describe how these statements can be configured for remote message receipt:
- The z/OS syslogd can log messages to various destinations, including z/OS File System files, the MVS™ console, the MVS operations log, SMF records, and so on. If the destination for the remote messages is the MVS console or MVS system log designated with the /dev/console destination, consider whether logging these messages to the MVS operations log (that is, the OPERLOG log stream) designated by the /dev/operlog destination is a suitable alternative. Logging messages to the OPERLOG log stream is more efficient and consumes less system resources than logging messages to the MVS console.
  The OPERLOG log stream must be configured and active before using the syslogd /dev/operlog destination. If the OPERLOG log stream is not active when syslogd attempts to log a message to the /dev/operlog destination, message FSUM1234 is logged with a facility.priority value of daemon.error. If the OPERLOG log stream later becomes active, message FSUM1235 is logged with a facility.priority value of daemon.info, and logging to OPERLOG automatically begins. For more information about using OPERLOG, see z/OS MVS Planning: Operations.
- You can identify which messages the z/OS syslogd should process by identifying the known remote syslogd instances from which you expect to receive messages. For example:
```
(host1.xyz.com).*.*        /dev/operlog
(host2.xyz.com).*.*        /dev/operlog
```
  In this example, syslogd resolves the specified host names to the IP addresses associated with those hosts during initialization by invoking the system resolver services. After initialization is complete and syslogd begins receiving remote messages, it first checks to determine whether the incoming messages match any of the specified configuration statements. In this example, syslogd processes only remote messages that have a source IP address associated with the hosts host1.xyz.com or host2.xyz.com, and logs these messages in the MVS operations log. Assuming that no other configuration statements are specified, any messages received from other hosts are discarded.
  Specifying configuration statements that identify each remote host using a host name also has the additional benefit of enabling these remote messages to include a host name identification when they are logged locally, without incurring the overhead of a host name resolver lookup for each incoming message. The per-message host name resolver lookup can be disabled using the -x syslogd option. If the ability to perform a resolver lookup for every message is necessary or useful in your environment, you should use the system resolver cache function (see Customizing the resolver and Resolver caching). If host name resolution is performed, and the message was received over a link-local IP address, the resolved host name might include scope information that identifies the interface over which the message was received. For more details on support for scope information on a host name, see z/OS Communications Server: IPv6 Network and Application Design Guide.
  
  In addition to host names, remote syslogd instances can also be identified using IPv4 or IPv6 addresses or by specifying an IPv4 subnetwork or IPv6 network prefix. For example:
```
(10.42.105/24).*.*        /dev/operlog
(10.43.110.15).*.*        /tmp/otherlog
```
  In this example, any remote messages received from hosts using an IP address in subnetworks 10.42.105.0 to 10.42.105.255 are logged in the MVS operations log, while messages received from the host identified by 10.43.110.15 are logged in the /tmp/otherlog file.
- In addition to identifying the remote syslogd instances that can forward messages, you can also use additional filters to determine which remote messages you want to log locally. For example:
```
(host1.xyz.com).*.crit        /dev/operlog
(host2.xyz.com).*.crit        /dev/operlog
```
  With these configuration statements, syslogd logs only messages received from hosts host1 and host2 that have a critical priority to the MVS operations log. Assuming that no other configuration statements are specified, any other messages received from those hosts are discarded.