Which open-source log management option fits your situation
If your team must keep logs inside its own infrastructure and needs to pick a log store, the broad fit is this: Grafana Loki suits teams that want cost-lean storage in object storage and can accept label-only indexing, with an authenticating reverse proxy placed in front of it. OpenSearch suits teams that need full-text indexing and an Apache-2.0 license, with the Security plugin supplying role-based access, audit logs and TLS. Graylog suits teams that want an operator-friendly web product with event-based alerts, but its Graylog Open license is SSPL-1.0, which is not OSI-approved, and it depends on MongoDB for configuration and metadata.
Loki's label-only index keeps the index small, but searching log contents means scanning chunks, so teams with heavy free-text investigation should test query speed on their own data. Loki also has no built-in authentication, so the reverse proxy becomes part of your security boundary and needs its own review. OpenSearch's inverted index handles free-text search well, but it brings heavier cluster sizing and shard management. Graylog's index rotation and retention are simple to operate, yet you will run three components (Graylog servers, MongoDB and a Data Node or self-managed OpenSearch), each needing its own upkeep.
The right answer depends on three things: how much you need to search log contents, how long you must retain logs, and how many people will run the stack day to day. A small team that mostly filters by service and host will weigh the stack differently from a security group that runs free-text hunts across months of data. Confirm the exact license terms, supported versions and retention controls with each vendor before you commit, because those details change between releases.
Which log platform to shortlist for each scenario
This table maps six common team situations to the log platform most worth shortlisting, with the researched fact that drives each choice. Read each row against your query patterns, search needs, license rules and existing storage or search investments. The main takeaway is that index model and license terms usually decide the shortlist before feature lists do.
| Scenario | Best fit | Why |
|---|---|---|
| Small team, modest daily volume, mostly label-based queries | Grafana Loki | Loki indexes only labels for each stream and stores compressed chunks in object storage, and its monolithic mode is documented for up to about 20 GB of logs per day. Confirm the query patterns fit label filters before committing. |
| Ad hoc full-text search across message bodies | OpenSearch | OpenSearch builds an inverted index for full-text search across shards that are each a full Lucene index. Expect more storage and heap planning than a label-only store requires. |
| Packaged UI with alerting and stream routing, and the team can run MongoDB | Graylog | Graylog Open provides streams, processing pipelines, dashboards and event-definition alerts, but it needs MongoDB for metadata plus a Data Node or OpenSearch backend. Plan for both components in the operating effort. |
| Strict license rules that exclude non-OSI licenses | OpenSearch or Loki, depending on license policy | Graylog Open is licensed under SSPL-1.0, which is not OSI-approved. OpenSearch is Apache-2.0, while Loki is AGPL-3.0, so confirm with legal whether AGPL is acceptable. |
| Existing S3-compatible object store | Grafana Loki | Loki stores compressed chunks and its index in object storage such as S3, so an existing store can hold log data. Confirm the store meets Loki's production guidance, since the docs say MinIO and filesystem backends are not typically recommended for production. |
| Already running OpenSearch for other workloads | OpenSearch, or Graylog with an existing cluster | Shared OpenSearch skills and security configuration lower the learning curve. Graylog 7.0 to 7.2 supports OpenSearch only up to 3.7.x, so check version alignment before reusing a cluster. |
What Grafana Loki, OpenSearch and Graylog each are
All three collect logs from many hosts, store them for search and alerting, and can run in your own infrastructure. They differ in what they index, which license governs them, and how many separate components you operate. The cards below set out each platform's model so you can judge the operating effort before comparing the rest of the page.
Grafana Loki
Loki is licensed under AGPL-3.0 and indexes only the labels attached to each log stream, not the log contents. It stores compressed chunks and its index in object storage such as S3, so storage cost tracks the object store you choose. Check the deployment mode first: the Loki documentation says simple scalable mode will be removed in Loki 4.0, so plan for monolithic or microservices layouts. Loki also has no built-in authentication, so an authenticating reverse proxy must sit in front of it.
OpenSearch
OpenSearch is licensed under Apache-2.0 and builds an inverted index for full-text search, with each shard a full Lucene index. It is a fork of Elasticsearch 7.10, and OpenSearch Dashboards derives from Kibana 7.10.2, so teams with existing Elasticsearch 7.10 tooling should test their clients and queries. Its Security plugin covers SAML, OpenID Connect, LDAP and role-based access control with field-level security. Expect to size and tune shards and indices, since indexing cost and heap use grow with ingest volume.
Graylog Open
Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved open source license, so legal review should happen before adoption. It ingests logs over syslog, GELF and Beats, routes them through streams and processing pipelines, and sends event alerts. A deployment needs Graylog server nodes, MongoDB for configuration, and a Graylog Data Node or self-managed OpenSearch for storage. Confirm the compatibility matrix for your chosen version, since OpenSearch 1.x use is deprecated from Graylog 7.0.
How the three log platforms compare on capability
This table sets Grafana Loki, OpenSearch and Graylog Open side by side on licensing, indexing, alerting, access control, tenancy, storage and packaging. Read each row as a question to confirm during evaluation, since a blank supplied fact means the team should check the vendor documentation before deciding. The main takeaway is that OpenSearch and Graylog ship more access control and alerting out of the box, while Loki needs an authenticating proxy in front of it.
| Capability | Grafana Loki | OpenSearch | Graylog Open |
|---|---|---|---|
| License | AGPL-3.0, moved from Apache-2.0 announced April 20, 2021 | Apache-2.0 for all project software | Server Side Public License v1, not OSI-approved |
| Paid edition | Grafana Enterprise Logs is a separate commercial product | No paid edition described in the OpenSearch FAQ | Graylog Enterprise and Graylog Security, licensed per processed data |
| Indexing model | Indexes only labels per log stream, not log contents | Inverted index for full-text search, split into Lucene-backed shards | Index sets rotate by message count, size or time |
| Search approach | Label-based selection of log streams, to confirm for query language and filters | Full-text search over inverted indexes | Search and dashboards over indexed messages |
| Alerting | To confirm with Loki alerting and ruler documentation | To confirm with OpenSearch alerting plugin documentation | Event definitions for real-time and historical monitoring, notifications to PagerDuty, Slack and email |
| Authentication and access control | No built-in authentication; an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium is required | Security plugin with SAML, OpenID Connect, LDAP, Kerberos and JWT backends, plus RBAC | User authentication configured in Graylog; confirm supported identity providers in its authentication docs |
| Multi-tenancy | Enabled with auth_enabled and tenant identified by X-Scope-OrgID header | Field and document-level security, field masking and user impersonation within one cluster | Confirm tenant isolation model with Graylog documentation |
| Storage backend | Compressed chunks and index in object storage, with S3, GCS and Azure Blob recommended for production | Local shards on cluster nodes, sized by the operator | MongoDB for metadata, Graylog Data Node or self-managed OpenSearch for log storage |
| Deployment modes or packaging | Monolithic, simple scalable (being removed in Loki 4.0) and microservices | Docker, Helm, Kubernetes Operator, tarball, RPM, Debian, Ansible and Windows | Debian or RPM packages, Docker Compose, and a multi-node guide with three Graylog and MongoDB nodes |
| Required supporting components | Object storage and an authenticating proxy; Grafana Alloy or Fluent Bit as shipper | Dashboards component and a sized cluster; log shipper of your choice | MongoDB replica set, OpenSearch or Data Node, and a load balancer for multi-node |
How indexing choices change storage and search cost
Indexing design decides where your storage and compute money goes. Loki indexes only labels for each log stream, not log contents, so its index stays small and grows mainly with the number of distinct label combinations. The message text is stored as compressed chunks in object storage such as S3. That keeps the index cheap, but a query that filters on message content has to scan the matching chunks for the selected streams, so broad content searches cost more time and read capacity. Before you commit, check how your team will query: if most searches start from a service, host or namespace label, Loki's model fits well. If analysts routinely hunt for arbitrary strings across all sources, plan for heavier scans or a different backend.
OpenSearch builds an inverted index for full-text search, and each index is split into shards that are each a full Lucene index. That structure makes free-text queries fast across large volumes, but the index itself consumes disk, and the cluster needs memory and heap headroom for shard metadata and caches. Shard count is a planning decision: too many small shards waste overhead, while oversized shards slow recovery and rebalancing. Ask the vendor or your own test cluster to confirm shard sizing, replica count and heap settings against your expected query mix before you size hardware. Graylog Open can use OpenSearch as its storage backend, so the same shard and memory trade-offs apply there.
Graylog stores logs in index sets and rotates them by message count, size or time, deleting the oldest indices under its retention setting. Storage then follows a simple shape: daily ingest, retention days, replication and the indexing overhead of the chosen backend all push the disk footprint up, while shorter retention or lower replication pulls it down. Label cardinality matters on the Loki side, since each new unique label combination adds streams to the index. The Graylog sizing guidance in its system architecture documentation advises planning log storage as daily ingest times retention days times 120 percent, and recommends giving the message journal 3 to 5 times daily ingest on SSDs. Use that rule as a starting estimate, then validate it with a measured sample of your own traffic.
What each license and paid edition actually includes
Grafana Loki is licensed under the GNU Affero General Public License version 3 (AGPL-3.0). Grafana Labs announced on April 20, 2021 that Loki and its other core projects would move from Apache License 2.0 to AGPLv3, so releases before that change and releases after it carry different terms. The AGPL requires that users who run a modified version and offer it to others over a network make the modified source available under the same license, so teams that patch Loki or embed it in a service should have their legal team review the obligations before deployment.
- License change: the move from Apache-2.0 to AGPL-3.0 was announced on April 20, 2021, which matters if you pin an older release for compliance reasons.
- Network clause: the AGPL reaches modified network services, so internal-only use and modified use behind a service need different review.
- Paid editions: the supplied facts do not describe a paid Loki edition, so confirm with Grafana Labs whether any enterprise build, support tier or licensed feature set exists.
- Enterprise log product: Grafana Labs publishes separate Enterprise Logs documentation, so confirm whether it is the relevant commercial path and what it covers.
- Support: confirm with Grafana Labs what support options, if any, are sold for self-hosted Loki.
Before you commit, ask Grafana Labs in writing which paid options exist for self-hosted Loki, what each includes, and whether they change the AGPL obligations for your use.
All software in the OpenSearch project is released under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe any paid edition. The project is a fork of open source Elasticsearch 7.10, and OpenSearch Dashboards derives from Kibana 7.10.2. Governance sits with the OpenSearch Software Foundation, a Linux Foundation project whose board includes members such as AWS, IBM, SAP and Uber, but the foundation states that it is not involved in technical oversight of the project.
- Permissive license: Apache-2.0 covers the project software as supplied, so there is no separate commercial license to buy for the core engine.
- Foundation role: the foundation handles governance and membership, while technical direction is set within the project itself, so review the project's maintainer and release process when assessing long-term risk.
- No described paid edition: the FAQ does not describe a paid tier, so any commercial support, hosting or add-on terms must come from the vendor or service provider you choose.
- Security features: the Security plugin ships in the project documentation, so confirm which features your environment needs and that they are available in the version you deploy.
- Support windows: OpenSearch versions stay under maintenance until a newer major version enters maintenance or one year passes, whichever is longer, so check the release page for the exact end dates of your version.
Check that your chosen support provider names the OpenSearch version and maintenance window in its written terms, since the open license alone does not promise support.
Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0). Starting with Graylog 4.0 in 2020, Graylog Open moved from GPL v3 to SSPL-1.0, which is not an OSI-approved open source license. Graylog's pricing page lists Graylog Open as free with no volume limits and community support. The paid editions are priced on processed data, with no per-user or per-device fees, and each has a minimum of 10 GB per day or 100 Graylog Compute Units.
- Graylog Enterprise: starts at 15,000 US dollars per year, per the Graylog pricing page, and adds a data lake with archive restore, data tiering, a correlation engine and 24/7 support.
- Graylog Security: starts at 18,000 US dollars per year, per the Graylog pricing page, and adds SIEM features such as risk scoring, anomaly detection, investigations, compliance packs and prebuilt threat detection content.
- Minimum volume: both paid tiers carry a minimum of 10 GB per day or 100 Graylog Compute Units, so a small environment should check whether the minimum applies before budgeting.
- Licensing basis: pricing is tied to processed data, so ingest growth drives the recurring fee, and quotes should state how that volume is measured.
- Open core limits: Graylog Open provides ingest, search, dashboards and event alerts, but tiering, archive restore and SIEM content are reserved for the paid editions.
Ask Graylog for a written quote that states the processed-data measure, the minimum that applies to your ingest, and which features each tier includes, and have counsel review SSPL-1.0 against your distribution and hosting plans.
What running each log stack asks of your operators
Loki is the lightest stack to start but not the simplest to run at scale. Pick the deployment mode first: the monolithic mode is a single binary that Loki documents for up to about 20 GB of logs per day, and the simple scalable mode, which splits read, write and backend targets, is being removed in Loki 4.0, so a new build should plan for microservices or a monolithic start with a clear growth path. Your operators must provision object storage (Amazon S3, Google Cloud Storage or Azure Blob Storage are the recommended production stores), and they must set retention explicitly. The compactor enforces retention, but retention is disabled by default, so logs accumulate indefinitely until retention_enabled is set. Loki also has no built-in authentication layer, so plan an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it and confirm how X-Scope-OrgID tenant headers are set and trusted. The Loki retention documentation is the document to walk through before go-live.
OpenSearch asks for the most cluster-level judgment. Operators own node roles, heap sizing, shard counts and index lifecycle, because each shard is a full Lucene index and oversized or undersized shards show up as search and recovery problems later. Plan shard counts per index with your ingest volume in mind, and confirm the index lifecycle and rollover settings your team will use. Security is a configuration task, not a default: the Security plugin provides role-based access control, document and field-level security, field masking, audit logs and TLS for node and client traffic, and the authentication backend (SAML, OpenID Connect, LDAP or Kerberos, among others) must be set and tested. Upgrades follow a maintenance window model. Each minor version receives bug and security fixes but no new features until the next major version enters maintenance or one year passes, whichever is longer, so your team needs a regular cadence to move off older lines before they lose support.
Graylog is the most prescriptive of the three, which helps teams that want a defined layout. For medium to large deployments the multi-node guide recommends three Graylog nodes and three MongoDB nodes running as a replica set, three Data Nodes on their own cluster, and a load balancer in front of the Graylog nodes, with is_leader set to false on followers. Operators therefore need working knowledge of MongoDB replica set administration alongside the search backend, and they must run the load balancer health checks and backups for MongoDB as part of normal operations. The compatibility matrix is a standing check: Graylog 7.0 to 7.2 pin specific MongoDB and OpenSearch ranges, and use of OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0, so any legacy search backend needs a migration plan. Confirm your storage sizing against the system architecture guidance before you commit to hardware.
How to choose and pilot open-source log management
This sequence turns the three-way choice between Loki, OpenSearch and Graylog into a written requirement set, a license decision and a measured pilot, so the platform you pick matches your ingest, search and alerting needs and your operating capacity.
Define daily ingest and retention in writing
The platform owner and the team that pays for storage agree on average and peak daily log volume per environment, the retention period for each log class, and the number of sources expected in the first year. Write these as a single sheet with one line per log class. The step is complete when the sheet has been signed off by both the operations lead and whoever owns the storage budget. Ingest and retention drive storage size in every candidate, so a vague number here makes every later comparison unreliable. Ask each vendor to size against your sheet, not against its own example.
Decide whether full-text search is required
The security or operations lead lists the query patterns that analysts actually run, such as searching message bodies for error strings, or filtering by labels like application, namespace and environment. Mark each as required or optional. Loki indexes only labels for each stream and not log contents, so body search is slower and more limited there, while OpenSearch builds an inverted index for full-text search and Graylog searches through its configured backend. The step closes when every required query has a named example and an owner. If label queries are enough for your teams, that is a legitimate outcome and it narrows the field.
Check the license against your policy
Legal or the compliance lead compares each candidate license with the organization's open-source policy. Grafana Loki is AGPLv3, OpenSearch is Apache License 2.0 with no paid edition described in its FAQ, and Graylog Open is licensed under the Server Side Public License version 1, which is not an OSI-approved open source license. Confirm whether your policy allows non-OSI licenses, whether AGPL obligations apply to any modifications you plan to make, and whether a paid tier would be needed for features you require. The step is complete when the policy decision is recorded for each candidate, with the reviewer's name and the date.
Confirm alerting and notification needs
The operations team lists the alert types it needs, such as log-based thresholds, scheduled or historical searches, correlation across sources, and notifications to on-call tools. Then it checks each vendor's current documentation for those capabilities, because feature sets differ by product and by edition. Graylog alerts come from event definitions, with notifications the Graylog Open product page says can go to PagerDuty, Slack and email, while correlation engine features are described on its paid Enterprise tier. Confirm the same items for Loki and OpenSearch against their current docs and record the version you checked. The step closes with a table of required alert types and the documented source for each.
Pilot one shipper with a representative source
The platform engineer deploys one candidate in a non-production environment, connects one log shipper and one representative source, such as a Kubernetes namespace or a set of Linux hosts, and runs it for a fixed evaluation window agreed in advance. Loki accepts Grafana Alloy, Fluent Bit, Fluentd and the Docker logging driver, while OpenSearch and Graylog accept their own input and ingest paths. Measure stored bytes per day, index or chunk growth, compaction or rotation behavior, and the time to answer the queries recorded in step two. The pilot closes when these numbers are written next to the sizing sheet from step one, so the storage estimate reflects your data rather than a sample.
Review operator skills and supporting services
The engineering manager lists who will run the platform after go-live and which skills each candidate requires. Loki needs object storage and an authenticating reverse proxy in front of it, since its documentation says it has no built-in authentication layer. OpenSearch needs cluster sizing, shard management and an upgrade plan, with its version maintenance windows documented on its releases page. Graylog needs MongoDB for configuration and a Data Node or self-managed OpenSearch for storage, with multi-node guidance calling for three Graylog and MongoDB nodes plus three Data Nodes. Record the staffing gap, the support model you need, and which items you would ask a partner to implement, harden, document or retain on a retainer. The step closes with a decision memo that names the chosen platform and its owners.
What does open-source log management cost to run
What drives the cost of running Loki, OpenSearch or Graylog?
Storage volume, compute and the supporting components usually matter most, and each stack spreads them differently. Daily ingest multiplied by retention sets the storage footprint. Loki keeps compressed chunks and a label index in object storage, so object storage capacity and request costs are the main line items. OpenSearch keeps full inverted indexes on shards, which makes fast disks and memory the main drivers. Graylog needs Graylog server nodes, MongoDB for configuration and metadata, and either Graylog Data Node or self-managed OpenSearch for storage. The Graylog system architecture page advises sizing log storage as daily ingest times retention days times 120 percent, and giving the message journal 3 to 5 times daily ingest on SSDs. Staff time is often the largest cost. Ask any vendor or partner to price compute, storage, backups, support and engineer hours separately so you can see which driver moves.
Which log management costs are one-time and which recur?
Design, installation, integration with log shippers, dashboard and alert build-out, and migration of existing pipelines are usually one-time. Infrastructure, object storage, backups, license or support fees, upgrades, patching and on-call duty recur every month or year. Retention is the recurring lever: with Loki, retention is disabled by default, so logs accumulate until retention is configured, which means storage grows without anyone deciding it should. Set retention deliberately from the start and budget storage as a monthly line. Upgrades also recur. OpenSearch minor versions arrive about every eight weeks, and each version stays under maintenance for a limited window, so plan a regular upgrade cycle rather than a one-off project.
Can Loki, OpenSearch or Graylog run without a paid edition?
Yes, each has a free core that you can run yourself, but the boundaries differ. Grafana Loki is AGPLv3 licensed, and the AGPL obligations apply if you modify and offer it over a network, so have counsel confirm your position. Loki has no built-in authentication layer, so you will need an authenticating reverse proxy in front of it. OpenSearch is released under Apache License 2.0, and the OpenSearch FAQ does not describe any paid edition. Its Security plugin is part of the open project and supports SAML, OpenID Connect, LDAP and other backends. Graylog Open is free with no volume limits and community support, but it is licensed under SSPL-1.0, which is not an OSI-approved license. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, according to the Graylog pricing page. Confirm the features you need, such as data tiering, correlation or SIEM content, against the edition tiers before you commit.
How long do a log management pilot and migration take?
No fixed duration applies to all teams, and the honest answer depends on scope. The main drivers are the number of log sources and their formats, the retention and search requirements, how many alerts and dashboards must be rebuilt, the identity integration, and whether you run the stack in Kubernetes, on virtual machines or on bare metal. Loki and OpenSearch pilots often move quickly once the shipper is in place, while Graylog pilots depend on how many inputs, streams and processing pipelines you recreate. Migration from an existing platform adds a parallel-run period, which lengthens the timeline. Ask for a written schedule tied to the agreed scope and milestones rather than a generic estimate. DeployOpen plans and implements these engagements under fixed scope agreed in writing before work starts, and the timeline follows from that scope.
Can a small team run a self-hosted log stack alone?
A small team can run one of these stacks alone if it has someone who owns storage, upgrades and on-call response, but the staffing question matters more than the license. Loki's simple scalable mode is being deprecated and removed in Loki 4.0, so a team building new should plan around monolithic or microservices modes, and check which fits its volume. Monolithic mode is documented for up to about 20 GB of logs per day. OpenSearch clusters need shard planning, index lifecycle management and security configuration, and Graylog clusters add MongoDB operations on top. A common pattern is one engineer owning the platform part time, with the vendor or partner covering upgrades, hardening and support. Decide in advance who gets paged, who approves retention changes and who reviews access, because those responsibilities are where self-hosting fails in practice.
What should a written quote for log management include?
A useful quote states the scope in measurable terms, so two proposals can be compared line by line. Include the daily ingest in gigabytes, the retention period for each log class, the number of environments such as development, staging and production, the sources and shippers in scope, the identity integration, and the alerting and notification targets. Name the platform version and the deployment target, whether that is Kubernetes, virtual machines or bare metal. State the support level, the upgrade approach and the backup and restore expectations. Separate one-time work from recurring retainers, and list any third-party license or subscription costs as their own items. Ask what the quote excludes, such as ongoing tuning, new log sources or compliance evidence. DeployOpen provides fixed-scope quotes from written scope, and it does not publish a price list.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including centralized log platforms. Work starts from a written scope that sets out what the log platform will ingest, store, search and alert on before any build begins.
How we scope
- Written scope covers which log sources, daily volumes and retention periods the platform must handle.
- Scope records whether search and alerting need a built-in security analytics layer or basic event alerts.
- Scope states the storage backend, identity integration and network boundaries in your own cloud or data center.
How we build
- Build covers the chosen log store, its object storage or search backend, and the shipping agents that feed it.
- Authentication sits in front of the platform through a reverse proxy or the product's own security layer, as the chosen tool requires.
- Retention, index rotation and tenant settings are configured and tested against the retention rules agreed in scope.
How we hand over
- Handover documents architecture, configuration, access roles, alert definitions and the storage sizing used for the build.
- Backup and restore procedures for the log store and its metadata are documented and exercised before handover.
- Testing results, including alert delivery and search performance checks, are delivered as part of the written deliverables.
How we support
- Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer scope covers version upgrades and license-change reviews, with the work confirmed in writing for each engagement.
