深入浅出边缘云 | 6. 监控与遥测

随着技术的发展以及应用对时延、带宽、安全的追求，一个明显的技术趋势是越来越多的应用组件将会被部署到企业所管理的网络边缘。本系列是开源电子书Edge Cloud Operations: A Systems Approach的中文版，详细介绍了基于开源组件构建的边缘云的架构、功能及具体实现。

第6章 监控与遥测

运行系统的遥测数据采集是管理平台的重要功能，从而使运维人员能够监控系统行为、评估性能、做出明智的配置决策、响应故障、识别攻击和诊断问题。本章主要讨论三种类型的遥测数据: 指标(metrics) 、日志(logs) 和跟踪(traces) ，以及用于帮助收集、存储并对每种数据采取行动的开源软件栈。

指标(Metrics)是关于系统的定量数据，包括常见的性能指标，如链路带宽、CPU利用率和内存使用情况，还包括与上下层对应的二进制结果，以及其他可以用数字编码的状态变量。系统周期性的通过读取计数器或者返回值产生和收集(例如，每隔几秒)这些指标。这些指标可以与物理资源(如服务器和交换机)、虚拟资源(如虚拟机和容器)或高级抽象(如5.3节中介绍的Connectivity Service)相关联。对于可能的数据源，指标监视堆栈的工作是收集、归档、可视化和分析这些数据。

日志(Logs)是定性数据，当发生值得注意的事件时生成，可用于确定有问题的操作条件(例如可能会触发告警的操作)，但更常见的是用于在检测到问题后进行故障排除。各种系统组件(从底层操作系统内核到高级云服务)向日志系统写入遵循良好定义格式的消息。这些消息包含时间戳，使得日志记录堆栈能够解析和关联来自不同组件的消息。

跟踪(Traces)是由用户发起的事务或作业产生的因果关系记录(例如，服务A调用服务B)。它们与日志相关，但提供了关于不同事件发生的上下文的更专门的信息。跟踪在单个程序中很容易理解，其中运行跟踪通常被记录为内存中的调用栈，但跟踪本质上体现的是分布在云上的微服务网络连接图。这使得问题具有挑战性，但也非常重要，因为通常情况下，理解时间依赖现象(例如为什么某个特定资源超载)的唯一方法是理解多个独立工作流彼此如何交互。

退一步看这三种遥测数据，有助于进一步理解设计空间，为此，我们做了四个观察。

首先，遥测数据通常有两个使用场景，大体上可以分为"监控"和"故障排除"。我们以最一般的术语来表示:(a)在一个状态稳定的系统中主动观察问题的告警信号(攻击、错误、故障、过载情况); 与(b)一旦出现潜在问题的告警，仔细观察以确定根本原因并解决问题(修复错误、优化性能、提供更多资源、抵御攻击)。这种区分很重要，因为前者(监控)需要保证最小的开销，最少的人力参与，而后者(故障排除)可能更具侵入性/更昂贵，通常涉及某种程度的人类专业知识。这不是一个完美的区分，大量运维活动发生在中间灰色区域，但了解可用工具的成本/效益权衡是一个重要的起点。

其次，监控和故障排除约自动化越好。首先是自动检测潜在问题的告警，通常包含仪表板，使人们很容易看到模式，并在所有三种数据类型中钻取相关细节。现在越来越多的利用机器学习和统计分析来识别对人类操作者不明显的更深层次的连接，并最终支持闭环控制，其中自动化工具不仅能够检测问题，而且能够发出纠正错误的控制指令。基于本章目的，我们给出了前两个(告警和仪表板)的例子，并声明后两个(分析和闭环控制)超出了本书范围(但可能作为后续章节概述的遥测数据的应用程序运行)。

第三，从生命周期管理的角度来看，监控和故障排除只是测试的延续，区别只在于是工作在生产负载而不是测试负载下。事实上，同一套工具可以用在开发与生产边界的任何一边。例如，任何一个对程序进行过剖析的人都会认识到，在开发过程中，跟踪是一个非常有价值的工具，既可以追踪错误，又可以调优性能。同样，人工端到端测试可以通过触发早期预警警报为生产系统提供价值，在处理有问题的故障模式时，这可能特别有帮助。

