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产品经理才行，维度得把控好才行。
- .自定义指标收集时候，最好不要侵入性代码，能解耦则解耦。