Directors: Management

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

Access

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

The Directors page 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/Orchestrated/Serverless), Version, Log stream, 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 "Director configuration changed after last update. Please deploy the current configuration." - 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 new 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:

• Manage director - Navigate to Director detail view (users with read-only access see See director details instead)

Status Management:

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

Configuration:

• Download config - Download vmetric.vmf configuration file (Self-managed, Orchestrated and Serverless Directors only)

Deletion:

• Delete director - Remove Director from platform

Detail View

Clicking a Director from the overview table opens the detailed management interface with nine tabbed panels: Director overview, Connection settings, Access management, TLS configuration, Update management, Health, Console logs, Live data, and Activity logs.

Director Overview Tab

View and edit Director configuration:

General settings panel:

• Director name - Editable unique identifier
• Platform Type - Read-only; cannot be changed after creation
• Installation Type - Read-only; cannot be changed after creation
• Director Status - Enabled or Disabled
• Mode - Managed, Self-managed, Orchestrated, or Serverless
• Container type - Docker, Kubernetes, Azure Container Instances, or Azure Container Apps. Shown for Serverless Directors only
• Processing mode - In-memory, Persistent, or Crash-resistant
• Linked cluster - The cluster the Director belongs to, if any

Managed environment settings (Serverless Directors on Azure Container Apps), or Environment options (Serverless Directors on Kubernetes): the published ports and, behind Show advanced settings, the Autoscaling policy — Backlog per replica, CPU target (%), Memory target (%) and Maximum replicas. The managed environment is shown on Azure Container Apps only. On Kubernetes, Backlog per replica is not offered, because it does not drive the HorizontalPodAutoscaler, and a Service account setting is added. Each row shows the value in force: a number you set, or the Director's own default where you never set one. In edit mode the same fields are editable. On Azure Container Apps an autoscaling change reaches the running Director within seconds without a redeploy. On Kubernetes the published ports, the autoscaling thresholds and the service account are rendered into the manifest, so a change to any of them flags the deployment as out of date and takes effect when the reinstalled manifest is applied. Blank hands a field back to the Director's default; 0 is a real setting that stops a target counting toward the decision or, on Maximum replicas, removes the ceiling. See Autoscaling Policy under Deployment for what each field does and the behaviors worth knowing before changing one.

Behind Show advanced settings, each of the four inputs carries a helper line that says what it weighs and names the default it falls back to:

• Backlog per replica — "Queued records one replica should hold; 0 ignores backlog. Default is 10000."
• CPU target (%) — "CPU utilization per replica; 0 ignores CPU. Default is 75."
• Memory target (%) — "Memory utilization per replica; 0 ignores memory. Default is 0."
• Maximum replicas — "Ceiling on the replicas this policy asks for; 0 means no ceiling. It can only reduce — the platform's own maximum still applies, and the smaller wins. Default is 2."

Anything that is not a whole number is refused with "Enter a whole number, or clear the field to use the default shown", and the two percentage fields refuse a value above 100 with "Enter a number no higher than 100".

note

Maximum replicas shows 2 on a Director that has never had a ceiling set, and saving the panel — for any change — stores that 2, capping a replica set the deployment manifest otherwise allows to reach 10. To keep such a Director uncapped, enter 0 before saving.

Director information panel: Created and Last updated timestamps.

Edit Functionality: Click Manage general settings to activate the editing form, then save or cancel your changes.

Connection Settings Tab

Shows the current Connection status (Connected/Not connected) and Connection history, alongside installation and reinstallation resources (Re-install Director, Verify connection):

Installation Scripts:

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

For Serverless Directors this tab shows the deployment manifest for the Director's container type instead, with no PowerShell/Bash choice. See Deployment for the manifest formats.

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

note

For Directors linked to a cluster, access management is controlled at the cluster level and this tab is read-only.

Update Management Tab

Configure the Director's update policy — see Updates for the available settings.

Updating a Serverless Director on Azure Container Apps:

How a Serverless Director picks up a new version depends on its container type. Docker and Azure Container Instances update by re-creating the container, and Kubernetes updates on restart (the manifest sets imagePullPolicy: Always). Azure Container Apps is different: restarting the Director does not update it. Container Apps restarts the container inside the replica it already has, and that replica keeps the image it booted with. A new version arrives only when the replica is replaced, which is what a revision restart does.

So Restart to apply update only updates an Azure Container Apps Director deployed with enableSelfUpdate — on update, that Director restarts its own revision. For any other Azure Container Apps Director, restart the revision yourself:

az containerapp revision restart -g <resource-group> -n <app> --revision <revision>

See Self-Update on Azure Container Apps under Deployment for the template parameters and the permissions a deployment with enableSelfUpdate needs. A Director deployed before self-update existed needs one redeploy with it turned on before the console can update it.

Health Tab

Shows how this Director has been running over a time window. The tab appears only to users who can read statistics.

Window controls: pick a preset range (from Last 15 minutes to Last 12 months) or a custom date and time range. With Live on, the window ends at now and refreshes every 10 seconds, pausing while you hover over a chart. Live is available for preset ranges of 24 hours or less, and is off with a custom range.

Summary card: the events per second over the end of the window (labelled Events (last 60s) or longer, as the window widens), Error rate, Drop rate, CPU, Memory, and Log warnings - Errors — the warnings and errors the Director wrote to its application log.

Charts:

• Throughput — events or bytes per second the Director ingested
• Processing latency — the average time spent processing each event, or the ingest delay
• Errors & Drops — a table of errors, drops and other issues per stage (Ingest, Routing, Delivery, Application logs) beside a chart of them over time. Click a stage to chart only that stage
• Resource — the Director's own CPU and memory usage

Routes table: the device-to-target flows through this Director, with Events out, Bytes out, Errors, Dropped, Throttled, Queue depth and Delivery lag for each.

Live Data Tab

Capture pipeline messages flowing through the Director at configurable processing stages — see Live Data.

Console Logs Tab

Stream real-time system debug messages from the Director — see Console Logs.

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). An update the platform ran, which the director reported, shows System and has no profile to open.
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
DirectorCreated	A new Director was created
DirectorUpdated	Director configuration was modified
DirectorDeleted	A Director was removed

The Director's own lifecycle records — DirectorLifecycleRequested, DirectorLifecycleCompleted, DirectorCrashRecovered and DirectorStartedUnexpectedly — also appear here, with System as the user. See Audit for what each one means.

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.

Export Template

1. Navigate to Director detail view
2. Click Actions menu
3. Select Export template

The Director opens as a Bicep template, to deploy again or to change first. See Export Template.

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 HTTPS listener, its certificate authorities, the proxy_tls configuration block, and the discovery endpoints agents use to bootstrap trust are documented under TLS and Certificates.

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.