最后，由于各个子系统收集的指标、日志和跟踪都有时间戳，因此可以在它们之间建立相关性，这在调试问题或决定是否需要发出告警时很有帮助。在本章的最后两节中，我们将举例说明这种遥测范围的功能在今天的实践中是如何实现的，并讨论产生和使用遥测数据的未来。

6.1 指标和告警

我们从指标开始，流行的开源监控堆栈使用Prometheus来收集和存储平台和服务指标，Grafana用来可视化指标，Alertmanager用来通知运维团队需要注意的事件。在Aether中，Prometheus和Alertmanager被实例化在每个边缘集群上，Grafana的单一实例在云中集中运行。网上可以找到每个工具的更多信息，所以我们只关注(1)单个Aether组件如何适配这一堆栈，以及(2)这个堆栈如何以特定方式对服务进行定制。

延伸阅读:
Prometheus.
Grafana.
Alertmanager.

6.1.1 导出指标

各个组件通过实现Prometheus导出器(Prometheus Exporter) 来提供组件指标的当前值。通过HTTP查询组件的Exporter，使用简单的文本格式返回相应的指标。Prometheus定期抓取Exporter的HTTP端点，并将指标存储在其时间序列数据库(TSDB, Time Series Database)中，以便进行查询和分析。许多客户端库都可以用于调用代码，以生成Prometheus格式的指标。如果组件指标以其他格式输出，那么通常可以使用工具将其转换为Prometheus格式并导出。

YAML配置文件指定了Prometheus要从中提取指标的一组Exporter端点，以及每个端点的轮询频率。另外，基于Kubernetes的微服务可以通过服务监视器(Service Monitor) 自定义资源描述符(Custom Resource Descriptor, CRD)进行扩展，然后Prometheus查询该描述符以了解微服务提供的任何Exporter端点。

除了基于组件的Exporter外，每个边缘集群还定期测试端到端连接(针对各种端到端定义)。一个测试是判断5G控制平面是否工作(即边缘站点是否可以连接运行在中心云中的SD-Core)，另一个测试是判断5G用户平面是否工作(即终端是否可以连接互联网)。这是一种常见模式，即单个组件可以导出累加器和其他本地变量，但只有"第三方观察者"才能主动测试外部行为，并报告结果。这些例子对应于第4章图19中最右边的"端到端测试"。

最后，当一个系统在多个边缘站点上运行时，就像Aether的情况一样，有一个设计问题，即监测数据是存储在边缘站点上，只在需要时才慢慢拉到中央位置，还是在产生后立即主动推送到中央位置。Aether同时采用了这两种方法，取决于所收集数据的数量和紧迫性。默认情况下，由Prometheus本地实例收集的指标留在边缘站点上，只有查询结果被返回到中央位置(例如，由Grafana显示，如下一小节所述)，适用于高流量和很少查看的指标。一个例外是上面提到的端到端测试，结果被立即推送到中央站点(绕过本地Prometheus)，因为数量不多，而且可能需要立即关注。

6.1.2 创建仪表板

Prometheus收集的指标可以用来可视化Grafana仪表板。在Aether中，意味着在中心云中作为AMP的一部分运行Grafana实例将查询发送到中心Prometheus实例的某个组合以及运行在边缘集群上的Prometheus实例的一个子集上。例如，图25显示了Aether边缘站点集合的摘要仪表板。

图25. 显示Aether边缘部署状态的中央仪表板。

Grafana为最常见的指标集提供了一套预定义的仪表板，特别是与物理服务器和虚拟资源(如容器)相关的仪表板，但也可以进行定制包含服务级指标和其他特定部署信息的仪表板(例如，Aether中的每个企业)。例如，图26显示了UPF(用户平面功能)的自定义仪表盘，这是SD-Core的数据平面包转发器。该例子显示了站点过去一小时的延迟和抖动指标，底部还有三个折叠的面板(PFCP会话和消息)。

