Enterprise Core Operations

Konduo Enterprise Core overlays license control, HA, advanced audit, external authentication, the MCP gateway, anomaly analysis, relationship analysis, Analysis Workspaces, and compliance checks on top of Community Core. Shared resource and plugin contracts stay in CE; Enterprise-only behavior is connected through overlay and contribution points.

Metric name prefixes

Use Existing Metric Name Prefix and New Metric Name Prefix in the resource's Metrics settings. Leave the existing prefix empty and enter prefix_ as the new prefix to prepend it to every mapped name. Set existing pg_ and new prefix_ to query prefix_up instead of pg_up; unmatched names stay unchanged. An empty new prefix removes the existing prefix; both empty keep original names. Dashboards, alerts, inspection, and diagnostic evidence share these settings. Keep resource label filters; other exporter name or unit differences still need mapping corrections. Removal that produces an invalid metric name is rejected.

Main Responsibilities

1. Gate Enterprise availability through license status. A valid Enterprise license enables the complete edition; quotas and HA claims are enforced separately and there are no per-feature license entitlements.
2. Protect HA write paths through PostgreSQL-backed leader election and membership.
3. Expose MCP catalog, resource, and tool endpoints as read-oriented operator interfaces.
4. Connect anomaly rules, correlation analysis, relationship graphs, and log evidence to resource workflows.
5. Compose related-resource metric panels in Analysis Workspaces for time exploration, presentation, and RCA evidence review.
6. Surface external auth providers, audit logs, API server logs, and compliance checks in Enterprise settings.

Kubernetes installation

Use the common application chart with EE backend/frontend image repositories and digests. Each Deployment Pod contains frontend and backend; start with one Pod, or use the EE HA profile for two or more Pods on separate nodes. Database HA is independent: both editions accept a bundled PostgreSQL StatefulSet with retained PVC, a separately installed CloudNativePG operator's HA Cluster, or an external single/HA database. Application replicas do not make a single database HA.

The integrated installer accepts explicit kubeconfig/context and existing Secret references. Operator mode installs only a separate database CR release, waits for its primary Service and CA, then installs the application. Keep JWT and encryption keys stable across Pods and upgrades; keep production license trust inside the approved image. Import offline images into every Kubernetes node's runtime or use a reachable private registry.

EE HA requires a stable cluster name, unique Pod identities/direct peer addresses, trusted peer CIDRs, sufficient license limits, and session affinity at ingress. Loss of membership ownership withdraws readiness. A terminal whose Pod fails requires reconnection; commands are never replayed automatically. A leader write with an unknown outcome must be checked before resubmission. Preserve database PVCs, Secrets, and installation identity when upgrading or reinstalling.

Deployment examples and network policy are in enterprise/deploy/kubernetes/; the offline bundle includes them under kubernetes/enterprise/. See the HA leadership, write-routing, and session runbooks for recovery procedures.

Runtime access and license trust

Runtime security is independent of GO_ENV. Use explicit stable JWT, configuration-encryption, database, and transport-policy inputs in every deployment. Same-origin direct, NodePort, LoadBalancer, and Ingress browser paths do not require publicURL or a trusted-browser-origin entry. publicURL is only an optional canonical address for generated links. Trust forwarded scheme metadata only from the actual immediate edge proxy CIDRs.

Enterprise license issuer keyrings are always signed and verified by the root embedded into the backend at build time. Runtime JSON or root-key environment overrides are rejected. A valid signed trial remains supported, but trial bootstrap installs only when no license exists and never replaces an expired license. HA forwarding peer CIDRs are a separate trust boundary from browser edge proxy CIDRs.

The complete Enterprise contract and internal-staging transition checklist are maintained at enterprise/docs/enterprise-runtime-access-policy.md. In a prepared Enterprise tree, also read the Community baseline at docs/runtime-access-policy.md.

Operations Flow

