Guides

How to choose a log analytics tool

Pick a log platform by who owns it, whether you index everything or only labels, and how the pricing model behaves as volume grows.

Every application, server and network device produces a stream of text describing what it just did, and at some point that stream gets too large to read by hand. A log analytics tool exists to make that stream searchable: collect it centrally, index enough of it to query quickly, and alert when a pattern shows up that someone should see. Every team running production software eventually needs one. The question is which shape of tool, because "index everything and search it" turns out to have very different costs depending on how it's built.

Full-text indexing versus label indexing

This is the architectural decision that separates most of the market, and it shows up directly in your bill.

Some platforms index the full content of every log line, so any word anywhere is searchable instantly. Elasticsearch, Splunk, OpenSearch and Graylog all work this way. It is the most flexible option for ad hoc investigation — you don't need to know in advance what you'll want to search for — but indexing everything is expensive at scale, in both storage and compute.

Grafana Loki takes the opposite approach: it indexes only a small set of metadata labels, the way Prometheus indexes metrics, and leaves the log body unindexed. That keeps ingestion and storage costs far lower, at the cost of slower full-text search when you don't know which labels to filter by. If your queries are mostly "show me logs from this service, this pod, this environment," label indexing is usually cheaper for the same volume; if you frequently need to search for an arbitrary string across everything, full-text indexing will feel faster.

A third pattern, used by Coralogix and Sumo Logic's tiering, analyzes data in motion — running alerts and pattern extraction as data streams in — before deciding what to index versus archive cheaply, aiming to get some of both worlds.

Open source, source-available, or fully closed

Licensing in this category is more contested than in most, because of one well-known event: when Elastic moved Elasticsearch off a permissive open-source license in 2021, Amazon forked it into OpenSearch, which now lives under the Linux Foundation as a genuinely open-source, Apache-2.0 project. Elasticsearch itself is source-available under the Elastic License/SSPL, not OSI open source, though an AGPL-3.0 option was added in 2024. Grafana Loki and Graylog's free "Open" edition are also self-hostable at no license cost, with Graylog's paid Enterprise and Security tiers layered on top by daily ingest volume. If your organization has a policy against source-available software, that alone can narrow the field to OpenSearch, Loki, Graylog Open, or a commercial SaaS product.

Self-hosting any of these is not actually free — it moves cost from a vendor invoice to the people who run and patch the cluster. Weigh that labor honestly against a managed option before assuming open source wins on cost.

How the pricing model behaves as you grow

Read past pricing.model on a tool's profile to how the number actually moves as your volume grows, because this category has several distinct shapes:

  • Per-GB ingested and retained (Grafana Loki via Grafana Cloud, Elasticsearch via Elastic Cloud) — cost tracks volume directly and predictably.
  • Credits or units decoupled from raw ingest (Sumo Logic) — ingest is unlimited, but running analytics against stored data draws down a prepaid pool, so cost tracks query activity more than storage.
  • Daily ingest volume tiers (Graylog Enterprise/Security) — licensed by GB/day or an annual consumption unit, typical of self-hosted-with-paid-upgrade products.
  • Quote-only, workload-based (Splunk) — no public rate card; cost is negotiated and depends on data volume and search workload.
  • Transparent per-GB, published on the pricing page (Better Stack) — unusual in this category and worth noting specifically if opaque quotes are a dealbreaker for your procurement process.

None of these is wrong, but they compound differently. A credits model can surprise you if query activity spikes even when ingest is flat; a per-GB model can surprise you if a noisy service starts logging verbosely. Ask each vendor to model your actual expected ingest and query pattern, not a generic sizing example.

A shortlist by situation

  • If you're already on Grafana and Prometheus, look at Grafana Loki — it shares dashboards and a query language with your metrics stack.
  • If you want a free, self-hosted core with a clear upgrade path to SIEM, look at Graylog, whose Open edition has no volume cap.
  • If you need an Elasticsearch-compatible stack without license-model risk, look at OpenSearch — fully Apache-2.0, governed by the Linux Foundation.
  • If your organization already runs Splunk for IT operations and wants the same data to serve SIEM, Splunk's Enterprise Security app extends the same indexed data rather than requiring a second platform.
  • If you're a smaller engineering team that finds enterprise observability suites overbuilt, Better Stack pairs log search with uptime and on-call under transparent, published pricing.
  • If you want unlimited ingest with cost decoupled from storage, Sumo Logic's credits model and Cloud SIEM sit on the same platform.
  • If your platform already runs the broader Elastic Stack, Elasticsearch lets Elastic Security ride on the same indices instead of a separate SIEM.

Questions to ask in a trial

  1. What does this cost at 2x and 5x our current log volume, modeled against our real growth trend, not a demo dataset?
  2. What happens to older data — does it become slower to query, get deleted, or move to cheaper storage automatically?
  3. How long does a representative full-text search actually take once the index holds a realistic volume of our own data?
  4. What is the actual, step-by-step process to onboard a new log source, and how much of it requires vendor support?
  5. If we needed to migrate off this platform in three years, how portable is our historical data and our alert/dashboard configuration?

Common mistakes

Choosing based on a demo with a small, curated dataset, then discovering query latency or cost behaves very differently at real volume. Ignoring retention cost until the first large invoice arrives — indexed retention is usually the most expensive line item, and it is easy to retain far more than anyone actually queries. Treating "open source" as "free" without budgeting the operational time to run and patch a self-hosted cluster. And centralizing logs without ever defining who owns alert tuning, so the platform slowly fills with noisy alerts nobody trusts.

For the two rivalries practitioners search most in this category, see Elasticsearch vs Splunk and Grafana Loki vs Graylog. See every tool in this category.

Related tools

Terms used in this guide

Latest on this topic