Management

The Directors web interface provides comprehensive management capabilities for Director deployment, configuration, and monitoring through an intuitive graphical dashboard.

Access

• Navigate to Home > Fleet Management > Directors -or-
• Use the hamburger menu and select Fleet Management > Directors.

The Directors dashboard provides centralized visibility and control over all Director instances across your infrastructure. Directors orchestrate data collection, processing, and routing, with support for distributed processing through Agent pre-processing capabilities.

Table

The table displays Name, Mode (Managed/Self-Managed), Installation Type (Standalone/Cluster), Status (Enabled/Disabled), Connection Status (Connected/Not Connected), and an Actions menu (⋮) for each Director.

For Self-Managed Directors, a warning icon appears next to the Mode when configuration has changed. The tooltip reads "Configuration has changed and the current one has to be deployed" - download the updated configuration file and deploy to Director.

warning

When the configuration change indicator appears, the Director is running with an outdated configuration. Download and deploy the updated vmetric.vmf file promptly to ensure consistent behavior.

Table Controls

Filter Directors using Search directors (by name) and Status dropdown (All, Enabled, Disabled). The Refresh button reloads table data. Click Create director to launch the creation wizard — see Deployment for the step-by-step walkthrough.

Actions

Each Director row provides an Actions menu (⋮) with the following operations:

View Details:

• See details - Navigate to Director detail view

Status Management:

• Enable Director - Activate disabled Director
• Disable Director - Deactivate enabled Director

Configuration:

• Download Config - Download vmetric.vmf configuration file (Self-Managed only)

Deletion:

• Delete Director - Remove Director from platform

Detail View

Clicking a Director from the overview table opens the detailed management interface with four tabbed panels.

Director Details Tab

View and edit Director configuration through editable tiles:

General Information:

• Director Name - Editable unique identifier
• Mode - Management type (Managed or Self-Managed)
• Status - Current operational state
• Connection Status - Real-time connectivity indicator

Edit Functionality:

• Edit icon on tiles for inline editing
• Save changes with validation
• Cancel to discard modifications
• Real-time validation feedback

Connection Details Tab

Installation Command Panel:

Access installation and reinstallation resources:

Installation Scripts:

• Platform-specific installation commands
• PowerShell script for Windows
• Bash script for Linux/macOS
• Copy button for easy clipboard access

API Key Management:

• Display current API key
• Regenerate API key when needed
• Update scripts with new key automatically

Reinstallation Process:

• Access reinstallation commands
• Use when Director needs redeployment
• Maintains configuration and settings
• Preserves Director identity and connections

Access Management Tab

View and edit access controls for the Director.

Access Tokens:

• List of configured tokens with expiration dates
• Create new tokens or revoke existing tokens
• Copy token values to clipboard

Access Restriction:

• Current restriction status and configured sources
• Edit to add, remove, or modify IP restrictions

Activity Logs Tab

Director Activity History:

Track Director operations and lifecycle events through comprehensive activity logging:

Activity Table Columns:

Column	Description
User	Email address of the user who performed the action (clickable link to user profile)
User IP	IP address from which the action was performed
Object Type	Entity type (always "Director" for this view)
Object	Name of the affected Director
Action	Operation performed (see Action Types below)
Action Description	Detailed description of the operation
Created At	Timestamp of when the action occurred

Action Types:

Action	Description
CreatedDirector	A new Director was created
UpdatedDirector	Director configuration was modified
DeletedDirector	A Director was removed

Table Features:

• Search - Filter activities by any field content
• Action Type Filter - Multi-select filter to show specific action types
• Timeframe Filter - Filter by time period (Last 24 hours, Last 7 days, Last 30 days, Last 90 days, All time)
• Pagination - Navigate through large activity logs with configurable page sizes (10, 20, 30 items)

Operations

Enable / Disable

To change Director status:

1. Navigate to Director detail view or use the Actions menu from overview
2. Click Actions menu
3. Select Enable Director or Disable Director
4. Confirmation notification confirms the status change

Enabled Directors actively process data. Disabled Directors preserve configuration but stop all processing.

Download Config

For Self-Managed Directors:

Download the current Director configuration file for deployment:

1. Navigate to Director detail view
2. Click Actions menu
3. Select Download Config
4. System downloads vmetric.vmf file to browser's Downloads directory
5. Deploy file to <vm_root>/Director/config/ directory on Director server

Configuration Update Workflow:

When configuration changes occur:

• Warning icon appears next to "Self-managed" mode indicator
• Tooltip indicates deployment needed
• Download updated config file
• Replace existing config on Director server
• Restart Director service to apply changes

warning

Self-Managed Directors require a service restart after deploying configuration updates. Plan maintenance windows accordingly for production environments.

Delete

Delete Director Process:

Remove a Director from the platform with dependency checking:

1. Navigate to Director detail view (or use Actions menu from overview)
2. Click Actions menu
3. Select Delete Director
4. Deletion modal appears with confirmation

