【星海随笔】Promethes(三) metrics

2023-12-12 01:30

本文主要是介绍【星海随笔】Promethes(三) metrics,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

注意: WEB UI / Grafana / API client 功能与实用型与Alertmanager 有重叠。

官网
http://prometheus.io
node_exporter
https://prometheus.io/download/#node_exporter

今天突然思考了一下运维的重点
运维要想做的好->需要自动化做的好
自动化做的好->需要不断的精细化
自动化精细化做的好->需要对业务的深度理解。
业务的深度理解->需要深度的经验和业务交流能力。

数据存储概念:metrics
Promethes 对采集过来的数据 统一称为 metrics 数据。

K/V 形式储存
当一个exporter(node_exporter) 被安装和运行在被监控的服务器上后。
使用简单的 curl 命令 就可以看到 exporer 帮我们采集到 metrics 数据的样子, 以k / v 的形式展现和保存。

查看已经被监控的机器

netstat -tnlp | grep 9100

查看信息

curl localhost:9100/metrics

形式为两行注释对下面返回的数据的解释

# HELP process_max_fds Maximum number of open file descriptions.
# TYPE process_max_fds gauge
process_max_fds 65535

prometheus的 exporter

官网提供了很多类型的exporter

blackbox_exporter #服务级别的数据抓取。
consul_exporter
graphite_exporter
haproxy_exporter #专门用于监控haproxy的exporter
memcached_exporter
mysqld_exporter
node_exporter
statsd_exporter

exporters 下载之后,就提供了启动命令,一般直接运行 带上一定的参数。
例如:

node_boot_time:系统启动时间
node_cpu:系统CPU使用量
node disk*:磁盘IO
node filesystem*:文件系统用量
node_load1:系统负载
node memeory*:内存使用量
node network*:网络带宽
node_time:当前系统时间
go_:node exporter中go相关指标
process_
:node exporter自身进程相关运行指标

push(被动拉取)

pushgateway 安装在客户端或者服务端(其实装哪里都无所谓)
pushgateway 本身也是一个 http 服务器
自己写脚本 抓取自己想要监控的数据,然后推送到 pushgateway(HTTP 更多使用的是POST) ,再由 pushgateway 推送到 prometheus 服务器。
node exporter提供的方法已经很多了,例如:硬件、资源、网络等。但是,我们有时候还需要采集一些定制化资源,例如用户方面,特定场景的特定资源的使用情况等。

CPU相关信息

监控需要首先对linux底层极为了解
例如:user_time / sys_time / nice time / idle time / irq /
用户时间、系统内核时间、nice使用的时间、空闲时间、中断事件

node_cpu

(1-(  (sum (increase (node_cpu{mode="idle"}[1m]) ) by (instance)) / (sum(increase(node_cpu[1m]) ) by (instance) )  )) * 100

CPU的使用率 = (所有非空闲状态的CPU使用时间总和 / (所有状态CPU时间的总和) )

(user(8mins) + sys(1.5mins) + iowa(0.5min) + 0 + 0 + 0 + 0  ) / (30mins)

针对空闲时间

idle(20mins) / (30mins) 

increase 函数 使用的是 CPU使用的是 counter 累加递进的类型。
[1m] #代表1分钟内的增量
increase(node_cpu{ mode=“idle” }[1m]) # 代表所有空闲CPU 1分钟的增量。
increase( node_cpu[1m] ) #代表所有CPU1分钟的增量。
#注:上面会把每个核的CPU全部显示出来。32核就会显示32条线

sum 计算总和。把所有的线总和为一条线。

sum 函数后 + by(instance)
可以将加合到一起的数值进行一层或多层拆分。
instance 代表的是 机器名

gauge类型的数据
count_netstat_wait_connections 

直接输入key就会出现想要的结果,是单点极值类型。
返回的数据中

count_netstat_wait_connections(exported_instance="A",exported_jos="pushgateway1", instance="localhost:9092",job="pushgateway")

其中exported_instance=“A” ,代表是监控的机器是名为A 的机器。

命令行

count_netstat_wait_connection !node_exporter (TCP wait_connect 数)
自定义的使用shell脚本 + pushgateway 的方法。

时间同步

prometheus是 T-S 时间序列数据库

timedatectl set-timezone Asia/Shanghai
# 设置NTP时间同步
ntpdate -u cn.pool.ntp.org
docker安装
#安装docker
yum install -y docker-io#下载镜像包
docker pull prom/node-exporter
docker pull prom/prometheus
tar包安装
cp -rf prometheus-xxx.linux-amd64  /usr/local/prometheus
#递归复制,如果有失败就放弃。适用于已知目录的复制。
#启动Prometheus
#启动node-exporter#新建目录Prometheus,编辑配置文件prometheus.yml。
mkdir /opt/prometheus
cd /opt/prometheus/
vim prometheus.yml启动prometheus:
docker run -d -p 9100:9100 \
-v "/proc:/host/proc:ro" \
-v "/sys:/host/sys:ro" \
-v "/:/rootfs:ro" \
--net="host" \
prom/node-exporter
#启动prometheus
docker run -d \
-p 9090:9090 \
-v /opt/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \
prom/prometheus#访问
<ip>:9090/graph
<ip>:9090/targets

