Skip to content

Platform components

The managed platform combines Elastic services with Azure infrastructure and iVedha-operated platform services.

The exact components available in a deployment depend on the Marketplace plan, platform version, configuration, and Elastic license.

Core components

Component Purpose
Elasticsearch Stores, indexes, searches, and analyzes customer data
Kibana Provides the user interface for search, dashboards, observability, Fleet, and supported administration
Fleet Centrally manages Elastic Agents, policies, integrations, and agent health
Fleet Server Provides the communication layer between Fleet and enrolled Elastic Agents
Elastic Agent Collects telemetry, runs integrations, and provides managed collection capabilities
OpenTelemetry Collector Receives, processes, enriches, and routes OpenTelemetry logs, metrics, and traces
Logstash Provides additional event processing and routing when specialized ingestion pipelines are required
Elastic connectors Connect supported Elastic workflows to approved external content or services

Elasticsearch

Elasticsearch is the core data platform.

It provides:

  • document indexing;
  • full-text search;
  • aggregations and analytics;
  • data streams;
  • ingest pipelines;
  • vector and semantic search;
  • storage for observability logs, metrics, and traces.

Customer search applications normally communicate directly with the Elasticsearch API.

Observability data is typically collected through Elastic Agent and OpenTelemetry-based pipelines.

Kibana

Kibana provides the browser-based interface to the platform.

Customers use Kibana for:

  • Discover;
  • dashboards and visualizations;
  • search and analytics;
  • observability;
  • Fleet;
  • users and roles;
  • supported Elasticsearch administration.

Kibana operates against the Elasticsearch deployment. It does not contain a separate copy of customer data.

Fleet

Fleet provides centralized management for Elastic Agents.

Customers use Fleet to:

  • enroll agents;
  • create and assign agent policies;
  • configure integrations;
  • monitor agent health;
  • review agent status;
  • manage supported agent upgrades.

See Manage Elastic Agents with Fleet.

Fleet Server

Fleet Server coordinates communication between Fleet and enrolled Elastic Agents.

Agents use Fleet Server to:

  • receive policy updates;
  • report health and status;
  • receive centrally managed configuration.

Fleet Server does not store collected telemetry. Telemetry is ultimately written to Elasticsearch.

Use the Fleet hostname provided for the deployment.

Elastic Agent

Elastic Agent is the standard managed collection and gateway layer for observability workloads.

Depending on the integration and deployment architecture, Elastic Agent can:

  • collect host metrics;
  • collect logs;
  • collect Kubernetes telemetry;
  • run Elastic integrations;
  • participate in OpenTelemetry-based collection pipelines;
  • send collected data to Elasticsearch.

The platform uses an OpenTelemetry-first approach for new observability onboarding.

Applications should use OpenTelemetry instrumentation and semantic conventions where practical, while Elastic Agent and Fleet provide managed collection and policy capabilities.

OpenTelemetry Collector

OpenTelemetry Collector provides a vendor-neutral telemetry processing layer for logs, metrics, and traces.

Depending on the workload architecture, it can:

  • receive OTLP telemetry from applications and infrastructure;
  • collect telemetry through OpenTelemetry receivers;
  • enrich and transform telemetry;
  • batch and process telemetry;
  • route telemetry to Elasticsearch;
  • provide a centralized collection point for multiple telemetry sources.

A typical flow can be:

Applications / Infrastructure
            ↓
 OpenTelemetry Collector
            ↓
      Elasticsearch
            ↓
          Kibana

A standalone OpenTelemetry Collector is useful when workloads require centralized OTLP ingestion, additional processing, routing to multiple destinations, or separation between applications and the backend.

Where Elastic Agent provides the required collection capabilities, the architecture can use Elastic Agent instead of an additional standalone Collector.

OpenTelemetry

OpenTelemetry is not a separate platform service. It is the standard and ecosystem used for telemetry instrumentation, semantic conventions, protocols, and processing.

It provides the common telemetry model for:

  • logs;
  • metrics;
  • traces.

Telemetry can be collected through Elastic Agent, OpenTelemetry Collector, or a combination of both depending on the deployment architecture.

A typical observability architecture is:

Application / Host / Kubernetes
             ↓
 OpenTelemetry instrumentation
             ↓
 Elastic Agent or OTel Collector
             ↓
        Elasticsearch
             ↓
            Kibana

Available integrations and supported collection patterns continue to evolve with Elastic and platform versions.

Logstash

Logstash is available for workloads that require specialized event processing or routing.

Common reasons to use Logstash include:

  • existing Logstash pipelines;
  • protocol-specific ingestion;
  • complex event transformation;
  • enrichment;
  • routing to multiple destinations.

For new observability workloads, prefer OpenTelemetry-based collection unless there is a specific requirement for Logstash.

Use the deployment-provided Logstash endpoint when Logstash is enabled.

Elastic connectors

Elastic connectors support approved workflows that integrate Elasticsearch with external content sources or services.

Availability depends on:

  • Elastic version;
  • license;
  • Marketplace plan;
  • platform configuration.

Connector availability does not automatically mean that a specific external data source, credential, or synchronization workflow has been configured.

Azure Kubernetes Service

Azure Kubernetes Service provides the runtime for the managed platform.

iVedha operates the Kubernetes layer as part of the managed service.

Customers should not modify:

  • Kubernetes workloads;
  • node pools;
  • platform namespaces;
  • operators;
  • platform secrets;
  • managed storage configuration.

Platform-level changes should use supported iVedha workflows.

Azure Key Vault

Azure Key Vault stores protected platform material such as:

  • deployment secrets;
  • certificate-related material;
  • credentials required by managed platform services.

Customers should not retrieve or modify managed secret values directly.

The private key generated for customer TLS certificates remains inside the managed platform.

Azure Storage

Azure Storage can support platform storage, diagnostics, and snapshot-related workflows depending on the deployment configuration.

Backup and recovery operations should use the documented managed workflows rather than manipulating platform storage directly.

See Back up and restore.

Networking

Azure networking provides connectivity to the managed services.

Depending on deployment configuration, this can include:

  • public endpoints;
  • Azure Private Link;
  • Private Endpoints;
  • DNS integration;
  • load balancing and ingress.

The deployment provides the authoritative hostnames for enabled services, including where applicable:

  • Elasticsearch;
  • Kibana;
  • Fleet;
  • Logstash.

Do not construct service endpoints from Azure or Kubernetes resource names.

Managed identities

Azure managed identities allow platform components to authenticate to supported Azure services without embedding Azure credentials in application configuration.

Identity assignments and Azure RBAC used internally by the platform are managed as part of the supported deployment.

Platform monitoring

iVedha runs monitoring components that collect operational health information from the managed platform.

This allows iVedha to monitor:

  • platform availability;
  • Elasticsearch health;
  • infrastructure health;
  • storage and capacity;
  • managed service conditions.

Platform monitoring is separate from customer workload observability.

Customer application data remains in the customer's Elasticsearch deployment.

Component availability

Not every component is enabled in every deployment.

Availability can depend on:

  • Marketplace plan;
  • Elastic license;
  • platform version;
  • selected deployment options;
  • workload requirements.

Use the Your deployment is ready notification and supported iVedha workflows to determine which services are available for a specific deployment.

For architecture and data flows, see Architecture details.

For ownership boundaries, see Shared responsibility.