Prometheus

什么是Prometheus? Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。 Prometheus使用Go语言开发，是Google BorgMon监控系统的开源版本。 2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prometheus纳入其下第二大开源项目。 Prometheus目前在开源社区相当活跃。 Prometheus和Heapster(Heapster是K8S的一个子项目，用于获取集群的性能数据。 )相比功能更完善、更全面。 Prometheus性能也足够支撑上万台规模的集群。 Prometheus的特点 多维度数据模型。 灵活的查询语言。 不依赖分布式存储，单个服务器节点是自主的。 通过基于HTTP的pull方式采集时序数据。 可以通过中间网关进行时序列数据推送。 通过服务发现或者静态配置来发现目标服务对象。 支持多种多样的图表和界面展示，比如Grafana等。 官网地址： https://prometheus.io/ 架构图 基本原理 Prometheus的基本原理是通过HTTP协议周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口就可以接入监控。 不需要任何SDK或者其他的集成过程。 这样做非常适合做虚拟化环境监控系统

背景 随着云原生和高动态服务端的发展，在运维领域，以 Prometheus 为代表的现代时间序列存储正在加速替代以 Zabbix 为代表的传统监控系统。运维领域在享受时间序列技术发展红利的同时，也面临时间序列管理思路上的转变和监控系统实际应用的上一些难点 —— nodata 告警便是其中之一。nodata 告警是传统监控系统的必备功能，但却缺席了几乎所有现代时间序列存储实践，这给运维监控带了诸多缺陷。本文尝试分析其中原因，并给出一些可能的解决方法。 nodata 告警触发器的特殊性与必要性 nodata 告警触发器（Trigger）与普通告警触发器相比具有原生的特殊性。普通告警触发器的作用是对一组监控指标（Metric）的过滤，通常是基于数值大小的过滤。 运维监控场景下，发生 nodata 告警最大的可能性是监控系统本身的失效，比如采集点失效或采集对象失效，在我们的实践中，服务器意外下线、磁盘故障、服务崩溃等都会导致 nodata 告警；另外还有一类监控指标，这类指标以 nodata 为『正常状态』，如 5xx code 产生的速率，在没有 5xx code 产生时，虽然我们希望指标的数值为 0 （而不是 nodata） ，但在实践中往往很难保证，对于这类指标有效性的保证，我们会在其他文章中详细说明。 nodata 告警触发器的难点之一在于全集 U 的获取。在高动态的服务端环境中

碎片监控 prometheus监控项 监控项 描述 阈值 redis_memory_used_rss_bytes os分配给redis的内存 redis_memory_used_bytes redis存储数据实际使用内存 redis_memory_used_rss_bytes/redis_memory_used_bytes >1.5 info memory 命令 127.0.0.1:7000> info memory # Memory used_memory:276755496 used_memory_rss:277745664 mem_fragmentation_ratio:1.00 mem_fragmentation_bytes:1031192 碎片整理 通过碎片整理将不连续的空闲内存，经过数据的拷贝迁移，实现空闲内存的合并、连续； 相关配置参数： 参数 默认值 描述 activedefrag no 是否开启碎片清理 active-defrag-ignore-bytes 100mb 当超过值时进行碎片清理 active-defrag-threshold-lower 10 内存碎片所占比例超过10%时进行碎片清理 active-defrag-cycle-min 1 碎片清理所用CPU时间比例不低于配置值 active-defrag-cycle-max 25

Nacos 0.8.0版本完善了监控系统，支持通过暴露metrics数据接入第三方监控系统监控Nacos运行状态，目前支持prometheus、elastic search和influxdb，下面结合prometheus和grafana如何监控Nacos，官网 grafana监控页面 。与elastic search和influxdb结合可自己查找相关资料 Nacos集群暴露metrics数据 集群每个节点中修改配置application.properties文件，暴露metrics数据 cd /workspace/nacos/conf vim application.properties management.endpoints.web.exposure.include=* 看是否能访问到metrics数据 http://xx.xx.xx.xx:8848/nacos/actuator/prometheus 部署prometheus采集Nacos metrics数据 下载地址为 download prometheus 解压prometheus压缩包并安装 tar xvfz prometheus-*.tar.gz /workspace/ cd /workspace/prometheus 修改配置文件，注意格式缩进 vim prometheus.yml - job_name:

Kubeadm 安装时的证书有效期设置为 1 年，虽说有 sealos 这样的不知名安装器以及各种方案来更新证书，但是对于像我一样经常跟不知来源的 Kubernetes 集群打交道的人来说，这个有效期就是达摩什么的利剑，不一定什么时候会砍到脖子上。如果能用 Prometheus 对证书有效期进行监控或者告警，就能更好地保护好自己的脖子了，ssl-exporter 就是这么个有趣的项目。 ssl-exporter 是个 Prometheus Exporter，能提供多种针对 SSL 的检测手段，包括：https 证书生效/失效时间、文件证书生效/失效时间，OCSP 等相关指标。下面用 API Server 证书检测来验证这一功能： 首先进行部署： apiVersion: v1 kind: Service metadata: labels: name: ssl-exporter name: ssl-exporter spec: ports: - name: ssl-exporter protocol: TCP port: 9219 targetPort: 9219 selector: app: ssl-exporter --- apiVersion: apps/v1 kind: Deployment metadata: name: ssl-exporter spec: replicas

使用kubeadm搭建的集群默认证书有效期是1年，续费证书其实是一件很快的事情。但是就怕出事了才发现，毕竟作为专业搬砖工程师，每天都很忙的。 鉴于此，监控集群证书有效期是一件不得不做的事情。Prometheus作为云原生领域的王者，如果能用它来监控证书有效期并能及时告警，那就再好不过了。 ssl_exporter就是来做这个事情的。ssh_exporter是一个Prometheus Exporter能提供多种针对 SSL 的检测手段，包括：https 证书生效/失效时间、文件证书生效/失效时间，OCSP 等相关指标。 下面就来监听集群证书的有效期。 安装 apiVersion: v1 kind: Service metadata: labels: name: ssl-exporter name: ssl-exporter spec: ports: - name: ssl-exporter protocol: TCP port: 9219 targetPort: 9219 selector: app: ssl-exporter --- apiVersion: apps/v1 kind: Deployment metadata: name: ssl-exporter spec: replicas: 1 selector: matchLabels: app: ssl-exporter

安装准备 redis服务器：172.22.3.163:6379 prometheus主机已安装prometheus和grafnana ： 参考： centos7.8安装prometheus和grafana实战 本实践基于prometheus对已存在redis服务进行监控。 相关安装文件 https://github.com/oliver006/redis_exporter/releases/download/v1.15.1/redis_exporter-v1.15.1.linux-amd64.tar.gz 安装redis_exporter 在redis服务器安装redis_exporter # cd /opt/ # wget https://github.com/oliver006/redis_exporter/releases/download/v1.15.1/redis_exporter-v1.15.1.linux-amd64.tar.gz # tar -zxf redis_exporter-v1.15.1.linux-amd64.tar.gz # cp redis_exporter-v1.15.1.linux-amd64/redis_exporter /usr/local/bin 创建service并设置自动启动 ## 创建service # vi /usr/lib

1. 前言 本文排查的问题是经典的TCP队列溢出问题，因TCP队列问题在操作系统层面没有明显的指标异常，容易被忽略，故把排查过程分享给大家。 2. 问题描述 A服务调用B服务接口超时，B服务主机IOWAIT高，具体超时情况分为两种： A服务的请求在B服务日志中可查到，但B服务的响应时间超过了A服务的等待超时时间3S。 A服务的请求在B服务日志中无法查到。 3. 问题分析 此种超时请求集中在很短的一段时间（通常在2分钟之内），过后便恢复正常，所以很难抓到问题现场分析原因，只能搭建测试环境，A服务持续请求B服务，在B服务主机上通过DD命令写入大量数据造成主机IOWAIT高，同时通过TCPDUMP在两端抓包分析。 部分服务超时日志： 服务A：Get http://xxx&id=593930: net/http: request canceled (Client.Timeout exceeded while awaiting headers) 服务B: "GET xxx&id=593930 HTTP/1.1" 200 64 "-" "Go-http-client/1.1" "-" "-" 165000（单位微秒） 服务A发起请求3S后没有收到服务B响应，断开连接，服务B日志显示处理时长为0.165S，远低于3S，服务A侧看服务B的响应时间为网络传输时间