Skip to main content
This appendix documents the wire format of forwarded HSM syslog messages. Read it before writing your own parsing rules, or before adapting this integration to a different collector or SIEM.

​
Anatomy of a message

A forwarded datagram looks like this:
The structure is:
The payload is wrapped in | pipe characters on both ends. The four payload fields correspond exactly to the columns the appliance shows in its own web portal log view, documented as Timestamp | Service | Log Level | Message. See Syslog. Naming the parsed fields after those columns keeps the collector output aligned with what an operator sees on the appliance.

​
How it deviates from RFC 3164

Four differences matter when choosing a parser:
  1. No HOSTNAME field. RFC 3164 places a hostname immediately after the timestamp. The appliance writes a literal : there instead.
  2. No TAG field. There is no process name or PID.
  3. The payload is pipe-wrapped, which no syslog standard specifies.
  4. A second timestamp lives inside the payload at microsecond precision, and it is the more accurate of the two.
The device identifier is carried inside the payload rather than in the hostname position, which is where a standard parser expects to find it.

​
Why the syslog receiver is the wrong choice

A conforming RFC 3164 parser accepts these lines. It reports no error, so the integration looks healthy. What it produces, however, is unusable. Parsed with the collector’s syslog receiver using protocol: rfc3164:
There is no hostname, and device, service, level, and event are all trapped in one string. The only structured values are the facility and priority, which are constant across every record and therefore carry no information. Parsed with the udplog receiver and an explicit regular expression:
This is the single most important detail in the integration. A standard syslog parser fails silently rather than loudly, so the fault is only discovered later, when someone tries to build a dashboard and finds there is nothing to group by.

​
Priority carries no routing information

Every observed record uses <5>, that is facility kern and severity notice, regardless of what the event represents. An authentication failure and a routine counter update share the same priority. Do not route or alert on syslog priority or facility. Use the LEVEL word from the payload for severity, and classify the message text for event type.

​
Observed services

Two services appear in the forwarded stream: The service name is space-padded to a fixed width in the datagram, so a parser must tolerate runs of whitespace between fields rather than assuming single spaces.

​
Message shapes

Message text follows a small number of recognizable shapes:
Two conventions are worth noting:
  • Messages beginning with CONFIG: list the acting identities as colon-separated segments before the action. A two-person authorized action therefore reads CONFIG:Admin1:Admin2:<action>:<target>. This makes dual-control actions attributable to both approvers.
  • Object update messages prefix the acting identities with a comma-separated list followed by a colon, then describe the change in prose, including the old and new values.
Do not attempt to fully parse the message text into fields. The shapes vary by event type and are not a stable contract. Extract the envelope, classify the event with pattern matches, and keep the message text intact. Over-parsing produces rules that break on the first firmware update.

​
Event classification

The collector configuration derives hsm.event_type from the message text:
Order matters. Failed Log In Attempt is a substring of Too Many Failed Log In Attempts, so the lockout rule must be evaluated after the failure rule or every lockout is misfiled as an ordinary failure. The configuration in this guide lists it last for that reason.
Two of these deserve attention when tuning alerts:
  • auth_lockout is the appliance reporting that it has locked an identity out after repeated failures. It is the highest-value security event in the stream and warrants its own alert rather than being folded into a failure count.
  • time_change is emitted on a recurring schedule by client applications that synchronize the appliance clock, roughly every ten minutes in the tested environment. Do not alert on it and do not group it with configuration changes, or the alert fires continuously.
Treat a rising count of other as a signal that the appliance is emitting a shape the rules do not yet cover, most likely after a firmware upgrade. Because the raw datagram is preserved in the log body, those events can be reclassified retroactively.

​
Timestamps

The appliance stamps both timestamps in UTC, and the header timestamp carries no timezone or year. Parse the microsecond payload timestamp instead, and pin the location to UTC. A parser that assumes the collector’s local timezone shifts every event by the host’s offset, which corrupts correlation with other sources.

Related topics

Appendix B: TroubleshootingLog ingestion with ObserveDeploy the OpenTelemetry CollectorAppendix A: Frequently asked questionsConfigure a syslog server