diff --git a/draft/use-federation-in-operator.md b/draft/use-federation-in-operator.md index 1031544..c824b44 100644 --- a/draft/use-federation-in-operator.md +++ b/draft/use-federation-in-operator.md @@ -1,4 +1,4 @@ -# 使用Promtheus构建联邦集群 +# 使用Prometheus构建联邦集群 通过本章前几节的内容读者应该对Prometheus Operator有了一个基本的认识。 这部分，我们将介绍如何通过Prometheus Operator搭建Prometheus联邦集群。 diff --git a/exporter/SUMMARY.md b/exporter/SUMMARY.md index 1c9f2fe..a99a8a8 100644 --- a/exporter/SUMMARY.md +++ b/exporter/SUMMARY.md @@ -1,3 +1,3 @@ # 小结 -Prometheus负责数据的统一收集并且提供统一的查询接口PromQL，而所有监控数据的产生则是由Exporter来进行实现，对于任何能够提供Promethues标准的监控样本的程序都可以称为Exporter。Exporter可以是一个单独的为了采集特定数据而构建的应用程序，也可以直接内置于特定的系统当中。 \ No newline at end of file +Prometheus负责数据的统一收集并且提供统一的查询接口PromQL，而所有监控数据的产生则是由Exporter来进行实现，对于任何能够提供Prometheus标准的监控样本的程序都可以称为Exporter。Exporter可以是一个单独的为了采集特定数据而构建的应用程序，也可以直接内置于特定的系统当中。 \ No newline at end of file diff --git a/ha/SUMMARY.md b/ha/SUMMARY.md index b6e7681..4cd0297 100644 --- a/ha/SUMMARY.md +++ b/ha/SUMMARY.md @@ -1,3 +1,3 @@ # 小结 -Prometheus的简单性贯穿于整个Prometheus的使用过程中，无论是单机部署还是集群化部署，简单性一致是Prometheus设计的基本原则。这本章中，我们系统学习了如果实现Prometheus下各个中间的高可用部署方式，同时给出了集中常用的高可用方案，读者可以根据自己的实际需求来选择如何部署自己的Promethues集群。 \ No newline at end of file +Prometheus的简单性贯穿于整个Prometheus的使用过程中，无论是单机部署还是集群化部署，简单性一致是Prometheus设计的基本原则。这本章中，我们系统学习了如果实现Prometheus下各个中间的高可用部署方式，同时给出了集中常用的高可用方案，读者可以根据自己的实际需求来选择如何部署自己的Prometheus集群。 \ No newline at end of file diff --git a/kubernetes/READMD.md b/kubernetes/READMD.md index 7a08d5f..8b0d526 100644 --- a/kubernetes/READMD.md +++ b/kubernetes/READMD.md @@ -1,6 +1,6 @@ # 第8章 Kubernetes监控实战 -Kubenetes是一款由Google开发的开源的容器编排工具，在Google已经使用超过15年。作为容器领域事实的标准，Kubernetes可以极大的简化应用的管理和部署复杂度。本章中，我们将介绍Kubernetes的一些基本概念，并且从0开始利用Prometheus构建一个完整的Kubernetes集群监控系统。同时我们还将学习如何通过Prometheus Operator简化在Kubernetes下部署和管理Promethues的过程。 +Kubenetes是一款由Google开发的开源的容器编排工具，在Google已经使用超过15年。作为容器领域事实的标准，Kubernetes可以极大的简化应用的管理和部署复杂度。本章中，我们将介绍Kubernetes的一些基本概念，并且从0开始利用Prometheus构建一个完整的Kubernetes集群监控系统。同时我们还将学习如何通过Prometheus Operator简化在Kubernetes下部署和管理Prometheus的过程。 本章的主要内容： diff --git a/kubernetes/SUMMARY.md b/kubernetes/SUMMARY.md index 967e482..985869a 100644 --- a/kubernetes/SUMMARY.md +++ b/kubernetes/SUMMARY.md @@ -1,3 +1,3 @@ # 小结 -Kubernetes与Promethues有着十分相似的历程，均是源自Google内部多年的运维经验。并且相继从CNCF基金会正式毕业。它们分别代表了云原生模式下容器编排以及监控的事实标准。 \ No newline at end of file +Kubernetes与Prometheus有着十分相似的历程，均是源自Google内部多年的运维经验。并且相继从CNCF基金会正式毕业。它们分别代表了云原生模式下容器编排以及监控的事实标准。 \ No newline at end of file diff --git a/kubernetes/service-discovery-with-kubernetes.md b/kubernetes/service-discovery-with-kubernetes.md index 7925431..1b9f339 100644 --- a/kubernetes/service-discovery-with-kubernetes.md +++ b/kubernetes/service-discovery-with-kubernetes.md @@ -93,7 +93,7 @@ ca.crt namespace token ## 服务发现 -在Kubernetes下，Promethues通过与Kubernetes API集成目前主要支持5种服务发现模式，分别是：Node、Service、Pod、Endpoints、Ingress。 +在Kubernetes下，Prometheus通过与Kubernetes API集成目前主要支持5种服务发现模式，分别是：Node、Service、Pod、Endpoints、Ingress。 通过kubectl命令行，可以方便的获取到当前集群中的所有节点信息： @@ -103,7 +103,7 @@ NAME STATUS ROLES AGE VERSION EXTERNAL-IP OS-IMAGE minikube Ready 164d v1.8.0 Buildroot 2017.02 4.9.13 docker://Unknown ``` -为了能够让Prometheus能够获取到当前集群中所有节点的信息，在Promtheus的配置文件中，我们添加如下Job配置： +为了能够让Prometheus能够获取到当前集群中所有节点的信息，在Prometheus的配置文件中，我们添加如下Job配置： ``` - job_name: 'kubernetes-nodes' @@ -207,10 +207,10 @@ instance="minikube" job="kubernetes-nodes" ``` -目前为止，我们已经能够通过Prometheus自动发现Kubernetes集群中的各类资源以及其基本信息。不过，如果现在查看Promtheus的Target状态页面，结果可能会让人不太满意： +目前为止，我们已经能够通过Prometheus自动发现Kubernetes集群中的各类资源以及其基本信息。不过，如果现在查看Prometheus的Target状态页面，结果可能会让人不太满意： ![Target页面状态](./static/prometheus-k8s-sd-example3.png) -虽然Prometheus能够自动发现所有的资源对象，并且将其作为Target对象进行数据采集。 但并不是所有的资源对象都是支持Promethues的，并且不同类型资源对象的采集方式可能是不同的。因此，在实际的操作中，我们需要有明确的监控目标，并且针对不同类型的监控目标设置不同的数据采集方式。 +虽然Prometheus能够自动发现所有的资源对象，并且将其作为Target对象进行数据采集。 但并不是所有的资源对象都是支持Prometheus的，并且不同类型资源对象的采集方式可能是不同的。因此，在实际的操作中，我们需要有明确的监控目标，并且针对不同类型的监控目标设置不同的数据采集方式。 -接下来，我们将利用Promtheus的服务发现能力，实现对Kubernetes集群的全面监控。 +接下来，我们将利用Prometheus的服务发现能力，实现对Kubernetes集群的全面监控。 diff --git a/kubernetes/use-prometheus-monitor-kubernetes.md b/kubernetes/use-prometheus-monitor-kubernetes.md index 0a4dbcc..c5d2005 100644 --- a/kubernetes/use-prometheus-monitor-kubernetes.md +++ b/kubernetes/use-prometheus-monitor-kubernetes.md @@ -1,6 +1,6 @@ # 使用Prometheus监控Kubernetes集群 -上一小节中，我们介绍了Promtheus在Kubernetes下的服务发现能力，并且通过kubernetes_sd_config实现了对Kubernetes下各类资源的自动发现。在本小节中，我们将带领读者利用Promethues提供的服务发现能力，实现对Kubernetes集群以及其中部署的各类资源的自动化监控。 +上一小节中，我们介绍了Prometheus在Kubernetes下的服务发现能力，并且通过kubernetes_sd_config实现了对Kubernetes下各类资源的自动发现。在本小节中，我们将带领读者利用Promethues提供的服务发现能力，实现对Kubernetes集群以及其中部署的各类资源的自动化监控。 下表中，梳理了监控Kubernetes集群监控的各个维度以及策略： @@ -18,7 +18,7 @@ Kubelet组件运行在Kubernetes集群的各个节点中，其负责维护和管理节点上Pod的运行状态。kubelet组件的正常运行直接关系到该节点是否能够正常的被Kubernetes集群正常使用。 -基于Node模式，Prometheus会自动发现Kubernetes中所有Node节点的信息并作为监控的目标Target。 而这些Target的访问地址实际上就是Kubelet的访问地址，并且Kubelet实际上直接内置了对Promtheus的支持。 +基于Node模式，Prometheus会自动发现Kubernetes中所有Node节点的信息并作为监控的目标Target。 而这些Target的访问地址实际上就是Kubelet的访问地址，并且Kubelet实际上直接内置了对Prometheus的支持。 修改prometheus.yml配置文件，并添加以下采集任务配置： @@ -37,7 +37,7 @@ Kubelet组件运行在Kubernetes集群的各个节点中，其负责维护和管 这里使用Node模式自动发现集群中所有Kubelet作为监控的数据采集目标，同时通过labelmap步骤，将Node节点上的标签，作为样本的标签保存到时间序列当中。 -重新加载promethues配置文件，并重建Promthues的Pod实例后，查看kubernetes-kubelet任务采集状态，我们会看到以下错误提示信息： +重新加载Prometheus配置文件，并重建Promthues的Pod实例后，查看kubernetes-kubelet任务采集状态，我们会看到以下错误提示信息： ``` Get https://192.168.99.100:10250/metrics: x509: cannot validate certificate for 192.168.99.100 because it doesn't contain any IP SANs @@ -303,7 +303,7 @@ kubernetes 10.0.2.15:8443 166d 因此，如果我们想要监控kube-apiserver相关的指标，只需要通过endpoints资源找到kubernetes对应的所有后端地址即可。 -如下所示，创建监控任务kubernetes-apiservers，这里指定了服务发现模式为endpoints。Promtheus会查找当前集群中所有的endpoints配置，并通过relabel进行判断是否为apiserver对应的访问地址： +如下所示，创建监控任务kubernetes-apiservers，这里指定了服务发现模式为endpoints。Prometheus会查找当前集群中所有的endpoints配置，并通过relabel进行判断是否为apiserver对应的访问地址： ``` - job_name: 'kubernetes-apiservers' diff --git a/operator/use-custom-configuration-in-operator.md b/operator/use-custom-configuration-in-operator.md index 1904cd9..75b51ca 100644 --- a/operator/use-custom-configuration-in-operator.md +++ b/operator/use-custom-configuration-in-operator.md @@ -34,7 +34,7 @@ volumes: secretName: prometheus-inst-cc ``` -Prometheus的配置文件实际上是保存在名为`prometheus-`的Secret中，当用户创建的Prometheus中关联ServiceMonitor这类会影响配置文件内容的定义时，Promethues Operator会自动管理。而如果Prometheus定义中不包含任何与配置相关的定义，那么Secret的管理权限就落到了用户自己手中。 +Prometheus的配置文件实际上是保存在名为`prometheus-`的Secret中，当用户创建的Prometheus中关联ServiceMonitor这类会影响配置文件内容的定义时，Prometheus Operator会自动管理。而如果Prometheus定义中不包含任何与配置相关的定义，那么Secret的管理权限就落到了用户自己手中。 通过修改prometheus-inst-cc的内容，从而可以让用户可以使用自定义的Prometheus配置文件，作为示例，我们创建一个prometheus.yaml文件并添加以下内容： diff --git a/operator/use-operator-manage-monitor.md b/operator/use-operator-manage-monitor.md index 90a6372..aa46d12 100644 --- a/operator/use-operator-manage-monitor.md +++ b/operator/use-operator-manage-monitor.md @@ -57,7 +57,7 @@ Prometheus重新加载配置后，从UI中我们可以查看到通过PrometheusR ### 使用Operator管理Alertmanager实例 -到目前为止，我们已经通过Prometheus Operator的自定义资源类型管理了Promtheus的实例，监控配置以及告警规则等资源。通过Prometheus Operator将原本手动管理的工作全部变成声明式的管理模式，大大简化了Kubernetes下的Prometheus运维管理的复杂度。 接下来，我们将继续使用Promtheus Operator定义和管理Alertmanager相关的内容。 +到目前为止，我们已经通过Prometheus Operator的自定义资源类型管理了Prometheus的实例，监控配置以及告警规则等资源。通过Prometheus Operator将原本手动管理的工作全部变成声明式的管理模式，大大简化了Kubernetes下的Prometheus运维管理的复杂度。 接下来，我们将继续使用Prometheus Operator定义和管理Alertmanager相关的内容。 为了通过Prometheus Operator管理Alertmanager实例，用户可以通过自定义资源Alertmanager进行定义，如下所示，通过replicas可以控制Alertmanager的实例数： diff --git a/operator/use-operator-manage-prometheus.md b/operator/use-operator-manage-prometheus.md index fab660e..44bd520 100644 --- a/operator/use-operator-manage-prometheus.md +++ b/operator/use-operator-manage-prometheus.md @@ -192,7 +192,7 @@ data: type: Opaque ``` -## 关联Promethues与ServiceMonitor +## 关联Prometheus与ServiceMonitor Prometheus与ServiceMonitor之间的关联关系使用serviceMonitorSelector定义，在Prometheus中通过标签选择当前需要监控的ServiceMonitor对象。修改prometheus-inst.yaml中Prometheus的定义如下所示： 为了能够让Prometheus关联到ServiceMonitor，需要在Pormtheus定义中使用serviceMonitorSelector，我们可以通过标签选择当前Prometheus需要监控的ServiceMonitor对象。修改prometheus-inst.yaml中Prometheus的定义如下所示： diff --git a/operator/what-is-prometheus-operator.md b/operator/what-is-prometheus-operator.md index fb9b473..9c91734 100644 --- a/operator/what-is-prometheus-operator.md +++ b/operator/what-is-prometheus-operator.md @@ -37,7 +37,7 @@ Prometheus的本职就是一组用户自定义的CRD资源以及Controller的实 git clone https://github.com/coreos/prometheus-operator.git ``` -这里，我们为Promethues Operator创建一个单独的命名空间monitoring： +这里，我们为Prometheus Operator创建一个单独的命名空间monitoring： ``` kubectl create namespace monitoring diff --git a/quickstart/install-prometheus-server.md b/quickstart/install-prometheus-server.md index c3c0478..4fef85d 100644 --- a/quickstart/install-prometheus-server.md +++ b/quickstart/install-prometheus-server.md @@ -52,7 +52,7 @@ scrape_configs: - targets: ['localhost:9090'] ``` -Promtheus作为一个时间序列数据库，其采集的数据会以文件的形式存储在本地中，默认的存储路径为`data/`，因此我们需要先手动创建该目录： +Prometheus作为一个时间序列数据库，其采集的数据会以文件的形式存储在本地中，默认的存储路径为`data/`，因此我们需要先手动创建该目录： ``` mkdir -p data diff --git a/sd/why-need-service-discovery.md b/sd/why-need-service-discovery.md index bad4160..f9d89f1 100644 --- a/sd/why-need-service-discovery.md +++ b/sd/why-need-service-discovery.md @@ -8,7 +8,7 @@ ![基于服务发现与注册中心动态发现监控目标](./static/prometheus-sd.png) -在不同的场景下，会有不同的东西扮演代理人（服务发现与注册中心）这一角色。比如在AWS公有云平台或者OpenStack的私有云平台中，由于这些平台自身掌握着所有资源的信息，此时这些云平台自身就扮演了代理人的角色。Prometheus通过使用平台提供的API就可以找到所有需要监控的云主机。在Kubernetes这类容器管理平台中，Kubernetes掌握并管理着所有的容器以及服务信息，那此时Prometheus只需要与Kubernetes打交道就可以找到所有需要监控的容器以及服务对象。Prometheus还可以直接与一些开源的服务发现工具进行集成，例如在微服务架构的应用程序中，经常会使用到例如Consul这样的服务发现注册软件，Promethues也可以与其集成从而动态的发现需要监控的应用服务实例。除了与这些平台级的公有云、私有云、容器云以及专门的服务发现注册中心集成以外，Prometheus还支持基于DNS以及文件的方式动态发现监控目标，从而大大的减少了在云原生，微服务以及云模式下监控实施难度。 +在不同的场景下，会有不同的东西扮演代理人（服务发现与注册中心）这一角色。比如在AWS公有云平台或者OpenStack的私有云平台中，由于这些平台自身掌握着所有资源的信息，此时这些云平台自身就扮演了代理人的角色。Prometheus通过使用平台提供的API就可以找到所有需要监控的云主机。在Kubernetes这类容器管理平台中，Kubernetes掌握并管理着所有的容器以及服务信息，那此时Prometheus只需要与Kubernetes打交道就可以找到所有需要监控的容器以及服务对象。Prometheus还可以直接与一些开源的服务发现工具进行集成，例如在微服务架构的应用程序中，经常会使用到例如Consul这样的服务发现注册软件，Prometheus也可以与其集成从而动态的发现需要监控的应用服务实例。除了与这些平台级的公有云、私有云、容器云以及专门的服务发现注册中心集成以外，Prometheus还支持基于DNS以及文件的方式动态发现监控目标，从而大大的减少了在云原生，微服务以及云模式下监控实施难度。 ![Push系统 vs Pull系统](./static/pulls_vs_push.png)