升级Grafana Loki
每一次尝试都是为了保持Grafana Loki向后兼容,这样升级应该是低风险和低摩擦。
不幸的是,Loki是一个软件,而软件是很难的,有时我们不得不在易用性和易用性之间做出决定。
如果我们有任何升级困难的预期,我们将在这里记录它。
随着发布的版本越来越多,在多个版本之间移动更有可能出现意想不到的问题。如果可能的话,尽量保持最新状态,并进行连续更新。如果您想跳过版本,请在尝试升级产品之前在开发环境中进行尝试。
检查配置更改
使用docker,你可以用如下命令检查Loki的两个版本之间的变化:
export OLD_LOKI=2.3.0 export NEW_LOKI=2.4.1 export CONFIG_FILE=loki-local-config。yaml diff——color=always——side-by-side <(docker run——rm -t -v "${PWD}":/config grafana/loki:${OLD_LOKI} -config。file=/config/${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=/config/${CONFIG_FILE} -print-config-stderr 2>&1 | sed '/Starting Loki/q' | tr -d '\r') | less -R
的Tr -d '\r'
对大多数人来说可能不是必要的,似乎WSL2偷偷在一些窗口换行符…
输出是令人难以置信的冗长,因为它显示了用于运行Loki的整个内部配置结构,如果您更喜欢只显示更改或不同风格的输出,您可以使用diff命令。
主要/未发布
2.7.0
洛基
洛基金丝雀许可
新推
模式洛基金丝雀可以将Loki金丝雀生成的日志直接推送到给定的Loki URL。以前,它只写到一个本地文件,你需要一些代理,如promtail,刮,并推动它到洛基。所以,如果你运行Loki背后的代理与不同的授权策略读写Loki,那么我们传递给Loki金丝雀的认证凭证现在需要两者都有读
而且写
权限。
不建议使用引擎查询超时
之前,我们有两个配置来定义查询超时:engine.timeout
而且querier.query-timeout
.因为他们相互矛盾engine.timeout
表现力不如querier.query-tiomeout
,我们弃用它而用依赖engine.query-timeout
只有。
fifocache
已被重新命名
内存中的fifocache
已重命名为embedded-cache
.这允许我们在未来用其他东西替换实现(目前是一个简单的FIFO数据结构)而不会引起混乱
在kubernetes节点上均匀分布Memcached pod作为块
我们现在在可用的kubernetes节点上均匀地分布memcached_chunks pod,但是允许多个pod被调度到同一个节点中。如果您希望每个节点最多运行一个pod,请设置.memcached.memcached_chunks.use_topology_spread美元
为假。
虽然我们尝试调度每个Kubernetes节点最多1个memcached_chunks podtopology_spread_max_skew: 1
字段,如果没有更多的节点可用,则多个pod将调度在同一节点上。这可能会影响服务的可靠性,因此请考虑根据您的风险承受能力调整这些值。
在kubernetes节点上均匀分布分发器
我们现在在可用的kubernetes节点上均匀地分布分发器,但是允许多个分发器被调度到同一个节点中。如果您希望每个节点最多运行一个分发服务器,请设置._config.distributors.use_topology_spread美元
为假。
虽然我们尝试在每个Kubernetes节点上调度最多1个分发服务器topology_spread_max_skew: 1
字段,如果没有更多可用节点,则多个分发器将调度到同一节点上。这可能会影响服务的可靠性,因此请考虑根据您的风险承受能力调整这些值。
在kubernetes节点上均匀分布查询器
现在,我们将查询器均匀地分布在可用的kubernetes节点上,但是允许多个查询器被调度到同一个节点中。如果您希望每个节点最多运行一个查询器,请设置._config.querier.use_topology_spread美元
为假。
我们尝试在每个Kubernetes节点上调度最多1个查询器topology_spread_max_skew: 1
字段,如果没有更多的节点可用,则多个查询器将调度在同一节点上。这可能会影响服务的可靠性,因此请考虑根据您的风险承受能力调整这些值。
的默认值server.http-listen-port
改变了
这个值现在默认为3100,所以Loki进程不需要特殊权限。在此之前,它被设置为端口80,这是一个特权端口。如果您需要Loki在端口80上监听,您可以使用命令将其设置回以前的默认值-server.http-listen-port = 80
.
Docker-compose设置已经更新
的docker-compose设置已更新为v2.6.0并包括许多改进。
值得注意的变化包括:
- 身份验证(多租户)是启用默认情况下;你可以禁用它
生产/码头工人/ config / loki.yaml
通过设置auth_enabled:假
- 存储现在使用Minio而不是本地文件系统
- 将当前存储移到
. data / minio
而且它应该是透明的
- 将当前存储移到
- 日志生成器被添加-如果你不需要它,只需从删除服务
docker-compose.yaml
或者不启动服务
删除的配置已更改
全球deletion_mode
压缩器配置中的选项移动到运行时配置。
- 的
deletion_mode
选项需要从您的压缩器配置中删除 - 的
deletion_mode
全局覆盖需要设置为所需的模式:禁用
,过滤器。
,或filter-and-delete
.默认情况下,filter-and-delete
启用。 - 任何
allow_delete
需要删除或更改为每租户覆盖deletion_mode
使用所需的模式进行覆盖。
度量名称loki_log_messages_total
改变了
此指标的名称更改为loki_internal_log_messages_total
减少歧义。以前的名称仍然存在,但已弃用。
使用报告/遥测配置已更改名称
向Grafana报告匿名使用统计信息的配置已从usage_report
来分析
.
TLScipher_suites
而且tls_min_version
已经
这些以前可以在下面配置server.http_tls_config
而且server.grpc_tls_config
分开。他们现在server.tls_cipher_suites
而且server.tls_min_version
.这些值现在也可以为个人客户端配置,例如:distributor.ring.etcd
或querier.ingester_client.grpc_client_config
.
查询器query_timeout
默认的改变
的默认值querier.query_timeout
的1米
已改为0
.
ruler.storage.configdb
已被移除
ConfigDB在2.0中被禁止作为标尺存储选项。配置结构体终于被删除了。
ruler.remote_write.client
已被移除
不能再为标尺指定远程写客户端。
Promtail
gcp_push_target_parsing_errors_total
有一个新的原因
标签
的gcp_push_target_parsing_errors_total
GCP推送目标指标已经添加了一个新的标签原因
.这包括可能导致解析失败的细节。
Windows事件日志:现在正确包含user_data
的内容user_data
字段错误地设置为相同的值event_data
在以前的版本中。这是在# 7461依赖于这种坏行为的日志查询可能会受到影响。
2.6.0
洛基
unwrapped的实现率
聚合改变
实施率()
聚合函数更改回以前的实现之前# 5013.这意味着每秒的速率是根据提取值的总和计算的,而不是随着时间的推移的平均增长。
如果您希望将提取的值处理为计数器公制,你应该用新的rate_counter ()
聚合函数,它计算向量的每秒平均增长率。
的默认值azure.container-name
改变了
这个值现在默认为洛基
,之前设置为皮质
.如果您的块或标尺存储依赖于此容器名称,则必须手动指定-azure.container-name =皮层
或-ruler.storage.azure.container-name =皮层
分别。
2.5.0
洛基
split_queries_by_interval
Yaml配置已经移动。
以前可以在两个地方定义这个值
Query_range: split_queries_by_interval: 10m
和/或
Limits_config: split_queries_by_interval: 10m
在2.5.0中,只能在limits_config
节中,洛基将无法启动,如果你不移除split_queries_by_interval
从query_range
部分。
此外,它有一个新的默认值30米
而不是0
.
CLI标志不会改变,保持不变querier.split-queries-by-interval
.
不再支持旧的普罗米修斯规则配置格式
以前的警报规则可以用两种格式指定:1.单击“确定”。X格式(遗留的,命名为半
内部)和2.x。我们决定放弃对格式的支持1.倍
因为它相当老,保持对它的支持需要大量的代码。
如果您仍在使用传统格式,请查看报警规则有关如何以新格式编写警报规则的说明。
作为参考,更新的格式遵循类似于下面的结构:
groups:—name: example rules:—alert: HighErrorRate expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5 for: 10m labels: severity: page annotations: summary: High request latency
同时,遗留格式是一个字符串,格式如下:
ALERT <警报名称> IF <表达式> [FOR <持续时间>][LABELS <标签集>][ANNOTATIONS <标签集>]
更改默认配置值
parallelise_shardable_queries
下query_range
配置现在默认为真正的
.split_queries_by_interval
下limits_config
配置现在默认为30米
,它是0
.max_chunk_age
在摄取
配置现在默认为2 h
以前是1 h
.query_ingesters_within
下查询器
配置现在默认为3 h
,以前是0
.结束时间大于的任何查询(或子查询)3 h
Ago将不会被发送到摄取器,这节省了摄取器对它们通常不包含的数据的工作。如果你经常写旧数据给洛基,你可能需要返回这个值给0
总是查询摄取者。max_concurrent
下查询器
配置现在默认为10
而不是20.
.match_max_concurrent
下frontend_worker
Config现在默认为true,这将取代并行性
设置,现在可以从配置中删除。控件可以控制单个进程的查询并行性查询器
max_concurrent
设置。flush_op_timeout
下摄取
配置块现在默认为10米
,从十年代
.这可以帮助在洛基启动时重玩大型WAL,并避免Msg ="failed to flush"…上下文截止日期已超过
错误。
Promtail
gcplog
标签变了
- 资源标签已从
__ <名称>
来__gcp_resource_labels_ <名称>
例如,如果你以前用过__project_id
然后您需要更新您的relabel配置来使用__gcp_resource_labels_project_id
. resource_type
已经转移到__gcp_resource_type
promtail_log_entries_bytes_bucket
直方图已被移除。
此直方图按文件报告日志行大小的分布。对于每个被跟踪的文件,它有8个桶。
这会产生大量的级数,我们认为这个指标没有足够的价值来抵消产生的级数的数量,所以我们删除了它。
虽然这不是一个直接的替代,但我们发现更有用的两个指标是通过管道阶段配置的大小和行计数器,如何配置这些指标的示例可以在度量管道阶段文档
添加Docker目标
日志信息已从level=error降级为level=info
如果您有依赖于日志级别的仪表板,请更改它们以搜索msg="added Docker target"
财产。
Jsonnet
压缩器配置定义为命令行参数移动到yaml配置
以下2个在jsonnet中定义为命令行参数的压缩器配置现在被移动到yaml配置中:
可以下载压缩文件的目录。# CLI标志:-boltdb.shipper.compactor.working-directory [working_directory: ] #用于存储boltdb文件的共享存储#支持类型:gcs, s3, azure, swift,文件系统。#命令行标志:-boltdb.shipper. compator .shared-store [shared_store: ]
测试盒框
以下是升级洛基之前应该审查和理解的重要变化。
洛基
以下改动与升级洛基有关。
单个二进制文件不再运行表管理器
二元洛基是指和洛基一起—target =所有
如果没有,默认是哪个—target
标志被传递。
这将影响以下场景中的任何人:
- 运行一个二进制洛基索引类型除了
boltdb-shipper
或boltdb
- 依赖于配置的留存率
retention_deletes_enabled
而且retention_period
任何在第一种情况下不吸毒的人boltdb-shipper
或boltdb
(如。卡珊德拉
或bigtable
)应该修改他们的洛基命令,包括—target =表管理
这将指示Loki为您运行一个表管理器。
任何处于第二种情况的人,你都有两个选择,第一种(不推荐)是通过添加表管理器来运行Loki—target =表管理
.
第二种建议的解决方案是通过压缩器使用删除:
压缩器:retention_enabled: true limits_config: retention_period: [30d]
看到保存文档更多信息。
启动时的日志消息:proto:已注册的副本原型类型:
公关# 3842cyriltovena:叉皮层块存储到洛基。
因为皮质不打算使用块
我们决定将其分叉到我们的存储包中,以便能够轻松地发展和修改它。然而,作为一个副作用,我们仍然提供Cortex,其中包括这个分叉的代码和protobuf文件,导致在启动时的日志消息如下:
2021-11-04 15:30:02.437911 I |原型:副本原型注册:净化计划。我|原型:复制原型类型注册:净化计划。ChunksGroup 2021-11-04 15:30:02.437939 I |原型:复制原型类型注册:purgeplan。ChunkDetails……
这些信息是无害的,我们将在未来努力删除它们。
更改一些默认限制为公共值
公关4415DylanGuedes:修改了一些限制的默认值,以保护用户不因依赖默认配置而导致摄入负载过重。
我们建议您仔细检查您的Loki配置中是否存在以下参数:ingestion_rate_strategy
,max_global_streams_per_user
max_query_length
max_query_parallelism
max_streams_per_user
reject_old_samples
reject_old_samples_max_age
.如果它们不存在,我们建议您仔细检查新值是否会对系统产生负面影响。这些变化是:
配置 | 新的默认 | 旧的违约 |
---|---|---|
ingestion_rate_strategy | “全球” | “本地” |
max_global_streams_per_user | 5000 | 0(不限) |
max_query_length | “721小时” | “0h”(不限) |
max_query_parallelism | 32 | 14 |
max_streams_per_user | 0(不限) | 10000 |
reject_old_samples | 真正的 | 假 |
reject_old_samples_max_age | “168小时” | “336小时” |
per_stream_rate_limit | 3 mb | - |
per_stream_rate_limit_burst | 15 mb | - |
更改配置默认值
配置 | 新的默认 | 旧的违约 |
---|---|---|
chunk_retain_period | 0 | 30年代 |
chunk_idle_period | 30米 | 1 h |
chunk_target_size | 1572864 | 1048576 |
- Chunk_retain_period在使用默认不启用的索引查询缓存时是必要的。如果您已经配置了index_queries_cache_config部分,请确保将chunk_retain_period设置为大于缓存TTL
- Chunk_idle_period是指在没有接收到日志的块被刷新之前的多长时间。
- chunk_target_size增加了,以刷新稍大的块,如果使用memcache存储块,请确保它将接受1.5MB大小的文件。
在内存中,FIFO缓存默认启用
Loki现在在内存中启用结果缓存和块缓存来提高性能。然而,这可能会增加内存使用,因为默认情况下允许缓存消耗最多1GB的内存。
如果您想禁用这些缓存或更改内存限制:
禁用:
Chunk_store_config: chunk_cache_config: enable_fifocache: false query_range: results_cache: cache: enable_fifocache: false
调整大小:
chunk_store_config: chunk_cache_config: enable_fifocache: true fifocache: max_size_bytes: 500MB query_range: results_cache: cache: enable_fifocache: true fifocache: max_size_bytes: 500MB
摄取生命周期final_sleep
现在默认为0
- 4608trevorwhitney:更改ingester lifecycle的默认值
final_sleep
从30年代
来0
这个最后的睡眠是为了让洛基运行足够长的时间,在关闭之前获得最后的普罗米修斯,然而它也导致洛基在关闭时闲置30分钟,这对许多人来说是一个令人讨厌的经历。
我们决定默认情况下禁用这种睡眠行为会更好,但是任何人都可以直接设置这个配置变量来返回之前的行为。
Ingester WAL现在默认为开启,并且块传输默认为禁用
- 4543trevorwhitney:修改更多默认值,提高普通存储配置的应用
- 4629owen-d: Loki jsonnet库中默认启用WAL
- 4624chaudum:禁用jsonnet lib中的chunk传输
这会改变一些默认值,导致摄取WAL现在默认开启,并且块传输重试默认禁用。注意,这意味着Loki将默认依赖于本地磁盘的WAL(预写日志)目录。默认为细胞膜
但是可以通过——ingester.wal-dir
或通过path_prefix
在公共配置部分。下面是带有先前默认值的配置片段,以及带有新值的配置片段。
以前的违约:
Ingester: max_transfer_retries: 10 wal: enabled: false
新的默认值:
Ingester: max_transfer_retries: 0 wal: enabled: true
成员列表配置现在自动适用于所有未配置的环
- 4400trevorwhitney: Config:自动应用成员列表配置也所有环时提供
此更改会影响摄取器、分发器和标尺环的行为。以前,如果你想为所有这些戒指使用成员列表,你必须提供一个memberlist
配置和指定存储:memberlist
为kvstore
你想要使用成员列表的每个环。例如,你的配置可能是这样的:
Memberlist: join_members:—loki.namespace.svc.cluster.local distributor: ring: kvstore: store: Memberlist ingester: lifecycler: ring: kvstore: store: Memberlist ruler: ring: kvstore: store: Memberlist
现在,如果你提供一个memberlist
至少配置一个join_members
,洛基将默认所有戒指使用kvstore
类型的memberlist
.您可以通过覆盖特定的配置来改变这种行为。例如,如果你想用领事
为你统治者
戒指,但memberlist
为摄取
而且经销商
,你可以使用以下配置(尽管我们不知道为什么有人想这样做):
Memberlist: join_members:—loki.namespace.svc.cluster.local ruler: ring: kvstore: store: consul consul: host: consul.namespace.svc.cluster.local:8500
更改了一些GRPC服务器设置的默认值
- 4435trevorwhitney:更改两个GRPC设置的默认值,以便查询器可以连接到前端/调度器
这将改变两个默认值,grpc_server_min_time_between_pings
而且grpc_server_ping_without_stream_allowed
供GRPC服务器使用。
之前的值:
服务器:grpc_server_min_time_between_ping: '5m' grpc_server_ping_without_stream_allowed: false
新值:
服务器:grpc_server_min_time_between_ping: '10s' grpc_server_ping_without_stream_allowed: true
这个问题有更多关于改动的信息。
一些度量前缀已经从cortex_
来loki_
Cortex_runtime_config * -> loki_runtime_config* cortex_chunks_store* -> loki_chunks_store*
记录规则存储现在是持久的
- 4344dannykopping:每个租户WAL
以前,由记录规则生成的样本在被远程写入到Prometheus之前只会缓冲在内存中;从这个版本,统治者
现在将这些样例写入每个租户的预写日志,以确保持久性。可以找到关于每个租户WAL的更多详细信息在这里.
的统治者
现在需要持久存储-请参阅操作有关部署的更多详细信息。
Promtail
以下更改与升级Promtail有关。
提示不再插入promtail_instance
刮痧时的标签gcplog
目标
- 4556james-callahan:删除
promtail_instance
刮痧时被提示添加的标签gcplog
目标。
tripwire
洛基
为没有至少一个相等匹配器的查询引入的查询限制
公关3216sandeepsukhani:检查流选择器至少有一个相等匹配器
这个改变现在拒绝任何不包含至少一个相等匹配器的查询,一个例子可以更好地说明:
= ~{名称空间“。*”}
这个查询现在将被拒绝,但是有几种方法可以修改它以使其成功:
添加至少一个等号标签匹配器:
= ~{集群= " us-east-1”,名称空间“。*”}
使用.+
而不是.*
{名称空间= ~ " + "}
这种差异可能看起来很微妙,但如果我们把它分解开来.
匹配任意字符,*
匹配前一个字符和的零个或多个+
匹配前面的一个或多个字符。的.*
Case将匹配空值.+
不会,这是重要的区别。{名称空间= " "}
是一个无效的请求(除非您像上面的例子一样添加另一个等于标签匹配器)
这个变化的原因与Loki中索引查找的工作方式有关,如果你没有至少一个相等匹配器,Loki必须执行一个完整的索引表扫描,这是一个昂贵且缓慢的操作。
2.2.0
洛基
在升级到2.2之前,请务必升级到2.0或2.1
在洛基2.2中,我们将内部版本的数据块格式从v2修改为v3,这是一个透明的更改,只有当你尝试时才有意义降级洛基装置。我们在2.0.1和2.1,以及2.2和任何未来版本中加入了读取v3块的代码。
如果你升级到2.2+,任何创建的块只能被2.0.1,2.1和2.2+读取
因此,首先升级到2.0、2.0.1或2.1非常重要之前升级到2.2,如果您因为任何原因需要回滚,您可以很容易地这样做。
注意:2.0和2.0.1在各个方面都是相同的,只是2.0.1包含读取v3块格式所需的代码。因此,如果你在2.0升级到2.2,如果你想回退,你必须回退到2.0.1。
洛基配置
如果您使用查询前端,请阅读此内容sharded_queries_enabled:真
我们发现,与长时间范围内的分片查询相关的查询调度可能会导致每个租户工作队列中的单个查询的不公平工作调度。
的max_query_parallelism
设置旨在限制一次允许将单个查询的“工作”的分割和分片单元放入每个租户工作队列中的数量。方法将查询按时间分割split_queries_by_interval
并将这个值与max_query_parallelism
然而,当填充队列时,启用了分片,每个分割随后被分片为16个额外的工作单元max_query_parallelism
应用了极限。
在2.2中,我们改变了这个行为来应用max_query_parallelism
分裂后而且对查询进行分片,可以为每个查询提供更公平和预期的队列调度。
这意味着什么如果您使用查询前端并启用了sharding_queries_enabled(您应该启用),Loki将在每个查询中将更少的工作放入工作队列中。你可能需要增加薪水max_query_parallelism
如果注意到查询性能较慢,则设置在实践中,您可能看不到区别,除非您运行的集群中有很多查询器,或者查询器的值非常高并行性
frontend_worker设置。
你可以考虑增加电流max_query_parallelism
设置为16以获得前面的行为,尽管在实践中,我们怀疑很少有人真正想要这么高的值,除非您有一个重要的查询器工作池。
还要注意确保max_outstanding_per_tenant
总是大于max_query_parallelism
或者大型查询将自动失败,返回给用户一个429。
Promtail
对于2.0,我们取消了长期被弃用的功能entry_parser
在Promtail配置中配置,然而这样做我们引入了一个非常令人困惑和错误的默认行为:
如果你没有指定pipeline_stages
项将为您提供一个默认值,其中包括码头工人
管道阶段。这可能导致一些非常令人困惑的结果。
在3404,我们纠正了这种行为
如果您正在使用docker,以及任何您的scrape_configs
都缺了一个pipeline_stages
定义,你应加入以下内容,以取得正确的行为:
Pipeline_stages: - docker: {}
魅惑
从2.0.0到2.1.0的升级应该是相当顺利的,请注意以下两点:
舵图移动了!
舵面图现在位于:https://github.com/grafana/helm-charts/
舵手回购URL现在是:https://grafana.github.io/helm-charts
Fluent Bit插件重命名
Fluent bit现在正式支持Loki输出插件!WoooHOOO !
然而,这与我们现有的输出插件产生了命名冲突(新的本机输出使用该名称洛基
)所以我们重命名了插件。
随着时间的推移,我们的计划是弃用并消除我们的输出插件,以支持本地Loki支持。然而,在此之前,您可以继续使用插件,并进行以下更改:
旧:
[输出]名称loki
新:
[输出]名称grafana-loki
2.0.0
这是一个主要的洛基版本,有一些非常重要的升级考虑因素。在大多数情况下,有影响的变化很少,而且大多数情况下这将是一个无缝升级。
2.0.0升级主题:
- 如果你正在使用docker映像,请阅读这篇文章!
- 重要的螺栓数据库-托运人升级注意事项
- 重要结果:从yaml配置中删除cachemax_fresh
- Promtail删除了entry_parser配置
- 如果您想使用新的单一存储索引和v11模式
如果你正在使用docker映像,请阅读这篇文章!
(这包括,Helm, Tanka, docker-compose等)
docker映像中的默认配置文件,以及默认helm值。Tanka的yaml和jsonnet都指定了一个模式定义,以使事情更容易开始。
如果您没有使用自己的模式定义指定自己的配置文件(或者在values.yaml中没有自定义模式定义),那么升级到2.0就会出现问题!
在2.0中,默认是v11模式和boltdb-shipper
索引类型。
的索引类型aws
,bigtable
,或卡珊德拉
这意味着您已经定义了一个自定义模式没有什么此外,您还需要对模式进行处理。但是,您可以考虑添加一个新的模式条目来使用newboltdb-shipper
如果您不想使用这些单独的索引存储区,而只使用一个对象存储区,请键入。
该怎么做
所需的最低操作是创建一个配置,该配置指定模式以匹配先前的默认值。
(请记住,这只会告诉洛基使用旧的默认模式,如果你想升级到v11和/或移动到单一存储boltdb-shipper,见下文)
我们在三个地方硬编码了模式定义:
舵
Helm在值中附带了相同的内部模式。Yaml文件很长一段时间。
如果你能提供自己的价值观。Yaml文件那么就没有了要求操作,因为您已经有了一个模式定义。
如果你没有提供自己的价值观。Yaml文件,你需要做一个!
我们建议使用所包含的值。Yaml文件从1.6.0标签
这与默认值相匹配。yaml文件是2.0之前的,是洛基在2.0后工作所必需的
如前所述,您还应该考虑迁移到v11模式和boltdb-shipper见下文获取更多信息。
短歌
这可能只影响一小部分tanka用户,因为Loki的默认模式配置是强制的GCS
而且bigtable
.
如果你的main.jsonnet
(或者在您手动创建的jsonnet中的某个地方)没有模式配置部分,那么您将需要像这样添加一个!
{_config+:: {using_boltdb_shipper: false, loki+: {schema_config+: {configs: [{from: '2018-04-15', store: 'bigtable', object_store: 'gcs', schema: 'v11', index: {prefix: '%s_index_' % $._config. {Table_prefix, period: '168h',},}],},}}
请注意如果你设置了
index_period_hours
到168h(之前的默认值)以外的值,您必须在上述配置中更新此值期:
来匹配你的选择。
请注意我们已经将默认的索引存储更改为
boltdb-shipper
补充一点很重要using_boltdb_shipper:假的,
直到你准备好改变(如果你想改变)
修改jsonnet配置以使用boltdb-shipper
类型与下面您需要添加一个新的模式部分。
然而当你改变的时候要注意using_boltdb_shipper:真
摄取器和查询器的部署类型将更改为状态集!使用boltdb-shipper的摄取器和查询器需要状态集。
Docker(例如Docker -compose)
对于docker相关的情况,你必须挂载一个Loki配置文件,与容器中装载的内容分开
的前面的默认文件1.6.0标签上的github
你如何让洛基安装和使用它可能会根据你如何使用图像而有所不同,但这是一个常见的例子:
Docker运行-d——name=loki——mount type=bind,source=" loki-config.yaml路径",target=/etc/loki/local-config.yaml
Loki docker镜像期望在/etc/loki/local-config.yaml
重要:boltdb-shipper升级注意事项。
在1.6.0到2.0.0之间,boltdb-shipper索引类型发生了重大变化,如果您已经在运行该索引并正在升级,则需要格外小心。
请强烈考虑采取一个完整的备份指数
目录,此位置可能略有不同,这取决于您使用的存储。它应该是一个名为index的文件夹里面有一堆文件夹,比如index_18561
,index_18560
...
chunks目录不需要任何特殊备份。
如果你有一个环境来测试这个,请在升级关键数据之前这样做。
有两个重要的更改保证该数据的备份,因为它们将使回滚不可能:
- 包括一个压缩器,它将获取现有的索引文件,并将它们压缩为每天一个,并删除未压缩的文件
- 所有索引文件现在都在上传前进行了gzip压缩
第二部分很重要,因为1.6.0不知道如何读取经过gzip压缩的文件,因此上传的任何新文件或压缩后的任何文件在1.6.0或更早版本都无法读取。
话虽如此我们不期望出现问题,我们的测试到目前为止还没有发现任何问题,但一些额外的预防措施可能会在不可预见的情况下避免数据丢失!
请通过GitHub报告任何问题,或通过#loki slack频道与我们联系。
请注意是否正在使用boltdb-shipper,并且正在高可用性和独立的文件系统下运行
这是一个文档记录很差的模式,而且我们还在使用boltdb-shipper进行试验。现在我们删除了文档和对这种模式的任何支持。
要在2.0中使用boltdb-shipper,您需要一个共享存储(S3、GCS等),官方不支持在HA中使用环运行单独的文件系统存储的模式。
我们没有做任何明确的事情来限制这个功能,但是我们没有任何时间来测试这个,这就是为什么我们删除了文档,并将其列为不支持。
如果在微服务中运行,在查询器之前部署摄取器
摄取器现在公开了一个新的RPC方法,当索引类型为时查询器使用该方法boltdb-shipper
.查询器通常比摄取器推出得快,因此如果新的查询器使用新的RPC查询旧的摄取器,查询将会失败。为避免在升级期间出现任何查询停机,请在查询之前推出摄取器。
如果运行压缩器,请确保压缩器具有对象存储的删除权限。
压缩器是一个可选的但建议使用的组件,用于组合和重复删除boltdb-shipper索引文件。当压缩索引文件时,压缩器写入一个新文件并删除未优化的文件。确保压缩机具有适当的删除文件权限,例如AWS s3具有“s3:DeleteObject”权限。
重要的是:results_cache.max_freshness
从YAML配置中删除
的max_freshness
配置从results_cache
已经被移除了另一个叫max_cache_freshness_per_query
在limits_config
效果是一样的。如果你碰巧有的话results_cache.max_freshness
设置请使用limits_config.max_cache_freshness_per_query
改为YAML配置。
Promtail配置被删除
长期被弃用的entry_parser
配置在Promtail已删除,使用pipeline_stages代替。
升级模式以使用boltdb-shipper和/或v11模式
如果还想利用新的Single Store (boltdb-shipper)索引,如果还没有使用v11模式,还可以使用它。
您可以通过添加一个新的模式条目来做到这一点。
这里有一个例子:
Schema_config: configs: - from: 2018-04-15①store: boltdb①④object_store:文件系统①④schema: v11②index: prefix: index_①period: 168h①- from: 2020-10-24③store: boltdb-shipper object_store: filesystem④schema: v11 index: prefix: index_ period: 24h⑤
①确保所有这些都匹配您当前的模式配置②确保这匹配您以前的模式版本,例如Helm可能是v9③确保这是一个日期未来请记住洛基只知道UTC,所以确保它是未来的UTC日期④确保这与您现有的配置相匹配(例如,也许您正在为object_store使用gcs)⑤boltdb-shipper需要24小时
还有更多的例子存储描述页面包括设置存储
螺栓-托运人部分。
1.6.0
重要提示:修改了Ksonnet端口,并从Docker镜像中删除了NET_BIND_SERVICE功能
在1.5.0中,我们将Loki用户更改为不以root用户运行,这导致了绑定端口80的问题。为了解决这个问题,我们更新了docker镜像,将NET_BIND_SERVICE功能添加到loki进程中,允许loki以非根用户的身份绑定到端口80,只要底层系统允许linux功能。
这已被证明是一个问题,因为许多原因和在公关2294该功能已被删除。
现在不可能再让Loki在发布的docker镜像中使用小于1024的端口启动。
Helm的默认端口一直是3100,Helm用户应该不会受到影响,除非他们更改了默认值。
然而,Ksonnet用户应该仔细检查他们的配置,在PR 2294中,loki端口从80更改为3100
重要提示:如果您在微服务模式下运行Loki,则需要特殊的滚出说明
添加了一个新的摄取器GRPC API,允许加速度量查询,以确保没有查询错误确保你先升级了所有的摄取器。完成此操作后,您就可以继续部署的其余部分,这是为了确保查询器不会查找尚未可用的API。
如果一次性推出所有内容,使用新代码的查询器将尝试查询API上可能没有新方法的食入器,查询将失败。
这将只影响读取(查询),而不影响写入,并且仅在推出期间。
重要提示:对Helm和Ksonnet的刮配置更改将影响Promtail创建的标签
公关2091对Promtail刮擦配置进行了几项更改:
这是由https://github.com/grafana/jsonnet-libs/pull/261触发的,上面的PR将实例标签更改为在刮取配置中惟一的。它还添加了一个pod和一个容器目标标签,以便可以轻松地将指标与来自cAdvisor、KSM和Kubelet的指标连接起来。此提交将相同的内容添加到Loki刮擦配置中。它还删除了container_name标签。和容器标签一样,之前已经添加到Loki但是,container_name标签已弃用,并且在K8s 1.16中已经消失,因此它很快就不能用于直接连接。
博士TL;
在Helm和Ksonnet Promtail刮擦配置中,以下标签都已更改:
实例
->圆荚体
container_name
->容器
实验性螺栓-托运人变化
公关2166现在迫使指数的周期为24小时
:
如果活动模式或即将到来的模式未设置为的时间段,Loki将无法启动并报错24小时
你可以像这样添加一个新的模式配置:
schema_config: configs: - from: 2020-01-01 <-----这是您的当前条目,日期将是不同的存储:boltdb-shipper object_store: aws schema: v11 index: prefix: index_ period: 168h - from: [INSERT FUTURE date HERE] <-----添加另一个条目,设置未来日期存储:boltdb-shipper object_store: aws schema: v11 index: prefix: index_ period: 24h <——这必须是24h
如果你不在的话模式:v11
这将是一个做出改变的好机会在新的模式配置中也。
请注意如果您所在时区中的当前时间已经在UTC午夜之后,请将日期再向前设置一天。
还有一个重大检修如何boltdb-托运人内部,这应该是不可见的用户,但由于这个功能是实验性的,在开发中的bug是可能的!
如果你看一下存储,最明显的变化是,Loki不再更新现有文件,而是每15分钟创建一个新的索引文件,这是一个重要的举动,以确保对象存储中的对象是不可变的,并将简化未来的操作,如压缩和删除。
打破CLI标志更改
以下CLI标志是为了提高一致性而更改的,它们预计不会被广泛使用
——查询器。Query_timeout +查询器。查询超时-分发器。额外查询延迟+查询器。额外查询延迟- max-chunk-batch-size + store。最大块批量大小-摄取器。concurrent-flush + ingester.concurrent-flushes
洛基金丝雀指标名称更改
当向金丝雀添加一些新功能时,我们意识到现有的指标不符合计数器名称的标准,以下指标已被重命名:
loki_canary_total_entries - > loki_canary_entries_total loki_canary_out_of_order_entries - > loki_canary_out_of_order_entries_total loki_canary_websocket_missing_entries - > loki_canary_websocket_missing_entries_total loki_canary_missing_entries - > loki_canary_missing_entries_total loki_canary_unexpected_entries - > loki_canary_unexpected_entries_total loki_canary_duplicate_entries - > loki_canary_duplicate_entries_total loki_canary_ws_reconnects - > loki_canary_ws_reconnects_totalLoki_canary_response_latency -> loki_canary_response_latency_seconds . loki_canary_response_latency_seconds
Ksonnet变化
在生产/ ksonnet洛基/ config.libsonnet
的变量storage_backend
的默认值“bigtable, gcs”
.这已经被更改为不提供默认值,如果在你的环境jsonnet中没有提供,将会错误,这里是一个你应该添加的例子,以具有与默认值相同的行为(命名空间和集群应该已经定义):
_config+::{命名空间:'loki-dev',集群:'us-central1', storage_backend: 'gcs,bigtable',
违约,gcs, bigtable
对于任何将ksonnet与其他存储后端一起使用的人来说,都会感到困惑,因为它会显示出模糊的大表错误。
1.5.0
注意:下面为版本1.4.0概述的所需升级路径仍然适用于从1.4.0之前的任何版本迁移到1.5.0(例如1.3.0->1.5.0也需要查看1.4.0的升级要求)。
破坏配置更改!
Loki 1.5.0供应商Cortex v1.0.0(恭喜!),它有一个大量的变化列表.
虽然更改命令行标志也会影响Loki,但我们通常建议人们使用配置文件代替。
Cortex在配置文件中做了大量的清理工作,强烈建议您查看一下配置文件带注释的差异在升级到洛基1.5.0之前。
以下字段从YAML配置中完全删除:claim_on_rollout
(总是正确的),normalise_tokens
(总是正确的)。
测试您的配置
要查看您的配置是否需要更改,快速测试的一种方法是从发布页面
然后运行提供配置文件的二进制文件。/ loki-linux-amd64 -config.file = myconfig.yaml
如果有配置不再有效,你会立即看到错误:
。/ loki-linux-amd64 -config.file = loki-local-config。Yaml解析配置失败:loki-local-config。Yaml: Yaml: unmarshal错误:第35行:字段dynamodbconfig在类型aws中未找到。StorageConfig
引用差动列表我可以看到这个配置改变了:
- dynamodbconfig: + dynamodb:
另外,其他几个AWS相关配置也发生了变化,需要对它们进行udpate。
Loki Docker映像用户和文件位置更改
为了提高安全性,在1.5.0中Docker容器不再运行loki进程根
相反,进程以用户身份运行洛基
在UID10001
和GID10001
这可能会在几个方面影响人们:
洛基港口
如果运行Loki时,配置打开的端口号大于1024(默认值,HTTP为3100,GRPC为9095),那么在端口方面,一切都应该正常工作。
如果你运行Loki时打开的端口号小于1024,Linux通常需要root权限来做这件事,但是在Docker容器中我们运行Setcap cap_net_bind_service=+ep /usr/bin/loki
该功能允许loki进程在以非root用户运行时绑定到小于1024的端口。
并不是每个环境都允许这个功能,但是在linux中限制这个功能是可能的。如果这个限制存在,你将被迫运行Loki,配置HTTP和GRPC端口超过1024。
文件系统
请注意Loki正在寻找docker映像中提供的配置文件的位置已经更改
在1.4.0和更早的版本中,docker容器中包含的配置文件使用的是目录:
/ tmp /洛基/索引/ tmp /洛基/块
在1.5.0中,这种情况发生了变化:
洛基/索引/洛基/块
这将主要影响任何使用docker-compose或docker运行Loki并指定一个卷持久化存储的人。
这里有两个需要关注的问题,一个是文件的正确所有权,另一个是确保你的坐骑更新到新的位置。
一个可能的升级路径是这样的:
如果我用这个命令来控制洛基Docker运行-d——name=loki——mount source=loki-data,target=/tmp/loki -p 3100:3100 grafana/loki:1.4.0
这将挂载一个名为loki-data
到/ tmp /洛基
洛基将在这个文件夹中保存指数
而且块
1.4.0中的文件夹
要移动到1.5.0,我可以执行以下操作(请注意,您的容器名称、路径和卷等可能不同):
docker stop loki docker rm loki docker run——rm——name="loki-perm" -it——mount source=loki-data,target=/mnt ubuntu /bin/bash cd /mnt chown -R 10001:10001 ./* exit docker run -d——name=loki——mount source=loki-data,target=/loki -p 3100:3100 grafana/loki:1.5.0
注意目标= /洛基
中指定的新数据目录位置包括洛基配置文件.
如果您可以轻松地访问这些文件来运行命令,那么使用ubuntu映像将Loki文件的所有权更改为新用户的中间步骤可能就没有必要了乔恩
直接的命令。前提是你能拿到/var/lib/docker/volumes
或者,如果您挂载到不同的本地文件系统目录,则可以直接更改所有权,而无需使用容器。
Loki Duration配置
如果你得到这样的错误:
。/ loki-linux-amd64-1.5.0日志。水平=调试-config.file = / etc /洛基/配置。Yml解析配置失败:/etc/loki/configYml:不是有效的持续时间字符串:"0"
这是因为一些潜在的更改不再允许没有单位的持续时间。
不幸的是,yaml解析器没有给出行号,但它很可能是以下两个中的一个:
chunk_store_config: max_look_back_period: 0s # DURATION值必须有一个单位,即使它们是0。table_manager: retention_deletes_enabled: false retention_period: 0s # DURATION值必须有一个单位,即使它们是0
Promtail配置更改
Promtail中使用的底层backoff库有一个配置更改,最初在发布说明中没有注意到:
如果你得到这个错误:
无法解析config: /etc/promtail/promtail。Yaml: Yaml:解组错误:第3行:字段maxbackoff未在util类型中找到。BackoffConfig第4行:字段maxretries not found in type util。BackoffConfig第5行:在util类型中没有发现字段minbackoff。BackoffConfig
新的值是:
Min_period: max_period: max_retries:
1.4.0
Loki 1.4.0供应商Cortex v0.7.0-rc。0,其中包含几个破坏性的配置更改.
一个这样的配置更改将影响Loki用户:
defaul_validity
已改为default_validity
此外,在不太可能的情况下,您是通过参数而不是配置文件配置模式的,这将不再支持。这不是我们通过文档提供的选项,也不太可能有人这样做,但值得一提。
其他配置更改应该与洛基无关。
升级路径
新版本的Cortex删除了环中与非规范化标记相关的代码。你需要知道的是:
注意:下面提到的“共享环”指的是使用领事或etcd对于以下配置中的值:
kvstore: #用于环的后端存储。支持的值有:# consul, etcd, inmemory store:
- 不使用共享环(内存中)运行:不需要任何操作
- 使用共享环运行并从v1.3.0 -> v1.4.0升级:无需任何操作
- 使用共享环运行并从v1.3.0以下的任何版本升级(例如v1.2.0) -> v1.4.0:行动要求
如果你不在1.3.0版本上,并且正在使用共享环,有两个升级选项:
- 首先升级到v1.3.0之前升级到v1.4.0
或
注意:如果您正在运行单个二进制程序,您只需要将此标志添加到单个二进制命令中。
- 在你的ingesters命令中添加以下配置:
-ingester.normalise-tokens = true
- 使用此配置重新启动您的摄取器
- 继续升级到v1.4.0
- 删除配置选项(只有在所有内容都运行v1.4.0之后才执行此操作)
注意:也可以通过配置文件启用此标志,请参阅lifecycler_config
配置选项。
如果使用Helm Loki图表:
extraArgs:摄取。normalise-tokens:真
如果使用Helm Loki-Stack图表:
loki: extraArgs: ingester。normalise-tokens:真
哪里会出错
如果您试图将v1.4.0版本的摄取器添加到Loki v1.2.0或更早版本创建的没有命令行参数的环中-ingester.normalise-tokens = true
(或通过配置文件), v1.4.0版本的摄取器将为其他所有摄取器删除环中的所有条目,因为它不能“看到”它们。
这将导致分发程序无法写入和系统的一般摄取失败。
如果发生这种情况,您将希望立即回滚部署。您需要尽快从环中删除v1.4.0的摄取器,这应该允许现有的摄取器重新插入它们的令牌。您还需要删除任何v1.4.0分发器,因为它们也不理解旧的环,并且将无法发送流量。
Loki相关资源
开始伐木和Grafana Loki (3 / 4)
加入本次网络研讨会,了解为什么在整个开发生命周期中相关的度量和日志是至关重要的,以及Loki如何帮助降低日志记录成本和操作开销。
洛基日志:基本配置设置
本次网络研讨会的重点是Grafana Loki配置,包括代理Promtail和Docker;洛基服务器;以及流行的后端洛基存储。
测井和Grafana的可观察性
了解如何使用Grafana和Grafana的日志应用程序Loki来利用、管理和可视化日志事件。