Standard Deletion:

• Confirm Director name matches
• Click Delete to proceed
• Success notification confirms deletion
• Redirect to Directors overview

Deletion with Dependencies:

If Director has active dependencies, error modal displays:

note

Directors with connected devices or agents cannot be deleted. The error modal lists all dependencies that must be reassigned or removed first.

Error Modal Contents:

• "Cannot delete Director" message
• Devices - List of devices using this Director
• Agents - List of agents connected to this Director
• Action Required - Remove or reassign dependencies before deletion

Dependency Resolution:

1. Note listed devices and agents
2. Reassign devices to different Director or delete
3. Reassign agents to different Director or delete
4. Retry Director deletion after dependencies removed

Transport Layer Security

The Director's HTTP configuration server terminates TLS for agent check-in, pipeline delivery, CA distribution, and installer downloads. TLS is configured through the proxy_tls block delivered via node or cluster properties on the platform. Users do not edit vmetric.yml for TLS — all settings are managed through the web interface.

This section documents the proxy_tls fields, the certificate resolution order, and the bootstrap endpoints used by agents to trust a self-signed Director. Cluster inter-node TLS is a separate concern, documented in Reference under Environment Configuration.

Modes

The Director listener operates in one of three TLS modes, selected by proxy_tls.mode:

Mode	Description
self-signed	Default. Director serves its own certificate. Agents bootstrap the CA through the plain-HTTP discovery endpoints (/ca.pem, /install.ps1, /install.sh).
custom	Operator provides a certificate as a PEM pair or a PKCS#12 (PFX) bundle, supplied either inline in the node configuration or as files on disk.
offloaded	An upstream load balancer terminates TLS. The Director skips its own HTTPS listener and serves plain HTTP to the upstream tier.

Configuration

The proxy_tls block carries the listener configuration delivered through node or cluster properties. Cluster-scoped values override node-scoped values, and node-scoped values override system defaults.

proxy_tls:
  mode: self-signed        # self-signed | custom | offloaded
  status: false            # enable the HTTPS listener
  cert_name: cert.pem      # PEM cert file path, or inline PEM starting with "-----BEGIN"
  key_name: key.pem        # PEM key file path, or inline PEM starting with "-----BEGIN"
  pfx_name: cert.pfx       # PKCS#12 bundle file path
  pfx_password: ""         # PFX password; overridden by VMETRIC_PFX_PASSWORD env var
  ca_name: ca.pem          # CA certificate file path or inline PEM
  port: 443                # HTTPS listener port
  discovery_enabled: true  # serve /ca.pem, /install.ps1, /install.sh on plain HTTP

Field	YAML Path	Type	Default	Required
Mode	proxy_tls.mode	string	self-signed	Y
Status	proxy_tls.status	bool	false	N
Cert Name	proxy_tls.cert_name	string	--	Y*
Key Name	proxy_tls.key_name	string	--	Y*
PFX Name	proxy_tls.pfx_name	string	--	Y*
PFX Password	proxy_tls.pfx_password	string	--	N
CA Name	proxy_tls.ca_name	string	--	N
Port	proxy_tls.port	int	443	N
Discovery Enabled	proxy_tls.discovery_enabled	bool	true	N

* = Conditionally required. In custom mode, supply either cert_name + key_name or pfx_name (with pfx_password where applicable). In self-signed mode, the Director generates its own material. In offloaded mode, no certificate is read.

The cert_name, key_name, pfx_password, and ca_name fields support Vault credential references. Instead of embedding a literal value, supply an environment variable (${VAR_NAME}) or a vault token ($secret{store=<name>,ref=<value>} or $secret{id=<id>}). The Director resolves the reference at startup with a 30-second timeout. If resolution fails, the HTTPS listener does not start and the error is logged with the specific field that failed.

Certificate resolution

Before evaluating the priority chain below, the Director resolves any credential references in the proxy_tls field values (environment variables and vault tokens). Resolution uses a 30-second timeout per field. On failure, the Director logs a field-specific error and aborts HTTPS startup.

Once references are resolved, certificate material is selected in the following order. The first step that yields a usable pair is used; later steps are not consulted.

1. Node PFX -- proxy_tls.pfx_name resolved relative to the Director root. The password comes from the VMETRIC_PFX_PASSWORD environment variable if set, otherwise from proxy_tls.pfx_password.
2. Node inline PEM -- proxy_tls.cert_name and proxy_tls.key_name values that start with -----BEGIN are treated as inline PEM content and consumed in memory without writing to disk. When no explicit CA is configured, the Director extracts intermediates and the root from the cert chain.
3. Node PEM files -- proxy_tls.cert_name and proxy_tls.key_name treated as file paths. Relative paths are resolved against the Director root and rejected if they escape it; absolute paths are allowed.
4. Disk fallback -- cert.pem, key.pem, and optional ca.pem placed directly in the Director configuration directory. If ca.pem is absent, the Director attempts to extract the CA chain from the certificate file.

