介紹

Grafana Loki (https://grafana.com/oss/loki/?pg=blog&plcmt=body-txt) 是 Grafana Labs 的開源日志聚合系統(tǒng)，靈感來自 Prometheus(https://prometheus.io/) 。Loki 具有水平可擴(kuò)展性、高可用性和多租戶特性。

Grafana Cloud 大規(guī)模運(yùn)營 Grafana Cloud Logs，集群分布在不同的區(qū)域和云平臺(tái)，如 AWS、Microsoft Azure 和 Google Cloud。Grafana Cloud 每天還攝取數(shù)百 TB 的數(shù)據(jù)，并在數(shù)千個(gè)租戶中查詢數(shù) PB 的數(shù)據(jù)。最重要的是，每天數(shù)據(jù)查詢與處理過程中，資源消耗都會(huì)有很大的波動(dòng)，這使得以對用戶響應(yīng)且對 Grafana Cloud 來說具有成本效益的方式手動(dòng)擴(kuò)展集群變得非常困難。 

在這篇博客中，我們將描述 Grafana Labs 的工程師如何使用基于 Kubernetes 的事件驅(qū)動(dòng)自動(dòng)縮放器 ( KEDA(https://keda.sh/) ) 來更好地處理后端的 Loki 查詢。

為什么我們需要 autoscaling

負(fù)責(zé)處理 Grafana Cloud Logs 查詢的 Loki 讀取路徑組件之一是 querier，它是將 LogQL(https://grafana.com/docs/loki/latest/logql/?pg=blog&plcmt=body-txt) 查詢與日志匹配的組件?？梢韵胂?，我們需要很多 querier 來實(shí)現(xiàn)如此高的吞吐量。但是，由于我們的集群全天工作負(fù)載發(fā)生重大變化，這種需求會(huì)發(fā)生波動(dòng)。直到最近，我們還是根據(jù)工作負(fù)載手動(dòng)擴(kuò)展 querier，但這種方法存在三個(gè)主要問題。

1、它會(huì)適當(dāng)?shù)財(cái)U(kuò)展 querier 以響應(yīng)工作量的增加。

2、我們可能會(huì)過度配置集群并使 querier 閑置一段時(shí)間。

3、這會(huì)導(dǎo)致操作繁瑣 (https://sre.google/sre-book/eliminating-toil/) ，因?yàn)槲覀儽仨毷謩?dòng)上下擴(kuò)展 querier。

為了克服這些問題，我們決定在 Kubernetes 中的 querier 部署中添加自動(dòng)縮放功能。

為什么選擇 KEDA

Kubernetes 附帶了一個(gè)用于水平自動(dòng)縮放 Pod 的內(nèi)置解決方案：HorizontalPodAutoscaler ( HPA)。您可以使用 HPA 根據(jù)來自 Kubernetes metrics-server(https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server) 的指標(biāo)為 StatefulSets 和 Deployments 等組件配置自動(dòng)縮放。metrics-server 公開 pod 的 CPU 和內(nèi)存使用情況，但如果需要，您可以為其提供更多指標(biāo)。

CPU 和內(nèi)存使用指標(biāo)通常足以決定何時(shí)擴(kuò)大或縮小規(guī)模，但可能還有其他指標(biāo)或事件需要考慮。在我們的案例中，我們對基于一些 Prometheus 指標(biāo)的擴(kuò)展感興趣。從 Kubernetes 1.23 開始，HPA 已經(jīng)支持外部指標(biāo)(https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#scaling-on-custom-metrics) ，所以我們可以選擇一個(gè) Prometheus adapter 來根據(jù) Prometheus 指標(biāo)進(jìn)行擴(kuò)展。然而，KEDA 使這變得更加容易。

KEDA 是最初由 Microsoft 和 Red Hat 開發(fā)的開源項(xiàng)目，我們已經(jīng)在內(nèi)部將它用于與Grafana Mimir(https://grafana.com/oss/mimir/?pg=blog&plcmt=body-txt) 類似的用例。除了熟悉之外，我們之所以選擇它，是因?yàn)樗墒欤宜试S根據(jù)來自不同來源（例如 Prometheus）的事件和指標(biāo)擴(kuò)展任何 Pod。KEDA 構(gòu)建在 HPA 之上，并公開了一個(gè)新的 Kubernetes 指標(biāo)服務(wù)器，該服務(wù)器為 KEDA 創(chuàng)建的 HPA 提供新指標(biāo)。

我們?nèi)绾卧?queriers 上使用 KEDA

Queriers 從查詢調(diào)度程序隊(duì)列中提取查詢并在所有 querier 上處理它們。因此，根據(jù)以下條件進(jìn)行擴(kuò)展是有意義的：

• 調(diào)度程序隊(duì)列大小
• 在 querier 中運(yùn)行的查詢

最重要的是，我們希望避免因短期工作負(fù)載高峰而擴(kuò)大規(guī)模。在這些情況下，查詢可能會(huì)比擴(kuò)展所需的時(shí)間更快地處理工作負(fù)載。

考慮到這一點(diǎn)，我們根據(jù)排隊(duì)查詢的數(shù)量加上正在運(yùn)行的查詢進(jìn)行擴(kuò)展。我們稱這些為 inflight requests。查詢調(diào)度程序組件將公開一個(gè)新指標(biāo) ，cortex_query_scheduler_inflight_requests 指標(biāo)結(jié)果使用百分比(https://grafana.com/blog/2022/03/01/how-summary-metrics-work-in-prometheus/?pg=blog&plcmt=body-txt) 跟蹤正在進(jìn)行的請求。通過使用百分比，我們可以避免在指標(biāo)出現(xiàn)短期峰值時(shí)進(jìn)行擴(kuò)容。

使用結(jié)果度量，我們可以在查詢中使用分位數(shù) (Q) 和范圍 (R) 參數(shù)來微調(diào)我們的縮放。Q 越高，指標(biāo)對短期尖峰越敏感。隨著 R 的增加，我們會(huì)隨著時(shí)間的推移減少度量變化。較高的 R 值有助于防止自動(dòng)縮放器過于頻繁地修改副本數(shù)量。

sum(
max_over_time(
  cortex_query_scheduler_inflight_requests{namespace="%s", quantile="<Q>"}[<R>]
)
)

然后我們需要設(shè)置一個(gè)閾值，以便我們可以根據(jù)度量值計(jì)算所需的副本數(shù)。Querier 程序處理來自隊(duì)列的查詢，每個(gè) querier 配置為運(yùn)行六個(gè) worker。我們希望為高峰留出一些富余處理空間，因此我們的目標(biāo)是使用這些 worker 中的 75%。因此，我們的門檻將是每個(gè) querier 6 個(gè) worker 的 75%，即 4 個(gè) worker。

這個(gè)等式定義了當(dāng)前副本中所需的副本數(shù)、度量值以及我們配置的閾值：

desiredReplicas = ceil[currentReplicas * ( currentMetricValue / threshold )]

例如，如果我們有一個(gè)副本和 20 個(gè)正在進(jìn)行的請求，并且我們的目標(biāo)是使用每個(gè) worker 可用的六個(gè) worker 中的 75%（四個(gè)），那么新的所需副本數(shù)量將是五個(gè)。

desiredReplicas = ceil[1 * (20 / 4)] = 5

考慮到這一點(diǎn)，我們現(xiàn)在可以創(chuàng)建 KEDA ScaledObject 來控制查詢器的自動(dòng)縮放。以下資源定義將 KEDA 配置為從 http://prometheus.default:9090/prometheus 提取指標(biāo)。它還可以擴(kuò)展到最大 50 個(gè) querier，縮小到最小 10 個(gè) querier，將 75% 用于 inflight requests 指標(biāo)，并在兩分鐘內(nèi)聚合其最大值。擴(kuò)展閾值仍然是每個(gè) querier 四個(gè) worker。

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: querier
namespace: <REDACTED INTERNAL DEV ENV>
spec:
maxReplicaCount: 50
minReplicaCount: 10
pollingInterval: 30
scaleTargetRef:
  kind: Deployment
  name: querier
triggers:
- metadata:
    metricName: querier_autoscaling_metric
    query: sum(max_over_time(cortex_query_scheduler_inflight_requests{namespace=~"REDACTED", quantile="0.75"}[2m]))
    serverAddress: http://prometheus.default:9090/prometheus
    threshold: "4"
  type: prometheus

使用 Grafana k6 Cloud 進(jìn)行測試

在部署到我們的內(nèi)部和生產(chǎn)環(huán)境之前，我們進(jìn)行了多次實(shí)驗(yàn)和基準(zhǔn)測試來驗(yàn)證。

Grafana k6 Cloud 是 Grafana k6 的完全托管版本，它是一個(gè)免費(fèi)、開源、以開發(fā)人員為中心且可擴(kuò)展的負(fù)載測試工具，可讓工程團(tuán)隊(duì)輕松進(jìn)行性能測試。

使用 k6 的 Grafana Loki 擴(kuò)展(https://grafana.com/blog/2022/06/08/a-quick-guide-to-load-testing-grafana-loki-with-grafana-k6/?pg=blog&plcmt=body-txt) ，我們創(chuàng)建了一個(gè) k6 測試 (https://gist.github.com/salvacorts/7f6fe8e53dcbdfc38606f3892918cfcc) ，該測試迭代地從多個(gè)虛擬用戶（VU；有效的運(yùn)行線程）向 Loki 開發(fā)集群發(fā)送不同類型的查詢。我們嘗試使用以下序列模擬真實(shí)的可變流量：

1、在兩分鐘內(nèi)，將 VU 從 5 個(gè)增加到 50 個(gè)。

2、用 50 個(gè) VU 保持一分鐘。

3、在 30 秒內(nèi)從 50 個(gè) VU 增加到 100 個(gè) VU，并在另外 30 秒內(nèi)增加到 50 個(gè)，以創(chuàng)建工作負(fù)載峰值。

4、重復(fù)上一個(gè)尖峰。

5、最后，在兩分鐘內(nèi)從 50 個(gè) VU 變?yōu)榱恪?/p>

在下圖中，我們可以看到測試在 k6 Cloud 中的表現(xiàn)，以及在測試期間進(jìn)行中的請求和查詢器副本的數(shù)量如何變化。首先，querier 會(huì)隨著工作負(fù)載的增加而擴(kuò)大，最后，querier 會(huì)在測試完成幾分鐘后回退。

一個(gè) Grafana k6 Cloud 測試，它迭代地將不同類型的查詢發(fā)送到 Grafana Loki 開發(fā)集群。

隨著 inflight request 數(shù)量的增加（頂部），querier 的數(shù)量增加（底部）。在工作負(fù)載減少后的某個(gè)時(shí)間，querier 的數(shù)量也會(huì)減少。

一旦我們確認(rèn)我們的方法按預(yù)期工作，下一步就是在一些實(shí)際工作負(fù)載上進(jìn)行嘗試。

部署和微調(diào)

為了驗(yàn)證我們的實(shí)現(xiàn)是否滿足我們在真實(shí)場景中的需求，我們在內(nèi)部環(huán)境中部署了自動(dòng)縮放器。到目前為止，我們已經(jīng)在 k6 創(chuàng)建所有工作負(fù)載的隔離環(huán)境中進(jìn)行了實(shí)驗(yàn)。接下來，我們必須估計(jì)最大和最小副本數(shù)的適當(dāng)值。

對于最小副本數(shù)，我們在前 7 天 75% 的時(shí)間內(nèi)檢查了平均 inflight request，目標(biāo)是 querier 的利用率為 75%。

clamp_min(ceil(
  avg(
      avg_over_time(cortex_query_scheduler_inflight_requests{namespace=~"REDACTED", quantile="0.75"}[7d])
  ) / scalar(floor(vector(6 * 0.75)))
), 2)

對于最大副本數(shù)，我們將當(dāng)前副本數(shù)與在前 7 天內(nèi)處理 50% 的 inflight request 所需的查詢器數(shù)相結(jié)合。由于每個(gè) querier 運(yùn)行六個(gè) worker，我們將 inflight 中的請求除以六。

clamp_min(ceil(
  (
      max(
          max_over_time(cortex_query_scheduler_inflight_requests{namespace=~"REDACTED", quantile="0.5"}[7d])
      ) / 6
      >
      max (kube_deployment_spec_replicas{namespace=~"REDACTED", deployment="querier"})
  )
  or
  max(
      kube_deployment_spec_replicas{namespace=~"REDACTED", deployment="querier"}
  )
), 20)

在估計(jì)了最小和最大副本的一些數(shù)字后，我們在內(nèi)部環(huán)境中部署了自動(dòng)縮放器。如下圖所示，我們實(shí)現(xiàn)了預(yù)期的結(jié)果：querier 隨著工作負(fù)載的增加而擴(kuò)大，在工作負(fù)載減少后縮小。

隨著我們部署中 inflight request 數(shù)量的增加（頂部），querier 的數(shù)量增加（底部）。當(dāng) worker 減少時(shí)，querier 的數(shù)量也會(huì)減少。

您可能已經(jīng)注意到由于縮放指標(biāo)值的不斷變化，副本數(shù)量的頻繁波動(dòng)（也稱為抖動(dòng)）(https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping)  。如果您在擴(kuò)展大量 pod 后過早縮減它們，最終會(huì)消耗 Kubernetes 中的大量資源來調(diào)度 pod。此外，它可能會(huì)影響查詢延遲，因?yàn)槲覀冃枰?jīng)常啟動(dòng)新的 querier 來處理這些查詢。幸運(yùn)的是，HPA 提供了一種機(jī)制來配置穩(wěn)定窗口(https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#stabilization-window) 以減輕這些頻繁的波動(dòng)，正如您可能已經(jīng)猜到的那樣，KEDA 也是如此。spec.advanced.horizontalPodAutoscalerConfig.behavior.scaleDown.stabilizationWindowSeconds參數(shù)允許您在 0 秒（立即縮放）和 3,600 秒（一小時(shí)）之間配置冷卻時(shí)間，默認(rèn)值為 300 秒（五分鐘）。該算法很簡單：我們使用一個(gè)跨越配置時(shí)間的滑動(dòng)窗口，并將副本數(shù)設(shè)置為該時(shí)間范圍內(nèi)報(bào)告的最高數(shù)量。在我們的例子中，我們配置了一個(gè) 30 分鐘的穩(wěn)定窗口：

spec:
advanced:
  horizontalPodAutoscalerConfig:
    behavior:
      scaleDown:
        stabilizationWindowSeconds: 1800

下圖顯示了圖表的形狀現(xiàn)在在副本數(shù)量方面如何更加統(tǒng)一。在某些情況下，querier 在縮小后不久就會(huì)擴(kuò)大規(guī)模，但總會(huì)有邊緣情況發(fā)生這種情況。我們?nèi)匀恍枰獮檫@個(gè)參數(shù)找到一個(gè)適合我們工作負(fù)載形狀的好值，但總的來說，我們可以看到峰值更少。

配置穩(wěn)定窗口后，與上圖相似的工作負(fù)載相比，副本數(shù)量波動(dòng)較小。

即使我們配置的最大副本數(shù)比手動(dòng)擴(kuò)展 Loki 時(shí)要高得多，但添加自動(dòng)擴(kuò)展程序后的平均副本數(shù)會(huì)更低。較低的平均副本數(shù)轉(zhuǎn)化為較低的查詢器部署的擁有成本。 

啟用查詢器自動(dòng)縮放器后，集群中運(yùn)行的平均副本數(shù)減少了。

此外，我們可以看到自動(dòng)縮放器沒有出現(xiàn)查詢延遲下降的問題。下圖顯示了 7 月 21 日 12:00 UTC 在啟用自動(dòng)縮放之前和之后的查詢和范圍查詢的 p90 延遲（以秒為單位）。

啟用查詢器自動(dòng)縮放器后，查詢延遲并沒有變差。

最后，我們需要一種方法來知道何時(shí)增加我們的最大副本數(shù)。為此，我們創(chuàng)建了一個(gè)警報(bào)，當(dāng)自動(dòng)縮放器長時(shí)間以配置的最大副本數(shù)運(yùn)行時(shí)觸發(fā)。以下代碼片段包含此指標(biāo)，如果它在至少三個(gè)小時(shí)內(nèi)輸出為 true，則會(huì)觸發(fā)。

name: LokiAutoscalerMaxedOut
expr: kube_horizontalpodautoscaler_status_current_replicas{namespace=~"REDACTED"} == kube_horizontalpodautoscaler_spec_max_replicas{namespace=~"REDACTED"}
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

原文：https://grafana.com/blog/2022/10/20/how-to-autoscale-grafana-loki-queries-using-keda/