随着云原生环境下资源数量暴增、云网快速动态变更、网络传输路径愈发复杂等因素，传统的运维管理模式已经难以应对。
云原生网络正呈现出高密度、多层级与频变动的三大特性：
- 高密度，大型企业的私有云环境中往往部署了上千台宿主机，由于虚拟化后的资源对象数量呈指数级上涨，因此拥有上万个虚拟节点成为常态。与此同时，虚拟网络以及虚拟化后的防火墙、负载均衡器、网关等关键组件数量也会成倍数增长。
- 多层级，从横向来看，云网增加了大量的虚拟交换机、多路复用器等虚拟化设施，网络会话从A端发送至B端需要经历多次IP转换；从纵向来看，网络会话还需要经过从Overlay到Underlay的多层封装。
- 频变动，虚拟化资源调度是云原生的技术优势，但同时高频的调度，也使得共享的计算、网络、存储资源之间产生多样的或深层的相互影响。
能够快速诊断问题是云原生服务不可或缺的特性，排查问题是每个运维人员的日常工作，经常会在这方面耗费大量时间和精力。服务器端尤其如此，有些偶发性的问题在本地难以重现，只有产品线上的日志可供分析。这时每个开发人员都变成了福尔摩斯，在蛛丝马迹之中寻找有价值的线索，演绎推理，大胆假设，小心求证。
以前对于一个单体服务，其服务器数量有限，只需要在有限的服务器上检查日志、分析问题即可。虽然单体服务的逻辑复杂，但毕竟波及的范围有限，处理得多了，也就熟能生巧了。但是云原生服务就不同了，消息在多台服务器之间流转，定位错误更加困难。在众多不熟悉的服务之间查找错误、定位发生故障的服务和节点并分析原因、制定解决方案，不能再靠以前的“三板斧”：读告警、查日志、做验证。所以需要掌握以下关键要点将服务访问链梳理，才能高效地进行问题分析、诊断和排错。
- 关键标识
- TrackingID：我们需要将一个应用流程上的若干条消息串起来。这里通常需要一个跟踪标识，可以顺藤摸瓜，明确来龙去脉。通常我们称为TrackingID，它可以用UUID或者其他全局唯一的字符串来表示。一个Trace指一条调用链路，由一连串的请求组成。
- SpanID：用来表示层级和顺序关系的标识。Span跨度是一个基本的工作单元，多个Span组成一个Trace。SpanID也可以用UUID或者其他全局唯一的字符串来表示。通过SpanID可以查询到Span所包含的描述（annotation）、时间戳（timestamp）、标签（tag）。
- Business ID：业务ID标识通过它来关联TrackingID。比如银行中的全局流水号，在流经每个业务系统时都是唯一的或者若干位是相同的。
- 关键路径
- 业务流程中会经过哪些节点，哪些服务参与了这个流程。
- 节点之间的网络拓扑、跳数，节点的地址，服务的端点、ip、port。
- 关键度量
- API的调用次数，花费的时间，响应码，重点关注40X、50X及超时错误，每秒查询数QPS（Query Per Second）或每秒调用数CPS（Call Per Second）。
- 网络传输中的关键指标延迟、丢包、抖动、带宽等指标。
- 音视频应用中的编码、码率、帧率、分辨率、加密与否。
- 数据库应用中的查询/更新次数、查询/更新时间、TPS（Transaction PerSecond）。
- 关键事件
一个业务流程中调用了哪些服务API，发送或接收了哪些消息，最为关键的、可以衡量成功与否的事件是什么。
- 事件名称。比如，即时通信中的出席（presence）、创建房间（createRoom）、加入房间（joinRoom）、离开房间（leaveRoom），等等。
- 事件发生的时间。服务器端建议用GMT格林尼治时区的时间，便于计算和统计。
以上只是针对云原生运维排查问题给出一些经验。对于运维团队而言，既需要总览全局，还需要细查局部，实现全栈全路径监测。同时，还需要以应用保障为核心，实时洞察云网异常，通过快速、智能化的排障工作流，将云网管理化繁为简，赋能业务高质量发展。
