[IGN-6344] Audit log full from system.tag.writeBlocking calls

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.

But this logging wasn't happening in 8.1.17

My audit log is FULL of "tag writes"

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.

I found the culprit

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

1 Like

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.

We’re looking into this.

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…

No, if you want to audit them keep doing what you’re doing for now.

We did briefly discuss adding an optional audit parameter to tag write and edit scripting functions, but that’s not the fix going into 8.1.19.

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.

1 Like

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.


1 Like

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?

@ryanjmclaughlin same here with 8.1.19.

To remember the content of this thread, here is what we are seeing:

  1. We get reports of file group full from IT (MSSQL storage)
  2. Gateway shows audit records quarantined in S&F
  3. When we look at what is actually being stored to audit log, there is a massive amount of records that are of no use to us or our users.

For example whenever system tag writes are happening:

Really, the amount of things we want to audit is very small such as:

  1. User login/logout events
  2. 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.



1 Like

I thibk this is fixed in the latest, 24. Could have been fixed earlier though

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?

Can you be specific on tag writes? Is that using writeBlocking and where are the writes being performed?