图26. 自定义仪表板，显示SD-Core组件转发数据平面UPF的时延和抖动指标。

简单来说，仪表板由一组面板(panels) 构建而成，其中每个面板都有定义良好的类型(例如，图graph、表table、测量gauge、热图heatmap)，绑定到某个特定的Prometheus查询。使用Grafana GUI创建新的仪表板，然后将生成的配置保存在JSON文件中。然后，这个配置文件被提交到配置存储库，当它作为生命周期管理的一部分重新启动时，加载到Grafana中。例如，下面的代码片段显示了与图25中的Uptime面板相对应的Prometheus查询。

"expr": "avg(avg_over_time(ace_e2e_ok{endpoint=\"metrics80\",name=\"$edge\"}[$__interval]) * 100)",

注意，这个表达式包括站点($edge)和计算uptime的时间间隔($__interval)的变量。

6.1.3 定义告警

当组件指标超过某个阈值时，在Prometheus中可以触发告警，通过Alertmanager这一工具，可以将告警发送到一个或多个收件人的电子邮件地址或Slack频道。

通过定义告警规则(alerting rule) 可以针对特定组件定义告警，该规则调用Prometheus查询表达式，每当指定时间段内计算为true时，就会触发一条相应的消息，并将其路由到一组接收者。这些规则记录在YAML文件中，该文件签入配置存储库中并被加载到Prometheus(或者独立组件的Helm Charts可以通过Prometheus Rule自定义资源定义规则)。例如，下面的代码片段显示了两个告警的Prometheus规则，其中expr行对应于提交给Prometheus的相应查询。

- alert: SingleEdgeTestNotReporting
  annotations:
    message: |
      Cluster {{`{{ .Labels.name }}`}} has not reported for at least 5 minutes.
  expr: (time() - aetheredge_last_update{endpoint="metrics80"}) > 300
  for: 1m
  labels:
    severity: critical
- alert: SingleEdgeConnectTestFailing
  annotations:
    message: |
      Cluster {{`{{ .Labels.name }}`}} reporting UE connect failure for at least 10 minutes.
  expr: aetheredge_connect_test_ok{endpoint="metrics80"} < 1
  for: 10m
  labels:
    severity: critical

在Aether中，Alertmanager被配置为向一组公共接收者发送具有关键(critical) 或警告(warning) 级别的告警。如果需要将特定告警路由到不同的接收端(例如，开发人员为特定组件使用的Slack频道)，需要相应改变Alertmanager的配置。

6.2 日志

从Unix早期开始，操作系统程序员就一直在向syslog写入诊断信息。最初收集在本地文件中，如今syslog抽象已经通过添加可扩展的服务适应了云环境。今天，典型的开源日志堆栈使用Fluentd来收集(聚合、缓冲和路由)由一组组件编写的日志消息，Fluentbit作为客户端代理运行在每个组件中，帮助开发人员规范日志消息。然后，ElasticSearch被用来存储、搜索和分析这些消息，Kibana被用来显示和可视化结果。图27显示了一般的数据流，使用Aether的主要子系统作为日志消息的说明性来源。

图27. 日志子系统的日志消息流。

延伸阅读:
Fluentd.
ElasticSearch.
Kibana.

6.2.1 通用模式

日志的关键挑战是在所有组件中采用统一的消息格式，由于集成在一个复杂系统中的各种组件往往是独立开发的，因此这一要求变得复杂起来。Fluentbit通过支持一组过滤器在规范这些消息方面发挥了作用。这些过滤器解析由组件编写的"原始"日志信息(ASCII字符串)，并将"规范的"日志信息输出为结构化的JSON。虽然还有其他选择，但JSON作为文本是合理可读的，这对于人类调试仍然很重要，同时也得到了工具的良好支持。

例如，SD-Fabric组件的开发人员可能会写这样的日志消息:

2020-08-18 05:35:54.842Z INFO [DistributedP4RuntimeTableMirror] Synchronized TABLE_ENTRY mirror for device:leaf1: 0 removed, 2 updated, 4 added

