使用Prometheus进行Kubernetes监控-最终指南（第1部分

current_active_users.free_tier = 423current_active_users.premium = 56

监视容器：可见性
容器是轻量级的，大多数情况下都是不变的黑匣子，这可能会带来监视方面的挑战……Kubernetes API和kube-state-metrics（本机使用prometheus度量标准）通过暴露Kubernetes内部数据（例如所需/正在运行的副本数）来解决了部分问题。在部署中，无法调度的节点等

Prometheus非常适合微服务，因为只需要公开指标端口即可，因此无需增加太多复杂性或运行其他服务。通常，服务本身已经提供了HTTP接口，而开发人员只需要添加其他路径（如/ metrics）即可。

在某些情况下，该服务尚未准备好提供Prometheus指标，因此无法修改代码以支持该指标。在这种情况下，需要部署与服务捆绑在一起的Prometheus导出器，通常将其作为同一pod的sidecar容器。

普罗米修斯有几种自动发现机制来解决这一问题。与本指南最相关的是：

Consul：用于服务发现和配置的工具。Consul是分布式的，高度可用的，并且具有极高的可伸缩性。

Kubernetes：Kubernetes SD配置允许从Kubernetes的REST API检索抓取目标，并始终与集群状态保持同步。

Prometheus Operator：基于熟悉的Kubernetes标签查询自动生成监视目标配置。稍后，我们将重点介绍此部署选项。

监控基础架构的新层：Kubernetes组件
使用Kubernetes的概念（例如物理主机或服务端口）变得无关紧要。需要围绕不同的分组组织监视，例如微服务性能（不同的Pod散布在多个节点上），名称空间，部署版本等。

结合使用Prometheus的基于标签的数据模型和PromQL，可以轻松地适应这些新范围。

使用Prometheus进行Kubernetes监控：架构概述
稍后我们将详细介绍，该图涵盖了我们要在Kubernetes集群中部署的基本实体：

1 – Prometheus服务器需要尽可能多的目标自动发现。
有几种方法可以实现此目的：
Consul
Prometheus Kubernetes SD插件
Prometheus  Operator及其自定义资源定义
2 –除了应用程序指标，我们还希望Prometheus收集与Kubernetes服务，节点和业务流程状态相关的指标。
节点导出器，用于与主机相关的经典指标：cpu，mem，network等。
业务流程和集群级别指标的Kube状态指标：部署，pod指标，资源预留等。
来自内部组件的Kube系统指标：kubelet，etcd，dns，调度程序等。
3 – Prometheus可以配置规则以使用PromQL触发警报，alertmanager将负责管理警报通知，分组，禁止等。
4 – Alertmanager组件将接收方，网关配置为传递警报通知。
5 – Grafana可以从任意数量的Prometheus服务器以及显示面板和仪表板中获取指标。

prometheus-2.3.1.linux-amd64$ ./prometheuslevel=info ts=2018-06-21T11:26:21.472233744Z caller=main.go:222 msg="Starting Prometheus"

这可能对Prometheus Web界面（默认为端口9090）产生第一印象。

更好的选择是将Prometheus服务器部署在容器内：

docker run -p 9090:9090 -v /tmp/prometheus.yml:/etc/prometheus/prometheus.yml        prom/prometheus

请注意，我们可以轻松地将此Docker容器调整为适当的Kubernetes部署对象，该对象将从ConfigMap挂载配置，公开服务，部署多个副本等

kubectl create configmap prometheus-example-cm --from-file prometheus.yml

然后可以应用以下示例yaml：

如果不想配置LoadBalancer /外部IP，则可以始终为服务指定NodePort类型。

几秒钟后，应该可以看到集群中正在运行的Prometheus Pod：

kubectl get podsNAME                                     READY     STATUS    RESTARTS   AGEprometheus-deployment-68c5f4d474-cn5cb   1/1       Running   0          3hprometheus-deployment-68c5f4d474-ldk9p   1/1       Running   0          3h

