微服务架构之监控预警

已于 2024-12-28 16:39:40 修改
阅读量834 收藏 25
点赞数 26
CC 4.0 BY-SA版权
分类专栏： 分布式专题 文章标签： 架构 微服务 云原生
于 2024-12-26 18:21:45 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u013506018/article/details/144745986

微服务架构之监控预警

微服务监控预警概念

前言

分布式和微服务架构的落地和发展，随着业务快速发展，服务器越来越多，中间件、应用、微服务、数据库等也越来越多样化，监控是微服务控制系统的关键部分，你的软件越复杂，那么你就越难了解其性能及问题排障。

业务量达到百亿、千亿规模后，几百、数千台虚拟机、中间件容器，需要监控的网络、硬件、软件、应用和各种数据库。

微服务的特点决定了功能模块的部署是分布式的，大部分功能模块都是单独部署运行的，彼此通过总线交互，都是无状态的服务。这种架构下，从前到后的业务流程会经过多台虚拟机和很多微服务进行处理、调用和传递，业务处理过程中会遇到很多棘手的问题：

如何基于同一套技术方案和架构来实时监控如此庞大的微服务体系？如何主动并提前发现生产问题和生产隐患？分散在各个服务器上的日志怎么处理？如果业务流出现了错误和异常，如何定位是哪个点出的问题？如何快速定位问题？如何跟踪业务流的处理顺序和结果？

微服务的挑战

(1)、监控源的多样化

较多的业务域，存在的大量的子系统、模块、数据库(mysql、redis、mongodb、neo4j)和中间件。

(2)、海量数据

海量的业务数据，结构化数据和非结构化数据(影像文件、电子合同、报文、身份证等)。
大量的微服务，部署在不同的虚拟机上，服务的注册、提供服务、挂起、版本更新、停止服务。

(4)、调用路径和环节长

完成一个业务动作可能会调用数个甚至超过10以上的服务，经过网状的服务调用路径，经过不同的主机、甚至不同的机房。生产出现问题可以跟环境、网络或存储都有关系。

(5)、基础组件众多

基于微服务架构的应用使用较多的基础和开源组件。

(6)、部署模式多样化

不同的应用、微服务、开源组件对部署环境的要求是不一致的。

服务维度监控

传统监控

传统IT模式都是按分层来监控，比如从基础设施（如网络、主机、虚拟机上的CPU、内存、磁盘等）、系统（操作系统、中间件、数据库）、应用（子系统、模块、功能的申请量、交易量、成功率、失败率）、前端（用户申请页面、动作等）。

微服务监控

微服务的监控主要以服务以中心来监控，业务发展比较顺利的情况下，金融业务突破百亿级规模是比较快速的。那么支撑这些业务量下服务的数量达到数千级别是比较正常的。在云化环境或虚拟化环境，一千多个服务被部署到不同的主机上，每个相同的服务最少部署了二个主机上，这时不同的服务之间的调用变得非常复杂。

如果基于微服务的监控体系没有成熟之前，微服务的弊端就会凸现。此时我们会深受其害，当一个业务流程出现问题后，我们无法知道那个环节出现的问题，只能靠慢慢看日志和后台数据，判断问题变的非常冗长。对服务提前预警以及快速诊断成为我们最迫切需要解决的问题。

技术架构

监控源

微服务架构下，网络的监控指标、主机指标、存储指标、中间件指标、虚拟机指标、应用和模块指标、微服务指标、服务间调用指标，都需要纳到我们的监控源里去。

采集和埋点

(1)、埋点

对业务流程节点和重点环节作日志埋点，对业务量、业务指标、波动值都可以作为微服务中的埋点打印出来。

(2)、日志监控

系统日志监控上，可以时间、服务为维度去匹配ERROR 或是 Exception 日志。把所有发现的异常都抓出来。

(3)、采集器

关于主机和网络的监控，主要靠采集器来定时打印日志，然后依靠日志分析来作抓取和后续分析。

指标监控又可以细分为多种类型:

  • 基础监控: 是针运行服务的基础设施的监控，比如容器、虚拟机、物理机等，监控的指标主要有内存的使用率，cpu 的使用率等资源的监控，通过对资源的监控和告警能够及时发现资源瓶颈从而进行扩容操作避免影响服务，同时针对资源的异常变化也能辅助定位服务问题，比如内存泄漏会导致内存异常
  • 运行时监控: 运行时监控主要有 GC 的监控包括 GC 次数、GC 耗时，线程数量的监控等等
  • 通用监控: 通用监控主要包括对流量和耗时的监控，通过流量的变化趋势可以清晰的了解到服务的流量高峰以及流量的增长情况，流量同时也是资源分配的重要参考指标。耗时是服务性能的直观体现，耗时比较大的服务我们往往需要进行优化，平均耗时往往参考价值不大，因为我们采取中位数，包括 90、95、99 值等
  • 错误监控: 错误监控是服务健康状态的直观体现，主要包括请求返回的错误码，如 HTTP 的错误码5xx、4xx，熔断、限流等等，通过对服务错误率的观察可以了解到服务当前的健康状态

