Thanos Querier 组件

query

---

thanos query其实就是查询入口，之前查询prometheus 客户端不再去查询promethues，而是经过thanos query，query再去查询后端其他的数据，它其实抽象了内部的store api的grpc接口，再去调用实现store api的组件，然后将数据汇聚到一起，然后再去做一些聚合，去重，最终呈现给客户端的就是完整的结果。

query与sidecar

---

 sidecar可以去读取Prometheus时序数据库当中的数据，暴露store api接口，query就会去调用这个接口获取数据，然后sidecar就去Prometheus当中查询数据，最后将各个Prometheus当中的数据做汇总，去重。

这样屏蔽了一些细节，如不需要知道背后有多少个Prometheus，客户端只需要知道query的地址就能够拿到完整的数据。

​​​​​​​

sidecar上传对象存储

---

sidecar不仅可以读取Prometheus当中的数据，还可以将Prometheus当中的数据上传到对象存储

sidecar有一个很重要的功能，就是数据的长期保存，因为Prometheus本身它磁盘空间是有限的，不可能无限的增长，如果需要查询数据就需要将数据备份到远端的存储当中，这样就可以查看久远的数据，而且对象存储是比较廉价的，最适合存储长期保存的数据。

Querier 组件

---

现在我们就创建成功了两个 Prometheus 实例，但是我们真正去使用的时候并不是像上面提到的在前面加一个负载均衡器去查询监控数据，而是使用 Thanos 的 Querier 组件来提供一个全局的统一查询入口。

对于 Quierier 最重要的就是要配置上 Thanos 的 Sidecar 地址，我们这里完全可以直接使用 Headless Service 去自动发现：

由于query是无状态的，所以可以去部署多个实例去保证query组件的高可用 

# thanos-querier.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: thanos-querier
  namespace: kube-mon
  labels:
    app: thanos-querier
spec:
  replicas: 2
  selector:
    matchLabels:
      app: thanos-querier
  template:
    metadata:
      labels:
        app: thanos-querier
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                topologyKey: kubernetes.io/hostname
                labelSelector:
                  matchExpressions:
                    - key: app
                      operator: In
                      values:
                        - thanos-querier
      containers:
        - name: thanos
          image: thanosio/thanos:v0.25.1
          args:
            - query
            - --log.level=debug
            - --query.replica-label=replica  //需要根据replica: $(POD_NAME)这个标签，去对我们的数据做个去重
            # Discover local store APIs using DNS SRV.
            - --store=dnssrv+thanos-store-gateway:10901
          ports:
            - name: http
              containerPort: 10902
            - name: grpc
              containerPort: 10901
          resources:
            requests:
              memory: 512Mi
              cpu: 500m
            limits:
              memory: 512Mi
              cpu: 500m
          livenessProbe:
            httpGet:
              path: /-/healthy
              port: http
            initialDelaySeconds: 10
          readinessProbe:
            httpGet:
              path: /-/healthy
              port: http
            initialDelaySeconds: 15
---
apiVersion: v1
kind: Service
metadata:
  name: thanos-querier
  namespace: kube-mon
  labels:
    app: thanos-querier
spec:
  ports:
    - port: 9090
      targetPort: http
      name: http
  selector:
    app: thanos-querier
  type: NodePort

- --query.replica-label=replica  //需要根据replica: $(POD_NAME)这个标签，去对我们的数据做个去重（在之前sidecar里面配置了）

如何发现我们要查询的数据呢？容器中的参数 --store=dnssrv+thanos-store-gateway:10901 可以帮助自动发现可以查询指标数据的所有组件（统一使用之前的headless service就可以发现所有实现了store-api的pod，有sidecar组件的，有store组件的）

  template:
    metadata:
      labels:
        app: prometheus
        thanos-store-api: "true"

          ports:
            - name: http-sidecar
              containerPort: 10902
            - name: grpc
              containerPort: 10901


# 该服务为 querier 创建 srv 记录，以便查找 store-api 的信息
apiVersion: v1
kind: Service
metadata:
  name: thanos-store-gateway
  namespace: kube-mon
spec:
  type: ClusterIP
  clusterIP: None
  ports:
    - name: grpc
      port: 10901
      targetPort: grpc
  selector:
    thanos-store-api: "true"

然后创建一个 thanos-querier 的 Serivce 对象可以来提供一个运行 PromQL 的 web 页面，也提供了一个是否对不同集群数据进行去重的入口。直接创建上面的对象：

☸ ➜ kubectl apply -f https://p8s.io/docs/thanos/manifests/thanos-querier.yaml
☸ ➜ kubectl get pods -n kube-mon -l app=thanos-querier
NAME                             READY   STATUS    RESTARTS   AGE
thanos-querier-cf566866b-r4jcj   1/1     Running   0          3m26s
☸ ➜ kubectl get svc -n kube-mon -l app=thanos-querier
NAME             TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
thanos-querier   NodePort   10.110.193.50   <none>        9090:31278/TCP   5m11s

部署完成后我们就可以通过 http://<任意节点IP>:31278 去访问 Querier 了，在 Stores 页面下面就会显示通过服务发现获取到的 Sidecar 信息：

实际上这里展现的就是query对接实现了store api的pod，这里对接上的sidecar，sidecar实现了api，也就是query这个组件查询的所有数据都来源于sidecar，sidecar会将数据代理到本地的prometheus-0或者prometheus-1里面

在 Graph 页面下同样可以去使用 PromQL 语句来查询监控信息，这个页面和 Prometheus 原生的页面几乎是一致的，比如我们查询 master 节点的负载信息：

这里我没有勾上 deduplication，所以 Thanos 不会帮我合并数据，所以能够看到 prometheus-0 和 prometheus-1 两条数据，因为我们有两个副本去抓取监控数据。

如果将 deduplication 选中，结果会根据 replica 这个标签进行合并，如果两个副本都有对应的数据，Querier 会取 timestamp 更小的结果：

当然这个时候我们在前面章节中 Grafana 里面配置的 Prometheus 的数据源也就失效了，因为现在监控数据的来源是 Thanos Querier，所以我们需要重新配置 Prometheus 的数据源地址为 http://thanos-querier:9090：

之前的监控图表也可以正常显示了：这些数据都是通过thanos获取的，后面对接的是两个Prometheus实例，因为有两个Prometheus那么实现了高可用，query在thanos当中充当了非常重要的作用，提供了全局的统一入口，帮我们做去重。

现在数据都是从sidecar里面去获取的，默认2个小时之内的数据存储在本地TSDB的块里面，sidecar会将TSDB块上传到对象存储，也就是本地只存储2个小时的数据，或者6个小时的数据，如果要查询历史的数据，那么就需要走对象存储了。