I'm trying to get all the gateway logs in a .log file using FileAppender. However, I'm unable to see the logs shown on UI (Diagnostic -> logs) which are maintained in .idb file using 'com.inductiveautomation.logging.SQLiteAppender'.
Is there any way to get the diagnostic logs to a .log file ?
On a standard installation, the data/logback.xml
file defines a few appenders in the configuration. You'll observe the SQLiteAppender
(which feeds records into the idb file that the UI uses) as well as a ConsoleAppender
. The latter emits logging to stdout, which is then picked up by the java service wrapper where it is ultimately emitted to a file (logs/wrapper.log
) via the wrapper.logfile
configuration in data/ignition.conf
. NOTE: this is different for Docker containers, where we emit logs to stdout, for collection by the container engine instead of duplicative file logs in the container filesystem.
You can configure your own RollingFileAppender
in the data/logback.xml
configuration to route logs of your choosing to individual files. See the configuration link there for more information.
Here is the data/logback.xml
file:
<configuration debug="true" packagingData="true">
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>logs/gateway.log</file>
<append>true</append>
<!-- set immediateFlush to false for much higher logging throughput -->
<immediateFlush>true</immediateFlush>
<!-- encoders are assigned the type
ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
<encoder>
<pattern>| %d{HH:mm:ss,SSS}Z | %cn | %level | %logger | %message | %exception |%n</pattern>
</encoder>
</appender>
<appender name="SysoutAppender" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%.-1p [%-30c{1}] [%d{HH:mm:ss,SSS}]: %m %X%n</pattern>
</encoder>
</appender>
<appender name="DB" class="com.inductiveautomation.logging.SQLiteAppender">
<dir>logs</dir>
<!--
Maintenance Settings
entryLimit: The maximum number of entries in the database. However, at any given time, there may be more than this number, due to how cleanup works.
maxEventsPerMaintenance: The number of event that can happen before a maintenance cycle occurs.
minTimeBetweenMaintenance: The minimum time (max frequency) between maintenance events. Takes precedent over max events.
vacuumFrequency: The number of maintenance cycles before a "vacuum" is performed, to recover disk space.
On disk, most log events are between 600-800 bytes.
<entryLimit>50000</entryLimit>
<maxEventsPerMaintenance>5000</maxEventsPerMaintenance>
<minTimeBetweenMaintenance>60000</minTimeBetweenMaintenance>
<vacuumFrequency>3</vacuumFrequency>
-->
</appender>
<appender name="SysoutAsync" class="ch.qos.logback.classic.AsyncAppender" queueSize="1000" discardingThreshold="0">
<appender-ref ref="SysoutAppender" />
</appender>
<appender name="DBAsync" class="ch.qos.logback.classic.AsyncAppender" queueSize="100000" discardingThreshold="0">
<appender-ref ref="DB" />
</appender>
<appender name="FileAsync" class="ch.qos.logback.classic.AsyncAppender" queueSize="1000" discardingThreshold="0">
<appender-ref ref="FILE" />
</appender>
<root level="ALL">
<appender-ref ref="SysoutAsync"/>
<appender-ref ref="DBAsync"/>
<appender-ref ref="FileAsync"/>
</root>
</configuration>
From UI, we're able to see logs (errors, info, ..) in UI from our custom OPC XMLDA driver module. However, by using FileAppender (as configured above) we're only able to see internal Ignition gateway logs.
Is it possible to configure the logback.xml to get all the logs (shown on UI + internal gateway logs) ?
A purpose of the wrapper is to capture the output from poorly-behaved classes/DLLs that write directly to stderr or stdout. Java's logging framework simply cannot capture those. That's why Ignition's gateway UI misses these, too.
I may not be able to clearly explain it. Let me try again.
For example, we have com.test.Test
class in custom driver module and this class somehow logs error.
This error is seen on UI (Status -> Diagnostic -> logs). However, when we configure logback.xml to append all logs in the file. We are not able to see this error.