Fluentbit过滤器将其转换成如下结构:

{
  "time": "2020-08-18 05:35:54.842Z",
  "logLevel": "INFO",  "component": "DistributedP4RuntimeTableMirror",
  "log": "Synchronized TABLE_ENTRY mirror for device:leaf1: 0 removed, 2 updated, 4 added"
}

这是一个简化的例子，但确实有助于说明基本的想法，同时还强调了DevOps团队在建立管理平台时面临的挑战，即为整个系统决定一套有意义的名/值对。换句话说，必须为这些结构化的日志信息定义通用模式。Elastic通用模式(Elastic Common Schema) 是一个很好的开始，除此之外，还有必要建立一套公认的日志级别，以及使用每个级别的惯例。例如，在Aether中，日志级别是: FATAL, ERROR, WARNING, INFO, 以及DEBUG。

延伸阅读:
Elastic Common Schema.

6.2.2 最佳实践

当然，建立一个共享日志平台没有什么价值，除非所有单独的组件都被正确的检测以写入日志消息。编程语言通常带有编写日志消息的库支持(例如Java的log4j)，但这只是一个开始。只有当组件遵循以下最佳实践时，日志才是最有效的。

• 平台处理日志传送。组件应该假设stdout/stderr被Fluentbit(或类似工具)吸收到日志记录系统中，并避免通过尝试路由自己的日志使工作变得更复杂。除了管理平台无法控制的外部服务和硬件设备，在部署过程中，必须确定这些系统如何将日志发送到日志聚合器。
• 应该禁用文件日志。将日志文件直接写入容器的分层文件系统被证明是I/O效率低下的，并可能成为性能瓶颈。如果日志也被发送到stdout/stderr，通常也没有必要这样做。通常，当组件在容器环境中运行时，不鼓励将日志记录到文件中。相反，组件应该将所有日志传输到收集系统中。
• 鼓励异步日志。在可伸缩环境中，同步日志可能成为性能瓶颈，组件应该异步写入日志。
• 时间戳应该由程序的日志记录器创建。组件应该使用所选的日志库来创建时间戳，并且使用日志框架所允许的尽可能精确的时间戳。由应用程序或日志处理程序记录时戳可能会比较慢，在接收时创建时间戳也可能会产生延迟，从而使得在日志聚合之后在多个服务之间对齐事件时产生问题。
• 必须能够在不中断服务的情况下更改日志级别。组件应该提供在启动时设置日志级别的机制，以及允许在运行时更改日志级别的API。基于特定子系统确定日志级别的范围是一个有用的特性，但不是必需的。当一个组件由一组微服务实现时，日志配置只需应用于一个实例，就可以应用于所有实例。

6.3 分布式跟踪

运行时跟踪是遥测数据的第三个来源。在云环境中，由于需要跟踪跨多个微服务的每个用户发起的请求的控制流，因此是一个挑战。好消息是，可以通过微服务的底层语言运行时系统(通常在RPC stub中)中激活跟踪支持，而不需要应用程序开发人员在程序中支持。

一般模式类似于我们已经看到的指标和日志: 代码执行过程中生成数据，然后收集、聚合、存储这些数据，并用于显示和分析。主要区别在于我们想要收集的数据类型，对于跟踪来说，通常是API从一个模块到另一个模块的调用序列，这些数据为我们提供了重建调用链所需的信息。原则上，我们可以利用日志系统跟踪，只需要勤奋的记录必要的接口调用信息，但这是一个通用用例，足以保证拥有自己的词汇表、抽象和机制。

在较高的级别上，跟踪(trace) 描述了事务在系统中的移动，由一系列span(每个span表示在服务中完成的工作)和一组span上下文(span context)(每个span上下文表示通过网络从一个服务到另一个服务的状态)交织组成。图28中显示了一个跟踪示例，但从抽象意义上讲，跟踪是一个有向图，其中节点对应于span，而边对应于span上下文。然后，节点和边被打上时间戳，并用端到端执行路径的相关事实(键/值标签)进行注释，包括何时运行以及运行了多久。每个span还包括在执行过程中生成的带时间戳的日志消息，从而简化了将日志消息与跟踪关联的过程。

