云原生（业务）网络监控的建设思路与实现
Posted 云杉网络
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了云原生（业务）网络监控的建设思路与实现相关的知识，希望对你有一定的参考价值。
受新冠疫情的影响，国内企业上云步伐被加速，云网络的服务水平成为企业上云的基石。国内外多家第三方机构的调查报告显示，企业上云的重要原则之一是在尽可能不修改应用的前提下，保证业务体验的一致性。得益于良好的可移植性、轻量、敏捷等优点，以容器、微服务为代表的云原生技术在企业上云过程中扮演着越来越重要的角色。
如上图所示，企业IT基础设施云化过程中引入的容器显著地加剧了云数据中心网络的复杂性，并进一步放大了虚拟网络的“黑盒”效应，给企业的监控、运维与安全合规带来了更大的挑战。企业需要建立面向云的网络监控架构，使之具备物理网络、池内网络流量统一分发，资源、网络、应用一体化监控管理能力，以便全面掌握网络资源使用状态，提高云网整体保障能力。
- 01 -
解决云网监控的难题，首先在于破解网络流量的“黑盒”——亦即，网络流量数据的可视化。传统的物理服务器的状态通常可以通过几个监控指标进行描述，但是随着云（虚拟化）系统越来越复杂以及业务安全稳定运行的要求越来越高，需要监控的对象正渐渐从“基础设施”转到“应用”本身。下图描述了对一个复杂系统的感知程度和能够收集到的信息之间的关系，而在云原生的行业大趋势下，通过技术手段描述系统更全面的状态、解决复杂系统的可观测性正在成为业界共识。
云计算正在颠覆传统的IT服务模式，网络作为云计算基础设施背后的重要角色，也在不断进化。云原生技术尤其是微服务的引入成为了业务和网络深度融合的催化剂，对云网络的全面观测成为业务端强劲的驱动力或者说需求。在网络方面，传统的监控工具通常是为了监控设备而设计的，其基于静态配置文件的方法并不适用于微服务或容器。在容器环境中，容器以令人难以置信的速度被创建和销毁，要解决云原生（业务）网络的观测性问题必须从更深入的数据着手。从当前较为成熟的NPM和APM市场来看，日志、Metrics和Tracing是解决云网络可观测性的三类重要数据源。
大多数现代监控系统为诸多不同的目的提供了大量的指标，用户很容易淹没其中，难以聚焦到与应用相关的核心数据上。鉴于网络具备独特的时序特性，我们应该更关注Metrics的数据，对于Tracing和日志数据，我们通常关注Service/Ingress前后L4流关联、L7服务请求关联以及相关日志信息。我们重点关注Metrics四个方面的指标量：
第一个方面是时延，它刻画的是当前的业务系统的访问是否顺畅、耗费的时间是否在增加，是检测性能下降问题的一个重要标志。例如说我们从四层网络的角度看，有三次握手的时延、协议栈响应的时延；从应用的角度看，有HTTP响应的时延、DNS响应的时延。
第二个方面是流量，更多的是刻画系统的吞吐。例如一个应用系统的BPS是多少、PPS是多少？新建连接数、新建连接速率是多少？HTTP的请求数是多少等？流量可以等同于吞吐量或者是速率这样的指标。
第三个方面是错误，错误可能发生在网络层，比如TCP的建连失败、TCP的重置、TCP的重传、TCP的零窗口，还可能会发生在应用层，比如HTTP的400、500等错误或者是DNS解析失败。错误信息是一个非常好的指标，通常能说明更深层次的问题。我们不仅要检测显性错误，还要检测隐性错误，例如不当的网络配置信息。
第四个方面是负载——通常来自于系统信息，一般来讲是对计算和存储资源的描绘，在虚拟网络情情况下也可以描述虚拟交换机的负载。网络层面的负载主要体现在并发连接数、当前正在活跃的用户数等指标。测量负载的关键是选择制约系统性能的指标，从Kubernetes节点获取系统指标与其他系统基本相同。
我们对网络的指标监控通常要考虑以上四个方面，这四个方面（外部可观测数据以及系统自身数据）能够覆盖一个分布式系统所有的角落，最终实现分布式系统的可观测。
如前文所述，企业上云的重要原则之一是在尽可能不修改应用的前提下，保证业务体验的一致性。同理，对于已经上云的业务进行监控，也要确保其符合“云原生”的特性。云杉网络自研的DeepFlow®正是这样一款云网络流量采集、分发、可视化与监控诊断产品，帮助企业在混合云环境中统一采集并分发任意工作负载之间的网络流量，实现对云原生业务关键路径的全面性能监控，并提供虚拟网络端到端的全路径诊断，解决企业分布式业务上云后遇到的监控、运维、安全等难题。
众所周知，云的特性是弹性、敏捷。不同于传统烟囱式的监控系统，DeepFlow®在部署方式、随云扩展、多云平台对接、分布式架构几个方面率先做到了弹性和敏捷。
为了提升DeepFlow®的适用性，云杉网络做了大量的工作适配主流的资源平台和云平台，并不是简单调用API，而是要与知识图谱等对接和关联起来的。目前，DeepFlow支持与20多个市场主流平台做资源信息的同步，通过抽象统一的采集层、构建了较为完备的网络知识图谱的体系。
部署方式无依赖、一键式云原生部署
DeepFlow®采集器软件针对不同的资源池提供不同形态的版本，以发挥最优的网络流量捕获能力。采集器以进程形态独立运行并支持一键部署，共有包括VMware ESXi采集器、KVM采集器、KVM-DPDK采集器、HyperV采集器、Workload-V/Workload-P采集器、容器OnVM采集器、容器OnHost采集器、专属服务器采集器等多个类型；对于裸金属设备资源池，获取其池内网络流量可通过Leaf交换机、接入交换机的端口镜像，汇总至TAP设备后交由专属服务器类型采集器实现对数据包处理操作，也可以选择将采集器安装在每一台需要采集的裸金属设备系统上。
DeepFlow®控制器按角色分为主控制器、备控制器、从控制器，用户可根据实际部署要求进行灵活选择。单一控制器可管理2000个采集器，足以覆盖一个可用区涉及的采集规模。主、备控制器与从控制器协同工作，控制器集群规模最大支持50台，整体可管理10万台采集器规模，可满足大型企业私有IT、公有云、容器等对云数据中心资源池建设持续演进的网络流量监控分析要求。此外，采集器不再是简单地获取网络流量管道，是具备对本地采集的网络流量进行处理的计算单元，众多采集器以及控制器构建成一个与云网规模一致的分布式流量处理系统。
DeepFlow®平台提供开放的数据供给服务。处理后的包头，网络元数据、遥测统计数据通过网络平面汇总至数据节点的高性能时序数据库中，用户可通过API、消息队列为其他数据消费平台调用，数据节点与控制器一样支持水平扩展。用户可在每个区域、可用区都可以配置高性能时序数据库。数据供给服务同时将采集与后端各类分析工具解耦，避免流量采集器局限在仅为单一工具服务的竖井中。
企业在上云过程中，云网融合会逐步加深、业务或者说应用对网络的依赖将会越来越大。企业在建设统一的监控体系时，需要秉持开放和解耦的原则，重点聚焦云端业务的核心数据，避免重复建设和系统绑定。
阅读原文 访问云杉网络官方网站！
以上是关于云原生（业务）网络监控的建设思路与实现的主要内容，如果未能解决你的问题，请参考以下文章