prometheus多实例 mesh和pubmed的关系

一、多实的关k8s kubectl常用命令总结

查看所有 pod列表,多实的关-n后跟 namespace,查看指定的命名空间

kubectl get pod

kubectl get pod-n kube

查看所有的命名空间

kubectl get ns

删除某个节点

kubectl delete pod节点名称-n命名空间

查看 RC和 service列表，-o wide查看详细信息

kubectl get rc,多实的关svc

kubectl get pod,svc-o wide

kubectl get pod-o yaml

查看某个名称空间下的所有节点以及ip

kubectl get pod-n名称空间名-o wide

模拟用户发起请求：

(模拟100个用户同时发起100000条请求，后面跟着ip地址)

ab-c 100-k 100000 wide

显示 Node的多实的关详细信息

kubectl describe node 192.168.0.212

显示 Pod的详细信息,特别是查看 pod无法创建的时候的日志

kubectl describe pod

eg:

kubectl describe pod redis-master-tqds9

根据 yaml创建资源, apply可以重复执行，create不行

kubectl create-f pod.yaml

kubectl apply-f pod.yaml

基于 pod.yaml定义的多实的关名称删除 pod

kubectl delete-f pod.yaml

删除所有包含某个 label的pod和 service

kubectl delete pod,svc-l name=

删除所有 Pod

kubectl delete pod--all

查看 endpoint列表

kubectl get endpoints

执行 pod的 date命令

kubectl exec– date

kubectl exec– bash

kubectl exec– ping 10.24.51.9

通过bash获得 pod中某个容器的TTY，相当于登录容器

kubectl exec-it-c– bash

eg:

kubectl exec-it redis-master-cln81– bash

查看容器的多实的关日志

kubectl logs

kubectl logs-f#实时查看日志

kubectl get pods--all-namespaces

kubectl get pods kubernetes-dashboard-76479d66bb-nj8wr--namespace=kube-system

查看pods具体信息

kubectl get pods-o wide kubernetes-dashboard-76479d66bb-nj8wr--namespace=kube-system

查看集群健康状态

kubectl get cs

获取所有deployment

kubectl get deployment--all-namespaces

列出该 namespace中的所有 pod包括未初始化的

kubectl get pods--include-uninitialized

查看deployment()

kubectl get deployment nginx-app

kubectl get rc,services

查看pods结构信息（重点，通过这个看日志分析错误）

对控制器和服务，多实的关node同样有效

kubectl describe pods xxxxpodsname--namespace=xxxnamespace

其他控制器类似吧，多实的关就是多实的关kubectl get控制器控制器具体名称

查看pod日志

kubectl logs$POD_NAME

查看pod变量

kubectl exec my-nginx-5j8ok– printenv| grep SERVICE

集群

kubectl get cs#集群健康情况

kubectl cluster-info#集群核心组件运行情况

kubectl get namespaces#表空间名

kubectl version#版本

kubectl api-versions# API

kubectl get events#查看事件

kubectl get nodes//获取全部节点

kubectl delete node k8s2//删除节点

kubectl rollout status deploy nginx-test

创建

kubectl create-f./nginx.yaml#创建资源

kubectl create-f.#创建当前目录下的所有yaml资源

kubectl create-f./nginx1.yaml-f./mysql2.yaml#使用多个文件创建资源

kubectl create-f./dir#使用目录下的所有清单文件来创建资源

kubectl create-f 使用 url来创建资源

kubectl run-i--tty busybox--image=busybox----创建带有终端的pod

kubectl run nginx--image=nginx#启动一个 nginx实例

kubectl run mybusybox--image=busybox--replicas=5----启动多个pod

kubectl explain pods,svc#获取 pod和 svc的文档

kubectl rolling-update python-v1-f python-v2.json#滚动更新 pod frontend-v1

kubectl rolling-update python-v1 python-v2--image=image:v2#更新资源名称并更新镜像

kubectl rolling-update python--image=image:v2#更新 frontend pod中的镜像

kubectl rolling-update python-v1 python-v2--rollback#退出已存在的进行中的滚动更新

cat pod.json| kubectl replace-f-#基于 stdin输入的 JSON替换 pod

强制替换，删除后重新创建资源。多实的关会导致服务中断。多实的关

kubectl replace--force-f./pod.json

为 nginx RC创建服务，多实的关启用本地 80端口连接到容器上的多实的关 8000端口

kubectl expose rc nginx--port=80--target-port=8000

更新单容器 pod的镜像版本（tag）到 v4

kubectl get pod nginx-pod-o yaml| sed‘s/(image: myimage):.*$/\1:v4/’| kubectl replace-f-

kubectl label pods nginx-pod new-label=awesome#添加标签

kubectl annotate pods nginx-pod icon-url= 添加注解

kubectl autoscale deployment foo--min=2--max=10#自动扩展 deployment“foo”

编辑资源