图28. 横跨两个网络服务的跟踪示例。

同样，就像指标和日志信息一样，细节很重要，而这些细节是由一个商定的数据模型来指定的。OpenTelemetry项目现在正在定义这样的模型，它建立在早期OpenTracing项目之上(该项目又受到Google开发的Dapper分布式追踪机制的影响)。除了定义一个能够捕获最相关的语义信息的模型这一挑战之外，还有一个务实的问题: (1)尽量减少跟踪的开销，以免对应用程序性能产生负面影响，但(2)从跟踪中提取足够的信息，以便使收集这些信息变得有价值。采样是一种被广泛采用的技术，因此被引入到数据收集流水线中来管理取舍。这些挑战的一个结果是，分布式跟踪是正在进行的研究主题，我们可以期待模型定义和采样技术在可预见的未来不断发展和成熟。

延伸阅读:
B. Sigelman, et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Technical Report. April 2010.
OpenTelemetry: High-quality, ubiquitous, and portable telemetry to enable effective observability.
Jaeger: End-to-End Distributed Tracing.

在机制方面，Jaeger是一个被广泛使用的开源跟踪工具，最初由Uber开发(Jaeger目前不包含在Aether中，但在ONF的前身边缘云中使用)。Jaeger包含了用于实现应用程序的语言的指令、收集器、存储，以及用于诊断性能问题并进行根因分析的查询语言。

6.4 集成仪表板

仪表化应用软件生成的指标、日志和跟踪使得收集有关系统健康状况的大量数据成为可能。但是，只有在正确的时间(需要采取行动的时候)将正确的数据显示给正确的人(那些有能力采取行动的人)时，这种工具才有用。创建有用的面板并将其组织成直观的仪表板是解决方案的一部分，但跨管理平台的子系统集成信息也是必要的。

统一所有这些数据是正在进行的工作的最终目标，比如上一节提到的OpenTelemetry项目，但也有机会使用本章介绍的工具来更好的集成数据。本节重点介绍两种一般策略。

首先，Kibana和Grafana都可以配置为显示来自多个来源的遥测数据。例如，可以直接在Kibana中集成日志和跟踪。通常首先将跟踪数据输入到ElasticSearch，然后由Kibana进行查询。类似的，如果有一种方便的方式来查看已收集的指标上下文中与特定组件关联的日志消息，就会很有用。而这很容易完成，因为可以配置Grafana显示来自ElasticSearch的数据，就像显示来自Prometheus的数据一样简单，两者都是可以查询的数据源。这使得创建包含一组选定的日志消息的Grafana仪表板成为可能，类似于图29中所示的来自Aether的消息。在这个例子中，我们看到与SD-Core的UPF子组件相关联的INFO级消息，扩充了图26所示的UPF性能数据。

图29. 日志消息与SD-Core的UPF组件显示在Grafana仪表板上。

其次，第5章中介绍的运行时控制界面提供了改变运行中系统的各种参数的方法，但要想做出明智的决定，获得所需数据以知道需要做哪些改变(如果有的话)是其前提条件。为此，理想做法是在一个综合仪表板上既能访问"按钮"又能访问"刻度盘"。可以通过在运行时控制GUI中加入Grafana框架来实现，在其最简单的形式下，可以显示一组与底层数据模型字段相对应的Web表单(更复杂的控制面板当然也是可能的)。

图30.示例控制仪表板显示了为虚构的Aether站点集合定义的设备组集合。

例如，图30显示了一组虚构的Aether站点的当前设备组，单击"Edit"按钮将弹出一个web表单，该表单允许企业IT管理员修改Device-Group模型的相应字段(未显示)，单击"Monitor"按钮将弹出类似于图31所示的Grafana生成的框架。原则上，这个框架是经过裁剪的，只显示与所选对象最相关的信息。

图31. 选择Device Group关联的监控帧示例。

6.5 可观测性

