服务可观测平台(一)---服务日志设计&实现(附源码)

本文链接：https://blog.csdn.net/szlhj/article/details/121378577

1. 背景

增强服务可观测性，预测与发现系统性能瓶颈，透视系统状态，为系统调优和改进提供可靠数据支撑

整个平台分为监控门户，服务日志，链路跟踪，业务指标，性能指标5部分，本文重点介绍服务日志

服务日志包括数据变更跟踪，即，服务调用改变了什么数据，数据从什么值改为什么值，但该部分需要链路跟踪支持，因此放到链路跟踪介绍

2. 参考和术语

Metrics

Metrics 计算 Events 发生数量的数据集，这些数据通常具有原子性，且可以聚合。从操作系统到应用程序，任何事物都会产生 Metrics 数据，这些数据可以用来度量操作系统或应用程序是否健康，或者是用以计算一段时间内请求的平均延时。

Logging

记录离散 Events，Logging 描述的是一些列离散事件，在缺乏有力的监控系统时，Logging 数据通常是工程师在定位生产问题时最直接的手段。如果说 Metrics 可以告诉你系统或者应用程序出现问题，那么 Logging 就可以告诉你为什么会出现问题。关于日志的采集现在也有很多方法，比如：filebeat, fluented, loki 等。

Tracing

记录应用程序操作的数据
一次请求的完整生命周期
分布式系统中一次请求经历过多个服务产生操作的数据（Spans）

Tracing 是通过有向无环图的方式记录在分布式系统中发生的 Events 之间的因果关系。云原生场景下，多个服务之间或多或少存在着依赖关系，一次 Tracing 通常会经过多个服务（Span），甚至在高度复杂的分布式系统中，一次 Tracing 包含数以万计的 Span 也是可能存在的。再者，Tracing 更多的是关注这种端到端系统之间的联系，基于该需求，分布式追踪系统应运而生。

3. 总体规划特性

监控门户，统一监控门户，用户自定义视图，告警(页面，钉钉，邮件)；Prometheus+grafana(运维)；elasticsearch agg+数据可视化(开发)
服务日志: 记录时间(起始/结束)，用户，用户地点(ip)，服务节点(ip)，服务名称，模块名称，参数(可配置)，tracingId，支持异步写入，减少服务正常执行影响
服务性能指标，RT，请求数(1m/5m/15m)，异常数(1m/5m/15m)，失败数(1m/5m/15m)
服务调用链路，服务调用拓扑，调用关系性能，topN(最忙服务，最慢服务)
业务度量组件，如，拉单每秒字节数，数据笔数，拉单作业数

*日志收集ELK不在本次计划

*系统监控，如cpu，线程数(jvm)，内存(jvm)，磁盘io，网络io 直接使用Prometheus，不在本平台范围