系列文章

前言

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

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

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

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

可观测性

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

.Net微服务实战之技术选型篇-LMLPHP

日志(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 作为演示。

.Net微服务实战之技术选型篇-LMLPHP

ElasticSearch部署与安装

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

导入 GPG key

rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
10-01 18:56