Loki 如何用 KEDA 基于调度器队列指标自动伸缩 Querier【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/lokiLoki 的 querier 会整天面对波动明显的查询负载。如果你的 Loki 以 microservices 模式部署在 Kubernetes 上且启用了 query-scheduler可以用 KEDA 监听调度器的队列指标来自动伸缩 querier 副本数让查询高峰期有足够 worker 消费队列低谷期又不会白占资源。前提条件有三个Loki 以一组 microservices 的形式运行在 Kubernetes 中使用了 query-schedulerquerier 从它的队列里拉取查询集群中已部署 KEDAKubernetes Event-Driven AutoscalingLoki 官方推荐用 KEDA 基于 Prometheus 指标做自动伸缩。注意 KEDA 本身的安装部署是 KEDA 项目的文档范畴本文不展开。伸缩依据loki_query_scheduler_inflight_requests因为查询是从 query-scheduler 的队列里拉取后在 querier worker 上执行的所以伸缩指标应基于两点调度器队列里排队的查询数加上 querier worker 中正在执行的查询数。query-scheduler 暴露的loki_query_scheduler_inflight_requests指标正好把这两者加在一起追踪。文档给出的伸缩查询是sum( max_over_time( loki_query_scheduler_inflight_requests{namespaceloki-cluster, quantileQ}[R] ) )其中Q和R是需要按你的负载微调的参数Q 是取哪个分位数。Q 越高指标对短时尖峰越敏感。R 是回溯窗口range。R 越大指标随时间波动越小能避免 autoscaler 过于频繁地调整副本数。Loki 文档建议 Q 取 0.75、R 取 2 分钟。有两个约束需要注意该指标只暴露固定的分位数值0.5、0.75、0.8、0.9、0.95、0.99。查询其他分位值时 Prometheus 不返回任何数据Q 必须从这份列表里选。指标本身在被 Prometheus 抓取前已经在一个 60 秒的滑动窗口上做过平滑所以 R 小于约一分钟几乎没有额外平滑效果。文档建议 R 保持一分钟或更高。容量规划确定副本数上下限和阈值配置伸缩前需要定四个值伸缩上下限的阈值、缩容稳定期、querier 副本数的最小值和最大值。先确定单个 querier 的 worker 数。querier worker 处理队列中的查询每个 querier 可以用-querier.max-concurrent标志YAML 配置里是max_concurrent设置 worker 数默认值是4。文档建议为了留出应对负载尖峰的余量不要使用超过 75% 的 worker伸缩阈值相应设置为floor(0.75 * worker数)。例如每个 querier 配置 6 个 worker阈值就是floor(0.75 * 6) 4。这里有一个容易踩坑的细节-querier.max-concurrent设置的是 querier 的 worker 总数但 querier 会把 worker 分摊到它连接的各个 query-scheduler或 query-frontend上。如果配置值小于 querier 连接的 query-scheduler 数量每条连接至少分到一个 worker实际 worker 数会高于配置值。所以在计算阈值之前先用loki_querier_worker_concurrency指标确认实际 worker 数。再确定最小副本数。至少运行一个 querier算出系统 75% 的时间内处理 inflight 请求的七天均值查询目标利用率是 75%。沿用每个 querier 6 个 worker 的例子查询为clamp_min(ceil( avg( avg_over_time(loki_query_scheduler_inflight_requests{namespaceloki-cluster, quantile0.75}[7d]) ) / scalar(floor(vector(6 * 0.75))) ), 1)然后确定最大副本数。最大副本数等于在七天内 50% 的时间里处理全部 inflight 请求所需的 querier 数同样按每个 querier 6 个 worker 计算ceil( max( max_over_time(loki_query_scheduler_inflight_requests{namespaceloki-cluster, quantile0.5}[7d]) ) / 6 )最后设置缩容稳定窗口尽量避免 Loki 刚缩容就紧接着扩容。配置 KEDAHelm chart 路径或手写 ScaledObject用 Helm chart 部署 Loki让 chart 生成 ScaledObject如果你用 Helm chart 部署 Loki不需要自己写 KEDA ScaledObject。chart 可以替你生成一个querier.kedaAutoscaling的默认值已经是一个基于loki_query_scheduler_inflight_requests的 Prometheus 触发器默认 Q 为 0.75、R 为 2 分钟且默认阈值threshold为4即按 6 个 worker、75% 利用率计算的值。需要做的是将querier.kedaAutoscaling.enabled设为true按你的容量规划结果设置minReplicas和maxReplicaschart 默认最小 1、最大 10需要按上面的 7 天查询结果覆盖设置defaults.kedaAutoscaling.prometheusAddress为你的 Prometheus 服务地址。这一项默认为空不设置的话触发器无法查询到指标如果想替换默认触发器设置querier.kedaAutoscaling.triggers。完整的 values 列表见仓库内 Helm reference 文档 docs/sources/setup/install/helm/reference.md其中querier.kedaAutoscaling一段还包含behavior对应 ScaledObject 的horizontalPodAutoscalerConfig.behavior、cooldownPeriod、fallback、pollingInterval等可调项defaults.kedaAutoscaling下另有customHeaders多租户场景可用来带X-Scope-OrgID、unsafeSsl、ignoreNullValues、authentication等字段。另外注意kedaAutoscaling.enabled与autoscaling.enabled互斥两者只能启用其一。不用 Helm chart手写 ScaledObject不使用 Helm chart或需要 chart 不支持的触发器时自己写ScaledObject。下面这个示例把自动伸缩配置在loki-cluster命名空间的 querier Deployment 上最小副本 10、最大副本 50。每个 querier 运行 6 个 worker目标是用掉 75%所以阈值设为 4指标从http://prometheus.default:9090/prometheus获取并配置了 30 分钟的缩容稳定窗口apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: querier namespace: loki-cluster spec: maxReplicaCount: 50 minReplicaCount: 10 scaleTargetRef: kind: Deployment name: querier triggers: - metadata: metricName: querier_autoscaling_metric query: sum(max_over_time(loki_query_scheduler_inflight_requests{namespaceloki-cluster, quantile0.75}[2m])) serverAddress: http://prometheus.default:9090/prometheus threshold: 4 type: prometheus advanced: horizontalPodAutoscalerConfig: behavior: scaleDown: stabilizationWindowSeconds: 1800按你自己的部署替换其中的命名空间、Deployment 名、Prometheus 地址、副本数上下限和阈值其余结构与文档示例一致。验证与容量告警副本数长期打满时报警伸缩生效与否可以从 HPA 状态判断配置的副本数上限可能不够用所以文档给出一条 Prometheus 告警用来识别 querier 副本数在配置的最大值上停留过久的情况。示例把“过久”定为 3 小时3hname: LokiAutoscalerMaxedOut expr: kube_horizontalpodautoscaler_status_current_replicas{namespace~loki-cluster} kube_horizontalpodautoscaler_spec_max_replicas{namespace~loki-cluster} for: 3h labels: severity: warning annotations: description: HPA {{ $labels.namespace }}/{{ $labels.horizontalpodautoscaler }} has been running at max replicas for longer than 3h; this can indicate underprovisioning. summary: HPA has been running at max replicas for an extended time如果这条告警触发说明最大副本数不足以吸收负载需要回到容量规划一节重新用 7 天数据评估maxReplicas。边界与限制该方案只适用于 microservices 模式 query-scheduler 的部署单二进制部署不适用。查询loki_query_scheduler_inflight_requests时 quantile 只能取文档列出的固定值0.5、0.75、0.8、0.9、0.95、0.99否则查不到数据。计算阈值前必须用loki_querier_worker_concurrency核对实际 worker 数因为连接数多于max_concurrent配置时实际 worker 会更多。Helm 路径下prometheusAddress为空时触发器不工作这是最容易漏配的一项。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Loki 如何用 KEDA 基于调度器队列指标自动伸缩 Querier？
Loki 如何用 KEDA 基于调度器队列指标自动伸缩 Querier【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/lokiLoki 的 querier 会整天面对波动明显的查询负载。如果你的 Loki 以 microservices 模式部署在 Kubernetes 上且启用了 query-scheduler可以用 KEDA 监听调度器的队列指标来自动伸缩 querier 副本数让查询高峰期有足够 worker 消费队列低谷期又不会白占资源。前提条件有三个Loki 以一组 microservices 的形式运行在 Kubernetes 中使用了 query-schedulerquerier 从它的队列里拉取查询集群中已部署 KEDAKubernetes Event-Driven AutoscalingLoki 官方推荐用 KEDA 基于 Prometheus 指标做自动伸缩。注意 KEDA 本身的安装部署是 KEDA 项目的文档范畴本文不展开。伸缩依据loki_query_scheduler_inflight_requests因为查询是从 query-scheduler 的队列里拉取后在 querier worker 上执行的所以伸缩指标应基于两点调度器队列里排队的查询数加上 querier worker 中正在执行的查询数。query-scheduler 暴露的loki_query_scheduler_inflight_requests指标正好把这两者加在一起追踪。文档给出的伸缩查询是sum( max_over_time( loki_query_scheduler_inflight_requests{namespaceloki-cluster, quantileQ}[R] ) )其中Q和R是需要按你的负载微调的参数Q 是取哪个分位数。Q 越高指标对短时尖峰越敏感。R 是回溯窗口range。R 越大指标随时间波动越小能避免 autoscaler 过于频繁地调整副本数。Loki 文档建议 Q 取 0.75、R 取 2 分钟。有两个约束需要注意该指标只暴露固定的分位数值0.5、0.75、0.8、0.9、0.95、0.99。查询其他分位值时 Prometheus 不返回任何数据Q 必须从这份列表里选。指标本身在被 Prometheus 抓取前已经在一个 60 秒的滑动窗口上做过平滑所以 R 小于约一分钟几乎没有额外平滑效果。文档建议 R 保持一分钟或更高。容量规划确定副本数上下限和阈值配置伸缩前需要定四个值伸缩上下限的阈值、缩容稳定期、querier 副本数的最小值和最大值。先确定单个 querier 的 worker 数。querier worker 处理队列中的查询每个 querier 可以用-querier.max-concurrent标志YAML 配置里是max_concurrent设置 worker 数默认值是4。文档建议为了留出应对负载尖峰的余量不要使用超过 75% 的 worker伸缩阈值相应设置为floor(0.75 * worker数)。例如每个 querier 配置 6 个 worker阈值就是floor(0.75 * 6) 4。这里有一个容易踩坑的细节-querier.max-concurrent设置的是 querier 的 worker 总数但 querier 会把 worker 分摊到它连接的各个 query-scheduler或 query-frontend上。如果配置值小于 querier 连接的 query-scheduler 数量每条连接至少分到一个 worker实际 worker 数会高于配置值。所以在计算阈值之前先用loki_querier_worker_concurrency指标确认实际 worker 数。再确定最小副本数。至少运行一个 querier算出系统 75% 的时间内处理 inflight 请求的七天均值查询目标利用率是 75%。沿用每个 querier 6 个 worker 的例子查询为clamp_min(ceil( avg( avg_over_time(loki_query_scheduler_inflight_requests{namespaceloki-cluster, quantile0.75}[7d]) ) / scalar(floor(vector(6 * 0.75))) ), 1)然后确定最大副本数。最大副本数等于在七天内 50% 的时间里处理全部 inflight 请求所需的 querier 数同样按每个 querier 6 个 worker 计算ceil( max( max_over_time(loki_query_scheduler_inflight_requests{namespaceloki-cluster, quantile0.5}[7d]) ) / 6 )最后设置缩容稳定窗口尽量避免 Loki 刚缩容就紧接着扩容。配置 KEDAHelm chart 路径或手写 ScaledObject用 Helm chart 部署 Loki让 chart 生成 ScaledObject如果你用 Helm chart 部署 Loki不需要自己写 KEDA ScaledObject。chart 可以替你生成一个querier.kedaAutoscaling的默认值已经是一个基于loki_query_scheduler_inflight_requests的 Prometheus 触发器默认 Q 为 0.75、R 为 2 分钟且默认阈值threshold为4即按 6 个 worker、75% 利用率计算的值。需要做的是将querier.kedaAutoscaling.enabled设为true按你的容量规划结果设置minReplicas和maxReplicaschart 默认最小 1、最大 10需要按上面的 7 天查询结果覆盖设置defaults.kedaAutoscaling.prometheusAddress为你的 Prometheus 服务地址。这一项默认为空不设置的话触发器无法查询到指标如果想替换默认触发器设置querier.kedaAutoscaling.triggers。完整的 values 列表见仓库内 Helm reference 文档 docs/sources/setup/install/helm/reference.md其中querier.kedaAutoscaling一段还包含behavior对应 ScaledObject 的horizontalPodAutoscalerConfig.behavior、cooldownPeriod、fallback、pollingInterval等可调项defaults.kedaAutoscaling下另有customHeaders多租户场景可用来带X-Scope-OrgID、unsafeSsl、ignoreNullValues、authentication等字段。另外注意kedaAutoscaling.enabled与autoscaling.enabled互斥两者只能启用其一。不用 Helm chart手写 ScaledObject不使用 Helm chart或需要 chart 不支持的触发器时自己写ScaledObject。下面这个示例把自动伸缩配置在loki-cluster命名空间的 querier Deployment 上最小副本 10、最大副本 50。每个 querier 运行 6 个 worker目标是用掉 75%所以阈值设为 4指标从http://prometheus.default:9090/prometheus获取并配置了 30 分钟的缩容稳定窗口apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: querier namespace: loki-cluster spec: maxReplicaCount: 50 minReplicaCount: 10 scaleTargetRef: kind: Deployment name: querier triggers: - metadata: metricName: querier_autoscaling_metric query: sum(max_over_time(loki_query_scheduler_inflight_requests{namespaceloki-cluster, quantile0.75}[2m])) serverAddress: http://prometheus.default:9090/prometheus threshold: 4 type: prometheus advanced: horizontalPodAutoscalerConfig: behavior: scaleDown: stabilizationWindowSeconds: 1800按你自己的部署替换其中的命名空间、Deployment 名、Prometheus 地址、副本数上下限和阈值其余结构与文档示例一致。验证与容量告警副本数长期打满时报警伸缩生效与否可以从 HPA 状态判断配置的副本数上限可能不够用所以文档给出一条 Prometheus 告警用来识别 querier 副本数在配置的最大值上停留过久的情况。示例把“过久”定为 3 小时3hname: LokiAutoscalerMaxedOut expr: kube_horizontalpodautoscaler_status_current_replicas{namespace~loki-cluster} kube_horizontalpodautoscaler_spec_max_replicas{namespace~loki-cluster} for: 3h labels: severity: warning annotations: description: HPA {{ $labels.namespace }}/{{ $labels.horizontalpodautoscaler }} has been running at max replicas for longer than 3h; this can indicate underprovisioning. summary: HPA has been running at max replicas for an extended time如果这条告警触发说明最大副本数不足以吸收负载需要回到容量规划一节重新用 7 天数据评估maxReplicas。边界与限制该方案只适用于 microservices 模式 query-scheduler 的部署单二进制部署不适用。查询loki_query_scheduler_inflight_requests时 quantile 只能取文档列出的固定值0.5、0.75、0.8、0.9、0.95、0.99否则查不到数据。计算阈值前必须用loki_querier_worker_concurrency核对实际 worker 数因为连接数多于max_concurrent配置时实际 worker 会更多。Helm 路径下prometheusAddress为空时触发器不工作这是最容易漏配的一项。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
