Opto22 Driver logs ignore log-template settings

Cross Link from Inductive Forums

I’m working on exporting log data for long term storage and in order to achieve that, I modified the Logback.xml file in order to truncate stack traces and render them to a single line so that I can pull them from the logfile and send them along.
The pattern:

  <appender name="SysoutAppender" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
		<pattern>BasePattern %p |M: %m |S: %replace(%ex{short}){'[\r\n]+', ''}%nopex | END %n</pattern>
	
    </encoder>
  </appender>

What I’m noticing is that while the appender is able to reduce the stack traces coming from Ignition scripts and standard modules, when my Opto22 devices are offline, my logfiles are inundated with entries that are ignoring the appender and showing up in full, unformatted form.

I’m hoping to get information on this because my logging strategy is pretty well defeated by having so much log data ignoring the defined format.

The Opto22 driver does use the logger and not System.out calls. So, I’m not sure why this might be the case.

As a sanity check - can you filter them by changing the log levels in the Ignition → Status → Logs page? If not, could you post a sample offending message?

I have filtered them out on my Prod servers because they’re causing some frustration with my partners that handle the log system.

I’ll see if I can get a copy of the offending entry from my test server.

Here’s a copy of the message. I just point the driver at a bad IP to reproduce it on my test server.

2022/01/25 15:12:33 | java.net.ConnectException: Connection refused: connect
2022/01/25 15:12:33 | 	at java.base/java.net.PlainSocketImpl.waitForConnect(Native Method)
2022/01/25 15:12:33 | 	at java.base/java.net.PlainSocketImpl.socketConnect(Unknown Source)
2022/01/25 15:12:33 | 	at java.base/java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
2022/01/25 15:12:33 | 	at java.base/java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
2022/01/25 15:12:33 | 	at java.base/java.net.AbstractPlainSocketImpl.connect(Unknown Source)
2022/01/25 15:12:33 | 	at java.base/java.net.SocksSocketImpl.connect(Unknown Source)
2022/01/25 15:12:33 | 	at java.base/java.net.Socket.connect(Unknown Source)
2022/01/25 15:12:33 | 	at com.cirruslink.opto22.snappac.Opto22.controllerproto.controlengineproto.open(controlengineproto.java:259)
2022/01/25 15:12:33 | 	at com.cirruslink.opto22.snappac.Opto22.controllerscanner.ScannerBase.engineInitialize(ScannerBase.java:313)
2022/01/25 15:12:33 | 	at com.cirruslink.opto22.snappac.Opto22.controllerscanner.ScannerBase.engineScannerStateMachine(ScannerBase.java:641)
2022/01/25 15:12:33 | 	at com.cirruslink.opto22.snappac.Opto22.controllerscanner.ScannerBase.run(ScannerBase.java:953)
2022/01/25 15:12:33 | 	at java.base/java.lang.Thread.run(Unknown Source)

By way of comparison here is a single line, formatted entry of the type I’m generating for more conventional logs. Base Pattern identifies my log entries and isn’t present in Prod, M is for the message from the log and S precedes the stack trace. End is a final marker so if I see M:|S: I know it’s an empty Message and S:|END means an empty stack trace. Also helps identify if my template itself isn’t correctly falling on a single line.

BasePattern ERROR |M: Connection lost due to - MqttException |S: org.eclipse.paho.client.mqttv3.MqttException: MqttException	at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:198)Caused by: java.util.ConcurrentModificationException: null	at java.base/java.util.TreeMap$PrivateEntryIterator.nextEntry(Unknown Source) | END 

What version of the Opto22 driver is this from?

It’s from version 4.0.9

Ok - so this was an issue in the Opto driver with not using the logger properly. These messages have been cleaned up in the nightly builds and will be available in the next release.

Excellent, that’s great news.

I’m not sure the release cadence for this sort of thing but in the meantime I think I can suppress the logs in Ignition by setting the level for that log source to Error

We’re working on a release now. If all goes very well it will be available before the end of this week (4.0.10). It could slide into next week though.