莫仁鹏《作业帮服务观测体系建设与实践》.pdf

1、作业帮服务观测体系建设与实践莫仁鹏作业帮资深架构师通过系列的段对多变且复杂的服务进观测满运维和诊断的需求服务观测Logging:单个的,离散的事件Metrics:可聚合,按时间维度变化Tracing:在单次请求范围内的信息技术挑战每天志PB级志数据量百GB/秒监控数据量千万/秒追踪数据量千万/秒志体系标可吞吐低延迟低成本志体系架构志输出stdout标准输出 统志输出式 不管理志的命周期 对采集友好 知晓志输出时间志采集log-agent优化 优化 json 解析逻辑 降低打标签的开销 持定义的志消息头 更好的逻辑隔离性能 单核持50MB/S的采集速率 单机采集性能提升3倍 采集CPU使率相下降

2、 70%志传输kafkaKafka Msg Header 集群名称 服务名称 节点IP 实例名称 志成时间 志类型Kafka Msg Body志原志检索怎么检索ELK?志检索检索设计检索持grep志按块切割志存储分级并发进检索志检索检索架构志存储数据沉降志存储存储成本数据来源:腾讯云志检索便接对志格式要求成本低压缩后写到对象存储速度快并对多个chunk进检索30S可以检索1T的志吞吐不做志反序列化 不做全量索引单核持50M/S的志写优势监控体系监控采集系统监控K8S 事件K8S组件ApiServerEtcd络监控节点络延迟集群络延迟集群络带宽基础组件监控注册发现组件服务观测组件运维基础组件中间

3、件监控mysql-proxyredis-proxymq-proxy资源监控Pod资源使Node资源使GPU使集群监控监控采集Runtime监控GoPHPJava定义监控业务指标服务监控监控采集服务流量监控请求QPS请求时延成功率错误码数量服务出流量监控数据库缓存依赖服务件存储流量监控关监控请求QPS请求时延请求码数量流量分布消息队列监控产/消费QPS产/消费耗时消费延迟成功率监控存储兼容Prometheus架构简单稳定 便扩展压缩率每个点位平均占30B吞吐单核持6W/S的写VictoriaMetrics监控存储降准追踪体系为什么需要它节点出现性能瓶颈链路出现络超时服务间调混杂,存在闭环追踪体系

4、架构图追踪采集边上报服务RPC流量服务上报框架打点业务定义打点志上报DB流量缓存流量消息队列产/消费Job运追踪存储ES|ClickHouseES遇到的问题 写性能不够,存在延迟 数据压缩率不理想,磁盘占 集群成本,占观测整体成本的40%ClickHouse性能表现 单核持1.5W/S的写速率 整体写性能提升40%CPU使下降了80%磁盘占下降了50%在我们对服务请求进追踪后,就可以获得服务间的依赖关系,从构建出张服务拓扑图来它持如下功能:实时的拓扑数据查看服务依赖查看服务被谁依赖追踪分析服务拓扑我们也可以换个视,从链路的度去聚合统计追踪数据,就可以得到请求链路分析数据.它持如下功能:服务下每

5、条链路的依赖情况服务在所有链路上的被依赖情况查看请求链路是否存在闭环追踪分析请求链路Serverless上的服务观测遇到的问题志通过云商的志采集器采集然后统投递到Kafka监控Pod的资源指标会在虚拟节点上暴露采集接通过Prometheus采集追踪不持采集需要服务适配容器注 服务编排感 持定义采集 要求适配云商Serverless上的服务观测观测建设先进观测能服务评价服务接质量接成功率接响应时延服务依赖情况资源请求成功率跨云依赖循环依赖服务资源使CPU使率内存使率服务错误数Pod重启次数panic/error志数量5XX状态码数量如何评价服务质量的好坏志、监控和追踪是我们观测服务的三种段,它们并不是完全独的是互相有交叉的.只有结合好这三者,才能让我们在系统中更全,更深地感知我们的服务.结语谢谢 谢谢 观观 看看THANKS