文章《腾讯云TKE-搭建prometheus监控》基于prometheus,手把手教你如何在TKE上搭建全面的平台和业务监控,为业务保驾护航。这是系列文章的第三篇,前两篇链接如下:
腾讯云TKE-搭建prometheus监控(一):在TKE上搭建prometheus、安装exporter和api server监控。
腾讯云TKE-搭建prometheus监控(二):在TKE上搭建告警系统和图形监控界面。
本文主要介绍基于prometheus,手把手教你如何在TKE上使用telegraf和thanos。
Prometheus的生态中,Exporter扮演了重要的角色。对于“知名”应用程序,服务器或数据库,Prometheus官方提供了足够多的Exporters。这也是Prometheus监视目标的主要方式。
官方给出的插件有node_exporter、blackbox_exporter、mysqld_exporter、snmp_exporter等,第三方的插件有redis_exporter,cadvisor等。
当然当你需要监控的中间件或是数据库类型比较少的时候,并没有什么问题。
但是当你的监控系统扩展到一定规模的时候,你可能需要维护几百种exporter,数量甚至是到了几万个的时候,这时候你大多的精力浪费在维护和升级exporter,甚至是管理他们的部署。
此时,telegraf作为他们的集大成者就登场了。
Telegraf是一种用Go语言编写的服务端采集,处理,聚合,输出metrics的组件。它由Influxdata开发,却不仅仅支持influxdb,Telegraf的输出很多,其中就包括了Prometheus。
设计目标是使插件系统的内存占用最小,以便社区中的开发人员可以轻松添加对收集指标的支持。
Telegraf是插件驱动的,具有4种不同的插件类型的概念:
目前支持采集的数据源非常多,包括节点的各类基础指标,各类数据库、中间件的指标等。
具体可见链接:https://docs.influxdata.com/telegraf/v1.16/plugins/
注意,由于要采集每个node上的数据,telegraf最好采用damonset形式运行。
和prometheus,telegraf启动也需要配置文件,用configmap存放telegraf.conf
yaml文件如下:
apiVersion: v1
data:
telegraf.conf: |
[global_tags]
[agent]
interval = "10s"
round_interval = true
metric_batch_size = 1000
metric_buffer_limit = 10000
collection_jitter = "0s"
flush_interval = "10s"
flush_jitter = "0s"
precision = ""
debug = false
quiet = false
logfile = ""
hostname = ""
omit_hostname = true
[[outputs.prometheus_client]]
listen = ":9273"
[[inputs.cpu]]
percpu = false
totalcpu = true
collect_cpu_time = true
report_active = true
[[inputs.disk]]
ignore_fs = ["tmpfs","devtmpfs","devfs","overlay","aufs","squashfs"]
fieldpass = ["free","inodes_free","used_percent"]
[[inputs.diskio]]
[[inputs.kernel]]
[[inputs.mem]]
[[inputs.processes]]
[[inputs.procstat]]
exe = "kubelet"
[[inputs.swap]]
[[inputs.system]]
[[inputs.netstat]]
[[inputs.net]]
[[inputs.conntrack]]
files = ["ip_conntrack_count","ip_conntrack_max",
"nf_conntrack_count","nf_conntrack_max"]
dirs = ["/proc/sys/net/ipv4/netfilter","/proc/sys/net/netfilter"]
kind: ConfigMap
metadata:
annotations:
name: telegraf-config
namespace: grant-tcr-test
对其中的参数进行简单解释:
agent部分配置
interval:所有输入的默认数据收集间隔
round_interval: 采用轮询时间间隔。默认是使用interval里面的值进行轮询,比如interval = "10s",那采集时间将是:00, :10, :20, 等
metric_batch_size:输出数据大小最多为metric_batch_size度量。这控制Telegraf发送到输出插件的写入大小。
metric_buffer_limit:Telegraf将缓存metric_buffer_limit大小的每个输出的指标,并在成功写入时刷新此缓冲区。这应该是倍数,metric_batch_size不能少于2倍metric_batch_size。
collection_jitter:通过随机度量来对采集时间进行抖动。每个插件在采集数据之前将会有一个随机时间的休眠,但是这个时间应小于collection_jitter,这个设置是为了防止多个采集源数据同一时间都在队列
flush_interval:所有输出的默认数据刷新间隔。
debug:在调试模式下运行Telegraf。
quiet:以安静模式运行Telegraf(仅限错误消息)。
[[outputs.prometheus_client]]
设定暴露给prometheus的接口地址。比如9273表明是prometheus会去本地的9273拿telegraf收集的数据。
注意因此在prometheus的配置文件中,也需要加上这个job,这个后面会提到。
[[input.*]]:这些就是需要采集的指标了。里面有一些通用的
比如input.cpu
percpu = true:采集每个cpu的指标
totalcpu = true:采集总的cpu指标
input.disk
ignore_fs = ["tmpfs", "devtmpfs"]:通过文件系统类型来忽略一些挂载点,比如tmpfs
fieldpass = ["inodes*"]:#仅存储磁盘inode相关的度量值
telegraf的damonset yaml文件
apiVersion: apps/v1beta2
kind: DaemonSet
metadata:
labels:
k8s-app: telegraf
qcloud-app: telegraf
name: telegraf
namespace: grant-tcr-test
spec:
revisionHistoryLimit: 10
selector:
matchLabels:
k8s-app: telegraf
qcloud-app: telegraf
template:
metadata:
creationTimestamp: null
labels:
k8s-app: telegraf
qcloud-app: telegraf
spec:
containers:
- env:
- name: PATH
value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
- name: TELEGRAF_VERSION
value: 1.16.0
image: ccr.ccs.tencentyun.com/grantzhao/my-telegraf:1.0
imagePullPolicy: IfNotPresent
name: telegraf
resources:
limits:
cpu: 500m
memory: 1Gi
requests:
cpu: 250m
memory: 256Mi
securityContext:
privileged: false
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /etc/telegraf/telegraf.conf
name: telegraf-config
subPath: telegraf.conf
dnsPolicy: ClusterFirst
hostNetwork: true
imagePullSecrets:
- name: qcloudregistrykey
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
volumes:
- configMap:
defaultMode: 420
name: telegraf-config
name: telegraf-config
updateStrategy:
rollingUpdate:
maxUnavailable: 25%
type: RollingUpdate
status:
currentNumberScheduled: 3
desiredNumberScheduled: 3
numberAvailable: 3
numberMisscheduled: 0
numberReady: 3
observedGeneration: 2
updatedNumberScheduled: 3
或者在tke页面上,新建damonset:
需要在promtheus的配置文件中添加telegraf的job,配置如下:
- job_name: 'influxdb-exporter'
scrape_interval: 5s
static_configs:
- targets: ['172.16.32.15:9273','172.16.32.8:9273','172.16.32.16:9273']
labels:
group: 'production'
接着就可以在protheus的rules里找到telegraf:
然后在query可以找到指标:
proometheus的目前存在几个问题。
1、单点故障
2、在面对多集群的时候,非常不友好。
3、在存储方面没有好的解决方案
thanos出现解决了这些问题。
准确的说 Thanos 只是监控套件,与原生 Prometheus 结合,满足了长期存储 + 无限拓展 + 全局视图 + 无侵入性的需求。
thanos 是无侵入的,只是上层套件,因此还是需要部署我们的 Prometheus。但对于prometheus的配置,还需要做如下改动:
这些参数作为args传入到pod中。
"./prometheus
--config.file=prometheus.yml \
--log.level=info \
--storage.tsdb.path=data/prometheus \
--web.listen-address='0.0.0.0:9090' \
--storage.tsdb.max-block-duration=2h \
--storage.tsdb.min-block-duration=2h \
--storage.tsdb.wal-compression \
--storage.tsdb.retention.time=2h \
--web.enable-lifecycle"
web.enable-lifecycle一定要开,用于热加载时 reload 你的配置,retention 保留 2 小时,Prometheus 默认 2 小时会生成一个 block,Thanos 会把这个 block 上传到对象存储。
采集配置:prometheus.yml
global:
scrape_interval: 60s
evaluation_interval: 60s
external_labels:
region: 'A'
replica: 0
rule_files:
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['0.0.0.0:9090']
- job_name: 'demo-scrape'
metrics_path: '/metrics'
params:
...
这里需要声明 external_labels,标注你的地域。如果你是多副本运行,需要声明你的副本标识,如 0号,1,2 三个副本采集一模一样的数据,另外2个 Prometheus 就可以同时运行,只是 replica 值不同而已。这里的配置和官方的 Federation方案差不多。
对 Prometheus 的要求:
部署thanos,作为prometheus的sidecar。
Sidecar 组件与 Prometheus server 部署于同一个 pod 中。 他有两个作用:
sidecar配置:
./thanos sidecar \
--Prometheus.url="http://localhost:8090" \
--objstore.config-file=./conf/bos.yaml \
--tsdb.path=/home/work/opdir/monitor/Prometheus/data/Prometheus/
"
配置很简单,只需要声明 Prometheus.url 和数据地址即可。
objstore.config-file 是可选项。如果你要把数据存放在对象存储(这也是推荐做法),就配置下对象存储的账号信息。
也可以选腾讯云的cbs存储。--tsdb.path=/data/prometheus
部署store gateway组件
在上面的 sidecar 配置中,如果你配置了对象存储 objstore.config-file或者cbs存储,你的数据就会定时上传到 bucket 中,本地只留 2 小时,那么要想查询 2 小时前的数据怎么办呢?数据不被 Prometheus 控制了,应该如何从 bucket 中拿回来,并提供一模一样的查询呢?
Store gateway 组件:store gateway 主要与对象存储交互,从对象存储获取已经持久化的数据。与sidecar一样,store gateway也实现了 store api,query 组可以从 store gateway 查询历史数据。
配置如下:
./thanos store \
--data-dir=./thanos-store-gateway/tmp/store \
--objstore.config-file=./thanos-store-gateway/conf/bos.yaml \
--http-address=0.0.0.0:19904 \
--grpc-address=0.0.0.0:19914 \
--index-cache-size=250MB \
--sync-block-duration=5m \
--min-time=-2w \
--max-time=-1h \
grpc-address 就是 store api 暴露的端口,也就是 query 中–store 是 xxx:19914的配置。
放个示意图,一个 Thanos 副本,挂了多个地域的 store 组件
有了多地域多副本的数据,就可以结合 Grafana 做全局视图了
至此,系列文章《腾讯云TKE-搭建prometheus监控》基于prometheus,手把手教你如何在TKE上搭建全面的平台和业务监控,为业务保驾护航,已经全部完结。欢迎大家多多评论,下篇将介绍基于TKE和helm chart实现应用管理。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。