使用Spring Boot Admin监控微服务

什么是Spring Boot Admin?

官方文档

Spring Boot Admin是一个开源社区项目，是用来管理 Spring Boot 应用程序的一个简单的界面。 应用程序作为Spring Boot Admin Client向为Spring Boot Admin Server注册（通过HTTP）或使用SpringCloud注册中心（例如Eureka，Consul）发现。 UI只是Spring Boot Actuator端点之上的Vue.js应用程序，展示Spring Boot Admin Client的Actuator端点上的一些监控。常见的功能或者监控如下：

  • 显示健康状况

  • 显示详细信息，例如

    ​ JVM和内存指标

    ​ 数据源指标

    ​ 缓存指标

  • 查看Spring Boot配置属性

  • 支持Spring Cloud的postable / env-和/ refresh-endpoint

  • 轻松的日志级管理

  • 查看计划任务

  • 与JMX-beans交互

  • 查看线程转储

  • 查看http跟踪

  • 查看auditevents

  • 查看http-endpoints

  • 查看和删除活动会话（使用spring-session）

  • 查看Flyway / Liquibase数据库迁移

  • 下载heapdump

  • 状态变更通知（通过邮件，Hipchat，Telegram Notifications…）

  • 状态更改的事件日志（非持久性）

快速开始

搭建 Admin Server

首先需要设置Server。由于Spring Boot Admin Server能够作为servlet或webflux应用程序运行，因此只需要对此进行确定并添加相应的Spring Boot Starter。在此示例中，我们使用Servlet Web Starter。

  1. 在pom文件中添加依赖
<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
	<groupId>de.codecentric</groupId>
	<artifactId>spring-boot-admin-starter-server</artifactId>
	<version>2.3.0</version>
</dependency>
<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-web</artifactId>
</dependency>
  1. 通过添加@EnableAdminServer到配置中来引入Spring Boot Admin Server 配置：
@SpringBootApplication
@EnableDiscoveryClient
@EnableAdminServer
public class SpringbootAdminApplication {
	
    public static void main(String[] args) {
  		SpringApplication.run(SpringbootAdminApplication.class);
	}

    @Configuration(proxyBeanMethods = false)
	public class SecuritySecureConfig extends WebSecurityConfigurerAdapter {

 	    private final AdminServerProperties adminServer;
		public SecuritySecureConfig(AdminServerProperties adminServer) {
			this.adminServer = adminServer;
		}
	    @Override
		protected void configure(HttpSecurity http) throws Exception {
		
        	SavedRequestAwareAuthenticationSuccessHandler successHandler = new 		   				 		SavedRequestAwareAuthenticationSuccessHandler();
			successHandler.setTargetUrlParameter("redirectTo");
			successHandler.setDefaultTargetUrl(this.adminServer.path("/"));
			http.authorizeRequests((authorizeRequests) ->
			authorizeRequests.antMatchers(this.adminServer.path("/assets/**")).permitAll()
			.antMatchers(this.adminServer.path("/login")).permitAll()
			.antMatchers(this.adminServer.path("/actuator/health")).
			permitAll().anyRequest().authenticated()
			).formLogin((formLogin) ->
				formLogin.loginPage(this.adminServer.path("/login")).successHandler(successHandler).and()
			).logout((logout) -	>logout.logoutUrl(this.adminServer.path("/logout"))).httpBasic(Customizer.withDef
			aults()).csrf((csrf) -> csrf.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
			.ignoringRequestMatchers(new AntPathRequestMatcher(this.adminServer.path("/instances"),
			HttpMethod.POST.toString()), new AntPathRequestMatcher(this.adminServer.path("/instances/*"),
			HttpMethod.DELETE.toString()), new AntPathRequestMatcher(this.adminServer.path("/actuator/**"))
			)).rememberMe((rememberMe) ->
          rememberMe.key(UUID.randomUUID().toString()).tokenValiditySeconds(1209600));
	 }
  }
}

3.配置文件

