查询前端示例

免责声明

这是一个通用示例；要使其正常工作，需要进行一些替换。这些变量采用 <variable_name> 的形式。您应该根据您的环境具体情况进行覆盖。

用例

刚开始尝试 Grafana Loki 时，为了简化部署并推迟学习（起初非必要的）细节，通常会将其作为单个二进制文件运行。随着我们对其范例越来越熟悉并开始迁移到更适合生产环境的部署，有一些事项需要注意。常见的瓶颈出现在读路径：在小数据集上轻松执行的查询可能会在较大数据集上停滞不前。有时我们可以通过增加查询器来解决这个问题。但是，当查询对于单个查询器来说太大而无法执行时，这并无帮助。这时我们就需要查询前端。

并行化

查询前端最重要的功能之一是能够将大型查询分解为更小的查询，并行执行它们，然后将结果重新组合起来。分解的频率由 `querier.split-queries-by-interval` 标志或 yaml 配置 `query_range.split_queriers_by_interval` 决定。如果将其设置为 `1h`，前端会将一个持续一天的查询分解为 24 个每小时的查询，将其分发给查询器，并收集结果。这在生产环境中非常有帮助，因为它不仅允许我们通过聚合执行大型查询，还能使查询器之间的工作分配更加均匀，避免一两个查询器因处理过大的查询而卡住，而其他查询器却处于空闲状态。

Kubernetes 部署

ConfigMap

使用此 ConfigMap 可利用 query-frontend 组件实现查询并行化和缓存的优势。

apiVersion: v1
kind: ConfigMap
metadata:
  name: loki-frontend
  namespace: <namespace>
data:
  config.yaml: |
    # Disable the requirement that every request to Loki has a
    # X-Scope-OrgID header. `fake` will be substituted in instead.
    auth_enabled: false

    # We don't want the usual /api/prom prefix.
    http_prefix:

    server:
      http_listen_port: 3100

    query_range:
      # make queries more cache-able by aligning them with their step intervals
      align_queries_with_step: true
      max_retries: 5
      cache_results: true

      results_cache:
        cache:
          # We're going to use the embedded cache
          embedded_cache:
            enabled: true
            max_size_mb: 100
            ttl: 24h

    limits_config:
      max_cache_freshness_per_query: '10m'
      # parallelize queries in 15min intervals
      split_queries_by_interval: 15m

    frontend:
      log_queries_longer_than: 5s
      downstream_url: http://querier.<namespace>.svc.cluster.local:3100
      compress_responses: true

前端服务

apiVersion: v1
kind: Service
metadata:
  annotations:
  labels:
    name: query-frontend
  name: query-frontend
  namespace: <namespace>
spec:
  ports:
    - name: query-frontend-http
      port: 3100
      protocol: TCP
      targetPort: 3100
  selector:
    name: query-frontend
  sessionAffinity: None
  type: ClusterIP
  ClusterIP: None
  publishNotReadyAddresses: true

前端部署

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    name: query-frontend
  name: query-frontend
  namespace: <namespace>
spec:
  minReadySeconds: 10
  replicas: 2
  selector:
    matchLabels:
      name: query-frontend
  template:
    metadata:
      labels:
        name: query-frontend
    spec:
      containers:
        - args:
            - -config.file=/etc/loki/config.yaml
            - -log.level=debug
            - -target=query-frontend
          image: grafana/loki:latest
          imagePullPolicy: Always
          name: query-frontend
          ports:
            - containerPort: 3100
              name: http
              protocol: TCP
          resources:
            limits:
              memory: 1200Mi
            requests:
              cpu: '2'
              memory: 600Mi
          volumeMounts:
            - mountPath: /etc/loki
              name: loki-frontend
      restartPolicy: Always
      terminationGracePeriodSeconds: 30
      volumes:
        - configMap:
            defaultMode: 420
            name: loki-frontend
          name: loki-frontend

Grafana

部署这些组件后，将您的 Grafana 数据源指向新的前端服务。该服务在集群内可通过 http://query-frontend.<namespace>.svc.cluster.local:3100 访问。

GRPC 模式（拉取模型）

查询前端有两种工作模式

指定 --frontend.downstream-url 或其等效的 YAML 配置 frontend.downstream_url。这将通过 HTTP 将请求代理到指定的 URL。
如果没有 --frontend.downstream-url 或其等效的 YAML 配置 frontend.downstream_url，查询前端默认为拉取服务。作为拉取服务，前端会为每个租户实例化一个队列，下游查询器通过 GRPC 从这些队列中拉取查询。要作为拉取服务运行，查询器需要指定 -querier.frontend-address 或其等效的 YAML 配置 frontend_worker.frontend_address。
将查询前端拉取服务的 ClusterIP 设置为 None。这将导致 DNS 解析每个查询前端 pod 的 IP 地址，避免错误地解析到服务 IP。
在查询前端拉取服务上启用 publishNotReadyAddresses=true。这样做可以消除一个竞态条件：当至少有一个查询器连接时，在查询前端准备好之前就需要其地址。