Ignition Alarm Journal Source Filters Need Wildcards

A bare gateway name in an alarm journal's Filter by Alarm Source field matches nothing. The alarm source is a long qualified path, and the gateway name is only one segment of it. A pattern such as *GATEWAY_NAME_1* matches any source string that contains that name, so each journal profile keeps only the alarms from its own gateway. The audit side has a different limit. A project points at one audit profile, and a remote audit profile using store-and-forward does not also keep a permanent local copy. Work through the checks below in order.

Where does an alarm event travel before the filter sees it?

Follow the packet. An alarm on a remote gateway passes through these hops before any row is written:

An empty journal after you add a filter usually points to hop 4. Rule out hops 2 and 3 first, so you do not tune a filter that was never going to receive data.

Check 1: Is the gateway network link actually up?

Layer one first. On the central gateway, open the gateway network status page and read the state of each remote gateway connection.

• Running / connected: transport is fine. Go to Check 2.
• Faulted, pending approval, or untrusted: fix the connection first. Approve the incoming connection and confirm that any certificates are trusted. Confirm the host and port are reachable through any firewall between sites. A journal filter cannot pass data that never arrives.

While you are on the status pages, read the store-and-forward engine for the journal's datasource.

• A growing buffer means records arrive but the database write is failing. Look at the database connection, not the filter.
• Quarantined records mean writes were rejected. Look at the database connection, not the filter.

Check 2: Do events arrive with the filter blank?

Clear the Filter by Alarm Source field on one journal profile, save it, and trigger a test alarm on one remote gateway. Then query the alarm events table in that journal's database.

• Rows appear: transport and database are healthy. The filter pattern is the fault. Go to Check 3.
• No rows: the problem is upstream of the filter. Check the following, then return to Check 1:
  • the remote gateway's alarm journaling configuration;
  • the tag provider exposure between the gateways;
  • the journal's datasource.

Check 3: What does the Source column actually contain?

Read the Source column of the rows you captured in Check 2. This is the string the filter is compared against. It is a qualified path, not the gateway name alone. It carries segments for:

• the originating system;
• the tag provider;
• the tag path;
• the alarm name.

The filter tests the pattern against the whole string. A pattern with no wildcards only matches a source that equals the pattern exactly, and no real alarm source ever equals a bare gateway name. That is why entering the gateway name returns no data.

Before you commit a pattern, check three things against the captured strings:

• Substring collisions. *GW1* also matches GW10 and GW11. Include the delimiter that follows the name in the Source column, so the pattern ends at the segment boundary.
• Case and spelling. Copy the name exactly as it appears in the Source column. The gateway's configured system name can differ from the hostname or the label you use informally.
• Renamed gateways. Renaming a gateway changes the source string for new events. Update the filter at the same time. Rows already stored keep the old name.

Why doesn't a remote audit profile also write to the local database?

This is a separate branch, and the answer is architectural. In the Designer, a project's audit setting selects one audit profile. When that profile is a remote audit profile:

• events go over the gateway network to the target gateway's profile;
• store-and-forward on the local side buffers them only until delivery;
• once forwarded, the local buffer drains, so it is not a durable local record.

Pointing the project at the remote profile therefore gives you remote logging only. The project setting cannot fan out to two profiles.

Whichever row you choose, save and publish the project after changing the audit profile. Then generate an auditable action and confirm the row lands in the table you expect.

How do you apply and verify the per-gateway alarm filter?

1. On the central gateway, open the alarm journal settings. Create one journal profile per remote gateway, or edit the existing ones.
2. In each profile's Filter by Alarm Source field, enter the wildcard pattern built from the Source column in Check 3. For example, use *GATEWAY_NAME_1* for the first gateway and for the second. Add the trailing delimiter if any names share a prefix.
3. Save each profile. Confirm the profile status shows running and the datasource connection is valid.
4. Trigger a test alarm on remote gateway 1 only. Query each journal's alarm events table. The row must appear in gateway 1's journal and in no other.
5. Repeat the test for every remote gateway. A row in the wrong journal means the pattern overlaps. Tighten it at the segment boundary and retest.
6. Clear each test alarm and confirm that the clear and acknowledge events land in the same journal as the active event.
7. Take a final reading of the store-and-forward status for each journal datasource. The buffer should be at or near zero, with no quarantined records, after the tests complete.

FAQ