从常规监控到普罗米修斯

系统的主要监控方式

评估系统的业务流程 业务的种类 架构体系 各个企业的产品不同，业务的方向不同，程序代码不同，系统架构更不同对于各个地方的细节都需要一定程度上的认知才可以设计源头

完善的监控架构图

监控类型的分类

• 业务监控：(难点)可以包含用户访问QPS、DAU日活、访问状态(Http code)、业务接口(登入、注册、聊天、上传、留言、短信、搜索)、产品转化率、充值额度、用户投诉、宏观的概念’

• 系统监控：主要是跟操作系统的基本监控项目CUP、内存硬盘、IO、TCP连接、进出口流量

• 网络监控：(IDC)对网络的监控(交换机、路由器、防火墙、VPN)，内网之间(物理内网、逻辑内网、可用区)外网对网络状态的监控很多时候被忽视的问题丢包率、延迟

• 日志监控：监控中的重头戏(收费Splunk,开源ELK)，往往单独的设计搭建，全部种类的日志都需要采集(syslog、soft、网络设备、用户行为)

• 程序监控：一般需要和开发人员配合，程序中镶嵌各种的接口直接获取数据或者特定的日志格式

数据采集编写

• 例如：shell/python/awk/lua（Nginx 安全控制，功能分类）/php/per/go等等shell：运维的入门脚本，任何和性能/后台/界面无关的逻辑都可以实现最快速的开发（shell 是在运维领域里开发速度最快难度最低的）

• python：各种扩展功能扩展库功能丰富，伴随各种程序的展示+开发框架（如django）等可以实现快速的中高档次的平台逻辑开发.目前在运维届除去shell这个所有人必须会的脚本之外，火爆程度就属python了awk.本身是一个实用命令也是一门庞大的编程语言.结合shell脚本或者独立都可以使用。在文本和标准输出处理上有很大的优势

• lua：多用于nginx的模块结合是比较新型的一个语言

• php：老牌子的开发语言，在大型互联网开发中，目前有退潮(php-fpm高并发的请求处理效率低)的趋势不过在运维中工具开发还是很依赖PHP – —

• perl：传说中对文本处理最快的脚本语言（但是代码可读性不强）go：新型的语言目前在开发和运维中炒的很热工资也高在各种后端服务逻辑的编写上开发速度快成行早

数据采集的形式分类

• 一次性采集：例如我们使用比较简单的shell/monitor.sh+crontab的形式按10秒/30秒/一分钟这样的频率去单词采集这种形式的优点
  • 一次性采集的模式稳定性较好不容易出现各种错误和性能瓶颈，且开发逻辑简单实现快速这种形式的缺点

  • 一次性采集对于有些采集项目实现起来不够智能也不够到位例如日志的实时采集（使用一次性采集也可以实现但是很low不够准确不够直观）

• 后台式采集：采集程序以守护进程运行在后台，持续不断的采集数据：例如 python/go开发的daemon程序后台持续不断的采集

  • 优点：后台采集程序数据准确性高采集密度精细管理方便

  • 缺点：后台采集程序如果开发过程不够仔细可能会出现各种内存泄漏僵尸进程性能瓶颈的问题，且开发周期较长）

• 桥接式采集：本身以后台进程运行但是采集不能独立依然跟服务器关联以桥接方式收集采集数据例如：NRPE for nagios

监控的发展史

1.早期企业无监控

-（路远靠走安全靠狗个_A）全部都是人工盯着服务器操作系统软件网络等等

2.中前期企业半自动脚本监控

• 利用shell脚本这种类似的形式，做最简单的监控脚本

• 循环登陆机器查看一些状态之后人工记录

• 无报警无自动化无监控图形

3.中期企业自动化程序/麒本/软件/监控

• 脚本更新换代开始使用各种开源非开源软件程序进行监控的搭建和开发

• 监控形成图形化，加入报警系统，有一定的监控本身自动化实现

• 这个阶段监控开始逐步成型但是仍然缺乏精确度和稳定程度报警的精细度

4.中后期企业集群式监控各种外援监控方案

• 监控开始自成体系加入各种自动化

• 除去自身开发和搭建监控系统外，还会大量使用各种外围监控（各种商品监控例如云计算监控监控宝友盟等等）监控发展出内监控外监控（内监控是企业自己搭建的自用监控，外监控是使用外援的商业监控产品往往对产品的最外层接口和用户行为进行更宏观的监控）当前和未来监控

