NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
Go modules · #84 by repository stars
Last release 9 months ago
17 Dec 2025
Release timing varies
gaps range from 1 weeks to 4 months
Most releases are documented
notes for 13 of 16 stable releases
Nothing withdrawn
no release was ever pulled
8 years old
3716 releases · first in 2018
Nothing published for this version
We realized after the release last week that piping data into promtail was not working on Linux or Windows, this should fix this issue for both platfo
We realized after the release last week that piping data into promtail was not working on Linux or Windows, this should fix this issue for both platforms:
Also thanks to @dottedmag for providing this fix for Fluent Bit!
One column per quarter.
Over 130 PR's merged for this release, from 40 different contributors!! We continue to be humbled and thankful for the growing community of contributo
Over 130 PR's merged for this release, from 40 different contributors!! We continue to be humbled and thankful for the growing community of contributors and users of Loki. Thank you all so much.
Really, this is important
Before we get into new features, version 1.4.0 brings with it the first (that we are aware of) upgrade dependency.
We have created a dedicated page for upgrading Loki in the operations section of the docs
The docker image tag naming was changed, the starting in 1.4.0 docker images no longer have the v prefix: grafana/loki:1.4.0
Also you should be aware we are now pruning old master-xxxxx docker images from docker hub, currently anything older than 90 days is removed. We will never remove released versions of Loki
The API now returns a plethora of stats into the work Loki performed to execute your query, eventually this will be displayed in some form in Grafana to help users better understand how "expensive" their queries are. Our goal here initially was to better instrument the recent work done in v1.3.0 on query parallelization and to better understand the performance of each part of Loki. In the future we are looking at additional ideas to provide feedback to users to tailor their queries for better performance.
This is a long overdue addition to Promtail which can help setup and debug pipelines, with these new features you can do this to feed a single log line into Promtail:
echo -n 'level=debug msg="test log (200)"' | cmd/promtail/promtail -config.file=cmd/promtail/promtail-local-config.yaml --dry-run -log.level=debug 2>&1 | sed 's/^.*stage/stage/g'
-log.level=debug 2>&1 | sed 's/^.*stage/stage/g are added to enable debug output, direct the output to stdout, and a sed filter to remove some noise from the log lines.
The stdin functionality also works without --dry-run allowing you to feed any logs into Promtail via stdin and send them to Loki
These two extensions to LogQL now let you execute queries like this:
* `sum(rate({app="foo"}[5m])) * 2`
* `sum(rate({app="foo"}[5m]))/1e6`
Now you can get per-stream line counts as a metric from promtail, useful for seeing which applications log the most
- metrics:
line_count_total:
config:
action: inc
match_all: true
description: A running counter of all lines with their corresponding
labels
type: Counter
These two configs let you set the max time a chunk can stay in memory in Loki, this is useful to keep memory usage down as well as limit potential loss of data if ingesters crash. Combine this with the query_ingesters_within config and you can have your queriers skip asking the ingesters for data which you know won't still be in memory (older than max_chunk_age).
NOTE Do not set the max_chunk_age too small, the default of 1h is probably a good point for most people. Loki does not perform well when you flush many small chunks (such as when your logs have too much cardinality), setting this lower than 1h risks flushing too many small chunks.
This isn't a feature but it's an important fix, this is the second time our canaries have tried to DDOS our Loki clusters so you should update to prevent them from trying to attack you. Aggressive little things these canaries...
These two PR's change how 429 HTTP Response codes are handled (Rate Limiting), previously these responses were dropped, now they will be retried for these clients
* Promtail
* Docker logging driver
* Fluent Bit
* Fluentd
This pushes the failure to send logs to two places. First is the retry limits. The defaults in promtail (and thus also the Docker logging driver and Fluent Bit, which share the same underlying code) will retry 429s (and 500s) on an exponential backoff for up to about 8.5 mins on the default configurations. (This can be changed; see the config docs for more info.)
The second place would be the log file itself. At some point, most log files roll based on size or time. Promtail makes an attempt to read a rolled log file but will only try once. If you are very sensitive to lost logs, give yourself really big log files with size-based rolling rules and increase those retry timeouts. This should protect you from Loki server outages or network issues.
There are many other important fixes and improvements to Loki, way too many to call out in individual detail, so take a look!
informational only feedback for codecovNothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
1486 Deprecated -distributor.limiter-reload-period flag / distributor's limiter_reload_period config option.
With 1.3.0 we are excited to announce several improvements focusing on performance!
First and most significant is the Query Frontend:
The query frontend allows for sharding queries by time and dispatching them in parallel to multiple queriers, giving true horizontal scaling ability for queries. Take a look at the jsonnet changes to see how we are deploying this in our production setup. Keep an eye out for a blog post with more information on how the frontend works and more information on this exciting new feature.
In our quest to improve query performance, we discovered that gzip, while good for compression ratio, is not the best for speed. So we introduced the ability to select from several different compression algorithms:
We are currently testing out LZ4 and snappy, LZ4 seemed like a good fit however we found that it didn't always compress the same data to the same output which was causing some troubles for another important improvement:
Extending on the work done by @bboreham on Cortex, @pstibrany added a few new flags and code to synchronize chunks between ingesters, which reduces the number of chunks persisted to object stores and therefore also reduces the number of chunks loaded on queries and the amount of de-duplication work which needs to be done.
As mentioned above, LZ4 was in some cases compressing the same data with a different result which was interfering with this change, we are still investigating the cause of this issue (It may be in how we implemented something, or may be in the compression code itself). For now we have switched to snappy which has seen a reduction in data written to the object store from almost 3x the source data (with a replication factor of 3) to about 1.5x, saving a lot of duplicated log storage!
Another valuable change related to chunks:
With this change you can set a chunk_target_size and Loki will attempt to fill a chunk to approx that size before flushing (previously a chunk size was a hard coded 10 blocks where the default block size is 262144 bytes). Larger chunks are beneficial for a few reasons, mainly on reducing API calls to your object store when performing queries, but also in reducing overhead in a few places, especially when processing very high volume log streams.
Another big improvement is the introduction of accurate rate limiting when running microservices:
Previously the rate limit was applied at each distributor, however with traffic split over many distributors the limit would need to be adjusted accordingly. This meant that scaling up distributors required changing the limit. Now this information is communicated between distributors such that the limit should be applied accurately regardless of the number of distributors.
And last but not least on the notable changes list is a new feature for Promtail:
With this change Promtail can receive syslogs via TCP! Thanks to @bastjan for all the hard work on this submission!
-distributor.limiter-reload-period flag / distributor's limiter_reload_period config option.Once again we can't thank our community and contributors enough for the significant work that everyone is adding to Loki, the entire list of changes is long!!
fluentd_thread label when flush_thread_count > 1One week has passed since the last Loki release, and it's time for a new one!
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
One week has passed since the last Loki release, and it's time for a new one!
One week has passed since the last Loki release, and it's time for a new one!
We have continued our work making our API Prometheus-compatible. The key changes centered around API compatibility are:
/loki/api/v1/label to loki/api/v1/labelsMeanwhile, @pstibrany has done great work ensuring that Loki handles hash collisions properly:
:heart: All PR's are important to us, thanks everyone for continuing to help support and improve Loki! :heart:
Some might call this a breaking change, we are instead calling it a bug fix as our goal was to be prometheus compatible and we were not :smiley:
It's been a busy 2 weeks since the 1.0.0 release and quite a few important PR's have been merged to Loki.
The most significant:
Some might call this a breaking change, we are instead calling it a bug fix as our goal was to be prometheus compatible and we were not :smiley:
But please be aware if you are using the /loki/api/v1/label or /loki/api/v1/label/<name>/values the JSON result will be different in 1.1.0
Old result:
{
"values": [
"label1",
"label2",
"labeln"
]
}
New result:
{
"status": "success",
"data": [
"label1",
"label2",
"labeln"
]
}
ALSO IMPORTANT
Binaries will now be zipped instead of gzipped as many people voiced their opinion that zip is likely to be installed on more systems by default.
If you had existing automation to download and install binaries this will have to be updated to use zip instead of gzip
Broken version info in startup log message:
1095 pstibrany: Makefile changes to allow easy builds with or without vendoring. Also fixes version bug for both cases.
The hashing algorithm used to calculate the hash for a stream was creating hash collisions in some instances. Please Note this is just one part of the fix and is only in Promtail, the second part for Loki can be tracked in PR1247 which didn't quite make the cut for 1.1.0 and will be in 1.2.0:
1254 pstibrany: pkg/promtail/client: Handle fingerprint hash collisions
Thank you @putrasattvika for finding and fixing an important bug where logs were some logs were missed in a query shortly after a flush!
1299 putrasattvika: storage: fix missing logs with batched chunk iterator
Thank you @danieldabate for helping to again improve our API to be more Prometheus compatible:
1355 danieldabate: HTTP API: Support duration and float formats for step parameter
LogQL will support duration formats that are not typically handled by Go like [1d] or [1w]
1357 cyriltovena: Supports same duration format in LogQL as Prometheus
:heart: All PR's are important to us, thanks everyone for continuing to help support and improve Loki! :heart:
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
:tada: Nearly a year since Loki was announced at KubeCon in Seattle 2018 we are very excited to announce the 1.0.0 release of Loki! :tada:
:tada: Nearly a year since Loki was announced at KubeCon in Seattle 2018 we are very excited to announce the 1.0.0 release of Loki! :tada:
A lot has happened since the announcement, the project just recently passed 1000 commits by 138 contributors over 700+ PR's accumulating over 7700 GitHub stars!
Internally at Grafana Labs we have been using Loki to monitor all of our infrastructure and ingest around 1.5TB/10 billion log lines a day. Since the v0.2.0 release we have found Loki to be reliable and stable in our environments.
We are comfortable with the state of the project in our production environments and think it's time to promote Loki to a non-beta release to communicate to everyone that they should feel comfortable using Loki in their production environments too.
With the 1.0.0 release our intent is to try to follow Semver rules regarding stability with some aspects of Loki, focusing mainly on the operating experience of Loki as an application. That is to say we are not planning any major changes to the HTTP API, and anything breaking would likely be accompanied by a major release with backwards compatibility support.
We are currently NOT planning on maintaining Go API stability with this release, if you are importing Loki as a library you should be prepared for any kind of change, including breaking, even in minor or bugfix releases.
Loki is still a young and active project and there might be some breaking config changes in non-major releases, rest assured this will be clearly communicated and backwards or overlapping compatibility will be provided if possible.
There were not as many changes in this release as the last, mainly we wanted to make sure Loki was mostly stable before 1.0.0. The most notable change is the inclusion of the V11 schema in PR's 1201 and 1280. The V11 schema adds some more data to the index to improve label queries over large amounts of time and series. Currently we have not updated the Helm or Ksonnet to use the new schema, this will come soon with more details on how it works.
The full list of changes:
match stageNothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
> IMPORTANT: The new /api/v1/* endpoints contain breaking changes on the query paths (push path is unchanged) Eventually the /api/prom/* endpoints wil…
A huge thanks to the 36 contributors who submitted 148 PR's since 0.3.0!
With PR 654 @cyriltovena added a really exciting new capability to Loki, a Prometheus compatible API with support for running metric style queries against your logs! Take a look at how to write metric queries for logs
PLEASE NOTE: To use metric style queries in the current Grafana release 6.4.x you will need to add Loki as a Prometheus datasource in addition to having it as a Log datasource and you will have to select the correct source for querying logs vs metrics, coming soon Grafana will support both logs and metric queries directly to the Loki datasource!
PR 1022 (and a few others) @joe-elliott added a new set of HTTP endpoints in conjunction with the work @cyriltovena to create a Prometheus compatible API as well as improve how labels/timestamps are handled
IMPORTANT: The new
/api/v1/*endpoints contain breaking changes on the query paths (push path is unchanged) Eventually the/api/prom/*endpoints will be removed
PR 847 owes a big thanks to @cosmo0920 for contributing his Fluent Bit go plugin, now loki has Fluent Bit plugin support!!
PR 982 was a couple weeks of painstaking work by @rfratto for a much needed improvement to Loki's docs! Check them out!
PR 980 by @sh0rez improved how flags and config file's are loaded to honor a more traditional order of precedence:
PLEASE NOTE: This is potentially a breaking change if you were passing command line arguments that also existed in a config file in which case the order they are given priority now has changed!
PR 1062 and 1089 have moved Loki from Dep to Go Modules and to Go 1.13
/loki/api/v1/push to use the v1 json formatLoki is now using a Bot to help keep issues and PR's pruned based on age/relevancy. Please don't hesitate to comment on an issue or PR that you think was closed by the stale-bot which you think should remain open!!
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Loki 877 pracucci: loki: Improve Tailer loop
809, 730 NOTE: Systemd journal support is currently limited to amd64 images, arm support should come in the future when the transition to building the arm image and binaries is done natively via an arm container <!-- -->
857 POSSIBLY BREAKING: If you relied on a custom pod label to overwrite one of the labels configured by the other sections of the scrape config:
job,namespace,instance,container_nameand/or__path__, this will no longer happen, the custom pod labels are now loaded first and will be overwritten by any of these listed labels.
There were over 100 PR's merged since 0.1.0 was released, here's a highlight:
There were over 100 PR's merged since 0.1.0 was released, here's a highlight:
There were many fixes, here are a few of the most important:
Your coding agent can read these notes before it upgrades. Set up the MCP server →