I upgraded Ignition from 8.1.17 to 8.1.18 on Monday (6/20). Version 8.1.17 did not log the system.tag.writeBlocking script calls in the audit log. Version 8.1.18 is logging all of them!
For example: I have a gateway timer script running to update a couple tags using the system.tag.writeBlocking function. I write the number of active and unacknowledged alarms to these tags so I can display an icon if there are alarms that need attention. Now when I get an alarm, the tag write function constantly gets recorded in the audit trail. This is occurring throughout my project in additional scripts. Any time a user pushes a button (perspective) that has a script to write to a tag not only does the user interaction get logged but also the tag write gets logged (sometimes it's more than one tag write in the script).
I saw @nminchin 's post, requesting a way to disable. I don't understand why this feature was added.
BTW, I've cleaned up the timer script so it doesn't write duplicate data but it's still really annoying having a bunch of random "Unknown Actor's" filling up the audit logs with 'tag write' entries.
Also, I did clear the Gateway Audit Profile but the tag writes are still getting logged.
I’m a bit confused how you would want this to work? For the majority of cases, I and most people want the audit log to capture all sources of tag writes into the audit log. Otherwise the audit log is kind of pointless, right?
The only reason that I want to skip logging is so that I can write my own logging code to log the previous value.
The system didn’t previously log perspective script tag writes so I had to build the project with custom audit logging. Now with this update I basically get double audit logging.
And, from my perspective (no pun intended) not all tag writes need to be logged. I have some memory tags that are used to just do a simple calculation (or count the number alarms). If these tags get changed it doesn’t affect my process.
Unfortunately, I don’t have the ability (time) to update all of the scripts to take advantage of the updated update.
So I presume you have multiple scripts that all individually insert audit log entries after each tag write? You don’t have a single library function that does this?
I simply created two library functions shared.tag.writeBlocking and shared.tag.writeAsync which were wrapper functions to the same system functions. So to disable my own audit logging all I did was comment out the audit log insert statements in the two functions
I like the way you approached it, in hindsight I wish I would have done the same. I do have a main script that writes to the audit log, for the majority of the tag writes, but my script stores custom data (like batch information and equipment IDs) that the system audit log doesn’t capture. I use the information for batch reporting. So now in one button press I get my custom audit log and at least on system tag write log (and some cases 2 or 3 extra tag write logs).
I guess I can live with it but it was a surprise to see so much data stored in the logs today. It took me a while to even find what I was looking for. I get the concept but it’s a surprising change for an existing project.
I would like to bump this thread to add my complaint about gateway level system.tag.write audit logging. This is bloating our audit logs because we have memory tags that are updated every few seconds so you can imagine the sheer amount of data being added that no one cares about.
What is the work around for this? Our systems relies on these dataset memory tags getting updated via a gateway timer script.
The intention was to capture writes or edits that originate from a Perspective session, and not any gateway-scoped script, but it sounds like that’s not what is happening.
Can the fix be to add the skipAudit argument to the function? What if I do want to audit gateway context events? I think it’s more confusing if perspective calls to the same function do audit but gateway timer scripts don’t…
Just updating this thread to say that this has been fixed for 8.1.19. Scripted tag writes / modifications will no longer be audited within gateway event scripts.
We are seeing that this feature which seems to capture all tag changes associated with perspective sessions generates a huge amount of unwanted (for us) audit events. We'd prefer to have an option to turn it off or have more control over what does and does not get sent to audit.
The main issue is that the data that is being stored has no use to us and will just consume memory faster.
I am on 8.1.19 and still getting flooded. My audit table is approaching a billion rows, IT is not happy. One high volume tag write comes in fix WebDev, did the fix in 8.1.19 not apply to something that would write via webdev?
Really, the amount of things we want to audit is very small such as:
User login/logout events
Whenever users modify tags from the front end (ex: user set thresholds, shift schedules)
The main issue we see now is that we have no granular control, its either all or nothing. We want to be able to store in the audit table only what we want to.
We have no need to store every single system tag change.
We are on 8.1.33 and tagwrites are being written to audit tables unnecessarily. Anyone knows if there is a way to disable tagwrites going into audit tables?
Facing the same situation here, we do write from a scheduled script a few tags per line per minute, but these easily add up to tens of thousands of write per day, and in Ignition Cloud Edition 8.1.39 the audit table is still getting flooded.
We were on 8.1.37 and did not have this issue. We just upgraded to 8.1.42 and we're now experiencing it and I'm not sure why. We are eating about 100 GB of logs a day now as a result.
We've turned off auditing on our project that has all of our scheduled gateway tasks as a way to stop the issue for now and are in the process of deleting the erroneous logs.
Yes definitely a bad design choice on part of IA to force tag writes to go to audit db. That should have been a checkbox to opt out of.
We have created a bunch of sql scripts and scheduled to cleanup the audit table on a hourly and daily basis to get us out of this situation. All unnecessary work due to a bad design choice.