5.未来的监控主要会在几个方面不断的提高

• 监控准确性真实性

• 监控高度集成自动化无人值守

• 监控成本的日益降低

• 监控和CMDB的集成化以及自愈系统的发展

6.企业当前实用的通用技术和工具

• 脚本监控（当前依然使用最原始的脚本运行的形式采集和监控的公司依然不在少数很多时候是为了节约成本）

• 开源/非开源工具监控如：Nagios/Cacti/icinga/Zabbix/Ntop/prometheus/等等。·

• 报警系统：Pagerduty/自建语普报警系统/自建邮件系统/自建短信通知/各种商业报警产品）

7.企业监控目前面临的一些问题

• 监控自动化依然不够

• 很少能和CMDB完善的结合起来

• 监控依然需要大量的人工

• 监控的准确性和真实性提高的级慢

• 监控工具和方案的制定较为流草

• 对监控本身的重视程度依然有待提高

8.介绍监控的未来最终理想化

• 完整自愈式监控体系：监控和报警总归还是只熊发现问题·出现问题之后的处理依然需要人工的大量干预未来当自愈系统完善之后，各种层级的问题都会被各种自动化持续集成人工智施灾备系统缓冲等等技术自行修复

• 真实链路式监控；监控和报譬的准确性真实性发展到最终级的一个理想化模型

举个例子：当系统发出报警信息后，往往是各个层级的报警一大堆一起发出把真实引趣问题的地方掩盖住非常不利于我们即时的发现和处理问题
例如：真实发生的问题是在于数据库的一个新的联合查询对系统资源消耗太大造成各个方面的资源被大量消耗间接的就引想各种链路的问题
于是乎各个层面的报警接距而至，日志在报警，慢查询在报警，数据裤CPU内存报警，程序层TCP链接堆积报警，HTTP返回码5xx499报警所有系统CPU缓存报警，企业级监控用户流量下降报警
种种一堆一堆被连带出来的报警全都暴露出来了，结果真正的背后原因这一个祸根的DB查询反而没有被监控发现或者说发现了但是被彻底淹没了

Prometheus

Promethus架构

• 引渡官方的图片

prometheus本身是一个以进程方式后动，之后以多进程和多线程实现监控数据收集计算查询更新存储的这样一个C/S横型运行模式本身的后动很简单

存储方式

• prometheus采用的是time-series（时间序列）的方式以一种自定义的格式存储在本地硬盘上

• prometheus的本地T-S（time-series）数据库以每两小时为间隔来分block（块）存储，每一个块中又分为多个chunk文件（我们以后会介绍chunk的概念），chunk文件是用来存放采集过来的数据的T-S数据，metadata和索引文件（index）

• index文件是对metrics（prometheus中一次K/V采集数据叫做一个metric）和labels（标签）进行索引之后存储在chunk中chunk是作为存储的基本单位，index and metadata是作为子集

• prometheus平时是将采集过来的数据先都存放在内存之中（prometheus对内存的消耗还是不小的）以类似缓存的方式用于加快搜索和访问

• 当出现当机时，prometheus有一种保护机制叫做WAL可以讲数据定期存入硬盘中以chunk来表示，并在重新后动时用以恢复进入内存

采集方式

• consul主动在集群的内部获取集群服务器中的已经正常运行的服务

• 采用HTTPpull/push两种对应的数据采集传输方式所有的数据采集都基本采用HTTP，而且分为pull/push推和拉两种方式去写采集程序方便

• 主动模式：Prometheus主动去获取服务器上的具体监控项目

被动模式

• pull：指的是客户端（被监控机器）先安装各类已有exporters（由社区组织或企业开发的监控客户端插件）在系统上之后，exporters以守护进程的模式运行并开始采集数据exporter 本身也是一个http_server可以对http请求作出响应返回数据（K/V metrics）prometheus用pull 这种主动拉的方式（HTTP get）去访问每个节点上exporter并采样回需要的数据

优势

• 监控数据的精细程度”行业第一”可以精确到1~5秒的采集精度

• 集群的部署的速度监控脚本的制作很快速大大缩减搭建的时间

• 周边的插件(exporter pushgateway)很丰富大多数的都不需要自己的开发

• 本身基于数学计算模型，大量的实用函数可以实现很复杂的规则业务逻辑监控(如QPS的曲线弯曲下跌比例等模糊的概念)

• 可以嵌入很多开元的工具的内部进行监控更准时更可靠的监控