server.port=9001
spring.application.name=spring-boot-admin
spring.cloud.nacos.discovery.server-addr=localhost:8848
spring.main.allow-bean-definition-overriding=true
#展示全部细节信息
management.endpoints.web.exposure.include=*
#显示健康具体信息 默认不会显示详细信息
management.endpoint.health.show-details=always
#允许admin工程远程停止本应用
management.endpoint.shutdown.enabled=true
#admin管理的端点(actuator)
spring.boot.admin.routes.endpoints=env,metrics,dump,jolokia,info,configprops,tra
ce,logfile,refresh,flyway,liquibase,heapdump,loggers,auditevents,hystrix.stream
# 登录账号和密码
spring.security.user.name=admin
spring.security.user.password=admin
启动 Admin Server

这里的用户名跟密码是前面配置文件中所配置的admin/admin。输入登录之后就会看到如下页面，由于没有Admin client注册，所以这里没有任何监控到的spring boot应用。

在这里插入图片描述

搭建 client 端
  • 在需要监测的项目的pom加入如下依赖
<!--每个要注册的应用程序都必须包含Spring Boot Admin Client。 -->
<dependency>
	<groupId>de.codecentric</groupId>
	<artifactId>spring-boot-admin-starter-client</artifactId>
</dependency>
  • 配置文件
spring.application.name=service-order
server.port=6001
feign.hystrix.enabled=true
spring.cloud.nacos.discovery.server-addr=localhost:8848
#admin工程的url
spring.boot.admin.client.url=http://localhost:9001
#展示全部细节信息
management.endpoints.web.exposure.include=*
#显示健康具体信息 默认不会显示详细信息
management.endpoint.health.show-details=always
#允许admin工程远程停止本应用
management.endpoint.shutdown.enabled=true
#admin工程的账号密码
spring.boot.admin.client.username=admin
spring.boot.admin.client.password=admin
  • 依次启动server和client就会看如下页面

点击 service-order 进入，页面如下，可以看到有我们之前介绍的一些功能。

这样一个Spring Boot Admin 2.3.0基于security 认证监控就算搭建完成了

基于Prometheus+Grafana图形化展示服务健康状态

Prometheus受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。

Prometheus架构

特点
  • 多维的数据模型（基于时间序列的k/v键值对）。
  • 灵活的查询及聚合语句（PromQL）。
  • 不依赖分布式存储，节点自治。
  • 基于HTTP的pull模式采集时间序列数据。
  • 可以使用pushgateway（prometheus的可选中间件）实现push模式。
  • 可以使用动态服务发现或静态配置采集的目标机器。
  • 支持多种图形及仪表盘。

相关概念

数据模型

Prometheus 存储的是时序数据, 即按照相同时序(相同的名字和标签)，以时间维度存储连续的数据的集合。

监控样本
# HELP system_cpu_usage The "recent cpu usage" for the whole system
# TYPE system_cpu_usage gauge
system_cpu_usage 0.23587264544090683
# HELP logback_events_total Number of error level events that made it to the
logs
# TYPE logback_events_total counter
logback_events_total{level="error",} 0.0
logback_events_total{level=“info”,} 557.0

  • HELP用于解释当前指标的含义，TYPE则说明当前指标的数据类型
  • system_cpu_usage、 logback_events_total表示当前指标的名称
  • {}中的标签反映了当前样本的一些特征和维度
  • 0.23587264544090683、0.0、557.0表示该监控样本的具体值
时序类型

Prometheus 时序数据分为 Counter, Gauge, Histogram, Summary 四种类型。

Prometheus的使用
安装
官方下载地址

以下使用：prometheus-2.22.0.windows-amd64

配置
Pom 依赖
<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
	<groupId>io.micrometer</groupId>
	<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
项目开启监控
management.endpoint.metrics.enabled=true
management.endpoints.web.exposure.include=*
management.endpoint.prometheus.enabled=true
management.metrics.export.prometheus.enabled=true
添加 Job

进入Prometheus安装根目录 vim prometheus.yml

新增节点

- job_name: 'service-order'
	metrics_path: '/actuator/prometheus'
	static_configs:
	- targets: ['localhost:6001']

job_name：任务名称 metrics_path： 指标路径 targets：实例地址/项目地址，可配置多个

运行Prometheus

进入Prometheus安装根目录 ./prometheus，Windows版本运行prometheus.exe

运行成功日志

管理页面地址：localhost:9090

PromQL
匹配过滤

操作符：= != =~ !~

=：匹配与标签相等的内容 !=：不匹配与标签相等的内容 =~: 根据正则表达式匹配与标签符合的内容

