15. The On-Site Agent
Every site that shares data with VDURA Sentinel does so through an on-site agent. The rest of this guide describes the cloud console, which only ever shows what these agents have chosen to send. This chapter describes the agent from the customer’s side: where it comes from, what it sends, and what the customer controls.
15.1 Two Forms of the Agent
The agent depends on the hardware at the site:
- V5000 systems: the VDURA Sentinel agent is built into PanFS, starting with PanFS 12.x. It ships and upgrades with PanFS and has no version or release schedule of its own.
- Legacy, pre-V5000 hardware: the agent is a standalone Docker container installed alongside the system. It has its own release cadence, unrelated to PanFS releases.
In both forms, the agent reads each realm’s own PanActive and Observability APIs read-only, and, if the customer has enabled sharing, periodically sends a summarized snapshot to VDURA Sentinel over outbound HTTPS. Nothing connects into the customer’s network, and VDURA Sentinel cannot ask a site to send anything on demand (see 1.2). The agent also serves the customer a local copy of the same kind of dashboard, entirely inside their own network, whether or not they share anything with VDURA.
The VDURA Sentinel cloud service itself is versioned separately, but that is internal to VDURA; there is nothing about it for a customer to track or upgrade.
15.2 What a Site Sends
Everything a site shares with VDURA Sentinel is chosen by the customer, leaves the site only as outbound HTTPS, and can be inspected before and after it is sent. Nothing is ever sent back into the customer’s network.
Always included: the agent’s hostname and the site’s customer ID and name, plus, for each realm, its management address, name, PanActive status (ok, warning, or error), online and reachable flags, collection time, and PanActive web UI address.
Included only while the matching category is switched on (the customer can switch each one off):
| Category | What is sent |
|---|---|
| Capacity | Total and used bytes per realm. No file or directory information of any kind. |
| Node inventory | Counts of directors, storage nodes, and storage sets by status, plus a list of up to 128 nodes per realm (name, chassis serial number, role, status, and management IP address). Switching this category off removes both the counts and the node list. |
| Alerts | Alert counts by severity and up to 100 alerts per realm (severity, message text, affected component, node addresses the alert mentions, timestamps, occurrence counts, and suggested remediation). Alert text is written by the realm and can name internal hosts or components. This category also feeds VDURA’s proactive alerting. |
| API deep dive | For realms with the Observability API enabled: the realm record, nodes, hardware inventory, storage sets and volumes (names, sizes, and space use), virtual subnets, tenant names and roles, and metrics target health. This is what powers the deep-dive pages and the API Explorer here. |
Never sent: credentials, file data (file names, directory structures, user data, or data samples), information about client machines or workloads, network captures, SSH keys, and configuration files. System logs are never part of the telemetry snapshot; they leave only through diagnostic captures (see 8.3), with credentials, tokens, and keys scrubbed out first. Filtering happens at the site before a snapshot is built, not in the cloud after it arrives.
15.3 What the Customer Controls
The agent’s own local page lets the customer:
- Pause and resume scheduled sharing at any time. While paused, nothing is sent automatically, but the customer can still push manually.
- Switch categories on and off, as described above.
- Inspect the payload. A payload inspector shows the exact data the next push will contain, with the category choices applied.
- Review the audit log. Every push, automatic or manual, is recorded with its time, number of realms, size, and whether it was delivered or failed. Every diagnostic send is recorded too. The exact contents of the most recent 100 pushes are kept on the site’s own machine, and that copy never leaves it.
If sharing is paused or has never been configured, local monitoring, alerts, and log captures carry on, but the features that run in the cloud stop for that site: VDURA cannot alert on the site’s fleet, captured logs are stored but not analyzed, no support request opens automatically, and the Ask Sentinel and Health Overview panels are unavailable because both reason over fleet history that the cloud holds.
15.4 Diagnostics from the Site
Diagnostic captures leave the site only in the ways described in 8.3: a person sends one, or the agent sends one automatically when a realm raises a critical or warning alert it has never shown before. Automatic sending is on by default and can be narrowed to critical alerts only or turned off from the agent’s own Sentinel page. Every capture is scrubbed of credentials, tokens, and keys before it leaves, and every send appears in the audit log described above.
15.5 Site Packages for Legacy Hardware
On legacy hardware, a site is onboarded with a deployment package built on the Site Deployment page. A site package is pre-provisioned with:
- The site’s identity (ID and display name).
- The collection mode and the realm addresses to monitor, either a fixed list of distinct IP addresses or automatic discovery.
- The polling interval, 300 seconds by default.
- The site’s ingest token (see 11).
- Automatic diagnostics, on by default.
The one thing left for the site to supply is a login for the storage systems; a read-only account is recommended. The token can be rotated or revoked at any time from the Ingest tokens page. Because the package contains a live token, it should be treated as sensitive and shared only with the person installing it.
This guide reflects VDURA Sentinel as observed at sentinel.vdura.dev in September 2026 (build b52faa3, API 0104ee3+, s3 mode; customers alpha-1, bravo-2, vdura-lab).