• Check license and HA status before relying on Enterprise-only capabilities.
• Keep a local administrator account when registering external auth providers, and validate login gates separately from RBAC mapping.
• Restrict MCP through Konduo user API key scopes, and confirm resource/tool descriptors remain read-oriented.
• Link metric sources, log sources, and relation evidence so anomaly analysis has enough context.
• In Analysis Workspaces, confirm that panels and RCA evidence expose only currently readable resources, and distinguish fixed-window behavior from live-window refresh.
• Some event panels show a check and a short label such as “No errors” when a supported query succeeds with no event series in its requested scope. Timelines keep the selected time axis, a faint dashed guide and the caption “No events observed in this range”; they can be expanded even when empty. The guide is not a measured zero. Query information explains the query mode and range; an instant value does not cover the whole selected range or prove resource health. Actual zero samples remain charts, and missing metrics and query failures keep their unknown/error state.
• For releases, verify CE base version, EE patch suffix, manual image, and license bootstrap artifacts together.

Unified Resource Alert Rules

Resource Alerts shows one list with Built-in and Custom labels beside rule names. Search, a status filter, Rule/Severity header sorting and pagination operate on the same inventory. Clicking a sorted header reverses its direction. System access is monitored automatically and is omitted from this inventory, including search and counts. Its incidents, history and notification delivery settings remain available. Core rules, including metric collection rules, are read-only. Managed rules allow condition tuning; custom rules allow full editing, toggling and deletion. Configure delivery workflows/routes and silences separately from rule definitions.

Resource Metric Details And Custom Threshold Alerts

Use the information button on a resource metric panel to open Metric details and settings. It has four tabs:

• Metric information describes the panel, metric, and display unit.
• Chart Filter controls which returned series are displayed for that panel.
• Alerts creates a resource-specific custom threshold rule when the panel is eligible.
• Query details shows the query blueprint, mapping-pack resolution, and resolved query evidence.

Create A Threshold Rule From A Chart

Open Alerts to review the rules already registered for the chart's logical metrics, including plugin-managed and custom rules that are disabled. The tab shows a related-rule count after a successful lookup. A failed lookup is shown as an error, not as an empty rule list.

Review each rule's condition, severity, enabled state, metric source, and query scope before adding another rule. A shared logical metric does not guarantee the same aggregation or series filter. Enabled configuration does not prove that evaluation or notification delivery is currently healthy. Resource-read permission allows this review; creation still requires resource-management permission.

Choose Add new rule to open the custom-rule form in that tab. The editor is part of Metric details and settings; it does not open another modal or add a separate chart action. The unified Alert Rules list, showing Custom labels, on the Resource Alert Page remains the place to review, edit, enable, disable, or delete the saved rules.

Opening the tab does not open a draft. A rule is created only after you enter a threshold and save it. Konduo does not infer a threshold from displayed samples or from the dashboard's selected time range. After saving, the related rules are refreshed. Back to rules returns to the list and asks before discarding an edited draft. Existing rule settings remain available through their rule page links, including on charts that do not support creating a new rule.

The initial chart-to-alert path accepts only a semantically safe, single logical-metric time-series preset: it must have one top-level query blueprint, or exactly one blueprint in queries. The draft carries that blueprint's logical metric key, operation, aggregation, query window, grouping, and parameters. The rule belongs to the selected resource and queries its linked metric-source instance. For a resource that provides its own metrics, the resource itself is the source. These IDs can differ; the target resource still determines the managed query scope.

The Alerts tab explains why creation is unavailable when the panel has no resource context or query blueprint, uses multiple metrics, contains dynamic variables or placeholders, has a query-stage filter, has temporary dashboard job or instance filters, uses a custom or unsupported instance selector, reduces values in the display (such as stat, gauge, bar, or pie panels), or declares a display transform such as top-N. A resource scope defined in the resource configuration remains eligible because alert evaluation rebuilds that managed selector independently.

A display-stage Chart Filter can seed the new rule only when it is an exact post-query series include or exclude filter. It then limits the alert's returned series after the metric query. Saving a Chart Filter never changes an existing alert rule, collected metrics, or the underlying metric query.

Set The Evaluation Correctly

The dashboard range is a viewing range for chart history. It does not define the alert evaluation window, the required duration, or the threshold.