这篇关于【星海随笔】Promethes(三) metrics的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/482776

相关文章

图解可观测Metrics, tracing, and logging

最近在看Gophercon大会PPT的时候无意中看到了关于Metrics,Tracing和Logging相关的一篇文章,凑巧这些我基本都接触过,也是去年后半年到现在一直在做和研究的东西。从去年的关于Metrics的goappmonitor,到今年在排查问题时脑洞的基于log全链路(Tracing)追踪系统的设计,正好是对这三个话题的实践。这不禁让我对它们的关系进行思考:Metrics和Loggi

prometheus删除指定metrics下收集的值

Prometheus 删除指定 Metric 官方文档: ​ - https://prometheus.io/docs/prometheus/latest/querying/api/#tsdb-admin-apis Prometheus 的管理 API 接口,官方到现在一共提供了三个接口,对应的分别是快照功能、数据删除功能、数据清理功能,想要使用 API 需要先添加启动参数 --web.en

Flink实战(七十二):监控(四)自定义metrics相关指标(二)

项目实现代码举例: 添加自定义监控指标,以flink1.5的Kafka读取以及写入为例,添加rps、dirtyData等相关指标信息。�kafka读取和写入重点是先拿到RuntimeContex初始化指标,并传递给要使用的序列类,通过重写序列化和反序列化方法,来更新指标信息。 不加指标的kafka数据读取、写入Demo。 public class FlinkEtlTest {priv

Flink实战(七十一):监控(三)自定义metrics相关指标(一)

0 简介 User-defined Metrics 除了系统的 Metrics 之外,Flink 支持自定义 Metrics ,即 User-defined Metrics。上文说的都是系统框架方面,对于自己的业务逻辑也可以用 Metrics 来暴露一些指标,以便进行监控。 User-defined Metrics 现在提及的都是 datastream 的 API,table、sql 可

Flink实战:监控(一)Metrics监控原理与实战

什么是 Metrics? Flink 提供的 Metrics 可以在 Flink 内部收集一些指标,通过这些指标让开发人员更好地理解作业或集群的状态。由于集群运行后很难发现内部的实际状况,跑得慢或快,是否异常等,开发人员无法实时查看所有的 Task 日志,比如作业很大或者有很多作业的情况下,该如何处理?此时 Metrics 可以很好的帮助开发人员了解作业的当前状况。 Metric Type

【 Android 应用开发随笔】-- PackageInstaller.SessionCallback

PackageInstaller.SessionCallback 是 Android 开发中的一个接口,用于在应用程序安装过程中接收安装状态的回调。这个接口属于 android.content.pm.PackageInstaller 类,主要用于处理通过 PackageInstaller 类进行的包安装。 主要功能 ◾ 安装进度通知: PackageInstaller.SessionCal

程序员的自我修养--术语随笔

PLT PLT(Procedure Linkage Table)是用于动态链接共享库中函数调用的一种数据结构,它在程序运行时起着至关重要的作用。下面是对 PLT 的详细解释:作用: PLT 主要用于实现库函数的延迟绑定(dynamic binding)。它负责将程序中对共享库中函数的调用映射到最终的共享库函数的地址上,并且支持共享库的重定位。 实现原理: 当一个程序调用共享库中的函数时,对应的

强化学习实操入门随笔

碎碎念:经过思考,打通底层逻辑,我认为未来ai的功能是在沟通领域代替人,未来人-人模式(媒介是死的语言,比如看古人留下的文字、聊天的暂时不在)会变成人-ai替身-人模式(符合本人想法的“预测个性化语言”)。由于沟通越来越虚拟化和低成本,以及各种模态(比如视频链接)的数字媒介比见面聊天效率更高,所以制作人的各种在虚拟数字空间的“替身”(模仿聊天、总结信息等秘书类事务)是很可能出现的重点问题。

K8S部署Metrics-Server服务

Metrics-Server是k8s集群采集监控数据的聚合器,如采集node、pod的cpu、内存等数据,从 Kubernetes1.8 开始默认使用Metrics-Server采集数据,并通过Metrics API的形式提供查询,但是,kubeadm安装的k8s集群默认是没有安装Metrics-Server的,所以我们来安装一下Metrics-Server。 ⚠️ 需要注意的是 在 Kub

周末随笔 | 笔耕者的悲哀 —— 盗亦无道

欢迎跳转到本文的原文链接:https://honeypps.com/talk/the-thief-has-no-way/ 今天所要说的不是技术,而是盗版这个现象。对于技术公众号来说,很少会写一些技术之外的东西。而且写一些实事类的东西对触碰到一部分人的利益,更有甚者会被“安排”。 对于盗版,我其实已经习惯了,也早已习惯地采取“鸵鸟策略”来应对。不过昨天发生的一件事情确实有点让人寒心。 前天我的