kubectl edit svc/docker-registry#编辑名为 docker-registry的 service

KUBE_EDITOR=“nano” kubectl edit svc/docker-registry#使用其它编辑器

动态伸缩pod

kubectl scale--replicas=3 rs/foo#将foo副本集变成3个

kubectl scale--replicas=3-f foo.yaml#缩放“foo”中指定的资源。

kubectl scale--current-replicas=2--replicas=3 deployment/mysql#将deployment/mysql从2个变成3个

kubectl scale--replicas=5 rc/foo rc/bar rc/baz#变更多个控制器的多实的关数量

kubectl rollout status deploy deployment/mysql#查看变更进度

kubectl delete-f./pod.json#删除 pod.json文件中定义的类型和名称的 pod

kubectl delete pod,service baz foo#删除名为“baz”的 pod和名为“foo”的 service

kubectl delete pods,services-l name=myLabel#删除具有 name=myLabel标签的 pod和 serivce

kubectl delete pods,services-l name=myLabel--include-uninitialized#删除具有 name=myLabel标签的 pod和 service，包括尚未初始化的多实的关

kubectl-n my-ns delete po,svc--all#删除 my-ns namespace下的所有 pod和 serivce，包括尚未初始化的

kubectl delete pods prometheus-7fcfcb9f89-qkkf7--grace-period=0--force强制删除

kubectl logs nginx-pod# dump输出 pod的日志（stdout）

kubectl logs nginx-pod-c my-container# dump输出 pod中容器的日志（stdout，pod中有多个容器的情况下使用）

kubectl logs-f nginx-pod#流式输出 pod的日志（stdout）

kubectl logs-f nginx-pod-c my-container#流式输出 pod中容器的日志（stdout，pod中有多个容器的情况下使用）

kubectl run-i--tty busybox--image=busybox– sh#交互式 shell的方式运行 pod

kubectl attach nginx-pod-i#连接到运行中的容器

kubectl port-forward nginx-pod 5000:6000#转发 pod中的 6000端口到本地的 5000端口

kubectl exec nginx-pod– ls/#在已存在的容器中执行命令（只有一个容器的情况下）

kubectl exec nginx-pod-c my-container– ls/#在已存在的容器中执行命令（pod中有多个容器的情况下）

kubectl top pod POD_NAME--containers#显示指定 pod和容器的指标度量

kubectl drain k8s-node#清空 my-node以待维护

kubectl top node k8s-node#显示 my-node的指标度量

kubectl cluster-info dump--output-directory=/path/to/cluster-state#将当前集群状态输出到/path/to/cluster-state

二、prometheus配置详解

本文按照官方文档的相关内容整理整理的配置语法以及实现功能

一个scrape_config片段指定一组目标和参数，目标就是实例，指定采集的端点，参数描述如何采集这些实例，配置文件格式如下

因为部署在kubernetes环境中所以我只在意基于kubernetes_sd_configs的服务发现和static_configs静态文件的发现

relable_configss是功能强大的工具，就是Relabel可以在Prometheus采集数据之前，通过Target实例的Metadata信息，动态重新写入Label的值。除此之外，我们还能根据Target实例的Metadata信息选择是否采集或者忽略该Target实例。

relabel_configs

配置格式如下：

其中action主要包括:

replace：默认，通过regex匹配source_label的值，使用replacement来引用表达式匹配的分组

keep：删除regex与连接不匹配的目标 source_labels

drop：删除regex与连接匹配的目标 source_labels

labeldrop：删除regex匹配的标签

labelkeep：删除regex不匹配的标签

hashmod：设置target_label为modulus连接的哈希值source_labels

labelmap：匹配regex所有标签名称。然后复制匹配标签的值进行分组，replacement分组引用（{ 2},…）替代

prometheus中的数值都是key:value格式，其中replace、keep、drop都是对value的操作， labelmap、labeldrop、labelkeep都是对key的操作

replace是action的默认值，通过regex匹配source_label的值，使用replacement来引用表达式匹配的分组

上面的列子中 address的值为$1:$2，其中$1是正则表达式([^:]+)(?::\d+)?从 address中获取，$2是正则表达式(\d+)从(\d+)中获取，最后的 address的数值为192.168.1.1:9100

上面的例子只要匹配__meta_kubernetes_service_annotation_prometheus_io_probe=true数据就保留，反正source_labels中的值没有匹配regex中的值就丢弃

drop的使用和keep刚好相反，还是使用keep的例子:

上面的例子只要__meta_kubernetes_service_annotation_prometheus_io_probe这个标签的值为true就丢弃，反之如果__meta_kubernetes_service_annotation_prometheus_io_probe!=true的数据就保留

labelmap的用法和上面说到replace、keep、drop不同， labelmap匹配的是标签名称，而replace、keep、drop匹配的是value

上面例子中只要匹配到正则表达式 __meta_kubernetes_service_label_(.+)的标签，就将标签重写为(.+)中的内容，效果如下：

