G. Pape

socklog - network logging

Logging via network connection cannot be made reliable. There is always a possibility for failures. The network connection itself may be down or the receiving machine has crashed for example. So there must be a decision, what to do in such cases.

The socklog network logging concept

There are no restrictions on how to transmit the log data, a separate process of your choice will do the work, e.g. tcpclient or netcat. This modularity lets you easily insert authentication, compression, encryption and other things.

Example setup

Log Server (machine receiving log data)

Setup a socklog-ucspi-tcp service as described in Configuration with the following socklog-ucspi-tcp/run and socklog-ucspi-tcp/log/run scripts:


  exec 2>&1
  exec softlimit -m 2000000 \
    envuidgid log tcpserver -vUHR -l0 0 $PORT socklog ucspi TCPREMOTEIP
  exec 2>&1
  exec setuidgid log multilog ${LOGDIR}/all \
    -* +'*' ${LOGDIR}/
You will then find all log data from remote hosts that was successfully transmitted in ${LOGDIR}/all/. Log data from will also be saved in ${LOGDIR}/

Log client (machine sending log data)

Change the socklog configuration to use a processor to transmit the log data:


  exec setuidgid log multilog s4096 n20 \
    !"tryto -pv tcpclient -v $LOGSERVERIP $PORT sh -c 'cat >&7'" \
and restart the service:
  # svc -t /service/socklog-unix/log
On each rotation of multilog's current, the data will be transmitted to $LOGSERVERIP:$PORT using tryto and tcpclient, failures will be noticed and notified on the next run.
Gerrit Pape <pape@smarden.org>
$Id: network.html,v 1.13 2003/01/30 10:44:32 pape Exp $