!~：根据正则表达式不匹配与标签符合的内容

匹配监控任务为service-order的GET请求方法的请求数

http_server_requests_seconds_count{job="service-order", method="GET"}

匹配监控任务为service-order的非POST请求方法的请求数，且请求路径不为/order和/storage

http_server_requests_seconds_count{job="service-order", method!="POST", uri !~
"/order|/storage"}
范围查询

查询最近5分钟内的所有样本数据： prometheus_http_requests_total{}[5m] 可选单位：

  • s - 秒
  • m - 分钟
  • h - 小时
  • d - 天
  • w - 周
  • y - 年
时间位移操作(offset)

查询5分钟前的样本数据： prometheus_http_requests_total{} offset 5m

查询昨天1天内的样本数据： prometheus_http_requests_total{}[1d] offset 1d

聚合操作
  • sum (求和)
  • min (最小值)
  • max (最大值)
  • avg (平均值)
  • stddev (标准差)
  • stdvar (标准差异)
  • count (计数)
  • count_values (对value进行计数)
  • bottomk (后n条时序)
  • topk (前n条时序)
  • quantile (分布统计) …
内置函数
  • increase(v range-vector)：获取区间向量中的第一个和最后一个样本并返回其增长量
  • rate(v range-vector)：计算区间向量v在时间窗口内平均增长速率
  • irate(v range-vector)：计算区间向量v在时间窗口内平均增长速率（瞬时增长率，基于最后两个数据）
  • predict_linear(v range-vector, t scalar)：预测时间序列v在t秒后的值
  • abs(v instant-vector)： 返回输入向量的绝对值
  • sort(v instant-vector)： 按升序排列
  • sort_desc(v instant-vector)： 按降序排列 …
Grafana可视化
安装
官方下载地址

以下使用：grafana-7.2.1.windows-amd64

Windows下启动示例
执行 grafana-server.exe

管理后台地址：localhost:3000

初始用户名和密码都是admin

添加Prometheus数据源

新增Dashboard

可以选择自己手动添加或者导入一个已配置好的Json文件 Dashboard分享社区：https://grafana.com/dashboards 这里可以下载别人分享的Dashboard Json配置文件

image

推荐下载：Spring Boot Statistics 下载完后 导入文件就可以看见类似一个这样的监控界面

最上面这一行是模板变量，可以动态选择

点击设置按钮，选择Variables，点击New可以新增变量

点击 title 选择 Edit 可以进行编辑

这里编写PromQL语句

在这里插入图片描述

监控报警
配置发件邮箱

vim grafana-7.2.1/defaults.ini 配置如下：

[smtp]

[smtp]
enabled = true
host = smtp.qq.com:25
user = 你的QQ@qq.com
# If the password contains # or ; you have to wrap it with trippel quotes. Ex
"""#password;"""
password = 邮箱口令（不是QQ密码）
;cert_file =
;key_file =
;skip_verify = false
from_address = 你的QQ@qq.com
from_name = Grafana
# EHLO identity in SMTP dialog (defaults to instance_name)
;ehlo_identity = dashboard.example.com

这里配置的是QQ邮箱，其他邮箱同理

配置完后，重启Grafana

services restart grafana
配置收件人

可以添加多个收件人，以“；”分隔

最后点击Send Test 可以收到一封测试邮件，配置成功

监控指标

需要注意的是，Prometheus不支持带有模版变量的监控设置报警，否则会提示“Template

variables are not supported in alert queries”

监控示例： 监控CPU使用率 PromQL:
system_cpu_usage{instance="实例地址", job="任务名称"}

创建报警

这里配置的是当CPU使用率超过1%则发出报警

添加报警通知邮箱以及报警的描述信息

保存之后，没过多久就收到了报警通知

基于exporter实现系统监控
Exporter 介绍
Exporter是什么

为Prometheus提供监控数据源的应用都可以被成为Exporter，比如Node Exporter则用来提供节点相关的资源使用状况，而Prometheus从这些不同的Exporter中获取监控数据，然后可以在诸如Grafana这样的可视化工具中进行结果的显示。

Exporter的类型
  • Exporter根据来源可以分为：社区提供的Exporter和自定义的Exporter两种
  • Exporter根据支持方式可以分为：很多软件现在已经内嵌支持Prometheus，比如kubernetes或者etcd，简单来说这种类型的软件中不需要单独的Exporter用于提供给Prometheus的监控数据的功能，这是其本身的功能特性之一。当然更多的情况则是通过独立运行的Exporter来进行，比如Node Exporter，操作系统本身由于不像kubernetes那样提供对于Prometheus的支持，所以需要单独运行Node Exporter用于提供节点自身的信息给Prometheus进行监控。