• 本身是开源的，更新速度，BUG修复快，支持N多语言做本身和插件的二次开发

• 图形高大上很美观

不足之处

• 目前不支持集群,但是可以用通过其他方式实现

• 学习成本大

• 对磁盘的资源消耗大，具体看监控的集群量监控的数据量的大小

数学理论基础而开发的监控软件

• 具有由度量名称和键/值对标识的时间序列数据的多维数据模型

• 一个灵活的查询语言 来利用这一维度

• 不依赖分布式存储; 单个服务器节点是自治的

• 时间序列集合通过HTTP上的拉模型发生

• 推送时间序列通过中间网关支持

• 通过服务发现或静态配置发现目标

• 多种图形和仪表板支持模式

metrics

Gauges

是一个最简单的度量标准，只有一个简单的返回值，或者叫瞬时状态。当需要监控硬盘或者内存的使用量，那么就应该使用Gauges的metrics格式来度量，因为硬盘的容量和内存的使用量是瞬间的，没有任何的规律，变化方式多种多样，而Gauges就是这种使用类型的代表

Counters

Counter就是计数器，从数据量0开始累积计算，在理想的状态下只能是永远的增长不会下降

Histogram

Histogram统计数据的分布情况，比如最小值，最大值，中间值，还有中位数，百分数值等，称为metrics中最难以理解的一种

• Http_response_time http的响应时间，在Nginx的日志中都有这一列

pushgateway

exporter是⾸先安装在 被监控服务器上 运⾏在后台
然后⾃动采集系统数据，本身又是一个HTTP_Server可以被prometheus服务器定时去HTTP_GET取得数据
push的形式是把pushgateway安装在客户端或者服务端,运维通过自己写脚本抓取数据然后推送到pushgateway再由它推送到服务端上

• pushgateway本⾝也是⼀个 http服务器

既然有强大的Node_exporder为何要pushgateway

• -> 既生瑜何生亮？

• (1)exporter虽然采集的类型相当的丰富，但是依然有一些人为的特殊请求，非规则化的数据监控项目，需要定制化

• (2)exporter由于数据类型采集量大，但是大多数采集回来的数据我们实际上完全不会使用上，pushgateway实际上就是帮我们节省资源

• (3)一个新的自定义的pushgateway脚本开发快速易上手，而要二次开发exporder需要熟悉它的语言和大量的时间的去调试

• (4)pushgateway比较的灵活适合生产环境中的快速开发监控

优缺点

• （1）pushgateway会形成一个单点瓶颈，假如好多个脚本同时发送给一个pushgateway的进程如果这个进程没了，那么监控数据也就没了

• （2）pushgateway并不能对发送过来的脚本采集数据进行更智能的判断假如脚本中间采集出问题了那么有问题的数据pushgateway一样照单全收发送给prometheus

入门基础

安装

• 时间序列数据库保障，所以安装之前需要时间绝对同步NTP

-> 不会同步时间的度娘一下 <-
timedatectl set-timezone Asia/Shanghai
crontab -e  * * * * * ntpdate -u cn.pool.ntp.org

• https://prometheus.io/download/ #官方下载网站

• wget http://prometheus-1252464731.file.myqcloud.com/prometheus-2.4.0.linux-amd64.tar.gz #外网主程序包，我就放腾讯云上了直接下载即可使用

• wget http://prometheus-1252464731.file.myqcloud.com/node_exporter-0.16.0.linux-amd64.tar.gz #需要被采集的节点安装包

• 安装过程无脑简单

[root@k8s-master prometheus]#tar -xf prometheus-2.4.0.linux-amd64.tar.gz    #前台运行想后台自己放
-> 修改配置文件
-------------------------------------------------------------------------------------------------
scrape_configs:
    static_configs:
    - targets: ['localhost:9090','k8s-node1:9100','k8s-node2:9100']     #逗号分隔开端口默认9100
-------------------------------------------------------------------------------------------------
[root@k8s-node1 node_exporter-0.16.0.linux-amd64]# ./node_exporter      #安装到各个被监控的节点上去

[root@k8s-node1 ~]# curl localhost:9100/metrics     #主动让采集工作返回一堆K/V值，随便取值一个去服务器查看

运维优化

• 在运维的过程中常规的将程序放在后台是使用nohup但是这个不是一个最好的方式

• screen是linux的一个较为快速方便的后台哪里工具