无需安装服务代理，只需公开一个Web端口即可。Prometheus服务器会定期抓取（拉出），因此不必担心推送指标或配置远程端点。
一些微服务已经使用HTTP来实现其常规功能，可以重用该内部Web服务器，而只需添加/ metrics之类的文件夹。
指标格式本身是人类可读的并且易于掌握。如果是微服务代码的维护者，则可以开始发布指标，而无需太多的复杂性或学习。
一些服务旨在从根本上公开Prometheus指标（Kubernetes kubelet，Traefik Web代理，Istio微服务网格等）。其他一些服务不是本地集成的，但是可以使用导出程序轻松进行调整。导出器是一项服务，它收集服务统计信息并将其“转换”为准备好要删除的Prometheus指标。本章中有两个示例。

kubectl create -f https://raw.githubusercontent.com/mateobur/prometheus-monitoring-guide/master/traefik-prom.yaml

Traefik运行后，可以显示服务IP：

kubectl get svcNAME                         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                   AGEkubernetes                   ClusterIP   10.96.0.1       <none>        443/TCP                   238dprometheus-example-service   ClusterIP   10.103.108.86   <none>        9090/TCP                  5htraefik                      ClusterIP   10.108.71.155   <none>        80/TCP,443/TCP,8080/TCP

可以使用curl来检查是否已公开Prometheus指标：

curl 10.108.71.155:8080/metrics# HELP go_gc_duration_seconds A summary of the GC invocation durations.# TYPE go_gc_duration_seconds summarygo_gc_duration_seconds{quantile="0"} 2.4895e-05go_gc_duration_seconds{quantile="0.25"} 4.4988e-05...

现在，需要将新目标添加到prometheus.yml conf文件中。

请注意到Prometheus会自动抓取自己：

  - job_name: 'prometheus'
    # metrics_path defaults to '/metrics'    # scheme defaults to 'http'.
    static_configs:    - targets: ['localhost:9090']

让我们添加另一个静态端点：

 - job_name: 'traefik'    static_configs:    - targets: ['traefik:8080']

如果服务位于其他名称空间中，则需要使用FQDN（即traefik.default.svc.cluster.local）

当然，这是最低配置，scrape配置支持多个参数。

仅举几例：

basic_auth和bearer_token：端点可能需要使用经典的登录/密码方案或请求标头中的承载令牌，通过HTTPS进行身份验证。
kubernetes_sd_configs或consul_sd_configs：不同的端点自动发现方法。
scrape_interval，scrap_limit，scrap_timeout：精度，弹性和系统负载之间的权衡取舍。
随着部署的Prometheus堆栈变得更加完整，我们将在下一章中使用其中一些。

修补ConfigMap和部署：

kubectl create configmap prometheus-example-cm --from-file=prometheus.yml -o yaml --dry-run | kubectl apply -f -
kubectl patch deployment prometheus-deployment -p   "{"spec":{"template":{"metadata":{"labels":{"date":"`date +'%s'`"}}}}}"

如果在Prometheus Web界面中访问/ targets URL，则应该看到Traefik端点UP：

使用主Web界面，我们可以找到一些traefik指标（由于在此示例中未配置任何Traefik前端或后端，因此很少使用traefik指标）并检索其值：

我们已经有一个关于Kubernetes的Prometheus工作示例！

如何使用Prometheus exporter监控Kubernetes服务使用Prometheus exporter监控应用
想在Kubernetes集群中部署的许多应用程序可能没有立即提供Prometheus指标。在这种情况下，需要捆绑Prometheus导出器，这是一个附加的过程，该过程能够检索主服务的状态/日志/其他度量标准格式并将此信息公开为Prometheus度量标准。换句话说，是Prometheus适配器。

可以使用以下命令部署包含Redis服务器和Prometheus sidecar容器的Pod：

# Clone the repo if you don't have it alreadygit clone git@github.com:mateobur/prometheus-monitoring-guide.gitkubectl create -f prometheus-monitoring-guide/redis_prometheus_exporter.yaml

如果显示redis pod，会发现其中有两个容器：

kubectl get pod redis-546f6c4c9c-lmf6zNAME                     READY     STATUS    RESTARTS   AGEredis-546f6c4c9c-lmf6z   2/2       Running   0          2m

现在，只需要像上一节中一样更新Prometheus配置并重新加载即可：

  - job_name: 'redis'    static_configs:      - targets: ['redis:9121']

要获取所有redis服务指标：

使用Prometheus和kube-state-metrics监视Kubernetes集群
除了监视集群中部署的服务之外，我们还希望监视Kubernetes集群本身。集群监视要考虑的三个方面是：

