“ELK” historically means Elasticsearch + Logstash + Kibana, but a modern production Elastic architecture is broader. A useful mental model is:

Sources
  ↓
Elastic Agent / OpenTelemetry / Beats / apps
  ↓
optional Logstash or Elasticsearch ingest pipelines
  ↓
Elasticsearch
  ↓
Kibana / APIs / alerts / investigations

What each component does

• Elasticsearch stores JSON documents, builds searchable structures, distributes data across shards, and executes search/aggregation workloads.
• Kibana is the exploration and operations UI: Discover, dashboards, alerting, data management, Fleet and more.
• Logstash is a programmable event-processing engine using input → filter → output pipelines.
• Elastic Agent is the modern unified agent for collecting logs, metrics and other telemetry; Fleet can centrally manage policies and integrations.
• Beats such as Filebeat and Metricbeat remain useful in existing or focused architectures, but should not be assumed to be the only ingestion path.
• OpenTelemetry can feed Elastic through supported OTel collection paths and is increasingly important for vendor-neutral telemetry pipelines.

Engineering questions before choosing a component

Where is telemetry generated?
How much transformation is required?
Can the source emit structured JSON?
Do we need buffering or fan-out?
Who manages collector configuration?
What schema should events follow?
How long must data be retained?
What queries and alerts will operators run?

A common mistake is adding Logstash simply because “ELK includes L.” If Elastic Agent or an ingest pipeline can perform the required processing, another stateful processing tier may add unnecessary complexity. Conversely, Logstash is valuable when you need richer parsing, routing, buffering, enrichment, or multiple outputs.