待续

使用labeldrop则可以对Target标签进行过滤，删除符合过滤条件的标签，例如：

该配置会使用regex匹配当前target中的所有标签，删除符合规则的标签，反之保留不符合规则的

使用labelkeep则可以对Target标签进行过滤，仅保留符合过滤条件的标签，例如：

该配置会使用regex匹配当前target中的所有标签，保留符合规则的标签，反之不符合的移除

上面我们说到relabel_config是获取metrics之前对标签的重写，对应的metric_relabel_configs是对获取metrics之后对标签的操作， metric_relabel_configs能够确定我们保存哪些指标，删除哪些指标，以及这些指标将是什么样子。

metric_relabel_configs的配置和relabel_config的配置基本相同，如果需要配置相关参数请参考 2.scrape_configs

主要用途为指定exporter获取metrics数据的目标，可以指定prometheus、 mysql、 nginx等目标

此规则主要是用于抓取prometheus自己数据的配置， targets列表中的为prometheus获取metrics的地址和端口，因为没有指定metrics_path所以使用默认的/metrics中获取数据，

简单理解就是， prometheus访问 获取监控数据

还可以配置指定exporter中的目的地址，如获取node_exporter的数据

简单理解为分别访问 获取metrics数据

kubernetes的服务发现可以刮取以下几种数据

通过指定kubernetes_sd_config的模式为endpoints，Prometheus会自动从Kubernetes中发现到所有的endpoints节点并作为当前Job监控的Target实例。如下所示，

该配置是使用kubernetes的发现机制发现kube-apiservers

上面的刮取配置定义了如下信息：

该配置是自动发现kubernetes中的endpoints

可以看到relable_configs中的规则很多，具体的内容如下

获取的metrics的信息如下：

三、普罗米修斯 Prometheus 入门

官方文档

Prometheus从被监控目标设备通过检索 metrics HTTP endpoints收集metrics。因为Prometheus自身也以同样的方式发布数据，所以它也可以监控自身的健康状态。

虽然Prometheus server仅采集自身的数据没什么意义，但是作为开始的范例很合适。

将下面的内容保存为 Prometheus配置文件prometheus.yml：

实际上安装包内已经包含了该文件，无需修改

查看其他配置项，请参阅 configuration documentation。

新开一个bash shell，查看服务和端口

访问测试

访问测试

我们试试查看Prometheus收集的自身的数据。要使用 Prometheus自带的 expression browser，导航到 ，选择"Graph" tab内的"Console" view。

既然你可以从 localhost:9090/metrics查看数据，那么可以看到一个Prometheus自己发布的指标 prometheus_target_interval_length_seconds(目标采集的实际间隔实际)。输入到expression console，然后点击"Execute":

如上，返回了一些不同的时间序列(along with the latest value recorded for each),都是 prometheus_target_interval_length_seconds的metric name，但是拥有不同的标签。这些标签显示了不同的时间段( latency percentiles)和目标组间隔(target group intervals)。

如果我们只对 99th percentile latencies有兴趣，我们可以通过如下查询：

要统计返回的时间序列数量，可以查询如下：

更多表达式语言参见 expression language documentation.

要图形表示，导航到 ，点击"Graph" tab。

比如，使用如下查询，图形表示demo Prometheus的per-second rate of chunks：

Experiment with the graph range parameters and other settings.

开始接入几个sample targets来演示。

Node Exporter用来作为范例，怎么使用参见 see these instructions.

范例监听在 , , and 。

现在我们配置 Prometheus来采集这些对象。我们把三个endpoints组成一个group到job内，称为node。假设，前两个是生产，第三个是金丝雀实例。为了在Prometheus区分，我们增加了数个endpoint组，给每个组增加标签。在范例中，我们将增加 group="production"标签给第一个组， group="canary"给第二个。

要实现这些，在prometheus.yml文件添加如下job定义到scrape_configs section，然后重启Prometheus实例。

回到 expression browser，确认 Prometheus现在已经有了关于这三个范例的信息，比如查询

虽然在范例中没有这个问题，但是当computed ad-hoc，跨成千上万时间序列的查询会变慢。为提升效率， Prometheus允许通过配置recording rules将预记录的表达式插入到新时间序列中。假设我们需要5分钟时间窗口(job, instance and mode dimensions)的平均值 per-second rate of cpu time(node_cpu_seconds_total)。我们可以查询如下：

实施图形展示。

要将这个表达式的值放到一个新metric job_instance_mode:node_cpu_seconds:avg_rate5m，使用下面的recording rule保存为 prometheus.rules.yml:

要让 Prometheus使用这个 rule，在 prometheus.yml添加 rule_files声明部分。如下是范例：

使用新配置文件重启 Prometheus，确认一个新指标 job_instance_mode:node_cpu_seconds:avg_rate5m可以通过expression browser查询了。

参考资料:OpenTelemetry