Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.
Version: 2.15.0

Health Check

Introduction​

Health Check provides the tools and workflows for validating that your Data Security environment is operating correctly. Rather than waiting for a missed detection or a gap in your audit trail to surface a problem, use this section to confirm — on a regular basis and after any change — that the underlying detection and audit pipeline is healthy.

Use Health Check to:

  • Validate ransomware detection and snapshot behavior.
  • Verify audit event ingestion and ECA processing.
  • Review service health and operational status.
  • Identify issues before they affect threat detection, auditing, or recovery workflows.

Health Check covers three self-test tools — Security Guard (validates the ransomware detection and response pipeline end to end), Robo Audit (validates the audit ingestion pipeline for Data Auditing), and Runbook Robot (validates disaster recovery failover/failback readiness — a Disaster Recovery feature that appears on this same shared Health Check page; see Runbook Robot in Health Check for the DR-specific configuration it depends on) — plus Manage Services, where you confirm the ECA nodes and Eyeglass itself are actually connected and processing events (see Manage Services below).

The Health Check page has five tabs: Overview (summary cards for Security Guard, Robo Audit, and Runbook Robot, plus a Runs calendar heatmap and per-tool run/pass/fail counters), Runs (a filterable, master-detail history of all three tools' executions), Manage Services (ECA Health Check / ECA Monitor service status — see ECA Health Check below), Log Parser (uploaded backup files used to generate Log Parser reports), and Settings (per-tool configuration for Security Guard, Robo Audit, and Runbook Robot).

When to Use Health Check​

  • After a new installation or upgrade.
  • After changing ECA, audit, or detection configuration.
  • When audit events are missing or delayed.
  • When detection, lockout, snapshot, or recovery behavior needs validation.
  • During routine operational reviews.

Security Guard​

What Security Guard Does​

Security Guard is an automated validation tool that tests whether your ransomware detection and response pipeline is working end to end. It simulates a ransomware attack against a dedicated honeypot location, verifies that Ransomware Defender detects it, confirms that the lockout fires correctly, and then validates that user access can be restored — all without touching your production data.

Running Security Guard regularly confirms that the complete detection-to-response chain is functioning: audit events are flowing from the cluster to the ECA, the ECA is processing them, Ransomware Defender is evaluating them, the lockout mechanism works, and the restore process works.

Security Guard tests the following in sequence:

  1. Creates test files with a known ransomware-associated extension on a dedicated honeypot share or ECS bucket.
  2. Waits for Ransomware Defender to detect the simulated attack.
  3. Verifies that the user lockout is applied correctly.
  4. Initiates a user access restore.
  5. Verifies that access is restored.
  6. Reports pass/fail for each step with timestamps.
  7. Emails results to the configured administrator.
info

Security Guard writes 100 test files at a rate of one per second. If the detection does not occur within those 100 seconds, Security Guard marks the test as failed. This can happen in environments where audit events experience processing delays between the cluster and the ECA — see Advanced timer configuration below.

How to Set Up Security Guard​

Security Guard is configured under Health Check → Settings in the left sidebar.

Health Check → Settings has a dedicated Security Guard panel with an enable/disable toggle, a Run Now button, an Active Directory User sub-section (Managed Device, Username, Password), and an Intervals Between Runs control (a number plus a unit dropdown, for example 1 / Days).

Prerequisites — PowerScale​

Before configuring Security Guard for a PowerScale cluster, you need a dedicated service account.

Service account requirements:

  • Must be created specifically for Security Guard — do not share it with any other service, including the Robo Audit service account.
  • Must authenticate on every network element (cluster node) where Security Guard is enabled.
  • Must follow one of these formats:
    • Local account: username@clustername
    • Domain account: username@domain
Best practice

If your environment has multiple PowerScale clusters, enable Security Guard on only one cluster. Use a local account created in the System Zone.

When Security Guard runs on PowerScale, it automatically creates a dedicated share named igls-securityguard in the System Zone. This share acts as the honeypot target. The service account is the only account added to this share's permissions — the simulated attack is fully isolated from production shares and real user accounts.

note

If the Security Guard service account is also added to other shares (beyond igls-securityguard), those shares will also be locked out during a simulated attack, even though test files are only written to the honeypot share.

Prerequisites — ECS​

For ECS environments, Security Guard uses two dedicated Bucket Object users:

  • Test user — used to simulate the attack. Must not be assigned to any buckets other than the dedicated Security Guard test bucket.
  • Versioning user — used to enable bucket versioning as a protective measure during the test.

When you create these Bucket Object users, generate and securely record their access keys — you will need them during configuration. Security Guard automatically creates the dedicated test bucket on ECS. Do not reuse this bucket for any other purpose.

Configuration Steps​

  1. Navigate to Health Check → Settings, which shows the Security Guard, Robo Audit, and Runbook Robot panels stacked on one page.
  2. In the Security Guard panel, use the toggle to activate scheduled Security Guard runs.
  3. Set Intervals Between Runs using the number field and unit dropdown (for example, 1 / Days).
  4. Under Active Directory User, select the Managed Device and enter the Security Guard service account username and password (PowerScale), or the Bucket Object user access keys (ECS).
  5. The system validates the credentials on save. If authentication fails, an error is displayed — verify the account format and that the account exists on the cluster.

Running Security Guard On Demand​

To run an immediate test without waiting for the scheduled interval:

  1. Navigate to Health Check → Overview or Health Check → Settings.
  2. Find the Security Guard card or panel.
  3. Click Run Now.

Monitor progress in Health Check → Runs — a master-detail view (Status, Job Type, and Date filters, plus search) shared with Robo Audit and Runbook Robot runs. Select the running Security Guard entry and expand its steps in the Job Tree panel on the right to see real-time status for each phase; an Errors tab (alongside Job Tree) surfaces only failed steps. These same runs are also visible in the shared Jobs section of the left sidebar, since Health Check runs are job executions like any other.

Reviewing Test Results​

  1. Navigate to Health Check → Runs.
  2. Find the relevant Security Guard entry in the list (filter by Status or Job Type if needed).
  3. Select it to view the Job Tree for that run in the detail panel on the right.

The log shows each step with a timestamp and a pass/fail status. Any failed step includes a description of what was not verified — for example, if the lockout did not occur within the detection window, or if the restore did not complete successfully.

Security Guard Status Indicator​

Each tool's card on the Health Check Overview (Security Guard, Robo Audit) shows a pass-rate status based on its last ten runs, using the same three-color scale:

Status colorPass rateMeaning
GreenMore than 7 of the last 10 runs passedPipeline is healthy.
Amber5 to 7 of the last 10 runs passedModerate — investigate intermittent failures.
RedFewer than 5 of the last 10 runs passedCritical — pipeline is not reliably functioning, escalate immediately.

Testing with a Custom File Extension​

You can also test the lockout and restore process manually using a file extension of your choice, without running a full Security Guard job. This is useful for verifying SIEM alert integration or testing a specific extension that is relevant to your environment.

Requirements: Eyeglass version 2.5.7 or later.

To test with a custom extension:

  1. Go to Detection Controls → Suspicious Extensions.
  2. Click Add + and enter a unique file extension that is not used in your production environment. Enable it.
  3. Note your current Critical Threshold values from Detection Controls → Settings → Advanced Severity Levels.
  4. Mount a SmartConnect name and share it within an access zone that has auditing enabled — for example: \\fqdn\smb-share-name.
  5. Create files using your custom extension until you exceed the Critical Threshold value. This triggers a lockout.
  6. Verify the lockout was applied and that the restore process works correctly.
  7. Remove the custom extension from the Suspicious Extensions list after testing.

Advanced Timer Configuration​

In some environments, audit events are delayed between the cluster and the ECA before they reach Ransomware Defender for processing. If Security Guard fails because the detection did not occur within the 100-second write window, you can extend the detection timer using the CLI commands below. You can also apply a timer between the lockout and restore steps to allow AD and share settings to propagate to the cluster before the restore is verified.

SSH to the Eyeglass appliance and run:

# Set the detection wait window (seconds Security Guard waits for the event to be detected)
igls rsw securityguardsettings set --sg_waitforevent_timer_seconds=600

# Set the delay between lockout and restore verification (seconds)
igls rsw securityguardsettings set --sg_restore_timer_seconds=60

Run igls rsw securityguardsettings help to see the current values for both settings.

If Security Guard events are being raised within minutes of the previous event being archived, extend the lockout time using the relevant CLI command.

Security Guard Best Practices​

  • Run Security Guard at least weekly. Daily is preferable in production environments. A passing Security Guard run is your proof that the end-to-end pipeline — cluster auditing, ECA processing, Ransomware Defender detection, lockout, and restore — is functioning correctly.
  • Do not share the Security Guard service account. The account must be unique to Security Guard. Sharing it with Robo Audit or other services causes both to fail.
  • Monitor the Security Guard status. A card dropping from green to amber is an early warning that something in the pipeline is degrading. Investigate before it reaches red.
  • Review failed steps in the job log. Each failed step provides a specific description. Common failures include audit event processing delays (extend the timer), credential issues (validate the service account on each node), and snapshot budget exhaustion (review snapshot quota settings).
  • Use Security Guard to validate after any infrastructure change. After upgrading Eyeglass, the ECA, or PowerScale OneFS, run Security Guard immediately to confirm the pipeline was not disrupted.

Robo Audit​

What Robo Audit Does​

Robo Audit is an automated health check for the Data Auditing pipeline. It continuously tracks user activity in SMB-connected environments by logging file and directory events, storing them in the audit database, and running scheduled reports that verify successful and failed event capture.

Where Security Guard validates the ransomware detection and response pipeline, Robo Audit validates that audit data is being correctly ingested by the ECA, written to the database, and made queryable. A passing Robo Audit job confirms that your audit infrastructure is functioning and that activity on your SMB shares is being recorded as expected.

Robo Audit is particularly useful for:

  • Confirming continuous audit data flow after infrastructure changes or ECA maintenance.
  • Detecting silent failures in the audit pipeline before they affect security visibility.
  • Providing a scheduled, timestamped audit record that can be used for compliance purposes.
Platform note

Robo Audit monitors SMB-connected environments only.

How to Set Up Robo Audit​

Prerequisites​

Create a dedicated service account for Robo Audit before configuring the feature.

Service account requirements:

  • Must be a local PowerScale user or an AD user account.
  • Must be created specifically for Robo Audit — it cannot be shared with Security Guard or any other service. These features require separate, unique service accounts.
  • Must have access to the SMB shares on the clusters you want to monitor.

Account format:

  • Local PowerScale user: user@clustername
  • Active Directory user: user@domain or domain\user

Configuration Steps​

Robo Audit configuration is under Health Check → Settings, in its own panel below Security Guard — with the same layout (enable toggle, Run Now button, Active Directory User sub-section with Managed Device, Username, Password, and an Intervals Between Runs control).

  1. Navigate to Health Check → Settings and find the Robo Audit panel.
  2. Under Active Directory User, select the Managed Device(s) and enter the username and password for the Robo Audit service account using the correct format for your account type:
    • Local PowerScale user: user@clustername
    • AD user: user@domain or domain\user
  3. Use the toggle to activate scheduled Robo Audit runs.
  4. Set Intervals Between Runs. The default is once per day. Leave this at the default unless you need to troubleshoot, in which case you can increase the frequency temporarily (for example, once per hour) to get faster feedback.
  5. The system validates the username and password on save. If authentication fails, an error message is displayed — verify the account credentials and format.
  6. Click Run Now to start the first Robo Audit job manually and confirm the configuration is working.

Monitoring Robo Audit Jobs​

Monitoring a job in progress​

The direct path is Health Check → Runs: select the running Robo Audit entry from the filterable list on the left (Status, Job Type, and Date filters, plus search) to see its Job Tree in the detail panel on the right. The same job also appears in the shared Jobs section of the left sidebar, since Health Check runs are job executions like any other — use whichever is more convenient.

  1. Navigate to Health Check → Runs (or Jobs in the left sidebar).
  2. Find and select the Robo Audit job in the list.
  3. The Job Tree panel on the right expands automatically, showing each step being executed and its current status; an Errors tab (alongside Job Tree) surfaces only failed steps.

The Job Tree for a Robo Audit run shows the following steps in sequence, each reported per monitored cluster with its own status and timestamp:

  1. Checking license status — confirms the cluster's Data Auditing license is valid.
  2. Checking reachability — confirms the cluster is reachable from the ECA.
  3. Checking igls-roboaudit share — confirms the Robo Audit test share exists and is accessible.
  4. Create robo audit events — writes test file/directory events to the share.
  5. Run Robo Audit User Query Report — confirms the test events are queryable by user.
  6. Run Robo Audit Path Query Report — confirms the test events are queryable by path.

Each step reports OK on success. The Job Tree tab shows this hierarchical step view; the Errors tab (alongside it) surfaces only steps that failed, if any.

Reviewing job results​

  1. Navigate to Health Check → Runs.
  2. Filter or search for the relevant Robo Audit entry. The list shows each run's name, subtitle (job ID), and current status.
  3. Select it to view the full Job Tree for that job in the detail panel on the right, with Started, Completed, and Duration shown above the step list, and Download/Copy actions for the log.

A successful Robo Audit job confirms that:

  • The service account was able to authenticate on the cluster.
  • File events were created and written to the SMB share.
  • Those events were ingested by the ECA.
  • The events are queryable in the audit database.

A failed job log will identify which step failed — for example, authentication failure, ECA connectivity issue, or missing events — so you can diagnose the specific problem.

Robo Audit Best Practices​

  • Run Robo Audit daily. The default once-per-day schedule is appropriate for most environments. A passing Robo Audit job means your audit pipeline is healthy.
  • Keep the Robo Audit service account separate from Security Guard. These two features require distinct service accounts. Using the same account will cause both to fail.
  • Use the job log to diagnose failures. Each step in the log has a timestamp and a clear description of what was tested. The failure point tells you exactly where the pipeline is broken.
  • Run Robo Audit after ECA maintenance. After any ECA upgrade, restart, or configuration change, run a manual Robo Audit job immediately to confirm the audit pipeline is intact before returning the system to normal operations.
  • Combine with Security Guard. Security Guard validates the ransomware detection pipeline. Robo Audit validates the audit ingestion pipeline. Both should pass before you consider your Data Security deployment fully healthy.

ECA Health Check​

In addition to running Robo Audit, you should periodically verify the health of your ECA cluster directly. ECA Health Check is a lightweight, on-demand diagnostic tool for the Extended Cluster Appliance (ECA) — it runs a targeted script that inspects the current state and configuration of ECA services and generates a report of any potential issues, which can be reviewed directly in the UI or copied for support escalation.

Running the ECA Health Check Diagnostic Script​

  1. Open Health Check → Manage Services.
  2. Click ECA Health Check.
  3. In the dropdown, select Start Script.
  4. When prompted, enter the Eyeglass admin password and ECA sudo password to authorize script execution. Click Submit.
  5. After the script starts, select View Logs.
  6. Click the refresh icon periodically to update the log list. The list will not refresh automatically. It may take a few minutes to complete.
  7. When the new log is available, select it to open the results.
  8. (Optional) Click Copy to Clipboard to copy the log contents for Support or internal review.

Verifying ECA Cluster and Container Health​

  1. Navigate to Health Check → Manage Services — this tab lists each ECA node (for example anoeca1_1, anoeca1_2, anoeca1_3) plus Eyeglass itself, in a table with Virtual machine, IP:Port, Eyeglass Token, and Service Type columns, a per-row status dot, and a Last check-in timestamp — toggle between ECA Health Check and ECA Monitor views above the table. ECA Monitor opens a Grafana dashboard showing the event rate coming in from each ECA over time — use it to confirm events are actually flowing, not just that the node is checked in.
  2. Expand a row (chevron on the left) to see its container or service list.
  3. Verify that the IP addresses of all ECA nodes are listed.
  4. Confirm that all cluster nodes and all Docker containers show a green health indicator.

Containers to verify:

  • turboauditor
  • fastanalysis
  • kafka
  • zookeeper
  • evtarchive
note

HBase status can take up to 5 minutes to transition from a warning state to green after a restart. If a container remains in a warning or red state after 5 minutes, open a support case.

Memory monitoring (auto-enabled in 2.13 and later): Memory monitoring is enabled by default for the critical ECA containers listed above. When memory usage in a monitored container exceeds the threshold (default: 95%), the system automatically captures and dumps logs to the eca_logs directory for diagnostics. Review this directory periodically as part of routine maintenance.

To customize the memory threshold, add the following to eca-env-common.conf:

export CONTAINER_MEM_THRESHOLD=<value>

Replace <value> with your desired threshold percentage (for example: 90 for 90%).

Monitor ECA from Eyeglass​

Eyeglass can communicate with multiple Ransomware Defender or Active Auditor endpoints. Each endpoint requires a unique API token, generated through Data Security → Integrations → API Tokens. After generating a token for a specific ECA, include it in the ECA's startup command for authentication, along with the Eyeglass location.

How to verify everything is working, end to end:

  1. Open Health Check → Manage Services and review each row's status.
  2. Active (green) means the service is checked in and processing; Inactive (red) means it isn't.
  3. If a row shows Inactive, confirm the API token still exists and is valid: open Integrations → API Tokens and check that the token for that ECA is present.
  4. Switch to the ECA Monitor view on the same tab to open the Grafana event-rate dashboard — this confirms events are actively flowing in, not just that the node last checked in.
  5. If something still isn't right, run the ECA Health Check diagnostic script (see Running the ECA Health Check Diagnostic Script above) and share the resulting logs with Support.

Communication between Eyeglass and the ECA is bidirectional: the ECA sends security events to Eyeglass, and Eyeglass regularly queries the analytics database and tests database access. The ECA also:

  • Sends heartbeats to Eyeglass.
  • Notifies Eyeglass of any detected threats.
  • Periodically sends statistics on processed events.
  • Periodically polls for updated ransomware definitions, thresholds, and ignore list settings.

Health Check → Manage Services (described above) is where registered ECAs and CA UIM probes appear, showing the health of each process running inside each node.

Understanding service states:

  • Active (green status dot) — the service has checked in with a heartbeat and is processing normally.
  • Inactive (red status dot) — the service has failed to send a heartbeat and is no longer processing.

This status dot is the fastest way to confirm Manage Services is working: green means everything is fine, red means something needs attention.

Interpreting health states:

  • Up — the service is running, and the uptime is displayed in days.
  • Down — the service is not running.
warning

Do not use the Delete icon per service registration unless directed by support. This action removes the registration from the remote service.

Troubleshoot Cluster Event Ingestion​

If event processing appears delayed or backlogged, use KafkaHQ to inspect the topic queue directly:

  1. Log in to ECA as ecaadmin.
  2. Run ecactl containers up -d kafkahq.
  3. Go to https://x.x.x.x/kafkahq (replace x.x.x.x with the IP address of node 1 in the ECA cluster) and log in as ecaadmin.
  4. Review the topics list. A positive number in the Lag column indicates a backlog in event processing.
  5. Screenshot the topics list and provide it to Support if you need to open a case.

Component Health Checks for Support Cases​

If Superna Support asks you to check the health of a specific ECA backend component beyond what ECA Health Check and Manage Services report, the component's own web UI can be checked directly.

HBase-master:

  1. Open Health Check → Manage Services → ECA Health Check, expand the relevant node, and select the Web Address link on the hbase-master row — this opens the HBase-master UI directly. (Alternatively, browse to http://<ECA_NODE1_IP>:16010.)
  2. Review the HBase table list for any regions shown as offline or failed.
  3. Take a screenshot of the HBase-master server info and any offline/failed regions, and provide it to Support.

Spark-master: If Data Auditing (Easy Auditor) reports an issue, Support may ask you to check the Spark-master UI. Open Health Check → Manage Services → ECA Health Check, expand the relevant node, and select the Web Address link on the spark-master row (the spark-history row links to the Spark History Server the same way). Take a screenshot of the current worker/application status and provide it to Support.

Kafka (KafkaHQ): See Troubleshoot Cluster Event Ingestion above for how to set up and access KafkaHQ, and what to check for a processing backlog.

Runbook Robot​

Runbook Robot is a Disaster Recovery self-test tool that automates daily DR testing by simulating failover and failback operations, but it's configured and monitored from this same shared Health Check page alongside Security Guard and Robo Audit.

What Runbook Robot Does​

Per its in-app description: Runbook Robot "automates daily disaster recovery testing by executing scheduled failover and failback operations on isolated test data." The "isolated test data" is the specially named SyncIQ policy (Basic DR Configuration) or full Access Zone simulation (Advanced DR Configuration) documented in the Runbook Robot configuration guide.

How to Set Up Runbook Robot​

Configured under Health Check → Settings, in its own panel below Robo Audit, with the same layout as the other two tools: an enable/disable toggle, a Run Now button, and an Active Directory User sub-section (Managed Device — supports selecting multiple devices, Username, Password). The underlying DR configuration this toggle depends on is covered in Basic DR Configuration or Advanced DR Configuration.

Monitoring Runbook Robot Jobs​

Runbook Robot runs appear alongside Security Guard and Robo Audit runs in Health Check → Runs, with the same Job Tree/Errors detail view described above for Robo Audit.

Health Check — including Runbook Robot — requires no additional license and is configured automatically during installation. Runbook Robot is labeled a Disaster Recovery feature even though it lives here in the shared Health Check page, alongside Security Guard and Robo Audit.

See the full Runbook Robot configuration guide for setup details.

Manage Services​

Manage Services is the Health Check tab where you confirm the services that process events coming from your storage device — running on each ECA node, plus Eyeglass itself — are actually connected and working. It ships with Data Security at no additional license, and is configured automatically during installation; there's nothing extra a customer needs to enable.

  • How to check it's working: each row shows a status dot — Active (green) means the service is checked in and processing; Inactive (red) means it isn't. See How to verify everything is working, end to end above for the full troubleshooting flow (status check → API token → Grafana event rate → ECA Health Check script for Support).
  • Why this matters: this is also how a customer confirms their ECA deployment is healthy day to day — there's no separate "Managed Services" status page beyond this tab. If something looks wrong here, the ECA Health Check script generates the logs Support needs to help you.

Contacting Superna Support​

When opening a support case related to Data Security, include:

  • Your Eyeglass version number
  • The ECA cluster name and version
  • A description of the issue or the relevant alarm/event IDs
  • Security Guard job history results if the issue relates to detection or response
  • ECA Health Check output if available

See also​