1.为什么需要监控服务
监控服务的所属服务器硬件(如cpu,内存,磁盘I/O等)指标、服务本身的(如gc频率、线程池大小、锁争用情况、请求、响应、自定义业务指标),对于以前的小型单体服务来说,确实没什么必要,但对于中大型项目,尤其那些群集部署显得尤为重要、尤其是现在的微服务架构,服务众多,而且很多服务都是群集部署,我们更是需要实时知道每一个服务所属的实例(pod,服务器)的运行、请求异常、自定义业务监控指标等情况。
2.监控方案
监控方案因公司而异,没有固定的套路,不一定复杂就好用,越复杂学习、维护、支出成本就越高,适合自己团队就好,抛砖引玉我们之前使用过的方案:
自己的服务器windows群集,.net core微服务架构,使用Telegraf在每台机服务器上进行采集cpu,内存,磁盘IO等等硬件指标数据和sqlserver、redis、rabbitmq等指标信息,使用Prometheus来采集.net core服务的请求相关的数据,无论是硬件指标还是软件指标,统一发送到时序数据库InfulxDB种,使用开源的报表程序Grafana来进行实时报表监控,通过Grafana的Alert条件触发webhook来将报警的数据信息组织好格式后,发送到我们自己写的一个服务接收,然后通过我们研发的通知订阅中心来发送给订阅者邮件、短信、企业微信、桌面等告警提示;
腾讯云Linux服务器,.net core微服务架构,基于k8s编排管理的docker集群,既然是云,很多硬件指标都是自带的监控,使用Prometheus监控集群下的所有服务的异常请求,Rabbitmq,Redis等等中间件指标信息,这次是基于Prometheus自带的时许数据库,使用其altermanger组件进行告警,全部Prometheus配置和自动发现新pod能力,都由牛逼的运维团队完成。
3.Prometheus
本文中,我们主要来说说目前非常流行的监控中间件Prometheus,基于docker的搭建、配置、基本指标采集、自定义业务指标采集。
Prometheus是一个开源的现代化的、支持云原生的系统监控与告警系统,2012年由前谷歌员工开发并做为社区开源项目开发,2015年正式发布,2016年加入云原生计算基金会CNCF,热度仅次于K8S。git地址。
已经很多知名的三方厂商已经基于Prometheus做成了导入器node exporter,比如linux系统,MYSQL数据库,Redis等等非常多的中间件,有了这些导入器,我们直接可以使用,非常丰富的监控指标人家已经为我们做好了。等下,我们演示以下使用linux的导入器来监控linux系统指标。
上面是官方给出的生态组件图,Prometheus整个生态圈组成主要包括prometheus server,Exporter,pushgateway,alertmanager,grafana,Web ui界面,Prometheus server由三个部分组成,Retrieval,Storage,PromQL;
- Retrieval 负责在活跃的target主机上抓取监控指标数据;
- Storage 存储主要是把采集到的数据存储到磁盘中;
- PromQL是Prometheus提供的查询语言模块;
工作流程,Prometheus server定期从活跃的目标主机上通过http pull的方式拉取指标数据,目标主机可以通过prometheus的配置文件进行配置或者通过服务发现方式来发现目标主机;也可以通过pushGateway组件,从目标主机推送该组件,Prometheus server再定时从该组件拉取指标数据;
4.Prometheus基于docker的搭建和监控
- 拉取linux系统的导入器node exporter
docker pull prom/node-exporter
- 启动linux监控容器
docker run --name=node-exporter -p 9100:9100 -itd prom/node-exporter
- 创建prometheus配置文件
mkdir /opt/prometheus
cd /opt/prometheus/
vim prometheus.yml
- 修改配置文件
global:
scrape_interval: 60s
evaluation_interval: 60s
scrape_configs:
- job_name: linuxNode1 --目标任务名称
static_configs:
- targets: ['ip:9100'] --可以是多台
labels:
instance: linux1 --指标维度
5.启动prometheus容器
docker run -d -p 9090:9090 -v /opt/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml --name prometheus prom/prometheus:latest
启动成功后,prometheus的webui也可以使用了,浏览器输入http://IP:9090/targets
5.Grafana
官方说明,grafana是用于可视化大型测量数据的开源程序,他提供了强大和优雅的方式去创建、共享、浏览数据。用过之后确实强大,可配置性灵活,现成的主流中间件基于prometheus的报表模板非常丰富。
- 拉取grafana镜像
docker pull grafana/grafana
- 启动grafana容器
docker run -d -p 3000:3000 --name=jmeterGrafana grafana/grafana
浏览器访问:http://ip:3000(账号密码都是:admin)
选择数据源
至此,我们的linux服务器的报表监控好了,接下来,我们来监控.net core服务的基本指标、请求、自定义业务数据。
6..net core集成prometheus
- nuget引入prometheus-net.AspNetCore
- startup类,管道运行时配置中
//收集一些服务基本信息,比如线程数,内存使用,句柄,3个GC得回收次数统计
app.UseMetricServer();
启动程序访问http://localhost:5000/metrics
做为API服务,我们当然要收集http请求,请求状态,耗时,次数这些
//收集一些服务基本信息,比如线程数,内存使用,句柄,3个GC得回收次数统计
app.UseMetricServer();
//收集http请求和计数监控,比如总请求数,每次请求得耗时
app.UseHttpMetrics();
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
});
- 我们还想收集一些.net core服务运行时一些更深的指标来定位一些困难问题,不用我们写,我们只需要再引入一个别人封装好的包 prometheus-net.DotNetRuntime,就可以得到以下指标:
- 垃圾回收的收集频率和时间;
- 服务占用堆大小;
- 对象堆分配的字节;
- JIT编译和JIT CPU消耗率;
- 线程池大小,调度延迟以及增长/缩小的原因;
- 锁争用情况;
代码如下:
//Program下main方法,为了减少性能开销,可以设置如下
DotNetRuntimeStatsBuilder
.Customize()
//每5个事件个采集一个
.WithContentionStats(sampleRate: SampleEvery.FiveEvents)
//每10事件采集一个
.WithJitStats(sampleRate: SampleEvery.TenEvents)
.WithThreadPoolStats()
.WithGcStats()
.StartCollecting();
再次运行会看到更多的指标了
这么多指标,维度的监控在prometheus原生UI上通过过滤可以看到响应的数据和报表,比如我们要看服务运行总内存,通过指标key:dotnet_total_memory_bytes,去webui上搜索:
- 原生UI多少差点意思,我们去prometheus报表模板市场去看看,有没有基于prometheus的.net core运行时的模板,市场传送门
我们找到一个模板,复制id用上文grafana导入模板的方法,导入进去,看看:
嗯,看上去好像不咋地,很多指标显示不出来,实际项目里,我们知道了指标数据,都是基于grafana自己配置要看的报表,下文我们继续来看看,怎么在.net core中基于promethues自定义一些指标收集,并且利用grafana来配置响应的报表。
7.自定义指标收集与配置报表
通过上文的metrics指标数据,指标数据其实就是key value结构,只不过key中有label增加维度,并且每一个键值对都有响应的指标类型,prometheus的metrics有以下4种主要类型:
- Counter:计数器,单调递增,应用启动之后只会增加不会减少
- Gauge:仪表,和 Counter 类似,可增可减
- Histogram:直方图,柱形图,Histogram其实是一组数据,主要用于统计数据分布的情况 —— 统计落在某些值的范围内的计数,同时也提供了所有值的总和和个数
- Summary:汇总,摘要,summary 类似于 histogram,也是一组数据。不同的是,它统计的不是区间的个数而是统计分位数。
- 接下来,我们在代码里,使用Counter和Gauge这两种类型,来演示自定义指标收集;
- 先定义一个收集中心HUB
public class PrometheusMetricsHub
{
/// <summary>
/// 监控计数器维度统计容器
/// </summary>
public Dictionary<string, Counter> Counters { get; set; } = new Dictionary<string, Counter>();
/// <summary>
/// 监控仪表盘维度统计容器
/// </summary>
public Dictionary<string, Gauge> Gauges { get; set; } = new Dictionary<string, Gauge>();
/// <summary>
/// 创建计数器容器
/// </summary>
/// <param name="key"></param>
/// <param name="desc"></param>
/// <returns></returns>
public void CreateCounter(string key, string desc)
{
if (!this.Counters.ContainsKey(key))
this.Counters.Add(key, Metrics.CreateCounter(key, desc));
}
/// <summary>
/// 创建仪表盘容器
/// </summary>
/// <param name="key"></param>
/// <param name="desc"></param>
/// <returns></returns>
public void CreateGauge(string key, string desc)
{
if (!this.Gauges.ContainsKey(key))
this.Gauges.Add(key, Metrics.CreateGauge(key, desc));
}
/// <summary>
/// 根据维度类型获取监控实例
/// </summary>
/// <typeparam name="TContainer"></typeparam>
/// <param name="prometheusEnum"></param>
/// <param name="key"></param>
/// <returns></returns>
public TContainer GetContainer<TContainer>(PrometheusEnum prometheusEnum, string key) where TContainer : class
{
if (prometheusEnum == PrometheusEnum.Counter && this.Counters.ContainsKey(key))
return this.Counters.GetValueOrDefault(key) as TContainer;
if (prometheusEnum == PrometheusEnum.Gauge && this.Gauges.ContainsKey(key))
return this.Gauges.GetValueOrDefault(key) as TContainer;
return null;
}
- 创建Prometheus注册容器的扩展方法
public static class PrometheusMetricsHubExtenisons
{
public static IServiceCollection AddPrometheusMetricsHub(this IServiceCollection services,Action<PrometheusMetricsHub> buildAction)
{
var hub = new PrometheusMetricsHub();
buildAction(hub);
services.AddSingleton<PrometheusMetricsHub>(hub);
return services;
}
}
- 启动类,使用扩展方法,进行对PrometheusHub配置并注入容器
//注册监控
services.AddPrometheusMetricsHub(hub =>
{
hub.CreateCounter("demoCounter", "测试计数器");
hub.CreateGauge("demoGauge", "测试仪表盘");
});
- 创建一个中间件,每一次请求,都使用Prometheus指标容器进行累加统计
public class PrometheusRequestMiddleware
{
private readonly RequestDelegate _next;
private readonly PrometheusMetricsHub _prometheusMetricsHub;
public PrometheusRequestMiddleware(RequestDelegate next, PrometheusMetricsHub prometheusMetricsHub)
{
_next = next;
_prometheusMetricsHub = prometheusMetricsHub;
}
public async Task InvokeAsync(HttpContext context)
{
try
{
//增加测试数据
var counter = _prometheusMetricsHub.GetContainer<Counter>(Models.PrometheusEnum.Counter, "demoCounter");
var gauge = _prometheusMetricsHub.GetContainer<Gauge>(Models.PrometheusEnum.Gauge, "demoGauge");
counter.Inc();
gauge.Inc();
await _next(context);
}
finally
{
}
}
}
app.UseMiddleware<PrometheusRequestMiddleware>();
- 启动,并查看metrics指标
- 配置Grafana报表
由上图所见,我们自定义的指标监控完成。
8.关于Prometheus高可用
Prometheus本身不支持群集部署,也就是说本身没法动态水平扩容,其实其本身的性能非常高,很少有撑不住情况,我们担心的是硬盘容量问题,假设真的是超级大量的指标数据,怎么办呢,下面有几个方案,也欢迎留言讨论:
- 取舍方案,放弃一些不重要的指标采集,降低指标数据持久化时间,调整采集速率等等一些逻辑优化;
- 服务维度拆分方案,也很容易理解,之前一台Prometheus去采集监控100个服务,现在用3台,划分服务,每台采集30多个服务;
- 分片方案,这种比较极端,某一个服务,pod规模上千甚至更多,这时候,你单台Promethues想完整采集这些pod的服务,对宽带、硬盘、CPU要求极高极高,性能估计也不咋地,这时候就要分片处理,从一台变多台,分别采集,但是这里有2个问题:
1.这么多pod,肯定是要利用注册中心,在promethues配置里通过服务发现来动态配置要监控的服务,consul可以,并且promethues服务发现配置也支持consul,然后在服务注册的时候通过区分一个维度注册,好让对应promethues知道哪些节点是当前这台需要采集的。
2.分片监控一个服务,基于Prometheus本身存储,肯定是没法集中聚合观看了,这里又涉及到统一使用其他数据源,比如InfluxDB,Redis等等,Promethes也支持配置只采集不存储,通过 remote write 方式写入远程存储库。
9.一些问题
- Prometheus不是持久化数据的,但是对于大部分指标监控,我们也不需要持久化,这里有一些产品上的业务指标,要想好是否需要持久化,别某台服务重启,之前数据没了。
- 报表问题,专业的BI产品经理才行,维度得把控好才行。
- .自定义指标收集时候,最好不要侵入性代码,能解耦则解耦。