If no certificate material is available, the Director logs a single warning and continues polling every five seconds until the platform API delivers one. The HTTPS listener does not start until resolution succeeds.

Certificate reload

File-based certificates reload automatically on the next TLS handshake after the file modification time changes. The Director pre-loads material at startup so configuration errors surface immediately rather than on first connection. Inline PEM material delivered through node configuration is static until the platform re-delivers the node properties.

The TLS listener enforces a minimum protocol version of TLS 1.2.

Agent bootstrap

In self-signed mode with discovery_enabled: true, the Director serves three discovery endpoints over plain HTTP so that agents can trust the self-signed certificate before establishing an HTTPS session:

Endpoint	Purpose
/ca.pem	CA certificate used to verify the Director during the initial TLS handshake.
/install.ps1	PowerShell installer. The embedded Director URL is substituted from the request host.
/install.sh	POSIX shell installer. Line endings are normalized to LF before delivery.

User-Agent routing on the /dl/ path serves install.ps1 to PowerShell clients, install.sh to curl or wget, and redirects any other client to the VirtualMetric website.

warning

The legacy plain-HTTP routes /status and /ws respond with the Deprecation: true header and an X-VirtualMetric-Upgrade header instructing agents to upgrade to the HTTPS channel. These routes are removed in the next major version.

Download limits

Both the CA and agent-binary download endpoints are semaphore-protected. When the concurrency cap is reached, the Director responds with HTTP 503 and a Retry-After header; the installer scripts respect this backoff automatically.

Endpoint	Max Concurrent	Retry-After
/dl/cert.pem	50	10 s
/dl/agent/{os}/{arch}	5	30 s

Supported operating systems for agent binary download: aix, darwin, freebsd, linux, netbsd, openbsd, solaris, windows. Supported architectures: amd64, arm64, 386, ppc64, ppc64le. An optional /dl/agent/{os}/{arch}/sign path serves the detached signature.

Messaging TLS

The VMMQ messaging client automatically adapts its connection scheme to match the Director listener: http:// becomes ws://, and https:// becomes wss://. When the Director is configured with TLS, the client enforces TLS 1.2 or higher and attaches client certificates when mutual TLS is enabled on the platform.

When the client encounters the NATS error certificate signed by unknown authority and no CA certificate is available locally, it automatically bootstraps the CA by:

1. Waiting a random interval between 0 and 30 seconds to avoid thundering herd on large fleets.
2. Downloading /dl/cert.pem from the Director with InsecureSkipVerify enabled for the duration of the bootstrap handshake.
3. Validating the returned PEM block and persisting it locally as ca.pem.
4. Rebuilding NATS options with the new CA and retrying the connection. Backoff for subsequent retries is 5s * errCount, capped at 30 seconds.

Hostname verification is intentionally skipped on the self-signed path because the Director certificate omits SANs by design; chain verification against the bootstrapped CA still runs on every connection.

Examples

Self-signed (default) -- the Director generates its own certificate and agents bootstrap the CA through the discovery endpoints...	proxy_tls: mode: self-signed status: true discovery_enabled: true
Custom PEM with explicit CA -- operator-supplied certificate, key, and CA delivered through node properties...	proxy_tls: mode: custom status: true cert_name: /etc/vmetric/tls/director.pem key_name: /etc/vmetric/tls/director.key ca_name: /etc/vmetric/tls/root-ca.pem port: 8443 discovery_enabled: false
Custom with vault -- certificate and key fetched from a credential store at startup; the PFX password sourced from a secrets registry entry...	proxy_tls: mode: custom status: true cert_name: $secret{store=azure-prod,ref=tls/director-cert} key_name: $secret{store=azure-prod,ref=tls/director-key} pfx_password: $secret{id=3001} discovery_enabled: false
Custom PKCS#12 bundle -- single PFX file with the password sourced from the environment...	proxy_tls: mode: custom status: true pfx_name: /etc/vmetric/tls/director.pfx export VMETRIC_PFX_PASSWORD='…'
Offloaded -- TLS terminates at the upstream load balancer and the Director skips its own HTTPS listener...	proxy_tls: mode: offloaded status: false

Agent Pre-Processing

Directors can configure Agents to perform pipeline-based pre-processing of logs before transmission. This distributed processing model reduces Director workload, decreases network bandwidth consumption, and enables edge-based data transformation such as compliance masking.

info

For complete Agent documentation including deployment, management, pipeline assignment, and troubleshooting, see Devices: Agents.

Notifications

The Directors interface provides automatic notifications for all operations:

Success

Success messages auto-dismiss after 10 seconds. These include confirmations for Director creation (connected or pending), enabling, disabling, and deletion. Hover to pause the auto-close timer, or click X to dismiss manually.

Errors

Error notifications persist until manually dismissed. These include failures for enable, disable, delete operations, and configuration download errors. Review error details and take corrective action before dismissing.