社区常见的Exporter
数据库

常见的主流数据库几乎逗留相应的Exporter，详细如下所示：

  • MongoDB exporter
  • MSSQL server exporter
  • MySQL server exporter (official)
  • OpenTSDB Exporter
  • Oracle DB Exporter
  • PostgreSQL exporter
  • Redis exporter
  • ElasticSearch exporter
  • RethinkDB exporter
  • Consul exporter (official) …
消息队列
  • Kafka exporter
  • IBM MQ exporter
  • RabbitMQ exporter
  • RocketMQ exporter
  • NSQ exporter
  • Gearman exporter …
存储
  • Ceph exporter
  • Gluster exporter
  • Hadoop HDFS FSImage exporter …
硬件相关
  • Node/system metrics exporter (official)
  • Dell Hardware OMSA exporter
  • IoT Edison exporter
  • IBM Z HMC exporter
  • NVIDIA GPU exporter …
问题追踪与持续集成
  • Bamboo exporter
  • Bitbucket exporter
  • Confluence exporter
  • Jenkins exporter
  • JIRA exporter
HTTP服务
  • Apache exporter
  • HAProxy exporter (official)
  • Nginx metric library
  • Nginx VTS exporter
  • Passenger exporter
  • Squid exporter
  • Tinyproxy exporter
  • Varnish exporter
  • WebDriver exporter
API服务
  • AWS ECS exporter
  • AWS Health exporter
  • AWS SQS exporter
  • Cloudflare exporter
  • DigitalOcean exporter
  • Docker Cloud exporter
  • Docker Hub exporter
  • GitHub exporter
  • InstaClustr exporter
  • Mozilla Observatory exporter
  • OpenWeatherMap exporter
  • Pagespeed exporter
  • Rancher exporter
  • Speedtest exporter
  • Tankerkönig API Exporter
日志
  • Fluentd exporter
  • Google’s mtail log data extractor
  • Grok exporter
监控系统
  • Akamai Cloudmonitor exporter
  • Alibaba Cloudmonitor exporterAWS CloudWatch exporter (official)
  • Azure Monitor exporter
  • Cloud Foundry Firehose exporter
  • Collectd exporter (official)
  • Google Stackdriver exporter
  • Graphite exporter (official)
  • Huawei Cloudeye exporter
  • InfluxDB exporter (official)
  • JavaMelody exporter
  • JMX exporter (official)
  • Nagios / Naemon exporter
  • Sensu exporter
  • SNMP exporter (official)
  • TencentCloud monitor exporter
  • ThousandEyes exporter …
其他
  • BIND exporter
  • Bitcoind exporter
  • cAdvisor
  • Dnsmasq exporter
  • Ethereum Client exporter
  • JFrog Artifactory Exporter
  • JMeter plugin
  • Kibana Exporter
  • kube-state-metrics
  • OpenStack exporter
  • PowerDNS exporter
  • Script exporter
  • SMTP/Maildir MDA blackbox prober
  • WireGuard exporter
  • Xen exporter …
使用方式

Prometheus Server提供PromQL查询语言能力、负责数据的采集和存储等主要功能，而数据的采集主要通过周期性的从Exporter所暴露出来的HTTP服务地址（一般是/metrics）来获取监控数据。而Exporter在实际运行的时候根据其支持的方式也会分为：

  • ​ 独立运行的Exporter应用，通过HTTP服务地址提供相应的监控数据（比如Node Exporter）
  • ​ 内置在监控目标中，通过HTTP服务地址提供相应的监控数据（比如kubernetes）
参考内容

https://prometheus.io/docs/instrumenting/exporters/

安装配置redis_exporter
下载

下载地址，也可以wget在线下载，这里我下载到了home目录下

# wget https://github.com/oliver006/redis_exporter/releases/download/v1.9.0/redis_exporterv1.9.0.linux-amd64.tar.gz

在这里插入图片描述

解压/usr/local目录下，并重命名
\# tar -zxvf redis_exporter-v1.9.0.linux-amd64.tar.gz -C /usr/local/
\# cd /usr/local/
\# mv redis_exporter-v1.9.0.linux-amd64/ redis_exporter

在这里插入图片描述

配置 redis_exporter

Redis 集群监控方案参考**：redis_exporter也可以支持加载配置文件启动，本篇单实例** redis 监控

