yunlzheng · yjjnls · Jul 30, 2020
diff --git 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
@@ -1,3 +1,3 @@
 # 小结
 
-Prometheus负责数据的统一收集并且提供统一的查询接口PromQL，而所有监控数据的产生则是由Exporter来进行实现，对于任何能够提供Promethues标准的监控样本的程序都可以称为Exporter。Exporter可以是一个单独的为了采集特定数据而构建的应用程序，也可以直接内置于特定的系统当中。
+Prometheus负责数据的统一收集并且提供统一的查询接口PromQL，而所有监控数据的产生则是由Exporter来进行实现，对于任何能够提供Prometheus标准的监控样本的程序都可以称为Exporter。Exporter可以是一个单独的为了采集特定数据而构建的应用程序，也可以直接内置于特定的系统当中。
diff --git a/ha/SUMMARY.md b/ha/SUMMARY.md
@@ -1,3 +1,3 @@
 # 小结
 
-Prometheus的简单性贯穿于整个Prometheus的使用过程中，无论是单机部署还是集群化部署，简单性一致是Prometheus设计的基本原则。这本章中，我们系统学习了如果实现Prometheus下各个中间的高可用部署方式，同时给出了集中常用的高可用方案，读者可以根据自己的实际需求来选择如何部署自己的Promethues集群。
+Prometheus的简单性贯穿于整个Prometheus的使用过程中，无论是单机部署还是集群化部署，简单性一致是Prometheus设计的基本原则。这本章中，我们系统学习了如果实现Prometheus下各个中间的高可用部署方式，同时给出了集中常用的高可用方案，读者可以根据自己的实际需求来选择如何部署自己的Prometheus集群。
diff --git 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
@@ -1,3 +1,3 @@
 # 小结
 
-Kubernetes与Promethues有着十分相似的历程，均是源自Google内部多年的运维经验。并且相继从CNCF基金会正式毕业。它们分别代表了云原生模式下容器编排以及监控的事实标准。
+Kubernetes与Prometheus有着十分相似的历程，均是源自Google内部多年的运维经验。并且相继从CNCF基金会正式毕业。它们分别代表了云原生模式下容器编排以及监控的事实标准。
diff --git 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     <none>    164d      v1.8.0    <none>        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
@@ -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
@@ -34,7 +34,7 @@ volumes:
       secretName: prometheus-inst-cc
 ```
 
-Prometheus的配置文件实际上是保存在名为`prometheus-<name-of-prometheus-object>`的Secret中，当用户创建的Prometheus中关联ServiceMonitor这类会影响配置文件内容的定义时，Promethues Operator会自动管理。而如果Prometheus定义中不包含任何与配置相关的定义，那么Secret的管理权限就落到了用户自己手中。
+Prometheus的配置文件实际上是保存在名为`prometheus-<name-of-prometheus-object>`的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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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)