> ## Documentation Index > Fetch the complete documentation index at: https://docs.futurex.com/llms.txt > Use this file to discover all available pages before exploring further. # Appendix A: Futurex syslog message format > Anatomy of the forwarded HSM syslog message, how it deviates from RFC 3164, and why a standard syslog parser silently loses the useful fields. 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: ```text wrap theme={null} <5>Aug 19 20:59:55 : |2026:08:19:20:59:55.777764 FX1234567890 cryptolib notice CONFIG:Failed Log In Attempt:Admin1| ``` The structure is: ```text wrap theme={null} MMM DD HH:MM:SS " : " | YYYY:MM:DD:HH:MM:SS.ffffff DEVICE SERVICE LEVEL MESSAGE | ``` | Element | Example | Notes | | ----------------- | ------------------------------------- | ----------------------------------------------------------------------- | | `PRI` | `<5>` | Facility `kern` (0) and severity `notice` (5) | | Header timestamp | `Aug 19 20:59:55` | Second precision, no timezone | | Separator | `:` | Occupies the position where hostname and tag belong | | Payload timestamp | `2026:08:19:20:59:55.777764` | Microsecond precision, UTC, colon-separated | | Device | `FX1234567890` | `FX` followed by the appliance serial number | | Service | `cryptolib` | Space-padded; matches the Service column in the appliance's syslog view | | Level | `notice` | Matches the Log Level column | | Message | `CONFIG:Failed Log In Attempt:Admin1` | Matches the Message column | 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](/Excrypt_HSM/7.10.1.x/administrator-guide/administration-configuration/web-portal/logging/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`: ```text wrap theme={null} facility: 0 facility_text: kern priority: 5 message: : |2026:08:19:20:59:55.777764 FX1234567890 cryptolib notice CONFIG:Failed Log In Attempt:Admin1| ``` 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: ```text wrap theme={null} hsm.device: FX1234567890 hsm.service: cryptolib hsm.level: notice hsm.message: CONFIG:Failed Log In Attempt:Admin1 hsm.event_type: auth_failure ``` 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: | Service | Role | | ----------- | ------------------------------------------------- | | `cryptolib` | Authentication outcomes and configuration actions | | `serv-0` | Identity and database object updates | 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: ```text wrap theme={null} CONFIG:Failed Log In Attempt:Admin1 CONFIG:Too Many Failed Log In Attempts:Admin1 CONFIG:Admin1:Log In User:Admin1 CONFIG:Admin1:Admin2:Log In User:Admin2 CONFIG:Admin1:Admin2:Syslog:Forwarding Port:5516:5515 CONFIG:AppIdentity-1:AppIdentity-2:Time Changed:08-19-2026 21-22-54 Admin1: Updated fxhsm::auth::Identity 'Admin1': 'Num Logins' changed from '22' to '23' Admin1,Admin2: Updated fxhsm::auth::Identity 'Admin2': 'Last Login' changed from '...' to '...' ``` 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::`. 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: | Value | Match | Meaning | | ----------------- | ----------------------------------------- | -------------------------------------- | | `auth_failure` | `Failed Log In Attempt` | A login was rejected | | `auth_lockout` | `Too Many Failed Log In Attempts` | Brute-force lockout triggered | | `auth_success` | `Log In User` | A login completed | | `config_change` | `CONFIG:` plus `Settings` or `Forwarding` | A device setting changed | | `identity_update` | `fxhsm::auth::Identity` | An identity record was updated | | `time_change` | `Time Changed` | The appliance clock was set | | `other` | Default | Unrecognized; inspect 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: Troubleshooting](/Integrations/VirtuCrypt/Log_ingestion_with_Observe/Appendix_B_Troubleshooting.md) - [Log ingestion with Observe](/Integrations/VirtuCrypt/Log_ingestion_with_Observe/Log_ingestion_with_Observe.md) - [Deploy the OpenTelemetry Collector](/Integrations/VirtuCrypt/Log_ingestion_with_Observe/Deploy_the_OpenTelemetry_Collector.md) - [Appendix A: Frequently asked questions](/Integrations/VirtuCrypt/Syslog_server_configuration_for_VirtuCrypt/Appendix_A_Syslog_FAQ.md) - [Configure a syslog server](/Integrations/VirtuCrypt/Syslog_server_configuration_for_VirtuCrypt/Configure_a_syslog_server.md)