搜文章
推荐 原创 视频 Java开发 iOS开发 前端开发 JavaScript开发 Android开发 PHP开发 数据库 开发工具 Python开发 Kotlin开发 Ruby开发 .NET开发 服务器运维 开放平台 架构师 大数据 云计算 人工智能 开发语言 其它开发
Lambda在线 > 云原生小白 > 云原生实践之Monitoring(一)

云原生实践之Monitoring(一)

云原生小白 2020-07-14

正文共: 2602字
预计阅读时间:7分钟

前小白有讲到线上服务的可观察性在当下无论是运维还是研发的同学都是必须要掌握和了解的特性。对于当前服务可观察所要承担的功能,各大公司或社区也已基本形成共识,其主要也是围绕三个方向来提出要求:

  • monitoring (监控)

  • logging (日志)

  • tracing (追踪)

当我们翻开CNCF的生态地图,发现最右边的Observability and Analysis正是给大家绘出了各类型服务观测的指导方案。

在这里小白以日常工作中常使用到的应用来跟大家简单介绍CNCF里面的一些云原生

1. Monitoring 监控

Prometheus |--> Thanos --> Grafana
|--> AlertManager
  • Prometheus

CNCF已毕业的一个主要面向度量监控的时序数据库,能和Kubernetes、Consul等能深度结合为监控服务发现带来极大的便利性

  • Thanos

CNCF沙箱内的一个面向Prometheus分布式架构的应用

  • Grafana

数据可视化展示的前端,以其丰富的数据源和酷炫插件捕获了大批用户

2.Logging 日志

            |--> Loki --> Grafana
Fluentd --> |--> Kafka --> Flume
|--> ElasticSearch --> Kibana
  • Fluentd

CNCF已毕业的一个由Ruby开发的日志采集客户端,具备良好的采集效率、灵活简单的配置和丰富的插件等特性,更以其与Kubernetes的紧密结合而获得市场快速的验证

  • Loki

GrafanaLab开源的一个类似Prometheus的日志聚合系统,以其轻量的设计和水平扩展,具备很高的成本收益而闻名

3.Tracing 追踪

Collector --> Jaeger --> Grafana
  • Jaeger

CNCF已毕业的一个分布式追踪系统,由Uber推出,因其简单友好的UI和与kubernetes、istio的结合,当下也聚集着大量的使用者

从今天开始,小白会按照上述的结构,并以云原生服务可观察性的这个区块内带大家初尝和体验,那么现在我们就由Prometheus开始吧

1

 Prometheus架构


首先小白在正式使用前先看下Prometheus的组件及其大概架构

云原生实践之Monitoring(一)

在图中小白可以了解到,Prometheus的监控数据来源主要分两种,直接从目标exporter中主动抓取数据,或者短期job上传给Pushgateway再由Prometheus主动抓取。其次Prometheus的数据以TSDB方式存储在本地磁盘,同时它也通过一些服务发现方式找到被监控的目标。最终Prometheus的呈现是以内置的UI或者集成Grafana以PromQL方式将数据可视化展示出来,当然用户也可以通过API方式自行绘图展示。

2

 Prometheus部署

关于部署小白不想展开篇幅细说,这里小白仅简单分析下当下主流的两种部署方式以及建议

  • 方式一 :Prometheus-Operator

    优点:利用Kubernetes的CRD将Prometheus的部署和配置抽象得更直观和理解,普通用户在K8S里面只需像声明Service一样定义监控即可,不用再过多去关心和维护Prometheus服务

    缺点:运维难度比较高,普通用户难以理解真实配置,比较适合熟悉Prometheus的高阶玩家

  • 方式二:Yaml

    优点:可以根据自己环境灵活选择部署的服务,更能了解模块之间的协作关系

    缺点:部署和配置略复杂,新手们需要一定的学习成本

小白建议新手们还是需要花一段时间从Yaml部署开始熟悉,虽然过程比较复杂,不过现在关于Prometheus部署的资料很多,不会有太大的问题。

3

 Prometheus实践 服务发现 Pod

