Relaying Unimus logs to a Syslog server

Introduction

"Logs don't lie – they just patiently wait for you to finally listen."

Logs are the diary of any system, revealing what’s truly happening behind the scenes amid the chaos of day-to-day operations. They can – and often do – provide invaluable insights during debugging or troubleshooting sessions.

Today, we’ll look at where Unimus stores its logs and walk through how you can configure Unimus to relay its logs to a Syslog server of your choice. Whether you're troubleshooting, monitoring, or just want to keep all your logs in one place, setting up external log forwarding is a smart move. Let's get started!

Why centralized logging matters

Unimus logs contain valuable clues about your system's activity: including backup jobs, device discoveries, Mass Config Pushes, and more. Integrating these logs into your logging system can simplify troubleshooting by making it easier to correlate Unimus logs with logs from your network devices and other systems. It also streamlines log management, and improves visibility.

Not to forget, storing Unimus logs in both your local file system and an external Syslog server provides a valuable layer of redundancy.

Finding your Unimus logs

The Unimus Server writes log files to the following directories:

• Linux: /var/log/unimus
• Windows: C:\ProgramData\Unimus\log
  

Note: C:\ProgramData\ is usually a hidden folder.

That is pretty much all the essential information you need to get started. However, if you’re curious about the Unimus Logging Subsystem, you can check out our wiki page for more details about the content of Unimus logs, how to customize the logging level, or modify the log rotation settings.

Before you configure Unimus

Before configuring Unimus to send logs to your Syslog server, there are a few essential prerequisites to ensure a working setup.

1. Syslog server setup
Before proceeding, make sure that your Syslog server is:

• Enabled and listening on UDP port 514.
• Configured to accept and properly process Syslog messages from your Unimus server.

When it comes to choosing a Syslog server solution, you have plenty of options. Popular choices include the Linux-based rsyslog and Syslog-ng, or a platform like Graylog, a powerful log analysis solution. Alternatively, many Network Monitoring Systems (NMSes) also come with built-in Syslog servers or receivers, such as Zabbix, LibreNMS, PRTG, or NetXMS. If you’re already using one of these for collecting your logs or for even inventory synchronization with Unimus, it might make sense to forward your Unimus logs to the same destination for centralized log management.

2. Ensuring network accessibility
Next, verify that the Unimus instance can reach the Syslog server over the network. Make sure that any firewalls between your Unimus instance and the Syslog server are configured to allow traffic on the Syslog port (UDP 514). If this port is blocked by a firewall, the logs will never reach the Syslog server.

On Linux, the logger command is ideal for testing Syslog. Tools like Netcat or Nmap can help verify network reachability and whether UDP port 514 is open. Keep in mind that UDP is connectionless, so even if the port is open, you might not get a definitive success/failure unless something responds.

nmap -sU -p 514 <your_syslog_server_IP>
logger -n <your_syslog_server_IP> -P 514 -d "Test syslog message"

On Windows, tools such as Packet Sender, or Netcat can help you send test messages to a remote server over UDP 514. You can also use PowerShell with .NET classes to craft and send UDP packets manually.

Once you’ve completed the above checks, you can proceed with the steps below.

Configuring Unimus to relay its logs to a Syslog receiver

1. Stop the Unimus service.

2. Create a file named syslog-logging.xml in /etc/unimus/ (or C:\Program Files\Unimus\) with the following contents:

<?xml version="1.0" encoding="UTF-8"?>

<configuration>
    <include resource="org/springframework/boot/logging/logback/base.xml"/>
    
  <!-- https://logback.qos.ch/manual/appenders.html#SyslogAppender -->
  <appender name="SYSLOG" class="ch.qos.logback.classic.net.SyslogAppender">
    <syslogHost>10.0.0.0</syslogHost>
    <facility>USER</facility>
    <suffixPattern>[%thread] %logger %msg</suffixPattern>
  </appender>

  <root level="INFO">
    <appender-ref ref="SYSLOG" />
  </root>
    
</configuration>

This is a custom Logback configuration file that tells Unimus how to send logs to an external Syslog server — including the destination IP log format, and Syslog facility.

3. Replace the syslogHost value with the IP address of your Syslog server. You can adjust other values, such as the suffix pattern or facility, as documented here:
https://logback.qos.ch/manual/appenders.html#SyslogAppender

4. For Linux deployments, add the following JVM options to the end of /etc/default/unimus:

-Dlogging.config=/etc/unimus/syslog-logging.xml -Dlogging.file.name=/var/log/unimus/unimus.log -Dlogging.logback.rollingpolicy.max-file-size=50MB -Dlogging.logback.rollingpolicy.max-history=9

For Windows deployments, add the following to C:\Program Files\Unimus\Unimus.l4j.ini:

-Dlogging.config="C:\Program Files\Unimus\syslog-logging.xml"
-Dlogging.file.name="C:\ProgramData\Unimus\log\unimus.log"
-Dlogging.logback.rollingpolicy.max-file-size=50MB
-Dlogging.logback.rollingpolicy.max-history=9

If you're running Unimus in a container, specify the above JVM options in the Docker Compose file instead, like this:

unimus:
    image: croc/unimus
    environment:
      - JAVA_OPTS=-Xms256M -Xmx1024M -Dlogging.config=/etc/unimus/syslog-logging.xml -Dlogging.file.name=/var/log/unimus/unimus.log -Dlogging.logback.rollingpolicy.max-file-size=50MB -Dlogging.logback.rollingpolicy.max-history=9
      - TZ=Europe/Budapest
    container_name: unimus
    ports:
      - "8085:8085"
      - "5509:5509/tcp"

Note that the above setups will relay the contents of the unimus.log file which can be found on a Unimus server.

If you wish to relay the logs from a Remote Core, edit the Core config file (/etc/default/unimus-core or C:\Program Files\Unimus\Unimus-Core.l4j.ini) and set the logging file parameter and specify /var/log/unimus-core/unimus-core.log or C:\ProgramData\Unimus-Core\log\unimus-core.log.

5. Restart the Unimus (or Unimus Core) service.

All done!

After the restart, Unimus will log both to /var/log/unimus/ (or C:\ProgramData\Unimus\log) and to the Syslog server specified in the syslog-logging.xml file. From this point on, every log entry written to the file system should also appear on your Syslog server.

Unimus not starting?

If Unimus fails to start, it's likely a syntax issue in your modified Unimus defaults file. Double-check for typos, unintentional or missing line breaks in the JVM options.

On Linux, make sure to place all the JVM options on a single line. On Windows deployments, each argument should be placed on its own line, and if the path argument contains spaces, wrap it in double quotes.

What's next?

Once the Unimus logs are flowing to your syslog server, the fun is not over. Modern Syslog collectors with log analysis capabilities let you go far beyond basic log collection.

You can correlate Unimus logs with those from routers, firewalls, and other systems to gain deeper insights. Want to detect when a Unimus server loses connection to a Remote Core? Create an event policy to trigger alerts or auto-generate tickets in your monitoring tools via API. Need to pinpoint the root cause of a BGP flap? Cross-reference Mass Config Push activity with network device logs. Focus on logs with severity levels 4 (WARN) and 3 (ERROR), as those specifically report problems that need attention.

With the right setup, your Unimus logs can become a rich source of operational intelligence, supporting you in troubleshooting when things go south.

Final words

Hopefully, this article has been helpful for those of you who’ve been looking for a way to set up log relaying in Unimus. If you have any questions or run into any issues that we didn’t foresee in this article, please feel free to post in the support section of our forums or reach out through our usual support channels.

Until next time, take care!