三种软件观测方法

三种现代软件观测方法

三种方法分别喂：metrics（指标）、logging（日志）、Tracing（分布式追踪）。

Metrics

Metrics是一种定量化的方式，用来衡量系统的状态和性能。通常以数字的形式呈现了反应系统的健康状态，这一属性经常会被用于与运维相关的领域上，比如CPU的使用率、磁盘利用率、redis的使用率、请求的响应时间（如某个API响应时间等等），请求数量（如每秒的QPS）等等。

或许会有人提出疑问说这些在一些的云服务上都能通过云商的服务能监测得到，比如阿里云，腾讯云，华为云等，并不需要自己去构建去学。

但事实上并不是这样，云商的云服务实际上只能看到总体的情况，比如说你的服务器上部署了几十个项目，然后其中的某一个环节崩了，但是在云商的检测平台上总体的状况却是比较平稳的会被整体的情况中和掉，就看不出来哪个服务有没有问题，况且对于现在的很多流量大的业务下，通常使用k8s集群部署，还需要监测具体的容器，这就得需要自己去实现这些功能然后进行观测，毕竟如果某个服务炸了但是一直没被发现或者被攻击了，那么损失的可能就不是几百几千了，各位程序员也不想自己承担这种责任吧。

如何实现

Metrics通常是使用Prometheus+Grafana来实现的，Prometheus是一套时序型数据库，会根据你需要的Metrics自动爬取到自己的时序型数据库（俗称TSDB）中，然后你只需要使用promql对数据库进行查询就能得到自己想要的Metrics。并且Prometheus允许用户基于查询结果设置警告规则，当某个条件满足时，Prometheus会触发警报并通知配置的警报接收器。

Grafana是一套监控图，用于展示数据，你几乎看到的所有市面上的监控图表都是由Grafana实现的。通过配置数据源，Grafana会使用相应的SQL拉取并绘制图表，能直接看到普罗米修斯的各个指标数据图表。

对于成熟的项目来说获取Metrics是必不可少的一部分，可以将Metrics部署到某个接口，并且只开放给开放人员，也可以将Metrics通过Grafana绘制成图表，甚至是再通过调用现在非常火的大模型添加prompt分析后再返回给钉钉、飞书等办公软件，方便开发人员进行查看。

Logging

这是最常见的一种观测方式了，就是日志，日志记录了喜提运行中的各种信息，也方便测试和调试数据，它可以提供问题发生时的上下文信息，是追踪故障和理解系统行为的关键。

特点：

• 详细，在go中几乎的任何报错都可以加上

if err != nil{
hlog.warn(err)//写的伪代码，看具体用什么日志的组件
return err
}

• 上下文性：日志可以包含事件的具体细节（如请求ID、用户信息、请求内容等），帮助开发者进行测试和查看报错的时候更快得发现原因。
• 持久性：日志可以自行得设置时间，可以查看历史记录。

Tracing

Tracing是一种追踪请求在多个服务之间流转的技术，特别适用于分布式系统，他可以帮助理解不同组件之间的交互、瓶颈和延迟。

特点：

• 跨服务追踪：在微服务架构中。请求往往跨越多个服务，Tracing可以追踪整个请求的生命周期，发现延迟和错误。
• 可视化：通常配合图形化工具来展示服务调用的链路，帮助你识别性能瓶颈。
• 请求粒度：每个请求会有一个唯一的追踪ID，追踪ID帮助开发者追踪整个请求的生命周期，展示在不同服务间的调用路劲。

举个列子，现在有个支付系统特别慢，这个支付系统包括API网关，订单系统，库存系统，支付系统，用户发起一个前端的请求，请求首先经过 API 网关，然后通过 订单服务，接着调用 库存服务，最后返回到 支付服务 进行支付处理。在每个服务中，Tracing都会为该请求分配一个唯一的Trace ID，并记录每个服务的相应时间、错误信息和调用状态。

假设系统出现了一个错误，某个用户的支付请求处理失败，而没有清晰的错误信息。在没有 Tracing 的情况下，排查过程可能会非常复杂，可能需要查看日志、手动检查各个服务之间的交互。而通过 Tracing，你可以很方便地追踪到整个请求的过程，找出错误发生的位置。

再举个例子，如果用户结算时显示订单失败，系统没有给出明确错误。

• 通过Tracing系统，你考研通过该请求的ID，追踪它在多个微服务之间的调用。
• 假设在支付系统中抛出了一个异常，你可以看到在支付服务的调用链条中，错误发生在具体位置和上下文信息，例如网络超时等，这样可以快速定位，而不需要看日志的报错再去找原因。

还能解决的问题有：争夺资源导致的性能问题，跨服务调用的问题，性能优化等。

有机会后续会写一个包括三种方式的demo。