When the chart blueprint specifies a Query Window, the draft preserves it as read-only. Otherwise, Window (seconds) sets the evaluation data window. For (seconds) is how long the condition must remain true before the rule fires. Enter the threshold as the underlying numeric sample value, before the chart applies display scaling. A panel's unit or axis-unit metadata controls presentation and is not a conversion guarantee for the alert value. Do not enter a value converted for a formatted chart label; for example, use the underlying byte value when the chart displays a scaled byte unit.

There is no editable no-data policy in this custom-rule form. When a successful query returns no sample for a series, Konduo does not create a new alert for that series. When a previously pending or firing series disappears, its state becomes inactive, resolving a firing alert. Query or plugin errors remain telemetry-unavailable and do not resolve the current alert state.

Custom rules use the same resource role contract as the Resource Alert Page. Core Admin or a Resource Operator can manage the resource-scoped rule; this does not grant global connector, template, or silence administration. Creating a rule does not create a delivery route. Configure or review its receivers, routes, and delivery behavior through the existing resource alert delivery settings after saving the rule.

This path creates custom threshold rules. Enterprise anomaly and correlation rules continue to use their existing editors.

Initial Administrator Provisioning

Konduo does not create a known default administrator password during runtime bootstrap. After schema migration and reference-data seeding, a new database without an active administrator reports setup_required from /readyz and admin-bootstrap-status. An operator must then create the initial administrator with the one-time command.

Docker Compose

Connect to the server running Docker Compose and open a Bash terminal in the directory containing the compose.yml and .env used for installation. Run these commands on the server, not in the browser or a shell inside the container.

The backend and database must be running. If your installation uses different file names or paths, replace --env-file and -f in every command below with the options used during installation.

docker compose --env-file .env -f compose.yml exec -T backend \
  /app/konduo-backend admin-bootstrap-status

If the state is setup_required, create the initial administrator below. Password input is hidden and passed through standard input.

read -rsp 'Initial administrator password: ' INITIAL_ADMIN_PASSWORD
echo
printf '%s\n' "$INITIAL_ADMIN_PASSWORD" |
  docker compose --env-file .env -f compose.yml exec -T backend \
    /app/konduo-backend admin-bootstrap --username admin --password-stdin
unset INITIAL_ADMIN_PASSWORD

• This example creates the username admin. Change --username to use another name.
• The password must meet the current authentication policy. INITIAL_ADMIN_PASSWORD is a temporary shell variable used by this command; adding it to .env does not create an account.
• Run the status command again after creation and confirm that it reports complete.
• If the state is already complete, use the existing administrator account. Running bootstrap again does not change its password.

Kubernetes

Create a one-shot Job that uses the same scratch image, database/TLS settings, and encryption key as the backend. Run the binary directly: no shell or staging container is needed. Mount the Secret at /run/konduo-bootstrap with defaultMode: 0440 and run the Pod as UID/GID and fsGroup 10001 so the Kubernetes password -> ..data/password projection remains readable only by the workload group. Set activeDeadlineSeconds to at least 600, and run:

admin-bootstrap --username admin --password-file /run/konduo-bootstrap/password

Do not wait for backend /readyz: a new installation remains setup_required until this Job succeeds. The command waits up to five minutes for concurrent automatic schema migration and seed completion, then fails on a deadline or a ledger integrity error. Job retries are safe. Once bootstrap is complete, another attempt succeeds without changing the existing password. Confirm the complete state, then delete the initial-password Secret and Job.

Login and Recovery Boundaries

• The first login must change the password immediately.
• The password must satisfy the current local authentication policy.
• Running bootstrap again in the complete state does not change the existing account or password.
• If no active administrator remains after bootstrap completed, the state becomes recovery_required. Do not use bootstrap to create a replacement; follow the approved password-reset or verified-backup recovery procedure.
• A successful password reset revokes existing login sessions and refresh tokens and requires another password change at the next login.

read -rsp 'Temporary password: ' TEMPORARY_PASSWORD
echo
printf '%s\n' "$TEMPORARY_PASSWORD" | \
  docker compose --env-file .env -f compose.yml exec -T backend \
    /app/konduo-backend password-reset --user admin --password-stdin
unset TEMPORARY_PASSWORD