-redis.addr：指明 Redis 节点的地址，默认为 redis://localhost:6379(如果有多个redis实例,

redis_exporter作者建议启动多个redis_exporter进程来进行监控数据获取)

-redis.password：验证 Redis 时使用的密码；

-redis.file：包含一个或多个redis 节点的文件路径，每行一个节点，此选项与 -redis.addr 互斥。

-web.listen-address：监听的地址和端口，默认为 0.0.0.0:9121

启动

前台启动，默认监听端口****9121

# ./redis_exporter -redis.addr 172.20.32.218:6379

后台启动

\# nohup ./redis_exporter -redis.addr 172.20.32.218:6379 & //无密码
\# nohup ./redis_exporter -redis.addr 172.20.32.218:6379 -redis.password 123456 //有密码
Prometheus 配置
进入prometheus安装目录，编辑prometheus.yml
# vim prometheus.yml
- job_name: 'redis'
  static_configs:
	- targets: ['172.20.32.218:9121']
3.2 重启 Prometheus
# systemctl restart prometheus

浏览器查看监控信息：http://172.20.32.218:9090/targets

注：State=UP，说明成功

安装配置mysql_exporter
1、下载及解压安装包

https://github.com/prometheus/mysqld_exporter tar -xvf mysqld_exporter-0.11.0.linux

amd64.tar.gz -C /app/prometheus

