从零开始prometheus

第一部分：先上一波实战，用prometheus-oprator监控你的k8s集群

一：为什么需要prometheus-operator

在Kubernetes中我们使用Deployment、DamenSet、StatefulSet来管理应用Workload，使用Service、Ingress来管理应用的访问方式，使用ConfigMap和Secret来管理应用配置。我们在集群中对这些资源的创建，更新，删除的动作都会被转换为事件(Event)，Kubernetes的Controller Manager负责监听这些事件并触发相应的任务来满足用户的期望。这种方式我们成为声明式，用户只需要关心应用程序的最终状态，其它的都通过Kubernetes来帮助我们完成，通过这种方式可以大大简化应用的配置管理复杂度。

而除了这些原生的Resource资源以外，Kubernetes还允许用户添加自己的自定义资源(Custom Resource)。并且通过实现自定义Controller来实现对Kubernetes的扩展，不需要用户去二开k8s也能达到给k8s添加功能和对象。

Prometheus-operator的本职就是一组用户自定义的CRD资源以及Controller的实现，Prometheus Operator这个controller有BRAC权限下去负责监听这些自定义资源的变化，并且根据这些资源的定义自动化的完成如Prometheus Server自身以及配置的自动化管理工作。

二：Prometheus-oprator的工作架构：

 

 三：Prometheus Operator引入的自定义资源包括

1. Prometheus
2. ServiceMonitor  
3. Alertmanager

四：部署Prometheus Operator：

git clone https://github.com/coreos/prometheus-operator.git
cd prometheus-operator/contrib/
rm -rf kube-prometheus/
git clone https://github.com/coreos/kube-prometheus.git
cd kube-prometheus/manifests
#####分批处理一下方便管理：
mkdir -p operator node-exporter alertmanager grafana kube-state-metrics prometheus serviceMonitor adapter
mv *-serviceMonitor* serviceMonitor/
mv 0prometheus-operator* operator/
mv grafana-* grafana/
mv kube-state-metrics-* kube-state-metrics/
mv alertmanager-* alertmanager/
mv node-exporter-* node-exporter/
mv prometheus-adapter* adapter/
mv prometheus-* prometheus/
######开始部署：
pro1k8s apply -f bundle.yaml 
######
kubectl apply -f adapter/
kubectl apply -f alertmanager/
kubectl apply -f node-exporter/
kubectl apply -f kube-state-metrics/
kubectl apply -f grafana/
kubectl apply -f prometheus/
kubectl apply -f serviceMonitor/

 五：里面的坑：

打开页面发现：

 

这是因为serviceMonitor是根据label去选取svc的，我们可以看到对应的serviceMonitor是选取的ns范围是kube-system，然而里面没有这两个组件对应的service，不知道k8s搞什么鬼。

创建一个service即可：

 cat 01kube-prom-service.yml 
apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: kube-controller-manager
  labels:
    k8s-app: kube-controller-manager
spec:
  selector:
    component: kube-controller-manager
  type: ClusterIP
  clusterIP: None
  ports:
  - name: http-metrics
    port: 10250
    targetPort: 10250
    protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: kube-scheduler
  labels:
    k8s-app: kube-scheduler
spec:
  selector:
    component: kube-scheduler
  type: ClusterIP
  clusterIP: None
  ports:
  - name: http-metrics
    port: 10250
    targetPort: 10250
    protocol: TCP

然而：

cat /etc/kubernetes/manifests/kube-scheduler.yaml|grep address
    - --address=127.0.0.1
cat /etc/kubernetes/manifests/kube-controller-manager.yaml|grep address
    - --address=127.0.0.1
sed -ri '/--address/s#=.+#=0.0.0.0#' /etc/kubernetes/manifests/kube-controller-manager.yaml
sed -ri '/--address/s#=.+#=0.0.0.0#' /etc/kubernetes/manifests/kube-scheduler.yaml

 

第二部分：prometheus详解：

一:什么是TSDB？

时间序列数据库的特点

• 大部分时间都是写入操作。
• 写入操作几乎是顺序添加，大多数时候数据到达后都以时间排序。
• 写操作很少写入很久之前的数据，也很少更新数据。大多数情况在数据被采集到数秒或者数分钟后就会被写入数据库。
• 删除操作一般为区块删除，选定开始的历史时间并指定后续的区块。很少单独删除某个时间或者分开的随机时间的数据。
• 基本数据大，一般超过内存大小。一般选取的只是其一小部分且没有规律，缓存几乎不起任何作用。
• 读操作是十分典型的升序或者降序的顺序读。
• 高并发的读操作十分常见。

二：什么是Prometheus?

• 多维度数据模型。
• 灵活的查询语言。
• 不依赖分布式存储，单个服务器节点是自主的。
• 通过基于HTTP的pull方式采集时序数据。
• 可以通过中间网关进行时序列数据推送。
• 通过服务发现或者静态配置来发现目标服务对象。
• 支持多种多样的图表和界面展示，比如Grafana等。

三：Prometheus都有哪些组件？

• Prometheus Server：主要负责数据采集和存储，提供PromQL查询语言的支持。
• 客户端SDK：官方提供的客户端类库有go、java、scala、python、ruby，其他还有很多第三方开发的类库，支持nodejs、php、erlang等。
• Push Gateway：支持临时性Job主动推送指标的中间网关。
• PromDash：使用Rails开发可视化的Dashboard，用于可视化指标数据。
• Exporter：Exporter是Prometheus的一类数据采集组件的总称。它负责从目标处搜集数据，并将其转化为Prometheus支持的格式。与传统的数据采集组件不同的是，它并不向中央服务器发送数据，而是等待中央服务器主动前来抓取。

Prometheus提供多种类型的Exporter用于采集各种不同服务的运行状态。目前支持的有数据库、硬件、消息中间件、存储系统、HTTP服务器、JMX等。

• alertmanager：警告管理器，用来进行报警。