Inconsistent Logging

JamesV 2 years ago in IQANdesign • updated by Gustav Widén (System support) 2 years ago 3

I have two duplicate event logs, each with several of the exact same log items in them, with the same triggering logic and channels etc... but with different access rights so service can't clear one of them. 

When I receive a clone from a machine and check it's logs the values stored in either log are often different. In some cases the value is not even recorded or the event wasn't triggered in the second log. Is it possible a high (nearing alarm point) utilization rate can cause this or is there something else to blame? 

Satisfaction mark by JamesV 2 years ago

First and foremost, the logging functionality has changed considerably over the years, so the answer will depend on what version you're using.

However regardless of that, I don't think we can guarantee that we can generate duplicate identical log events such that you describe it.

I guess the problem would be the amount of log records generated per time quanta (indirect affected by high utilization).

In later versions you could add a SIC with value Log queue [%] to check how the logging sub system is doing.

If that channel reaches 100% you run the risk of loosing log records.

A solution to that (I guess) would be to invert the trigger and pulse it low before you want to log and then keep it high. Then that item will be logged once the Log queue falls below 100%.

However at that point the application will have advanced and you will probably log another value.

One additional comment about the changes in log functionality that Marcus mentions is that in 2.x and 3.x, the logging could more easily miss events. Since version 4.00, the log event items are calculated as part of the application, and when a log event is triggered it is placed on the log queue. 

Writing the events to the log flash memory takes a lot longer time than calculating the triggering conditions, and is done in a separate lower priority process. If there are too many events triggered before the IQAN master has time to record all, the System Information Channel Log queue will as Marcus mentioned reach 100%, indicating that only some of the events will be saved.