知道收集什么样的遥测数据，以便在需要的时候得到准确的信息，但这样做又不会对系统性能产生负面影响，这是一个困难的问题。可观测性(Observability) 是一个相对较新的术语，被用来描述这个一般的问题空间，虽然这个术语被认为是最新的市场流行语(确实如此)，但也可以被解释为所有好的系统都渴望的另一个"特性"，与可扩展性(scalability)、可靠性(reliability)、可用性(availability)、安全性(security)、易用性(usability)等等并列。可观测性是一个系统的质量，可以让人们看到其内部运行的事实，从而做出明智的管理和控制决策。这已经成为肥沃的创新空间，因此我们以两个可能在不久的将来成为普遍现象的例子来结束本章。

首先是带内网络遥测(INT, Inband Network Telemetry) ，它利用可编程交换硬件的优势，使运营商能够在数据包流经网络时，提出关于数据包如何被"带内"处理的新问题。这与依赖硬接入固定功能网络设备的预定义计数器集，或仅能检查数据包的抽样子集形成对比。由于Aether使用可编程交换机作为其基于SDN的交换结构的基础，能够使用INT作为第四种遥测数据，并以此对流量模式和网络故障的根本原因提供定性的更深入的见解。

例如，INT已经被用来测量和记录单个数据包在沿着端到端路径穿越一连串交换机时所经历的排队延迟，从而有可能检测到微爆(microbursts, 以毫秒甚至亚毫秒的时间尺度测量的排队延迟)。甚至有可能将这一信息与遵循不同路径的数据包流联系起来，以确定哪些流在每个交换机上共享缓冲容量。作为另一个例子，INT已经被用来记录指导数据包如何交付的决策过程，也就是说，在端到端路径上的每个交换机都应用了哪些转发规则。这为使用INT来验证数据平面是否忠实执行网络运营商所期望的转发行为打开了大门。关于INT的更多信息，请参考我们的SDN配套书籍。

延伸阅读:
L. Peterson, et al. Software-Defined Networking: A Systems Approach. November 2021.

其次是第一章中提到的服务网格(Service Mesh) 的出现。像Istio这样的服务网格框架提供了一种通过在微服务之间注入"观察/执行点"来执行细粒度安全策略并收集云原生应用遥测数据的手段。这些注入点被称为边车(sidecar) ，通常由一个容器来实现，该容器在实现每个微服务的容器旁边运行，从服务A到服务B的所有RPC调用都要通过相关的sidecar。如图32所示，这些sidecar实现运营商想要施加在应用程序上的任何策略，将遥测数据发送到全局收集器并从全局策略引擎接收安全指令。

图32. 服务网格框架概述，通过sidecar拦截在服务A和服务B之间流动的消息。每个sidecar执行从中央控制器接收到的安全策略，并向中央控制器发送遥测数据。

从可观测性的角度来看，sidecar可以被编程以记录运营商可能想要收集的任何信息，原则上甚至可以根据条件的需要动态更新。这为运维人员提供了一种定义系统观测方式的通用方法，而不需要依赖开发者在服务中包含指令。缺点是，sidecar在服务间的通信上带来了不可忽视的开销。由于这个原因，替代sidecar的方法越来越多，特别是Cilium，它使用eBPF(扩展的伯克利包过滤器, extended Berkeley Packet Filters)在内核内而不是在sidecar中实现可观测性、安全性和网络数据平面特性。

关于Istio服务网格的更多信息，我们推荐Calcote和Butcher的书，同时Cilium项目在其网站上有大量的文档和教程。

延伸阅读:
L. Calcote and Z. Butcher Istio: Up and Running. October 2019.
Cilium: eBPF-based Networking, Observability, Security.

关于本书

深入浅出边缘云(Edge Cloud Operations: A Systems Approach) 的源代码可在GitHub上根据创作共用许可协议(CC BY-NC-ND 4.0)获得。邀请社区在相同条款下提供更正、改进、更新和新材料。虽然本授权并不自动授予制作衍生作品的权利，但我们非常希望与感兴趣的各方讨论衍生作品(如翻译)。请联系discuss@systemsapproach.org。

