Every server, firewall and laptop you manage writes logs, and nobody reads them until something breaks. The ELK stack is the open-source toolkit teams reach for to pull those logs into one place they can search. Here's what each piece does, what running it yourself costs a small team, and when OpenSearch or Grafana Loki is the better fit.
What Is the ELK Stack?
The ELK stack is three open-source tools that work as one log platform. Elasticsearch stores and searches the data. Logstash collects logs from many sources, cleans them up and sends them on. Kibana is the web interface where you search, filter and build dashboards. Together they turn scattered log files into one searchable record.
The name stuck, but the stack grew. Elastic added Beats, small agents that ship data from each machine: Filebeat for log files, Metricbeat for metrics and Winlogbeat for Windows event logs. With Beats in the picture, Elastic now calls the whole thing the Elastic Stack. Search results still say ELK, and so does everyone on a help desk.
How the Pieces Fit Together
Think of it as a pipeline with four stops. A Beat on each server reads the logs and ships them. Logstash, if you use it, parses them, so a raw firewall line becomes fields like source IP, port and action. Elasticsearch indexes those fields so a search across millions of lines comes back in seconds. Kibana sits at the end, where a tech types a query or opens a dashboard.
Logstash is optional for simple setups. Beats can send straight to Elasticsearch, and teams often add Logstash later, once they need to reshape messy sources like syslog from network gear. That's the trade: Logstash is flexible, and it's also one more service to run and patch.
This three-minute explainer from May 2026 walks through the same flow, one component at a time.
What Small IT Teams Use It For
The first use is plain troubleshooting. When a service fails across 30 servers, searching one Kibana screen beats SSH-ing into each box and grepping. You filter by host, time window and error level, and the pattern shows up in minutes.
The second is security. Failed logons, new admin accounts, blocked connections: once Windows event logs and firewall logs sit in the same index, you can see them side by side. Elastic ships a security app on top of the stack, so a team can grow from log search toward SIEM-style detection without starting over.
The third is keeping records. Plenty of audits ask how long logs are retained and whether anyone can change them. A central store with a written retention policy answers that better than logs rotating off individual machines.
Is it still the default choice? This December 2025 r/devops thread asks exactly that. Replies say ELK is still actively developed and widely used, especially at scale, while teams on managed Kubernetes often lean on their cloud provider's log tools and newer setups move toward OpenTelemetry.
Free to Run, Complicated to License
You can download and self-host it at no cost. What changed over the years is whether it counts as open source, and the history matters if you care about that.
Elasticsearch and Kibana started under the Apache 2.0 license. On 14 January 2021, Elastic announced that from version 7.11 both would move to a dual license: the Server Side Public License (SSPL) and the Elastic License. Neither is an open-source license by the usual definition. The move was aimed at cloud providers selling Elasticsearch as a service.
AWS answered by forking the last Apache-licensed version into OpenSearch in 2021. On 16 September 2024, the Linux Foundation launched the OpenSearch Software Foundation, and AWS handed the project over. OpenSearch stays under Apache 2.0.
Then Elastic moved again. On 29 August 2024, founder Shay Banon wrote that Elastic would add AGPL as a third license option, so "Elasticsearch and Kibana can be called Open Source again." The older licenses stay available alongside it.
For a small team self-hosting for its own use, any of these licenses works. The difference shows up if you plan to offer the stack as a service to others, or if your policy only allows OSI-approved licenses.
What Running It Yourself Costs
The software is free. The hardware and the hours are not, and that's where small teams get surprised.
Elasticsearch indexes the fields of every log line so searches come back fast. That speed costs disk and memory. Log volume grows with every server you add, and the index grows with it, so storage fills faster than the raw log files would suggest.
Then there's upkeep. Someone has to size the Java heap, plan shards, set retention so old indexes get deleted, turn on authentication and TLS, and run version upgrades without losing data. None of this is exotic. All of it lands on whoever set the cluster up, usually a tech with other tickets.
A retention policy is the single cheapest fix. Decide how long each log type needs to live, write it down, and let Elasticsearch's index lifecycle management delete the rest on schedule.
ELK vs OpenSearch vs Grafana Loki
Three open options come up again and again for self-hosted logs. They split on license and on how much they index.
| ELK (Elastic Stack) | OpenSearch | Grafana Loki | |
|---|---|---|---|
| License | AGPL, SSPL or Elastic License (your choice) | Apache 2.0 | AGPLv3 (since April 2021) |
| What it indexes | Every field of every log line | Every field (Elasticsearch-compatible) | Labels only; log text is compressed and stored |
| Storage cost | Higher | Higher | Lower, uses object storage |
| Search speed | Fast full-text search | Fast full-text search | Fast by label, slower when scanning text |
| Governance | Elastic, a single company | Linux Foundation | Grafana Labs, a single company |
Loki is the one that changes the math. Grafana relicensed it to AGPLv3 in April 2021, and it indexes only labels like host and app, not the text inside each line. That makes it cheaper to run and slower when you search for a word nobody labeled.
If Loki sounds like your fit, our Grafana Loki review covers it in depth.
In this r/devops thread, a team handling 50 to 100 GB of logs a day asks whether to move from Elasticsearch to Loki. The top answer, from someone who has run both, would pick Loki for a new build today. Another explains the trade: Elasticsearch pre-indexes everything so searches are quick, while Loki's object storage is cheaper but slower to query.
Which One Fits
Pick ELK if your team searches free text often, wants Kibana's dashboards, and has someone who can own the cluster. Guides and community answers are easy to find, and Elastic's security app gives you a path toward detection later.
Pick OpenSearch if you want the same search model under a license run by a foundation rather than a vendor. Its interface, OpenSearch Dashboards, is a fork of Kibana, so the workflow feels familiar. It's also the base of AWS's managed service, which matters if you ever want someone else to run it.
Pick Loki if cost and simplicity come first and your team already lives in Grafana. Label your logs well, and most searches never need full-text indexing.
If the real goal is security events rather than general logs, look at a purpose-built open-source SIEM instead of building one. Our Wazuh comparison walks through that route.
Start With One Log Source
The ELK stack is a solid, well-documented way to put every log in one searchable place, and it's free to run yourself. The bill comes in disk, memory and upkeep, so decide what you'll keep and for how long before you turn it on.
Start small: ship Windows event logs from a handful of servers, set a 30-day retention policy, and see which searches your team runs. For the lighter alternative, read our Grafana Loki review.
Content Marketing Lead
Ohayo! I run content, SEO, social, and community at Flamingo. Before IT, I worked as a correspondent for Ukraine's Public Broadcasting Company and have a Master's in journalism.
