Audit Events in Ignition 8.1.18

[nicholas.robinson]

Compared to 8.1.17 I am seeing new behavior that every tag change made by the system (not by the user) is being sent to the audit log in 8.1.18. I noticed this in our Kafka stream after the tag gateway was updated to 8.1.18:

Audit events in the millions caught my eye.

Looking at the data I can see that every single system driven tag change is being logged to the audit profile.

Was there any change in 8.1.18 and is this expected behavior?

Edit
We did not change the module when upgrading from 8.1.17 to 8.1.18.

In 8.1.17 we saw far fewer audit events happening, typically less than 100 per day.

Thanks,

Nick

[kcollins1]

It looks like 8.1.18 saw the addition of audit events from tag write calls within Perspective sessions. It also seems that a regression was introduced here that also brought in events from any gateway scope (tag event scripts, etc) instead of just Perspective sessions. This might account for some of the increased activity in the audit. This shows to be resolved with 8.1.19.

[nicholas.robinson]

@kcollins1 thanks for the quick response, much appreciated.

I don’t suppose there is anyway to prevent it from happening within 8.1.18?

At the point where we send the data to Kafka, I don’t immediately see a field that would allow us to choose not to send an event other than something like actor and actor host being unknown:

  public void sendAuditData(AuditRecord record) {
      if (kafkaConfig.getAuditEnabled()) {
          long epochms = record.getTimestamp().getTime();
          try {
              String json = new JSONObject()
                      .put("epochms", epochms)
                      .put("originatingSystem", record.getOriginatingSystem())
                      .put("originatingContext", record.getOriginatingContext())
                      .put("actor", record.getActor())
                      .put("actorHost", record.getActorHost())
                      .put("action", record.getAction())
                      .put("actionTarget", record.getActionTarget())
                      .put("actionValue", record.getActionValue())
                      .put("statusCode", record.getStatusCode())
                      .toString();
              SinkData toSend = new SinkData(auditTopic, json, auditSinkName);
              sendKafkaData(toSend, true);
          } catch (JSONException e) {
              logger.error("Error sending audit record: " + e.getCause());
              this.auditSink.addOneFailedCount(auditSignature);
          }
      }
  }

Adding
The way we have it setup is whatever goes to DB is also sent to Kafka so we could only control the Kafka route and whatever happens when an audit record is logged to our MSSQL DB is largely out of our control other than turning it on or off.

Thanks,

Nick

[kcollins1]

I don’t suppose there is anyway to prevent it from happening within 8.1.18?

Not that I can see.. Here are the two other threads that relate to the issue, for reference:

[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 const…

[IGN-6344] Frontend/Backend gateways - Perspective system.tag.write* causing two audit entries

Split Gateway architecture, Frontend and Backend. Recently upgraded from 8.1.5 to 8.1.18. I’ve just noticed that calling system.tag.write* in Perspective, not affecting Vision (haven’t specifically checked anywhere else) is causing duplicate entries to be recorded into the audit log - the frontend row has the ACTOR and ACTOR_HOST non-null while the backend row has these as null (makes sense). I’m assuming that both the frontend and backend are auditing these independently: frontend handles th…

[nicholas.robinson]

@kcollins1 we upgraded a gateway to 8.1.19 today and it seems this issue is still present. As an example, we can count around 5000 audit events in ~10 minutes time.

Can you please verify?

Thanks,

Nick

[kcollins1]

I do expect there to be more audit events occurring with 8.1.18+, but hopefully the new ones you’re observing are indeed from Perspective sessions (with the fix from 8.1.19 reducing the unintended additions)?

[nicholas.robinson]

I have our Kafka module installed on one of our tag gateways And this is around 20 minutes of audit events:

Looking at the events themselves, they originate from the front end gateway so this does point to them coming from perspective sessions.

However, the volume of audit events is still too much and we do not want to see an audit event for every single tag change that happens due to a perspective session. While we can manage with the retention period on the audit profile, the concern we have is excessive storage consumption without a need for the data.

For users like us that do not want to see all of these events, it seems like there should be an option to shut them off.

I think I mentioned before, but we split the audit events to MSSQL and Kafka so while Kafka is not really a concern for memory, MSSQL always is.

Thanks,

Nick