What is „Syslog“ and why does one especially need „Remote Syslog” with their CS141/BACS?

It is not possible or feasible to "start from scratch" every time a given network product becomes otherwise obsolete or reaches EOL status ("End-Of-Life"). As such, over time every network grows into a heterogeneous structure in which different hardware manufacturers have inherently instilled upon it their very own operating concepts. In the event of a network error in such a heterogeneous network, the responsible administrator is left with little choice: if they’re unlucky, they will need to "surf" each individual device with software from the manufacturer in order to download the necessary log files (event logs) and transfer them into a uniform format so that the process can be automated - or "read" each entry in the log file themselves and draw the right conclusions, accordingly. This is far from what might be called “user-friendliness” and is completely unsuitable for practice in large networks – and yet, that’s precisely the practice for many such administrators in the field of UPS network devices.

Many of the primarily Chinese suppliers of UPS network cards certainly offer "download management tools" that can take over the "collection work" at this point, but only support their own products and rarely allow the data to be transferred to another format for evaluation. Automation is not possible with such devices and is only acceptable for small networks.

Was does Remote SYSLOG do for CS141/BACS

Essentially the idea is that everything a given device might write to its own log file, also be sent as a standardized message to a central database. The centralized data collection then contains all sorts of information, such as

• Timestamp, Device name / IP / DNS-Name, Specific Problem / Issue, ...

A typical example from the UPS industry would be the question of fill level warnings for printers and scanners, on the basis of which the company's internal controlling process can determine savings potentials for consumables such as paper and printer cartridges: Thanks to Remote Syslog, the information required for this is conveniently available in a database; all that is needed is to know the appropriate search term. Without Remote Syslog, each printer would have to be read out individually and the data compiled manually.
In the industrial infrastructure sector, the same technology can be applied to any number of network devices to transmit log files to a central database. This enables fully automated evaluation by internal statistics and maintenance programs without requiring third-party software within the server environment.

Exactly this optimization of networks is now delivered by the CS141/BACS with Remote Syslog:

Each CS141/BACS with firmware version 2.04 or higher can send its local logfiles directly to a SYSLOG receiver and thus enable a centrally manageable overview of the health status of ALL UPS or BACS systems located in the network.

How is Remote SYSLOG configured to work with CS141/BACS?

With Firmware 2.04 one can find the new menu „RSYSLOG“ in the „SERVICE“ Configuration:

The input of IP address / host name and TCP port of the responsible SYSLOG server are sufficient to automatically write all EVENTS of the CS141/HW161 into this file.

Even measured values can be transferred into the SYSLOG; for this the CS141/BACS offers to design the logfile individually. This possibility allows the user to have everything entered into this central SYSLOG file in freely selectable intervals.

Remote Syslog gives the user the freedom to manage everything centrally with minimal effort without costly software - even without in-depth knowledge of the end devices!

Example for the creation of a data record into the logfile of the CS141/BACS for automatic transfer into the SYSLOG:

• Select an Event, e.g. with the CS141/BACS one can find under the UPS-Menu for example the option „UPSMan started“:
• Here one might add the job "Log" and select as text a unique term or code which can in turn be searched for later in the syslog database. In this example we have chosen the name "SL_Datapoint".
• Next, one selects which measured values the CS141/BACS ought to send with this SL_Datapoint SYSLOG message - here the "Output frequency L1 in Hz".
• The job SL_Datapoint is triggered as soon as the CS141/BACS has completed its boot process. In order to guarantee now that the measured values are present, one must define a transmission delay (e.g. of 60 seconds) after completion of the boot process and a repetition every 24 hours (86000 seconds) via the timing function.
• On the SYSLOG server side, one now only needs to search in the search program for the term "SL_Datapoint" review all sent measured values, renewed every 24 hours. The basis for further statistic evaluations is thus firmly established and the user does not need to worry about the peculiarities of the end device.