如果使用了该作品，应包括以下版权信息:

Title: Edge Cloud Operations: A Systems Approach
Authors: Larry Peterson, Scott Baker, Andy Bavier, Zack Williams, Bruce Davie
Source: https://github.com/SystemsApproach/ops
License: CC BY-NC-ND 4.0

阅读本书

本书是系统方法系列的一部分，其在线版本发布在https://ops.systemsapproach.org。

要跟踪进度并接收关于新版本的通知，可以在Facebook和Twitter上关注这个项目。要阅读关于互联网发展的评论，可以关注系统方法Substack。

构建本书

要构建可供网页浏览的版本，首先需要下载源码:

$ mkdir ~/systemsapproach
$ cd ~/systemsapproach
$ git clone https://github.com/SystemsApproach/ops.git 
$ cd ops

构建过程实现在Makefile中，并且需要安装Python。Makefile将创建一个虚拟环境(venv-docs)，用于安装文档生成工具集，可能还需要使用系统的包管理器安装enchant C库，以便拼写检查器正常工作。

请运行make html，在_build/html中生成HTML。

请运行make lint检查格式。

执行make spelling检查拼写。如果有拼写正确但字典中没有的单词、名称或首字母缩写词，请添加到dict.txt文件中。

请运行make查看其他可用的输出格式。

向本书投稿

如果你使用这些材料，希望也愿意给出回馈。如果你是开放源码的新手，可以查看How to Contribute to Open Source指南，你将学到如何发布Issue，如何发出Pull Request合并改进，以及其他一些主题。

如果你想投稿，并且正在寻找一些需要关注的内容，请查看wiki上的当前待办事项列表。

关于作者

Larry Peterson是普林斯顿大学计算机科学系Robert E. Kahn名誉教授，并从2003年到2009年担任主席。Peterson教授的研究主要集中在互联网大规模分布式系统的设计、实现和操作，包括广泛使用的PlanetLab和MeasurementLab平台。他目前正在为开放网络基金会(ONF)的Aether接入边缘云项目做出贡献，并担任首席科学家。Peterson是美国国家工程院院士，ACM和IEEE院士，2010年IEEE Kobayashi计算机与通信奖得主，2013年ACM SIGCOMM奖得主。Peterson拥有普渡大学博士学位。

Scott Baker是英特尔云软件架构师，在英特尔收购开放网络基金会(ONF)工程团队时加入英特尔。在ONF期间，他领导了Aether DevOps团队。在ONF之前，曾在普林斯顿大学和亚利桑那大学从事云相关的研究项目，包括PlanetLab、GENI和VICCI。Baker于2005年获得亚利桑那大学计算机科学博士学位。

Andy Bavier是英特尔云软件工程师，在英特尔收购开放网络基金会(ONF)工程团队时加入英特尔。在ONF期间，他参与了Aether项目。在加入ONF之前，他是普林斯顿大学的研究科学家，从事PlanetLab项目。1990年在威廉玛丽大学获得哲学学士学位，1995年在亚利桑那大学获得计算机科学硕士学位，2004年在普林斯顿大学获得计算机科学博士学位。

Zack Williams是英特尔云软件工程师，在英特尔收购开放网络基金会(ONF)工程团队时加入英特尔。在ONF期间，他参与了Aether项目，并领导了基础设施团队。在加入ONF之前，他是亚利桑那大学的系统程序员。Williams于2001年获得亚利桑那大学计算机科学学士学位。

Bruce Davie是计算机科学家，因其在网络领域的贡献而闻名。他是VMware亚太区的前副总裁兼首席技术官，在VMware收购SDN初创公司Nicira期间加入VMware。在此之前，他是Cisco Systems研究员，领导一个架构师团队，负责多协议标签交换(MPLS)。Davie拥有超过30年的网络行业经验，并合著了17个RFC。他于2009年成为ACM研究员，并于2009年至2013年担任ACM SIGCOMM主席。他还在麻省理工学院做了五年的访问讲师。Davie是多本书的作者，拥有40多项美国专利。

你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。
微信公众号：DeepNoMind