Validate the integration - Futurex Documentation

Validate in three stages: generate events, confirm the collector parsed them, then confirm they arrived in Observe with usable fields. Checking Observe alone hides parsing faults, because badly parsed records still arrive.

Allow enough time before judging the result

End to end delivery takes roughly 15 seconds: the HSM emits the event, the collector’s batch processor holds it for up to 5 seconds, then the export and Observe ingest complete.

Do not conclude that the integration failed after a few seconds of silence. Checking too early produces a convincing false negative and sends you looking for firewall problems that do not exist. Wait at least 15 seconds, then check again.

Generate representative events

Authentication events are the simplest to produce on demand and they exercise the fields that matter most.

Produce an authentication failure by logging in with an incorrect password. Expect the failure envelope [AOGUSR;BBLOGIN FAILED;CNN;ERInvalid login.;].

Produce an authentication success by completing both administrative logins on one connection.

Optionally produce a configuration change by reading and rewriting the forwarding setting with SLFW.

Each successful dual login also generates identity update events, because the HSM records the last login time and the login counter for both identities.

Confirm the collector parsed the events

With the debug exporter enabled, inspect the collector output:

docker logs otelcol-observe 2>&1 | grep -E 'Timestamp|SeverityText|-> hsm\.'

A correctly parsed authentication failure looks like this:

Timestamp: 2026-08-19 21:19:36.532553 +0000 UTC
SeverityText: notice
     -> hsm.device: Str(FX1234567890)
     -> hsm.service: Str(cryptolib)
     -> hsm.level: Str(notice)
     -> hsm.message: Str(CONFIG:Failed Log In Attempt:Admin1)
     -> hsm.event_type: Str(auth_failure)

Check the following:

All five hsm. attributes are present and populated.
Timestamp matches the event time in UTC, not the time the collector received it.
No un-namespaced device, service, level, message, pri, or fx_time attributes remain.

Confirm nothing failed to parse or export:

docker logs otelcol-observe 2>&1 | grep -icE 'permanent error|failed to send|401|403|429'

A result of 0 means every record exported cleanly.

Confirm the events arrived in Observe

In Observe, open a worksheet and select your datastream, for example futurex-hsm-syslog.

Set the time range to the last 15 minutes.

Filter for your appliance identifier, for example FX1234567890.

Rows appear with hsm.device, hsm.service, hsm.level, hsm.message, and hsm.event_type populated as separate fields.

Confirm that at least one row has hsm.event_type set to auth_failure and others set to auth_success.

Expected fields

Field	Source	Example
`hsm.device`	Appliance identifier, `FX` plus the serial number	`FX1234567890`
`hsm.service`	The Service column in the appliance’s syslog view	`cryptolib`, `serv-0`
`hsm.level`	The Log Level column	`notice`
`hsm.message`	The Message column, unmodified	`CONFIG:Failed Log In Attempt:Admin1`
`hsm.event_type`	Derived classification	`auth_failure`, `auth_success`, `config_change`, `identity_update`, `other`
`host.name`	Resource attribute copied from `hsm.device`	`FX1234567890`
`service.name`	Resource attribute set by the collector	`futurex-hsm`
Log body	The unmodified syslog datagram	`<5>Aug 19 21:19:36 : \|...\|`

The raw datagram is always retained in the log body, so no information is lost even when a message shape is not recognized.

Expect steady background traffic

An HSM in service produces a continuous baseline of authentication and identity update events from its own service accounts and client applications. Client identities log in on a recurring schedule, so event volume never drops to zero. Treat that baseline as a feature. A sudden drop to zero is a strong signal that log delivery has broken, which is worth alerting on. It also means volume dashboards will never look quiet, so tune alert thresholds against the observed baseline rather than against zero.

Remove the debug exporter

Once validation passes, remove debug from the exporter list and restart the collector. The detailed verbosity writes every log record to the collector’s own output, which wastes disk and duplicates the shipped data.

​Allow enough time before judging the result

​Generate representative events

​Confirm the collector parsed the events

​Confirm the events arrived in Observe

​Expected fields

​Expect steady background traffic

​Remove the debug exporter

Allow enough time before judging the result

Generate representative events

Confirm the collector parsed the events

Confirm the events arrived in Observe

Expected fields

Expect steady background traffic

Remove the debug exporter