小白以当前认为最实用的基于Kubernetes Pod为服务发现的案例来和大家一起分析,首先我们先来看下配置

- job_name: kubernetes-pods-discovery
honor_timestamps: true
scrape_interval: 15s
scrape_timeout: 10s
metrics_path: /metrics
scheme: http
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
separator: ;
regex: "true"
replacement: $1
action: keep
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
separator: ;
regex: (.+)
target_label: __metrics_path__
replacement: $1
action: replace
- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
separator: ;
regex: ([^:]+)(?::\d+)?;(\d+)
target_label: __address__
replacement: $1:$2
action: replace
- separator: ;
regex: __meta_kubernetes_pod_label_(.+)
replacement: $1
action: labelmap
- source_labels: [__meta_kubernetes_namespace]
separator: ;
regex: (.*)
target_label: kubernetes_namespace
replacement: $1
action: replace
- source_labels: [__meta_kubernetes_pod_name]
separator: ;
regex: (.*)
target_label: kubernetes_pod_name
replacement: $1
action: replace

这段配置的解释如下:

  • 匹配POD元数据中的pod_annotation字段,找到key为prometheus_io_scrape的label,利用正则表达式匹配true字段,成功则通过服务发现

  • 匹配POD元数据中的pod_annotation字段,找到key为peomerheus_io_path的label,然后把目标label变更为metrics_path

  • 匹配POD元数据中的所有以_meta_kubernetes_pod_label_开头的标签,然后全部重定向到新的label当中

  • 匹配POD元数据中的_meta_kubernetes_namespace标签,然后重定向成新的kubernetes_namespace标签

  • 匹配POD元数据中的_meta_kubernetes_pod_name标签,然后重定向成新的kubernetes_pod_name标签

如上规则我们大体就可以看出来,小白想要实现在Prometheus发现目标为容器的服务大体要满足spec.template.metadata.annotations里面的三个要素:

  • scrape:定义是否需要采集监控指标

  • port:定义监控指标的采集端口

  • path:定义监控指标的采集路径

spec:
template:
metadata:
annotations:
prometheus.io/path: /metrics
prometheus.io/port: "9104"
prometheus.io/scrape: "true"


4

 Prometheus实践 服务发现 Consul

node.json主要解释了node注册到Consul中的一些基本的元数据,这部分可以由你的cmdb生成,或者也可以通过其它工具渲染生成。

{
"Datacenter": "<your-consul-datacter>",
"Node": "x.x.x.x",
"Address": "x.x.x.x",
"Service": {
"ID": "node-exporter",
"Service": "node-exporter",
"Port": 9100,
"Tags": [
"<your-server-group>"
]
}
}

在prometheus中的consul服务发现就可以按照如下配置:

  - job_name: consul-node-exporter
consul_sd_configs:
- server: <your-consul-address>
datacenter: <your-consul-datacter>
scheme: https
username: "<base_auth_username>"
password: "<base_auth_password>"
services: ["node-exporter"]
relabel_configs:
- source_labels: ["__meta_consul_service"]
regex: "(.*)"
target_label: "job"
replacement: "$1"
- source_labels: ["__meta_consul_node"]
regex: "(.*)"
target_label: "instance"
replacement: "$1"
- source_labels: ["__meta_consul_tags"]
regex: ".*,(.*),.*"
target_label: "host_group"
replacement: "$1"

这段配置的解释如下:

  • 匹配Consul中service字段,并将其值赋值给label为job的目标

  • 匹配Consul中node字段,并将其值赋值给label为instance的目标

  • 匹配Consul中tag字段,以逗号分隔,并将其值赋值给label为host_group的目标

这样的话,小白就能通过Consul控制Prometheus内的目标采集节点了。这时候如果需要再进一步推进的话,我们就可以考虑打通公司自身的CMDB了,大概的思路也比较简单。有条件的同学可以在CMDB系统内直接与Consul交互来维护资产,没有条件的同学也可以通过脚本的方式定时同步CMDB数据到Consul,其基本的逻辑如下:

CMDB --------------> |
|--> Script --> | Consul --> Prometheus

