> ## 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.

# Validate the integration

> Generate representative HSM events, confirm the collector parses them, and verify the records and their fields arrive in Observe.

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.

<Warning>
  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.
</Warning>

## Generate representative events

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

<Steps>
  <Step>
    Produce an authentication failure by logging in with an incorrect password. Expect the failure envelope `[AOGUSR;BBLOGIN FAILED;CNN;ERInvalid login.;]`.
  </Step>

  <Step>
    Produce an authentication success by completing both administrative logins on one connection.
  </Step>

  <Step>
    Optionally produce a configuration change by reading and rewriting the forwarding setting with `SLFW`.
  </Step>
</Steps>

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:

```bash theme={null}
docker logs otelcol-observe 2>&1 | grep -E 'Timestamp|SeverityText|-> hsm\.'
```

A correctly parsed authentication failure looks like this:

```text wrap theme={null}
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:

```bash theme={null}
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

<Steps>
  <Step>
    In Observe, open a worksheet and select your datastream, for example `futurex-hsm-syslog`.
  </Step>

  <Step>
    Set the time range to the last 15 minutes.
  </Step>

  <Step>
    Filter for your appliance identifier, for example `FX1234567890`.

    <Check>
      Rows appear with `hsm.device`, `hsm.service`, `hsm.level`, `hsm.message`, and `hsm.event_type` populated as separate fields.
    </Check>
  </Step>

  <Step>
    Confirm that at least one row has `hsm.event_type` set to `auth_failure` and others set to `auth_success`.
  </Step>
</Steps>

## 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.


## Related topics

- [Validate the integration](/Integrations/CryptoHub/Certificate_Authority/Smallstep_step-ca/Validate_the_integration.md)
- [Validate and test](/Integrations/CryptoHub/IT_automation_and_orchestration/Ansible/Post-integration_tasks/Validate_and_test.md)
- [Validate and test the integration](/Integrations/KMES_Series_3/Data_protection/Google_Workspace_Client-Side_Encryption/Validate_and_test_the_integration.md)
- [Initiate and validate the tunnel](/Integrations/CryptoHub/VPN/strongSwan/Initiate_and_validate_the_tunnel.md)