Kubernetes主机（节点）–传统的系统管理员指标，例如cpu，负载，磁盘，内存等。
编排级别指标–部署状态，资源请求，调度和api服务器延迟等。
内部kube系统组件–调度程序，控制器管理器，dns服务等的详细服务指标。

监视Prometheus堆栈上的Kubernetes组件
Heapster：Heapster是监视和事件数据的整个集群范围的聚合器，在集群中作为Pod运行。

除了Kubelets / cAdvisor端点之外，还可以像kube-state-metrics一样将其他度量标准源附加到Heapster

Heapster现在已弃用，其替代物是metrics-server。

cAdvisor：cAdvisor是一个开源容器资源使用和性能分析代理。它是专门为容器而构建的，并且本身就支持Docker容器。在Kubernetes中，cAdvisor作为Kubelet二进制文件的一部分运行，任何检索节点本地和Docker指标的聚合器都将直接抓取Kubelet Prometheus端点。

Kube-state-metrics：kube-state-metrics是一项简单的服务，它侦听Kubernetes API服务器并生成有关对象状态（例如部署，节点和Pod）的度量。重要的是要注意kube-state-metrics只是一个指标终结点，其他实体需要抓取它并提供长期存储（即Prometheus服务器）。

Metrics-server：Metrics-server是资源使用情况数据的群集范围内的聚合器。它旨在作为默认的Heapster替代品。同样，指标服务器将仅显示最后的数据点，并且不负责长期存储。

从而：

Kube state度量标准专注于业务流程元数据：部署，窗格，副本状态等。
Metrics-server专注于实现资源指标API：CPU，文件描述符，内存，请求延迟等。
使用Prometheus监视Kubernetes节点
需要监视Kubernetes节点或主机，我们有很多工具可以监视Linux主机。在本指南中，我们将使用Prometheus node-exporter：

它由Prometheus项目本身托管
是下一章中使用Prometheus operator 时将自动部署的那个
可以作为DaemonSet部署，因此，如果在集群中添加或删除节点，它将自动扩展。
可以使用多种选项来部署此服务，例如，在此存储库中使用DamonSet：

kubectl create ns monitoring kubectl create -f https://raw.githubusercontent.com/bakins/minikube-prometheus-demo/master/node-exporter-daemonset.yml

或使用Helm / Tiller：

如果要使用Helm，请记住在继续之前为分till组件创建RBAC角色和服务帐户。

helm init --service-account tillerhelm install --name node-exporter stable/prometheus-node-exporter

安装并运行后，可以显示需要抓取的服务：

kubectl get svc NAME                                     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                     AGEnode-exporter-prometheus-node-exporter   ClusterIP   10.101.57.207    <none>        9100/TCP

一旦像上一节中一样添加了scrape配置，就可以开始收集和显示节点指标：

使用Prometheus监视kube-state-metrics
部署和监视kube-state-metrics也是一项非常简单的任务。同样，可以像下面的示例一样直接部署或使用Helm图表。

git clone https://github.com/kubernetes/kube-state-metrics.gitkubectl apply -f kube-state-metrics/kubernetes/...kubectl get svc -n kube-systemNAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGEkube-dns             ClusterIP   10.96.0.10       <none>        53/UDP,53/TCP       13hkube-state-metrics   ClusterIP   10.102.12.190    <none>        8080/TCP,8081/TCP   1h

创建一个指向kube-scheduler pod的服务：

kind: ServiceapiVersion: v1metadata:  name: scheduler-service  namespace: kube-systemspec:  selector:    component: kube-scheduler  ports:  - name: scheduler    protocol: TCP    port: 10251    targetPort: 10251

现在将能够抓取端点：scheduler-service.kube-system.svc.cluster.local：10251

下一步是什么？
我们已经有一个具有6个目标端点的Prometheus部署：2个“最终用户”应用程序，3个Kubernetes集群端点和Prometheus本身。此时，配置仍然简单稚，并且不是自动化的，但是我们拥有运行中的Prometheus基础架构。

下一章将介绍通常与Prometheus服务一起部署的其他组件。我们将开始使用PromQL语言来汇总指标，触发警报并生成可视化仪表板。

本文始发于微信公众号（python运维技术）：使用Prometheus进行Kubernetes监控-最终指南（第1部分