总之我们终极的目标是任何资产的变更都能同步到Prometheus。

5

 node-exporter实践

node-exporter是Prome社区开源一个用于采集主机性能指标的服务,想必大家比较熟悉,小白这里就主要分别提一下关于node-exporter设置启动参数文本收集器

node-exporter的启动参数如下:

/usr/local/bin/node_exporter \
--collector.textfile.directory /var/lib/node_exporter/textfile_collector \
--collector.tcpstat \
--collector.processes \
--collector.netclass.ignored-devices="^(cali.*|veth.*|cni.*|docker.*|flannel.*)$" \
--collector.netdev.ignored-devices="^(cali.*|veth.*|cni.*|docker.*|flannel.*)$" \
--collector.filesystem.ignored-fs-types="^(autofs|binfmt_misc|bpf|cgroup2?|configfs|debugfs|devpts|devtmpfs|fusectl|hugetlbfs|mqueue|nsfs|overlay|proc|procfs|pstore|rpc_pipefs|securityfs|selinuxfs|squashfs|sysfs|tracefs|tmpfs)$" \
--collector.vmstat.fields="^(oom_kill|pgpg|pswp|pg.*fault).*" \
--web.disable-exporter-metrics

这里面可以看到小白在启动时分别打开了TCP连接状态、进程状态和系统OOM的采集,同时过滤掉了容器相关的网卡信息,以及过滤一些不重要的文件系统数据的采集。

另外关于文本收集器,小白将它理解为是一个文件版的PushGateway,它允许用户自定义一些文件后缀为.prom且满足metrics格式的文本,这样我们就能在http请求里面找到自定义的指标。对于普通用户,我们不用对于一些特定的小功能去开发一个exporter,而是通过crontab定时执行脚本的方式产生一些文本让node-exporter来帮助我们暴露指标。小白举个实用的脚本例子,可以让大家更直观的看到文本收集器的作用,下面这个脚本主要用途为采集主机上磁盘的Uitl值

#!/bin/bash
iostat -x -k 1 2 -d |grep -E 'sd[a-z]' | sed "/(sd[a-z])/N;n;d;" | grep -E "sd[a-z]" | awk '{print $1 "\t" $NF}' \
| while read dev utils; do
echo "cloud_storage_disk_uitls{device=\"$dev\"} $utils";
done > /tmp/cloud_storage_disk_utils_info.prom
mv /tmp/cloud_storage_disk_utils_info.prom /var/lib/node_exporter/textfile_collector/cloud_storage_disk_utils_info.prom

最终我们就得到这样的数据

云原生实践之Monitoring(一)


6

 PushGateway实践

PushGateway主要是为了满足允许临时任务或者批处理任务需要将指标让Prometheus来采集的场景。这一块比较简单,小白只推荐一个比较好用,并且带ttl功能的镜像给大家

dmathai/prom-pushgateway-ttl:latest    

我们在启动的时候通过参数--metric.timetolive=60s来指定metrics在pushgateway里的保留时间。这里有同学可能会问:"为什么要用ttl",这里小白就卖个关子,有兴趣的同学可以在自己的环境内对比两者的区别😃

7

 下期预告


  • PromQL/Grafana 实践

  • Rules实践

  • Prometheus常见架构

  • Thanos实践

--- end ---

关于云原生小白

云原生小白的创号目的是将平日里离大家较远云原生应用以实用的角度展现出来,站在小白的角度来看待和使用云原生,并以每篇文章解决一个实际问题的出发点带领大家走进云原生世界。

觉得不错,请点个在看


版权声明:本站内容全部来自于腾讯微信公众号,属第三方自助推荐收录。《云原生实践之Monitoring(一)》的版权归原作者「云原生小白」所有,文章言论观点不代表Lambda在线的观点, Lambda在线不承担任何法律责任。如需删除可联系QQ:516101458

文章来源: 阅读原文

相关阅读

关注云原生小白微信公众号

云原生小白微信公众号:cloudxiaobai

云原生小白

手机扫描上方二维码即可关注云原生小白微信公众号

云原生小白最新文章

精品公众号随机推荐