2、创建密码填写内容.my.cnf文件
vim .my.cnf
[client]
host=127.0.0.1
user=root
password=root
3、创建**mysqld_exporter.service **的 systemd unit 文件
vim /usr/lib/systemd/system/mysqld_exporter.service
[Unit]
Description=node_exporter
Documentation=https://prometheus.io/
After=network.target
[Service]
Type=simple
User=prometheus
ExecStart=/app/prometheus/mysqld_exporter/mysqld_exporter --config.mycnf=/app/prometheus/mysqld_exporter/.my.cnf
Restart=on-failure
[Install]
WantedBy=multi-user.target
4、启动服务
systemctl daemon-reload
systemctl enable mysqld_exporter.service
systemctl start mysqld_exporter.service
5、运行状态
#systemctl status mysqld_exporter.service
● mysqld_exporter.service - node_exporter
Loaded: loaded (/usr/lib/systemd/system/mysqld_exporter.service; enabled;
vendor preset: disabled)
Active: active (running) since 一 2019-06-17 00:11:52 CST; 4s ago
Docs: https://prometheus.io/
Main PID: 27193 (mysqld_exporter)
CGroup: /system.slice/mysqld_exporter.service
└─27193 /app/prometheus/mysqld_exporter/mysqld_exporter --config.mycnf=/app/prometheus/mysqld_exporter/.my.cnf
6月 17 00:11:52 qas-zabbix4 systemd[1]: Started node_exporter.
6月 17 00:11:52 qas-zabbix4 mysqld_exporter[27193]: time="2019-06-
17T00:11:52+08:00" level=info msg="Starting mysqld_exporter (version=0.11.0,
branch=HEAD, revision=5d7179615...ter.go:206"
6月 17 00:11:52 qas-zabbix4 mysqld_exporter[27193]: time="2019-06-
17T00:11:52+08:00" level=info msg="Build context (go=go1.10.3,
user=root@3d3ff666b0e4, date=20180629-15:00:3...ter.go:207"
6月 17 00:11:52 qas-zabbix4 mysqld_exporter[27193]: time="2019-06-
17T00:11:52+08:00" level=info msg="Enabled scrapers:"
source="mysqld_exporter.go:218"
6月 17 00:11:52 qas-zabbix4 mysqld_exporter[27193]: time="2019-06-
17T00:11:52+08:00" level=info msg=" --collect.global_status"
source="mysqld_exporter.go:222"
6月 17 00:11:52 qas-zabbix4 mysqld_exporter[27193]: time="2019-06-
17T00:11:52+08:00" level=info msg=" --collect.global_variables"
source="mysqld_exporter.go:222"
6月 17 00:11:52 qas-zabbix4 mysqld_exporter[27193]: time="2019-06-
17T00:11:52+08:00" level=info msg=" --collect.slave_status"
source="mysqld_exporter.go:222"
6月 17 00:11:52 qas-zabbix4 mysqld_exporter[27193]: time="2019-06-
17T00:11:52+08:00" level=info msg=" --collect.info_schema.tables"
source="mysqld_exporter.go:222"
6月 17 00:11:52 qas-zabbix4 mysqld_exporter[27193]: time="2019-06-
17T00:11:52+08:00" level=info msg="Listening on :9104"
source="mysqld_exporter.go:232"
Hint: Some lines were ellipsized, use -l to show in full.
6、prometheus.service添加配置
vim /app/prometheus/cfg/prometheus.yml
  - job_name: 'mysql'
    static_configs:
    - targets: ['localhost:9104']
7、重启服务
systemctl restart prometheus.service
安装配置****node_exporter

Node_exporter是可以在Linux系统上运行的计算机度量标准的导出器。

Node_exporter 主要用于暴露 metrics 给 Prometheus，其中 metrics 包括：cpu 的负载，内存的使用情况，网络等。

官方下载地址：[https://github.com/prometheus/node_exporter/releases/download/v0.17.0/node_exporter-0.17.0.linux-amd64.tar.gz](https://github.com/prometheus/node_exporter/releases/download/v0.17.0/node_exporter-0.17.0.linux-amd64.tar.gz

1、安装Node_exporter

解压缩node_exporter并将目录重命名为“node_exporter”放到/usr/local/下。

tar -xf node_exporter-0.17.0.linux-amd64.tar.gz``mv node_exporter-0.17.0.linux-amd64 /usr/local/node_exporter

放在后台启动即可：

nohup ./node_exporter &

2、修改Prometheus的配置文件 prometheus.yml的scrape_configs下添加node_exporter，后重启Prometheus。

scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped
from this config.
  - job_name: 'prometheus'
    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.
    static_configs:
	- targets: ['localhost:9090']
 - job_name: 'node_exporter'
   static_configs:
	 - targets:
	   - '172.31.182.140:9100'
	   - '172.31.182.141:9100'
3 、添加 granfana

模板下载地址：https://grafana.com/api/dashboards/1860/revisions/13/download

导入后的效果：

基于Alert manager实现服务告警

Prometheus本身不支持的告警功能，主要通过插件Alertmanager 来实现告警。Alertmanager用于接收Prometheus发送的告警信息并对告警进行一系列的处理后发送给指定的用户或组。

Prometheus触发一条告警的过程如下：

prometheus server —>触发阈值—>超出指定时间—>alertmanager—>分组|抑制|静默—>媒体类型—>邮件|钉钉|微信等等。

一、安装配置Alert manager

下载解压

$ wget
https://github.com/prometheus/alertmanager/releases/download/v0.20.0/alertmanage
r-0.20.0.linux-amd64.tar.gz
tar -zxf alertmanager-0.20.0.linux-amd64.tar.gz -C /usr/local/
$ cd /usr/local/
$ mv alertmanager-0.20.0.linux-amd64 alertmanager
这里先讲一个坑：

Alermanager会将数据保存到本地中，默认的存储路径为 data/ ，我们在启动文件中直接用 --storage.path 参数指定，不然会报错如下：

Jun 01 17:04:56 localhost.localdomain alertmanager[9742]: level=error ts=2020-
06-01T09:04:56.626Z caller=main.go:236 msg="Unable to create data directory"
err="mkdir data/: permission denied

创建存储目录

mkdir -p /usr/local/alertmanager/data

并用 --config.file 指定alertmanager配置文件路径。

创建启动文件：alertmanager.service

/usr/lib/systemd/system/alertmanager.service

[Unit]
Description=alertmanager
Documentation=https://github.com/prometheus/alertmanager
After=network.target
[Service]
Type=simple
User=prometheus
ExecStart=/usr/local/alertmanager/alertmanager --
config.file=/usr/local/alertmanager/alertmanager.yml --
storage.path=/usr/local/alertmanager/data
Restart=on-failure
[Install]
WantedBy=multi-user.target

配置告警信息

在配置之前，先备份下alertmanager的配置文件

cp /usr/local/alertmanager/alertmanager.yml
/usr/local/alertmanager/alertmanager.yml_bak

然后修改alertmanager.yml

global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.163.com:25'
  smtp_from: '15257862054@163.com'
  smtp_auth_username: '15257862054@163.com'
  smtp_auth_password: 'PNRUAELMPDOMTEMP' # 这里是邮箱的授权密码，不是登录密码
  smtp_require_tls: false
route: # route用来设置报警的分发策略
  group_by: ['alertname'] # 采用哪个标签来作为分组依据
  group_wait: 30s # 组告警等待时间。也就是告警产生后等待10s，如果有同组告警一起发出
  group_interval: 10s # 两组告警的间隔时间
  repeat_interval: 20m # 重复告警的间隔时间，减少相同邮件的发送频率
  receiver: 'default-receiver' # 设置默认接收人
  routes: # 可以指定哪些组接收哪些消息
  - receiver: 'default-receiver'
    continue: true
    group_wait: 10s  
  - receiver: 'ding-receiver'
    group_wait: 10s
    match_re: # 根据标签分组，匹配标签dest=hzjf的为ding-receiver组
	  dest: hzjf
receivers:
- name: 'default-receiver'
  email_configs:
  - to: '2315741184@qq.com'
- name: "ding-receiver"
  webhook_configs:
  - url: 'http://xx.xx.xx.xx/dingtalk'
    send_resolved: true

启动Alertmanager

$ chown -R prometheus:prometheus /usr/local/alertmanager
$ systemctl daemon-reload
$ systemctl start alertmanager.service
$ systemctl enable alertmanager.service
$ systemctl status alertmanager.service
$ ss -tnl|grep 9093
123456

web ui查看 ： http://alertmanager_ip:9093

然后再说一个坑：上面配置了使用邮件报警，但是在发送邮件的时候会有报错 Jun 05 13:35:21

localhost.localdomain postfix/sendmail[9446]: fatal: parameter inet_interfaces: no

local interface found for ::1 ，需要改一下postfix的配置文件：

vim /etc/postfix/main.cf
# 把
inet_interfaces = localhost
# 改为
inet_interfaces = all
# 即可
二、配置Prometheus与Alertmanager通信

vim /usr/local/prometheus/prometheus.yml

alerting:
  alertmanagers: # 配置alertmanager
  - static_configs:
    - targets:
      - 127.0.0.1:9093 #alertmanager服务器ip端口
rule_files: # 告警规则文件
  - 'rules/*.yml'
三、配置报警规则

上面已经定义了，把报警规则的定义文件放在 rules 目录下，所以先要创建这个目录：

mkdir -p /usr/local/prometheus/rules

然后来创建报警规则，这里我们创建三个报警规则：

/usr/local/prometheus/rules/node.yml

groups:
- name: hostStatsAlert
  rules:
  - alert: InstanceDown
	expr: up == 0
	for: 30s
	labels:
	  severity: critical
	annotations:
	  summary: "Instance {{ $labels.instance }} down"
	  description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 30 seconds."
  - alert: hostCpuUsageAlert
	expr: 100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100) > 85
	for: 1m
	labels:
	  severity: warning
	annotations:
	  summary: "Instance {{ $labels.instance }} CPU usgae high"
	  description: "{{ $labels.instance }} CPU usage above 85% (current value: {{ $value }})"
  - alert: hostMemUsageAlert
	expr: 100 - (node_memory_MemFree_bytes+node_memory_Cached_bytes+node_memory_Buffers_bytes) /
node_memory_MemTotal_bytes * 100 > 85
	for: 1m
	labels:
	  severity: warning
	annotations:
	  summary: "Instance {{ $labels.instance }} MEM usgae high"
	  description: "{{ $labels.instance }} MEM usage above 85% (current value: {{ $value }})"
  • alert：报警规则名称
  • expr：基于PromQL表达式告警触发条件，用于计算是否有时间序列满足该条件。
  • for：评估等待时间，可选参数。用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警的状态为pending。
  • labels：自定义标签，允许用户指定要附件到告警上的一组附加标签
  • annotations：用于指定一组附加信息，比如用于描述告警详细信息的文字等，annotations的内容在告警产生时会一同作为参数发送到Alertmanager。

检查告警规则

$ /usr/local/prometheus/promtool check rules
/usr/local/prometheus/rules/node.yml
Checking /usr/local/prometheus/rules/node.yml
SUCCESS: 3 rules found

重启prometheus使告警规则生效。

$ chown -R prometheus:prometheus /usr/local/prometheus/rules
$ systemctl restart prometheus
四、验证

首先在prometheus界面的alert可以看到配置的3条报警规则。

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

1、验证InstanceDown报警规则

停止 192.168.0.182 节点上的 node_exporter 服务，然后查看效果。

$ systemctl stop node_exporter

  • 绿色表示正常。

  • 红色状态为 PENDING 表示alerts还没有发送至Alertmanager，因为rules里面配置了 for: 30s 。

  • 30s之后状态由 PENDING 变为 FIRING ，此时，prometheus才将告警发给alertmanager，在Alertmanager中可以卡看到有一个alert。
    收到邮件：

2、拉高CPU使用率，验证邮件

我们可以手动拉高系统的CPU使用率：

cat /dev/zero>/dev/null

运行命令后cpu使用量会迅速上升。

在这里插入图片描述

收到邮件：
在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值