yum -y install screen   #安装
screen 直接进入到screen的模式中
运行我们需要后台执行的程序./prometheus
这个时候这个程序在前台，按住ctrl+a+d进入后台运行
screen -ls 可以查询在screen后台中运行的程序
如果想看程序前台只需查询screen -ls 的进程的ID号
screen -r 进程ID 进入程序的前台！方便又快捷赶快试试吧！

• daemonize unix后台进程的管理软件，原生自带，更加的正常和稳定。自行研究

• https://github.com/bmc/daemonize #git地址

git clone git://github.com/bmc/daemonize.git 
sh configure && make && sudo make install daemonize-c/data/prometheus//data/prometheus/up.sh

数据存储方式

• prometheus将近期的数据存储在内存中

• 将长期的数据存储在本地的硬盘中

• 生产中建议只存储15天左右的历史数据，想要更多则用分布式存储和更大的内存空间

生产中的参数配置

• –web.listenaddress=”0.0.0.0:9090″ #Prometheus监听的端口

• –web.read-timeout=5m #请求链接最大的等待时间，防止链接过长占用资源

• –web.max-connections=10 #最大链接数量

• –storage.tsdb.retention=15d #历史数据的最大保留时间

• –storage.tsdb.path=”data/” #存储data的目录

• –query.max-concurrency=20 #防止多人一起查询

• –query.timeout=2m #查询队列超时的时间

编写规则

CPU工作负载的某一时刻的某一分钟如何来实现呢？

• Counter数据类型 -> 计数器(虚拟的数据类型针对返回的数值,本身不代表数据文本的格式)

• node_exporter -> node_cpu 返回的就是Counter的数据(cpu底层是时间的积累)

• increase() -> 在prometheus中就是用来针对Counter这种持续增长的数值，截取其中的一段时间的增长量

当今线上的CPU核数高如何获得一个有意义的曲线？

• sum（）-> 累加value值

实战测试

将cpu中的所有的空闲的CPU时间每分钟的增量过滤出来

• node_cpu_seconds_total{mode=”idle”} -> 所有的CPU的空闲时间

• node_cpu_seconds_total{mode=”idle”}[1m] -> 所有CPU的空闲时间的每分钟的增量

• increase(node_cpu_seconds_total{mode=”idle”}[1m]) -> 累计所有

• 但是图像太混乱尝试加入sum()查看数据所以的累加值的图像
  • sum() -> 将所有的机器的CPU全部加和变成服务器集群的总CPU平均值

• 引入 by(instance) -> 可以将sum()加合到一起的数值按照指定的一个方式进行拆分，instance -> 机器名称

• sum(increase(node_cpu_seconds_total{mode=”idle”}[1m])) by(instance)

pushgateway的使用

pushgateway 是另一种采用被动推送的方式（而不是exporter主动获取）获取监控数据的prometheus 插件，pushgateway本身是没有任何抓取监控数据的功能的它只是被动的等待推送过来

• github地址：https://github.com/prometheus/pushgateway

• 下载地址：http://prometheus-1252464731.file.myqcloud.com/pushgateway-0.5.2.linux-amd64.tar.gz

exporter编写

Prometheus是纯天然的Golang开发的的程序，其独特简单的运行方式深受人们的喜爱，有的时候在企业的需要对一些特殊的问题进行监控，所以需要对exporter二次开发

• exporter是一个完全独立运行的采集程序

自行开发的注意项

• （1）自身是HTTP服务器，可以响应从外发过来的HTTP GET请求

• （2）自身需要运行在后台，并可以定期触发抓取本地的监控数据

• （3）返回给prometheus_server的内容是需要符合prometheus规定的metrics 类型（Key-Value）

• （4）prometheus-server(key/value) -> prometheus(TS时间序列)values(float，int) -> 不能返回string -> 返回必须是要数值

Golang开发代码不放了

Grafana和Prometheus的结合

开源的数据汇总绘图的平台，强大美观的绘图方式，奠定了它的基础

• 官方地址：https://grafana.com/

• 下载最新版地址：http://prometheus-1252464731.file.myqcloud.com/grafana-5.2.4-1.x86_64.rpm

• 部署太过于简单自行百度或官方网站

1.服务名grafana-server
2.默认端口号3000
3.默认登入的账号密码admin-admin
4.第一次会要求修改密码
5.创建控制面板图形
6.关联来源
7.编写数据公式
8.保存退出over

Kubernetes部署promethues

k8s的监控对象

