Upgrade Loki
Every attempt is made to keep Grafana Loki backwards compatible, such that upgrades should be low risk and low friction.
Unfortunately Loki is software and software is hard and sometimes we are forced to make decisions between ease of use and ease of maintenance.
If we have any expectation of difficulty upgrading, we will document it here.
As more versions are released it becomes more likely unexpected problems arise moving between multiple versions at once. If possible try to stay current and do sequential updates. If you want to skip versions, try it in a development environment before attempting to upgrade production.
Checking for config changes
Using docker you can check changes between 2 versions of Loki with a command like this:
export OLD_LOKI=2.9.4
export NEW_LOKI=3.0.0
export CONFIG_FILE=local-config.yaml
diff --color=always --side-by-side <(docker run --rm -t -v "${PWD}":/config grafana/loki:${OLD_LOKI} -config.file=/etc/loki/${CONFIG_FILE} -print-config-stderr 2>&1 | sed '/Starting Loki/q' | tr -d '\r') <(docker run --rm -t -v "${PWD}":/config grafana/loki:${NEW_LOKI} -config.file=/etc/loki/${CONFIG_FILE} -print-config-stderr 2>&1 | sed '/Starting Loki/q' | tr -d '\r') | less -RThe tr -d '\r' is likely not necessary for most people, seems like WSL2 was sneaking in some windows newline characters…
The output is incredibly verbose as it shows the entire internal config struct used to run Loki, you can play around with the diff command if you prefer to only show changes or a different style output.
Main / Unreleased
Distributor Max Receive Limits for uncompressed bytes
The next Loki release introduces a new configuration option (i.e. -distibutor.max-recv-msg-size) for the distributors to control the max receive size of uncompressed stream data. The new options’s default value is set to 100MB.
Supported clients should check the configuration options for max send message size if applicable.
Helm Chart Upgrades
Note
With the move to the Grafana-community/helm-charts repository, the chart numbering has changed. Major version updates signal breaking changes in the chart. For more information, refer to the README.
Migrating from the Loki Repository Helm Chart to the Community Helm Chart
If you are upgrading from the Helm chart previously hosted in the Loki repository (chart version 6.x) to the Grafana Community Helm chart (chart version 18.x), refer to the dedicated migration guide: Upgrade to the Community Helm chart.
Helm Chart 6.50.0 - Respect the global registry in the sidecar image
If you prefixed the sidecar container with a private registry (sidecar.image.repository), this is no longer necessary and is deprecated as the global registry is used starting with Helm chart 6.46.1. Therefore please use global.imageRegistry or alternatively, sidecar.image.registry for more fine-grained control.
Helm Chart 6.50.0 - Uniform naming for image digest also in the sidecar image
For most images used in the helm chart, a .digest is available to pin an image to a specific hash. The sidecar images diverges from this convention by introducing a .tag.
Starting with Helm chart 6.46.1, the .tag is deprecated and .digest should be used.
Helm Chart 6.46.0 - Default service account name change
Warning
Helm chart version 6.46.0 introduces a breaking change that affects users who rely on the default service account name to bind external identity, such as AWS EKS Pod Identity, IAM Roles for Service Accounts (IRSA), GCP Workload Identity, or Azure Workload Identity.
Starting with Helm chart 6.46.0 (#19590), when serviceAccount.create is true and serviceAccount.name is not set, the default service account name is now derived from the chart’s fullname template instead of the chart name. For example:
If an external identity, such as an AWS IAM role through EKS Pod Identity or IRSA, is bound to the previous service account name, your pods lose access to that identity after the upgrade. For object-storage backends, this typically results in an outage because Loki components can no longer read or write to the bucket.
Recommended action:
To preserve the previous behavior and avoid the rename, set the service account name explicitly in your values.yaml:
serviceAccount:
name: enterprise-logs # use "loki" for open source deploymentsSetting serviceAccount.name explicitly is forward-compatible and works on both pre- and post-6.46.0 chart versions, so it is also the recommended setting going forward if you want the service account name to be independent of the Helm release name.
If you have already upgraded and your pods have lost cloud-provider IAM access, you have two options:
- Set
serviceAccount.nameto the previous default (for example,enterprise-logs) and runhelm upgradeagain. The previously bound external identity will resume working. - Update the external identity binding (for example, the EKS Pod Identity association or the IRSA trust policy) to reference the new service account name.
Helm Chart 6.34.0 - Zone-aware Ingester Breaking Change
Warning
Helm chart version 6.34.0 introduces a breaking change that affects users with zone-aware ingester replication enabled.
If you are using zone-aware ingesters (ingester.zoneAwareReplication.enabled: true), upgrading to Helm chart 6.34.0 requires manual StatefulSet deletion before the upgrade. This is due to a fix for the serviceName field in zone-aware ingester StatefulSets, which is an immutable field in Kubernetes.
For detailed upgrade instructions, see: Helm Chart 6.x Upgrade Guide - Zone-aware Ingester Breaking Change
Key points:
- Only affects deployments with
ingester.zoneAwareReplication.enabled: true - Requires manual StatefulSet deletion with
--cascade=orphan - No data loss - PersistentVolumeClaims and data are preserved
- New StatefulSets will be created with correct service references
3.6.0
Loki 3.6.0
Upgraded AWS SDK to v2
Loki uses the official AWS SDK for configuring and communication with S3 object storage. Version 1 of the SDK reached its end of life on 31st, 2025, and therefore had to be replaced with Version 2. While the user-facing configuration in Loki did not change, internal functionality of the object store client did change, without affecting functionality of Loki.
Please refer to the full release notes of v2 https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2025-01-15 for further information and whether you may be impacted by any of the changes.
3.5.0
Loki 3.5.8
Removal of BusyBox Shell from Docker Images
Starting in Loki version 3.5.8, the busybox utility was removed from the official Loki Docker images. This means that shell utilities like /bin/sh are no longer available inside the container by default.
Impact
- You cannot
execinto the Loki container to use a shell as before. Commands likekubectl exec -it podname -- shordocker exec -it containername shwill fail because/bin/shdoes not exist in the image. - Common utilities provided by BusyBox (e.g.,
ls,cat,ps) are also not available inside the container.
Why was BusyBox removed?
Removing BusyBox addresses the following CVEs:
- CVE-2023-42364
- CVE-2023-42365
- CVE-2023-42363
- CVE-2023-42366
- CVE-2025-46394
- CVE-2024-58251
How do I troubleshoot or inspect a running Loki container now?
If you need to debug or inspect a Loki container:
- Use ephemeral containers: Kubernetes allows you to attach an ephemeral container with a shell to a running Pod for debugging (if your cluster supports it).
- Example:
kubectl debug -it <pod-name> --image=busybox --target=<container-name>
- Example:
- Copy files out/in instead of shelling in: Use
kubectl cpordocker cpto move logs or config files for inspection. - Include shell utilities in your own derived image: If your operational process requires a shell, you can build a custom Docker image based on Loki and add BusyBox or another shell to it (not recommended for production).
- Example Dockerfile snippet:
FROM grafana/loki:3.5.8 USER root RUN apk add --no-cache busybox USER 10001
- Example Dockerfile snippet:
3.4.0
Loki 3.4.0
New Object Storage Clients
Loki release 3.4.0 introduces new object storage clients based on the Thanos Object Storage Client Go module, this is an opt-in feature. In a future release, this will become the default way of configuring storage and the existing storage clients will be deprecated.
The new storage configuration deviates from the existing format. Refer to the Thanos storage configuration reference to view the complete list of supported storage providers and their configuration options.
The documentation now also includes a migration guide and configuration examples for using Thanos-based storage clients.
3.3.0
Loki 3.3.0
Experimental Bloom Filters
With Loki 3.3.0, the bloom block format changed and any previously created block is incompatible with the new format.
Before upgrading, we recommend deleting all the existing bloom blocks in the object store. We store bloom blocks and
metas inside the bloom path in the configured object store. To get rid of all the bloom blocks, delete all the objects
inside the bloom path in the object store.
3.2.0
Loki 3.2.0
HTTP API
The API endpoint for instant queries /api/v1/query now returns a HTTP status 400 (Bad Request) when the provided query
parameter contains a log selector query instead of returning inconsistent results. Please use the range query endpoint
/api/v1/query_range (Range type in Grafana Explore) instead.
Configuration
Loki changes the default value of -ruler.alertmanager-use-v2 from false to true. Alertmanager APIv1 was deprecated in Alertmanager 0.16.0 and is removed as of 0.27.0.
Experimental Bloom Filters
Note
Experimental features are subject to rapid change and/or removal, which can introduce breaking changes even between minor version. They also don’t follow the deprecation lifecycle of regular features.
The bloom compactor component, which builds bloom filter blocks for query acceleration, has been removed in favor of two new components: bloom planner and bloom builder. Please consult the Query Acceleration with Blooms docs for more information.
CLI arguments (and their YAML counterparts) of per-tenant settings that have been removed as part of this change:
-bloom-compactor.enable-compaction-bloom-compactor.shard-size-bloom-compactor.shard-size-bloom-compactor.shard-size
CLI arguments of per-tenant settings that have been moved to a different prefix as part of this change:
-bloom-compactor.max-page-sizechanged to-bloom-builder.max-page-size-bloom-compactor.max-block-sizechanged to-bloom-builder.max-block-size-bloom-compactor.ngram-lengthchanged to-bloom-builder.ngram-length-bloom-compactor.ngram-skipchanged to-bloom-builder.ngram-skip-bloom-compactor.false-positive-ratechanged to-bloom-builder.false-positive-rate-bloom-compactor.block-encodingchanged to-bloom-builder.block-encoding
Their YAML counterparts in the limits_config block are kept identical.
All other CLI arguments (and their YAML counterparts) prefixed with -bloom-compactor. have been removed.
3.0.0
Note
If you have questions about upgrading to Loki 3.0, please join us on the community Slack in the
#loki-3channel.Or leave a comment on this Github Issue.
Tip
If you have not yet migrated to TSDB, do so before you upgrade to Loki 3.0.
Loki 3.0 is a major version increase and comes with several breaking changes.
Here is the shortlist of things we think most people may encounter:
- Structured metadata is enabled by default and requires
tsdbandv13schema or Loki won’t start. Refer to Structured Metadata, Open Telemetry, Schemas and Indexes. - The
shared_storeconfig is removed. Refer to Removedshared_storeandshared_store_key_prefixfrom shipper configuration. - Loki now enforces a max line size of 256KB by default (you can disable this or increase this but this is how Grafana Labs runs Loki). Refer to Changes to default configure values.
- Loki now enforces a max label limit of 15 labels per series, down from 30. Extra labels inflate the size of the index and reduce performance, you should almost never need more than 15 labels. Refer to Changes to default configure values.
- Loki will automatically attempt to populate a
service_namelabel on ingestion. Refer toservice_namelabel. - There are many metric name changes. Refer to Distributor metric changes, Embedded cache metric changes, and Metrics namespace.
If you would like to see if your existing configuration will work with Loki 3.0:
- In an empty directory on your computer, copy you configuration into a file named
loki-config.yaml. - Run this command from that directory:
docker run --rm -t -v "${PWD}":/config grafana/loki:3.0.0 -config.file=/config/loki-config.yaml -verify-config=trueNote
If you introduce a new schema_config entry it may cause additional validation errors.
Tip
If you configure
path_prefixin thecommonconfig section this can help save a lot of configuration. Refer to the Common Config Docs.
The Helm chart has gone through some significant changes and has a separate upgrade guide: Upgrading to Helm 6.x.
Loki 3.0.0
Caution
Before upgrading your software from Loki 2.x to 3.0, you should follow the instructions to Migrate to TSDB.
Structured Metadata, Open Telemetry, Schemas and Indexes
A flagship feature of Loki 3.0 is native support for the Open Telemetry Protocol (OTLP). This is made possible by a new feature in Loki called Structured Metadata, a place for metadata which doesn’t belong in labels or log lines. OTel resources and attributes are often a great example of data which doesn’t belong in the index nor in the log line.
Structured Metadata is enabled by default in Loki 3.0, however, it requires your active schema be using both the tsdb index type AND the v13 storage schema. If you are not using both of these you have two options:
- Upgrade your index version and schema version before updating to 3.0, see schema config upgrade.
- Disable Structured Metadata (and therefore OTLP support) and upgrade to 3.0 and perform the schema migration after. This can be done by setting
allow_structured_metadata: falsein thelimits_configsection or set the command line argument-validation.allow-structured-metadata=false.
service_name label
Loki 3.0 will automatically assign a service_name label to all ingested logs by default. A service name is something required by Open Telemetry semantic conventions and is something Grafana Labs is building into our future user interface and query experiences.
Loki will attempt to create the service_name label by looking for the following labels in this order:
- service_name
- service
- app
- application
- name
- app_kubernetes_io_name
- container
- container_name
- component
- workload
- job
If no label is found matching the list, a value of unknown_service is applied.
You can change this list by providing a list of labels to discover_service_name in the
limits_config block.
Note
If you are already using a
service_label, Loki will not make a new assignment.
You can disable this by providing an empty value for discover_service_name.
Removed shared_store and shared_store_key_prefix from shipper configuration
The following CLI flags and the corresponding YAML settings to configure shared store for TSDB and BoltDB shippers are now removed:
-boltdb.shipper.shared-store-tsdb.shipper.shared-store
Going forward the object_store setting in the
period_config will be used to configure the store for the index.
This enforces chunks and index files to reside together in the same storage bucket for a given period.
We are removing the shared store setting in an effort to simplify storage configuration and reduce the possibility for misconfiguration.
Warning
With this change Loki no longer allows storing chunks and indexes for a given period in different storage buckets. This is a breaking change for setups that store chunks and indexes in different storage buckets by setting
-boltdb.shipper.shared-storeor-tsdb.shipper.shared-storeto a value different fromobject_storeinperiod_config.
- If you have not configured
-boltdb.shipper.shared-store,-tsdb.shipper.shared-storeor their corresponding YAML setting before, no changes are required as part of the upgrade. - If you have configured
-boltdb.shipper.shared-storeor its YAML setting:- If it matches the value of
object_storefor all the periods that useboltdb-shipperas index type, no additional changes are required besides removing the usage of the deleted configuration option. - If there is a mismatch, you lose access to the index for periods where
-boltdb.shipper.shared-storedoes not matchobject_store.- To make these indexes queryable, index tables need to moved or copied to the store configured in
object_store.
- To make these indexes queryable, index tables need to moved or copied to the store configured in
- If it matches the value of
- If you have configured
-tsdb.shipper.shared-storeor its YAML setting:- If it matches the value of
object_storefor all the periods that usetsdbas index type, no additional changes are required besides removing the usage of the deleted configuration option. - If there is a mismatch, you lose access to the index for periods where
-tsdb.shipper.shared-storedoes not matchobject_store.- To make these indexes queryable, index tables need to moved or copied to the store configured in
object_store.
- To make these indexes queryable, index tables need to moved or copied to the store configured in
- If it matches the value of
The following CLI flags and the corresponding YAML settings to configure a path prefix for TSDB and BoltDB shippers are now removed:
-boltdb.shipper.shared-store.key-prefix-tsdb.shipper.shared-store.key-prefix
Path prefix for storing the index can now be configured by setting path_prefix under index key in
period_config.
This enables users to change the path prefix by adding a new period config.
period_config:
index:
path_prefix: "index/"
period: 24hNote
path_prefixonly applies to TSDB and BoltDB indexes. This setting has no effect on legacy indexes.
path_prefix defaults to index/ which is same as the default value of the removed configurations.
- No changes are required if you have not configured
-boltdb.shipper.shared-store.key-prefix,-tsdb.shipper.shared-store.key-prefixor the corresponding YAML setting previously. - If you have configured
-boltdb.shipper.shared-store.key-prefixor its YAML setting to a value other thanindex/, ensure that all the existing period configs that useboltdb-shipperas the index havepath_prefixset to the value previously configured. - If you have configured
-tsdb.shipper.shared-store.key-prefixor its YAML setting to a value other thanindex/, ensure that all the existing period configs that usetsdbas the index have thepath_prefixset to the value previously configured.
Removed shared_store and shared_store_key_prefix from compactor configuration
The following CLI flags and the corresponding YAML settings to configure the shared store and path prefix for compactor are now removed:
-boltdb.shipper.compactor.shared-store-boltdb.shipper.compactor.shared-store.key-prefix
Going forward compactor will run compaction and retention on all the object stores configured in
period configs where the index type is either tsdb or boltdb-shipper.
delete_request_store should be explicitly configured
-compactor.delete-request-store or its YAML setting should be explicitly configured when retention is enabled, this is required for storing delete requests.
The path prefix under which the delete requests are stored is decided by -compactor.delete-request-store.key-prefix, it defaults to index/.
Configuration async_cache_write_back_concurrency and async_cache_write_back_buffer_size have been removed
These configurations were redundant with the Background configuration in the
cache-config.
async_cache_write_back_concurrency can be set with writeback_goroutines
async_cache_write_back_buffer_size can be set with writeback_buffer
additionally the Background configuration also lest you set writeback_size_limit which can be used to set a maximum amount of memory to use for writeback objects vs a count of objects.
Legacy ingester shutdown handler is removed
The already deprecated handler /ingester/flush_shutdown is removed in favor of /ingester/shutdown?flush=true.
Ingester configuration max_transfer_retries is removed
The setting max_transfer_retries (-ingester.max-transfer-retries) is removed in favor of the Write Ahead log (WAL).
It was used to allow transferring chunks to new ingesters when the old ingester was shutting down during a rolling restart.
Alternatives to this setting are:
- A. (Preferred) Enable the WAL and rely on the new ingester to replay the WAL.
- Optionally, you can enable
flush_on_shutdown(-ingester.flush-on-shutdown) to flush to long-term storage on shutdowns.
- Optionally, you can enable
- B. Manually flush during shutdowns via
the ingester
/shutdown?flush=trueendpoint.
Removed the default section of the runtime overrides config file
This was introduced in 2.9 and likely not widely used. This only affects you if you run Loki with a runtime config file AND you had populated the new default block added in 2.9.
The default block was removed and instead a top level config now exists in the standard Loki config called operational_config, you can set default values here for runtime configs.
Configuration use_boltdb_shipper_as_backup is removed
The setting use_boltdb_shipper_as_backup (-tsdb.shipper.use-boltdb-shipper-as-backup) was a remnant from the development of the TSDB storage.
It was used to allow writing to both TSDB and BoltDB when TSDB was still highly experimental.
Since TSDB is now stable and the recommended index type, the setting has become irrelevant and therefore was removed.
The previous default value false is applied.
Deprecated configuration options are removed
- Removed already deprecated
store.max-look-back-periodCLI flag and the corresponding YAML settings. Usequerier.max-query-lookbackconfig instead. - Removes already deprecated
-querier.engine.timeoutCLI flag and the corresponding YAML setting. - Also removes the
query_timeoutfrom the querier YAML section. Instead of configuringquery_timeoutunderquerier, you now configure it in Limits Config. s3.sse-encryptionis removed. AWS now defaults encryption of all buckets to SSE-S3. Usesse.typeto set SSE type.ruler.wal-cleaer.periodis removed. Useruler.wal-cleaner.periodinstead.experimental.ruler.enable-apiis removed. Useruler.enable-apiinstead.split_queries_by_intervalis removed fromquery_rangeYAML section. You can instead configure it in Limits Config.frontend.forward-headers-listCLI flag and its corresponding YAML setting are removed.frontend.cache-split-intervalCLI flag is removed. Results caching interval is now determined byquerier.split-queries-by-interval.querier.worker-parallelismCLI flag and its corresponding yaml setting are now removed as it does not offer additional value to already existingquerier.max-concurrent. We recommend configuringquerier.max-concurrentto limit the max concurrent requests processed by the queriers.ruler.evaluation-delay-durationCLI flag and the corresponding YAML setting are removed.validation.enforce-metric-nameCLI flag and the corresponding YAML setting are removed.boltdb.shipper.compactor.deletion-modeCLI flag and the corresponding YAML setting are removed. You can instead configure thecompactor.deletion-modeCLI flag ordeletion_modeYAML setting in Limits Config.- Compactor CLI flags that use the prefix
boltdb.shipper.compactor.are removed. You can instead use CLI flags with thecompactor.prefix.
Distributor metric changes
The loki_distributor_ingester_append_failures_total metric has been removed in favour of loki_distributor_ingester_append_timeouts_total.
This new metric will provide a more clear signal that there is an issue with ingesters, and this metric can be used for high-signal alerting.
Changes to default configuration values in 3.0
Automatic stream sharding is enabled by default
Automatic stream sharding helps keep the write load of high volume streams balanced across ingesters and helps to avoid hot-spotting. Check out the operations page for more information
More results caching is enabled by default
The TSDB index type has support for caching results for ‘stats’ and ‘volume’ queries which are now enabled by default.
’label’ and ‘series’ requests can be cached now too and this is enabled by default.
All of these are cached to the results_cache which is configured in the query_range config section. By default, an in memory cache is used.
Write dedupe cache is deprecated
Write dedupe cache is deprecated because it not required by the newer single store indexes ( TSDB and boltdb-shipper). If you using a legacy index type, consider migrating to TSDB (recommended).
Embedded cache metric changes
The following embedded cache metrics are removed. Instead use
loki_cache_fetched_keys,loki_cache_hits,loki_cache_request_duration_secondswhich instruments requests made to the configured cache (embeddedcache,memcachedorredis).querier_cache_added_totalquerier_cache_gets_totalquerier_cache_misses_total
The following embedded cache metrics are renamed:
querier_cache_added_new_totalis renamed toloki_embeddedcache_added_new_totalquerier_cache_evicted_totalis renamed toloki_embeddedcache_evicted_totalquerier_cache_entriesis renamed toloki_embeddedcache_entriesquerier_cache_memory_bytesis renamed toloki_embeddedcache_memory_bytes
Already deprecated metric
querier_cache_stale_gets_totalis now removed.
Metrics namespace
Some Loki metrics started with the prefix cortex_. In this release they will be changed so they start with loki_. To keep them at cortex_ change the metrics_namespace from the default loki to cortex. These metrics will be changed:
cortex_distributor_ingester_clientscortex_dns_failures_totalcortex_dns_lookups_totalcortex_dns_provider_resultscortex_frontend_query_range_duration_seconds_bucketcortex_frontend_query_range_duration_seconds_countcortex_frontend_query_range_duration_seconds_sumcortex_ingester_flush_queue_lengthcortex_kv_request_duration_seconds_bucketcortex_kv_request_duration_seconds_countcortex_kv_request_duration_seconds_sumcortex_member_consul_heartbeats_totalcortex_prometheus_last_evaluation_samplescortex_prometheus_notifications_alertmanagers_discoveredcortex_prometheus_notifications_dropped_totalcortex_prometheus_notifications_errors_totalcortex_prometheus_notifications_latency_secondscortex_prometheus_notifications_latency_seconds_countcortex_prometheus_notifications_latency_seconds_sumcortex_prometheus_notifications_queue_capacitycortex_prometheus_notifications_queue_lengthcortex_prometheus_notifications_sent_totalcortex_prometheus_rule_evaluation_duration_secondscortex_prometheus_rule_evaluation_duration_seconds_countcortex_prometheus_rule_evaluation_duration_seconds_sumcortex_prometheus_rule_evaluation_failures_totalcortex_prometheus_rule_evaluations_totalcortex_prometheus_rule_group_duration_secondscortex_prometheus_rule_group_duration_seconds_countcortex_prometheus_rule_group_duration_seconds_sumcortex_prometheus_rule_group_interval_secondscortex_prometheus_rule_group_iterations_missed_totalcortex_prometheus_rule_group_iterations_totalcortex_prometheus_rule_group_last_duration_secondscortex_prometheus_rule_group_last_evaluation_timestamp_secondscortex_prometheus_rule_group_rulescortex_query_frontend_connected_schedulerscortex_query_frontend_queries_in_progresscortex_query_frontend_retries_bucketcortex_query_frontend_retries_countcortex_query_frontend_retries_sumcortex_query_scheduler_connected_frontend_clientscortex_query_scheduler_connected_querier_clientscortex_query_scheduler_inflight_requestscortex_query_scheduler_inflight_requests_countcortex_query_scheduler_inflight_requests_sumcortex_query_scheduler_queue_duration_seconds_bucketcortex_query_scheduler_queue_duration_seconds_countcortex_query_scheduler_queue_duration_seconds_sumcortex_query_scheduler_queue_lengthcortex_query_scheduler_runningcortex_ring_member_heartbeats_totalcortex_ring_member_tokens_ownedcortex_ring_member_tokens_to_owncortex_ring_memberscortex_ring_oldest_member_timestampcortex_ring_tokens_totalcortex_ruler_client_request_duration_seconds_bucketcortex_ruler_client_request_duration_seconds_countcortex_ruler_client_request_duration_seconds_sumcortex_ruler_clientscortex_ruler_config_last_reload_successfulcortex_ruler_config_last_reload_successful_secondscortex_ruler_config_updates_totalcortex_ruler_managers_totalcortex_ruler_ring_check_errors_totalcortex_ruler_sync_rules_total
The metrics_namespace setting is deprecated already. It will be removed in the next minor release. The default prefix will be loki then.
LogCLI
Store for retrieving remote schema
Previously LogCLI used to fetch remote schema from the store configured in -boltdb.shipper.shared-store when -remote-schema is set to true.
A new CLI flag -schema-store is introduced as a replacement to configure the store for retrieving remote schema.
Further reading
To upgrade from one of the versions of Loki 2.x, refer to Upgrade Loki 2.x versions.
To upgrade from one of the versions of Loki 1.x, refer to Upgrade Loki 1.x versions.


