介紹

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

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

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

為什么我們需要 autoscaling

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

1、它會適當地擴展 querier 以響應工作量的增加。

2、我們可能會過度配置集群并使 querier 閑置一段時間。

3、這會導致操作繁瑣 (https://sre.google/sre-book/eliminating-toil/) ，因為我們必須手動上下擴展 querier。

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

為什么選擇 KEDA

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

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

KEDA 是最初由 Microsoft 和 Red Hat 開發的開源項目，我們已經在內部將它用于與Grafana Mimir(https://grafana.com/oss/mimir/?pg=blog&plcmt=body-txt) 類似的用例。除了熟悉之外，我們之所以選擇它，是因為它更成熟，而且它允許根據來自不同來源（例如 Prometheus）的事件和指標擴展任何 Pod。KEDA 構建在 HPA 之上，并公開了一個新的 Kubernetes 指標服務器，該服務器為 KEDA 創建的 HPA 提供新指標。

我們如何在 queriers 上使用 KEDA

Queriers 從查詢調度程序隊列中提取查詢并在所有 querier 上處理它們。因此，根據以下條件進行擴展是有意義的：

• 調度程序隊列大小
• 在 querier 中運行的查詢

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

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

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

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

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

這個等式定義了當前副本中所需的副本數、度量值以及我們配置的閾值：

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

例如，如果我們有一個副本和 20 個正在進行的請求，并且我們的目標是使用每個 worker 可用的六個 worker 中的 75%（四個），那么新的所需副本數量將是五個。

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

考慮到這一點，我們現在可以創建 KEDA ScaledObject 來控制查詢器的自動縮放。以下資源定義將 KEDA 配置為從 http://prometheus.default:9090/prometheus 提取指標。它還可以擴展到最大 50 個 querier，縮小到最小 10 個 querier，將 75% 用于 inflight requests 指標，并在兩分鐘內聚合其最大值。擴展閾值仍然是每個 querier 四個 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 進行測試

在部署到我們的內部和生產環境之前，我們進行了多次實驗和基準測試來驗證。

Grafana k6 Cloud 是 Grafana k6 的完全托管版本，它是一個免費、開源、以開發人員為中心且可擴展的負載測試工具，可讓工程團隊輕松進行性能測試。

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

1、在兩分鐘內，將 VU 從 5 個增加到 50 個。

2、用 50 個 VU 保持一分鐘。

3、在 30 秒內從 50 個 VU 增加到 100 個 VU，并在另外 30 秒內增加到 50 個，以創建工作負載峰值。

4、重復上一個尖峰。

5、最后，在兩分鐘內從 50 個 VU 變為零。

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

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

隨著 inflight request 數量的增加（頂部），querier 的數量增加（底部）。在工作負載減少后的某個時間，querier 的數量也會減少。

一旦我們確認我們的方法按預期工作，下一步就是在一些實際工作負載上進行嘗試。

部署和微調

為了驗證我們的實現是否滿足我們在真實場景中的需求，我們在內部環境中部署了自動縮放器。到目前為止，我們已經在 k6 創建所有工作負載的隔離環境中進行了實驗。接下來，我們必須估計最大和最小副本數的適當值。

對于最小副本數，我們在前 7 天 75% 的時間內檢查了平均 inflight request，目標是 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)

對于最大副本數，我們將當前副本數與在前 7 天內處理 50% 的 inflight request 所需的查詢器數相結合。由于每個 querier 運行六個 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)

在估計了最小和最大副本的一些數字后，我們在內部環境中部署了自動縮放器。如下圖所示，我們實現了預期的結果：querier 隨著工作負載的增加而擴大，在工作負載減少后縮小。

隨著我們部署中 inflight request 數量的增加（頂部），querier 的數量增加（底部）。當 worker 減少時，querier 的數量也會減少。

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

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

下圖顯示了圖表的形狀現在在副本數量方面如何更加統一。在某些情況下，querier 在縮小后不久就會擴大規模，但總會有邊緣情況發生這種情況。我們仍然需要為這個參數找到一個適合我們工作負載形狀的好值，但總的來說，我們可以看到峰值更少。

配置穩定窗口后，與上圖相似的工作負載相比，副本數量波動較小。

即使我們配置的最大副本數比手動擴展 Loki 時要高得多，但添加自動擴展程序后的平均副本數會更低。較低的平均副本數轉化為較低的查詢器部署的擁有成本。 

啟用查詢器自動縮放器后，集群中運行的平均副本數減少了。

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

啟用查詢器自動縮放器后，查詢延遲并沒有變差。

最后，我們需要一種方法來知道何時增加我們的最大副本數。為此，我們創建了一個警報，當自動縮放器長時間以配置的最大副本數運行時觸發。以下代碼片段包含此指標，如果它在至少三個小時內輸出為 true，則會觸發。

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/