k8s上的监控方式，节点级别的监控，以及Pod级别的核心指标，程序级别的指标

• 节点监控 -> node_exporter,cAdivisor(节点和容器的指标数据)

• kube-state-metrics：在ks的namespace中派生出相关的指标数据Metedata，使用聚合计算某个namespace中pod的数量，一个pod为一个计数器，默认k8s没有计数器必须使用他来聚合向外输出

k8s上的监控组件

• kube-state-metrics

kube-state-metrics通过监听API Server生成有关资源对象的系统状态指标,它只是简单的提供了一个metrics的指标数据并不会去存储这个数据,所以metrics采集的指标是不稳定的会随时的变动,如果有需要则需要向后端的数据库进行存储.

• metrics-server

它的出现就是为了替代Heapster的是一个链路的聚合工具,它与kube-stat-metrics是不同的,kube-stat-metrics采集的是元数据等静态的数据指标,,metrics-server是管理获取实时数据指标的例如cpu/元数据/文件描述符/请求延时/实时内存等指标数据

• node_exporter -> 节点监控器，数据收集器

• AlterManager -> 告警

• Prometheus-Server -> 采集数据

• k8s-prometheus-adapter -> 自定义的指标服务器

允许prometheus自动抓取pod的指标参数

//在pod的定义上使用annotations参数scrape：true才能监控
annotations
    prometheus.io/scrape -> 允许Prometheus动态的自动抓数据
    promethues.io/path -> 当前Pod中能够输出指标的数据的URL，默认为/metrics
    promethues.io/port -> 抓取数据时候使用的套接字端口

部署Proemtheus

• 官方提供的部署清单

• prometheus-opreator

• 自定义的配置清单：prometheus-cm.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: kube-mon
data:
  prometheus.yml: |
    global:
      scrape_interval: 15s
      scrape_timeout: 15s
    scrape_configs:
    - job_name: 'prometheus'
      static_configs:
      - targets: ['localhost:9090']
    #coredns地址kubectl get pod -n kube-system -o wide查看
    - job_name: 'coredns'
      static_configs:
      - targets: ['10.244.0.2:9153','10.244.4.3:9153']
    #这个是测试的redis-export地址
    - job_name: 'redis-export'
      static_configs:
      - targets: ['redis:9121']
    #node节点信息此处过滤了不必要的项替换了原来的10250端口
    - job_name: 'kubernetes-nodes'
      kubernetes_sd_configs:
      - role: node
      relabel_configs:
      - source_labels: [__address__]
        regex: '(.*):10250'
        replacement: '${1}:9100'
        target_label: __address__
        action: replace
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)
    #容器监控走https方式获取
    - job_name: 'kubernetes-cadvisor'
      kubernetes_sd_configs:
      - role: node
      scheme: https
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      relabel_configs:
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)
      - target_label: __address__
        replacement: kubernetes.default.svc:443
      - source_labels: [__meta_kubernetes_node_name]
        regex: (.+)
        target_label: __metrics_path__
        replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
    #apiserver监控此处过滤了少数几项
    - job_name: 'kubernetes-apiservers'
      kubernetes_sd_configs:
      - role: endpoints
      scheme: https
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      relabel_configs:
      - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
        action: keep
        regex: default;kubernetes;https
    #对端点的监控
    - job_name: 'kubernetes-endpoints'
      kubernetes_sd_configs:
      - role: endpoints
      relabel_configs:
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
        action: replace
        target_label: __scheme__
        regex: (https?)
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
        action: replace
        target_label: __address__
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
      - action: labelmap
        regex: __meta_kubernetes_service_label_(.+)
      - source_labels: [__meta_kubernetes_namespace]
        action: replace
        target_label: kubernetes_namespace
      - source_labels: [__meta_kubernetes_service_name]
        action: replace
        target_label: kubernetes_name
      - source_labels: [__meta_kubernetes_pod_name]
        action: replace
        target_label: kubernetes_pod_name

prometheus-server部署

• service和主程序清单

• 是没有做数据持久化都是挂载到本地的，如果删除重新拉起是没数据的最好方式固定节点，资源充足的可以考虑使用分布式存储

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: kube-mon
  labels:
    app: prometheus
