.Net微服务实战之可观测性（一）

2022-04-24 273

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

可观测可视化 Grafana 版，10个用户账号 1个月

应用实时监控服务-应用监控，每月50GB免费额度

可观测监控 Prometheus 版，每月50GB免费额度

简介： .Net微服务实战之可观测性（一）

系列文章

前言

很多次去面试，有经验的面试官都会问一个问题，你是怎么去定位日常遇到的问题？平常跟同行分享自己遇到的问题，事后他会问我，这种看起来毫无头绪的问题，你是怎么去定位解决的？

其实我们平常不知道怎么问题出在哪，主要是所了解的信息量不足，那么怎么才能提高给咱们定位问题的信息量呢？其实上面两个问题的答案都是同一个：日志、指标、跟踪。

有日志记录才能清楚知道当前系统的运行状况和具体问题；指标是给与后续做优化和定位偶发性问题的一些参考，没指标参考就没标准；我们平常做得多的调试、查看调用栈也是跟踪的一种，但是在分布式时代，更多考量的是跨进程通信的调用链路。

日志、指标、跟踪三者结合起来有一种统称——可观测性

运维是架构的地基，我第一次看到这句是在张辉清写的《小团队构建大网站：中小研发团队架构实践》，说实话，我非常的认同。不少小团队的运维都是由开发兼职的，而团队的运维能力决定了日后架构选型与日常维护。有良好的运维监控体系，就有足够的信息量提供给开发人员进行定位排错。

可观测性

可观测性的意思是可以由系统的外部输出推断其内部状态的程度，在软件系统中，可观察性是指能够收集有关程序执行、模块内部状态以及组件之间通信的数据。分别由三个方向组成：日志（logging）、跟踪（ tracing）、指标（Metrics）《Metrics, tracing, and logging》

日志（logging）

日志的定义特征是它记录离散事件，目的是通过这些记录后分析出程序的行为。

例如：应用程序调试或错误消息通过转换文件描述，通过 syslog 发送到 Elasticsearch；审计跟踪事件通过 Kafka 推送到 BigTable 等数据存储；或从服务调用中提取并发送到错误跟踪服务（如 NewRelic）的特定于请求的元数据。

跟踪（ tracing）

跟踪的定义特征是它处理请求范围内的信息，目的是排查故障。

在系统中执行的单个事务对象生命周期里，所绑定的数据或元数据。例如：RPC远程服务调用的持续时间；请求到数据库的实际 SQL 查询语句；HTTP 请求入站的关联 ID。

指标（Metrics）

指标的定义特征是它们是可聚合的，目的是监控和预警。

这些指标在一段时间内，能组成单个逻辑仪表、计数器或直方图。例如：队列的当前长度可以被建模为一个量规；HTTP 请求的数量可以建模为一个计数器，更新后通过简单的加法聚合计算；并且可以将观察到的请求持续时间建模为直方图，更新汇总到某个时间段中并建立统计摘要。

代表性产品

日志（logging）基本上是ELK (ElasticSearch, Logstash, Kibana) 技术栈一家独大了，但是Logstash比较重量级的，而轻量级的Filebeat可能更加受大家的青睐。下文里的实战部分，我是以EFK(ElasticSearch, Filebeat, Kibana)演示。

跟踪（ tracing）相比于日志就是百花齐放了，Skywalking、zipkin、鹰眼、jeager、Datadog等等……但是在.Net的技术栈里，能提供出SDK的相对会少，所以选择也会少一些，我在之前的实战和下文的演示都是用Skywalking，主要优势无侵入。

指标（Metrics）在云生时代Prometheus比Zabbix更加受大家欢迎，同时Prometheus社区活跃度也占非常大的优势。下文实战部分我以Prometheus 作为演示。

ElasticSearch部署与安装

后面的Skywaking和日志都需要用到ElasticSearch，所以我把部署流程优先提了出来。

导入 GPG key

rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
添加源
vim /etc/yum.repos.d/elasticsearch.repo
[elasticsearch]
name=Elasticsearch repository for 7.x packages
baseurl=https://artifacts.elastic.co/packages/7.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=0
autorefresh=1
type=rpm-md
重新加载
yum makecache
安装
sudo yum install -y --enablerepo=elasticsearch elasticsearch
修改配置
vim /etc/elasticsearch/elasticsearch.yml
network.host: 0.0.0.0
discovery.type: single-node
启动
/sbin/chkconfig --add elasticsearch
sudo -i service elasticsearch start
systemctl enable elasticsearch.service

用浏览器访问，能出现下图就是可以了

Prometheus与Grafana实现指标

架构简析

核心组件

Prometheus server

Prometheus的主程序，本身也是一个时序数据库，它来负责整个监控集群的数据拉取、处理、计算和存储，是使用pull方式由服务端主动拉取监控数据。

Alertmanager

Prometheus的告警组件，负责整个集群的告警发送、分组、调度、警告抑制等功能。需要知道的是alertmanager本身是不做告警规则计算的，简单来说就是，alertmanager不去计算当前的监控取值是否达到我设定的阈值，上面已经提过该部分规则计算是prometheus server来计算的，alertmanager监听prometheus server发来的消息，然后在结合自己的配置，比如等待周期，重复发送告警时间，路由匹配等配置项，然后把接收到的消息发送到指定的接收者。同时他还支持多种告警接收方式，常见的如邮件、企业微信、钉钉等。1.3

Pushgateway

Pushgateway 它是prometheus的一个中间网管组件，类似于zabbix的zabbix-proxy。它主要解决的问题是一些不支持pull方式获取数据的场景，比如：自定义shell脚本来监控服务的健康状态，这个就没办法直接让prometheus来拉数据，这时就可以借助pushgateway，它是支持推送数据的，我们可以把对应的数据按照prometheus的格式推送到pushgateway，然后配置prometheus server拉取pushgateway即可。

UI

Grafana、prometheus-ui是用来图形化展示数据的组件，其中prometheus-ui是prometheus项目原生的ui界面，但是在数据展示方面不太好用，因此推荐grafana来展示你的数据，grafana支持prometheus的PromQL语法，能够和prometheus数据库交互，加上grafana强大的ui功能，我们可以很轻松的获取到很多好看的界面，同时也有很多做好的模版可以使用。

Prometheus Target

采集指标的API，有不同的Exporter，如果redis、mysql、server nodel提供给Prometheus server定时pull数据到数据库。