spec:
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      serviceAccountName: prometheus
      nodeSelector:
        monitor: prometheus
      containers:
      - image: prom/prometheus:v2.14.0
        name: prometheus
        args:
        - "--config.file=/etc/prometheus/prometheus.yml"
        - "--storage.tsdb.path=/prometheus"  # 指定tsdb数据路径
        - "--storage.tsdb.retention.time=24h"
        - "--web.enable-admin-api"  # 控制对admin HTTP API的访问，其中包括删除时间序列等功能
        - "--web.enable-lifecycle"  # 支持热更新，直接执行localhost:9090/-/reload立即生效
        - "--web.console.libraries=/usr/share/prometheus/console_libraries"
        - "--web.console.templates=/usr/share/prometheus/consoles"
        ports:
        - containerPort: 9090
          name: http
        volumeMounts:
        - mountPath: "/etc/prometheus"
          name: config-volume
        - mountPath: "/prometheus"
          name: data
        resources:
          requests:
            cpu: 100m
            memory: 512Mi
          limits:
            cpu: 100m
            memory: 512Mi
      securityContext:
        runAsUser: 0
      volumes:
      - name: data
        hostPath:
          path: /data/prometheus/
      - configMap:
          name: prometheus-config
        name: config-volume
---
apiVersion: v1
kind: Service
metadata:
  name: prometheus
  namespace: kube-mon
  labels:
    app: prometheus
spec:
  selector:
    app: prometheus
  type: NodePort
  ports:
    - name: web
      port: 9090
      targetPort: http

• RBAC权限清单

apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  namespace: kube-mon
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - services
  - endpoints
  - pods
  - nodes/proxy
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - "extensions"
  resources:
    - ingresses
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - configmaps
  - nodes/metrics
  verbs:
  - get
- nonResourceURLs:
  - /metrics
  verbs:
  - get
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: kube-mon

node-export部署

• 检查Pod状态：kubectl get pod -n kube-mon

• 检查nodeport端口：kubectl get svc -n kube-mon

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: kube-mon
  labels:
    app: node-exporter
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      hostPID: true
      hostIPC: true
      hostNetwork: true
      nodeSelector:
        kubernetes.io/os: linux
      containers:
      - name: node-exporter
        image: prom/node-exporter:v0.18.1
        args:
        - --web.listen-address=$(HOSTIP):9100
        - --path.procfs=/host/proc
        - --path.sysfs=/host/sys
        - --path.rootfs=/host/root
        - --collector.filesystem.ignored-mount-points=^/(dev|proc|sys|var/lib/docker/.+)($|/)
        - --collector.filesystem.ignored-fs-types=^(autofs|binfmt_misc|cgroup|configfs|debugfs|devpts|devtmpfs|fusectl|hugetlbfs|mqueue|overlay|proc|procfs|pstore|rpc_pipefs|securityfs|sysfs|tracefs)$
        ports:
        - containerPort: 9100
        env:
        - name: HOSTIP
          valueFrom:
            fieldRef:
              fieldPath: status.hostIP
        resources:
          requests:
            cpu: 150m
            memory: 180Mi
          limits:
            cpu: 150m
            memory: 180Mi
        securityContext:
          runAsNonRoot: true
          runAsUser: 65534
        volumeMounts:
        - name: proc
          mountPath: /host/proc
        - name: sys
          mountPath: /host/sys
        - name: root
          mountPath: /host/root
          mountPropagation: HostToContainer
          readOnly: true
      tolerations:
      - operator: "Exists"
      volumes:
      - name: proc
        hostPath:
          path: /proc
      - name: dev
        hostPath:
          path: /dev
      - name: sys
        hostPath:
          path: /sys
      - name: root
        hostPath:
          path: /

Grafana部署

apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: kube-mon
spec:
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      volumes:
      - name: storage
        hostPath:
          path: /data/grafana/
      nodeSelector:
        monitor: prometheus
      securityContext:
        runAsUser: 0
      containers:
      - name: grafana
        image: grafana/grafana:6.7.1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 3000
          name: grafana
        env:
        - name: GF_SECURITY_ADMIN_USER
          value: admin
        - name: GF_SECURITY_ADMIN_PASSWORD
          value: admin321
        readinessProbe:
          failureThreshold: 10
          httpGet:
            path: /api/health
            port: 3000
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 30
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /api/health
            port: 3000
            scheme: HTTP
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          limits:
            cpu: 150m
            memory: 512Mi
          requests:
            cpu: 150m
            memory: 512Mi
        volumeMounts:
        - mountPath: /var/lib/grafana
          name: storage
---
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: kube-mon
spec:
  type: NodePort
  ports:
    - port: 3000
  selector:
    app: grafana