1952108 李凯胤 第一周任务 - XLab-Tongji/2021-WorkloadSimulation GitHub Wiki
1.云原生简介
云原生（CloudNative）以容器化、微服务、可持续交付性，快速构建/运行弹性扩展应用，应用构建简便快捷，部署轻松自如，应用按需伸缩，云原生是一套技术体系/方法论。Cloud表示应用程序位于云中，而非传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。
云原生概括为4个要点：DevOps+持续交付+微服务+容器，云原生架构的应用系统应该采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。
云原生构建应用简便快捷，部署应用轻松自如、运行应用按需伸缩。优点不一而足，缺点微乎其微，远优于传统Web框架。
1.1 关于云端
云是和本地相对的，传统的应用必须跑在本地服务器上，现在流行的应用都跑在云端，云包含了IaaS、PaaS和SaaS。
把云计算理解成一栋大楼，而这栋楼又可以分为顶楼、中间、低层三大块。那么我们就可以把IaaS（基础设施）、PaaS（平台）、SaaS（软件）理解成这栋楼的三部分。基础设施在最下端，平台在中间，软件在顶端。别的一些“软”的层可以在这些层上面添加。
1.1.1 IaaS: Infrastructure-as-a-Service（基础设施即服务）
举例：几年前如果你想在办公室或者公司的网站上运行一些企业应用，你需要去买服务器，或者别的高昂的硬件来控制本地应用，才能让你的业务正常运行。
但现在可以租用IaaS公司提供的场外服务器，存储和网络硬件。这样一来，便大大的节省了维护成本和办公场地。
1.1.2 PaaS: Platform-as-a-Service（平台即服务）
PaaS处于中间层，服务商提供基础设施底层服务，提供操作系统（Windows，Linux）、数据库服务器、Web服务器、域控制器和其他中间件，以及服务模型中的备份服务等中件层服务。例如IIS，.NET，Apache，MySQL ……客户自己控制上层的应用程序部署与应用托管的环境。
1.1.3 SaaS: Software-as-a-Service（软件即服务）
SaaS处于最上层，服务商提供基于软件的解决方案，满足客户最终需求；如OA、CRM、MIS、ERP、HRM、CM、Office 365、iCloud、G Suite等应用，客户不需考虑任何形式的专业技术知识，获得完整的软件包，使他们的日常工作和生活变得更轻松。生活中，几乎我们每一天都在接触SaaS云服务，比如：我们平时使用的苹果手机云服务，网页中的一些云服务等。
1.2 关于原生
原生就是土生土长的意思，我们在开始设计应用的时候就考虑到应用将来是运行云环境里面的，要充分利用云资源的优点，比如️云服务的弹性和分布式优势。
1.3 云原生的基本内容
目前业界公认的云原生主要包括以下几个层面的内容。
1.4 云原生 = 微服务 + DevOps + 持续交付 + 容器化？
1.4.1 微服务
微服务解决的是我们软件开发中一直追求的低耦合+高内聚。
微服务的本质是把一块大饼分成若干块低耦合的小饼，比如一块小饼专门负责接收外部的数据，一块小饼专门负责响应前台的操作，小饼可以进一步拆分，比如负责接收外部数据的小饼可以继续分成多块负责接收不同类型数据的小饼，这样每个小饼出问题了，其它小饼还能正常对外提供服务。
微服务将系统的不同单元或功能运行不同的容器，每一个服务的容器数量可以根据自己的负载进行调整。比如，一个大系统包含用户登录、货品展示、货品交互等功能，但这个系统的各个部分并不是同时线性增加的，有些部分可能忙一些，有些部分的容量可能还有富余。
1.4.2 DevOps
DevOps如果从字面上来理解只是Dev（开发人员）+Ops（运维人员），表示开发和运维不再是分开的两个团队，而是你中有我，我中有你的一个团队。
实际上，它是一组过程、方法与系统的统称。首先，组织架构、企业文化与理念等，需要自上而下设计，用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合，简单而言组织形式类似于系统分层设计。其次，自动化是指所有的操作都不需要人工参与，全部依赖系统自动完成，比如上述的持续交付过程必须自动化才有可能完成快速迭代。再次，DevOps的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发部门和运维部门必须紧密合作。总之，DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。
1.4.3 持续交付
持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用，要做到这点非常非常难。缺乏持续交付能力的话，每次版本上线之后都会给不同的用户造成不同程度的影响。持续交付更多是代表一种软件交付的能力
1.4.4 容器化
容器技术解决了本地、测试、线上环境的隔离，解决部署服务初始化繁琐的问题，运维的时候不需要再关心每个服务所使用的技术栈，每个服务都被无差别地封装在容器里，可以被无差别地管理和维护。现在比较流行的工具是docker和k8s。
容器，即Container，可翻译成集装箱，在港口把货物用集装箱封装起来，然后经过货轮从海上运输到另一个港口，再在港口卸载后通过大货车运送到目的地。如此货物便可在任何地方流转时，都封装在集装箱，无需根据是在货轮还是大货车而对货物重新装配。
软件的容器也就这么个作用，它封装的是软件的运行环境。容器本质是Linux里的进程，但容器通过Namespace和Cgroups，可有自己的root文件系统、网络配置、进程空间，甚至自己的用户ID空间，如此容器里的进程就像运行在宿主机上的另外一个单独的os内，从而实现与宿主机os里运行的其他进程隔离。
2013 年 docker 出现，容器技术成熟，然后围绕容器编排一场大战，最后在 2017 年底，Kubernetes 胜出。2015 年 CNCF 成立，（CNCF 是目前云计算领域最成功的开源基金会之一，是 Kubernetes、 etcd、Envoy 等知名开源项目的托管基金会）并在近年形成了 cloud native 生态。以下简单介绍一下容器发展的历史进程：
基于虚拟机技术，陆续出现了 IaaS/PaaS/FaaS 等形态，以及他们的开源版本。
从 2013 年 Docker 项目发布开始说起，Docker 项目的发布使得全操作系统语义的沙盒技术唾手可得，使得用户能够更好地、更完整地打包自己的应用，使得开发者可以轻而易举的获得了一个应用的最小可运行单位，而不需要依赖任何 PaaS 能力。这对经典 PaaS 产业其实是一个“降维打击”。
2014 年的时候，Kubernetes 项目发布，其意义在于 Google 将内部的 Borg/Omega 系统思想借助开源社区实现了“重生”，并且提出了“容器设计模式”的思想。而 Google 之所以选择间接开源 Kubernetes 而不是直接开源 Borg 项目，其实背后的原因也比较容易理解：Borg/Omega 这样的系统太复杂了，是没办法提供给 Google 之外的人使用，但是 Borg/Omega 这样的设计思想却可以借助 Kubernetes 让大家接触到，这也是开源 Kubernetes 的重要背景。
这样到了 2015 年到 2016 年，就到了容器编排“三国争霸”的时代，当时 Docker、Swarm、Mesos、Kubernetes 都在容器编排领域展开角逐，他们竞争的原因其实也比较容易理解， 那就是 Docker 或者容器本身的价值虽然大，但是如果想要让其产生商业价值或者说对云的价值，那么就一定需要在编排上面占据一个有利的位置。
其中，Swarm 更偏向于生态，而 Mesos 技术更强一些。相比之下， Kubernetes 则兼具了两者优势，最终在 2017 年“三国争霸”的局面中得以胜出，成为了当时直到现在的容器编排标准。这一过程的代表性事件就是 Docker 公司宣布在核心产品中内置了 Kubernetes 服务，并且 Swarm 项目逐渐停止维护。
到了 2018 年的时候，云原生技术理念开始逐渐萌芽，这是因为此时 Kubernetes 以及容器都成为了云厂商的既定标准，以“云”为核心的软件研发思想逐步形成。K8S正式毕业。
2019 年，阿里巴巴宣布要全面上云，而且“上云就要上云原生”。我们还可以看到，以“云”为核心的软件研发思想，正逐步成为所有开发者的默认选项。像 Kubernetes 等云原生技术正在成为技术人员的必修课，大量的工作岗位正在涌现出来。
1.5 云原生时代下的十二要素
“12要素”英文全称是The Twelve-Factor App，最初由Heroku的工程师整理起步，是集体贡献总结的智慧，如图所示。12-Factor并非相互独立，而是一个整体，有的涉及代码和框架（Node和Rails），有的涉及工具（Docker和Compose）有的涉及架构和平台。在云原生时代，12-Factor仍然具有强大的生命力，每一条原则都是应用开发的珠玑，而且每一个原则也不是一成不变的，随着新的理念出现，原有的Factor会得到延伸和发展，也会出现新的原则。
2.可观测数据
我们来回顾一下提供可观测性的大背景，正如前面提到的云原生应用，云原生应用目前是大行其道，除了表面光鲜亮丽的热度之外，其内容丰富多彩。主要涉及到以下三大点：
首先是应用架构发生了变化：
- 从单体应用向微服务过渡
- 应用架构过渡为松耦合系统
- 应用版本迭代更快、周期更短
基础设施层发生了变化：
- 容器化、应用自身快、轻、微
- Kubernetes 成为运行容器的默认平台
- IaaS、PaaS 和 CaaS （通信即服务，将传统电信能力封装成API）平台底层来承载 Kubernetes 平台
软件生命周期：
- 服务通过 DevOps 流水线持续部署
- 服务变更低成本和低风险
- 呈现高频率和全自动变更
规模化的微服务对我们分布式系统的要求提升：
- 需要在分布式系统下确保我们的服务发现/注册中心的可用性；
- 必须面对容器化环境给我们系统带来的挑战；
- 多个服务之间的依赖关系变得复杂无比，需要通过一定 DevOps 手段来对系统进行治理。
同时也对我们如何对其监控带来了挑战：
- 微服务的规模和动态性使得数据收集的成本大幅度提高，例如 CPU 、内存和网络传输的开销；
- 大量的监控数据对后台数据处理分析的产生影响，服务体量非常大的情况下，出现了问题之后，如何快速定位到发生问题的根本原因上；
- 对于可视化和关联分析的要求方面，传统APM(应用性能监测软件)缺少好的手段。
在如今云原生时代，或者说在分布式系统时代，系统故障点可能出现在任何地方，任何地方都有出现故障的隐患。这也许会让你开始觉得分布式系统或许开始变得不那么美好。采用容器化之后，可能基础设施都已经不受我们太强的控制。所以，现在更多的是希望在这样一个云原生系统下的观测。
传统的运维可能只能给我们带来最顶层的“告警”和“概况”。
那么当应用系统宕机或者一些别的原因，运维需要更深层次的错误信息的排错，即可观测。
而可观测性包含了传统监控的范畴。总的来看这一套“信号量”显得有点复杂，我们尝试将其精简一下：
可观测信息的三个维度：
- Tracing：调用链；
- Logging：日志；
- Metrics：指标。
- Tracing，面向的是请求，可以轻松分析出请求中异常点，但与 Logging 有相同的问题就是资源消耗较大。通常也需要通过采样的方式减少数据量。比如一次请求的范围，也就是从浏览器或者手机端发起的任何一次调用，一个流程化的东西，我们需要轨迹去追踪。再举例来说就是：对某一项工作的定期汇报，某个工作开始做了A，制作A事件的报告，收集起来，然后这个工作还有B、C、D等条目，一个个处理，然后都汇总进报告，最终的结果就是一个Tracing。
- Logging，描述一些离散的（不连续的）事件，展现的是应用运行而产生的事件或者程序在执行的过程中间产生的一些日志，可以详细解释系统的运行状态，但是存储和查询需要消耗大量的资源。所以往往使用过滤器减少数据量。Logging举例来说就是：废品回收站。各种各样的物品都会汇总进入到配品回收站里，然后经过分门别类归纳整理，成为各种可回收资源分别回收到商家那里。一般来说我们在大型系统中提到Logging说的都不是简单的日志，而是日志聚合系统。
- Metrics，是一种聚合数值，存储空间很小，可累加的，具有原子性，每个都是一个逻辑计量单元，或者一个时间段内的柱状图。可以观察系统的状态和趋势，但对于问题定位缺乏细节展示。这个时候使用等高线指标等多维数据结构来增强对于细节的表现力。
3.Elasticsearch介绍
3.1 Elasticsearch的文件存储
Elasticsearch是面向文档型数据库，一条数据在这里就是一个文档，用JSON作为文档序列化的格式，比如下面这条用户数据：
{
"name" : "John",
"sex" : "Male",
"age" : 25,
"birthDate": "1990/05/01",
"about" : "I love to go rock climbing",
"interests": [ "sports", "music" ]
}
用oracle之类的数据库存储就会容易想到建立一张User表，有各种各样的字段，在Elasticsearch里这就是一个文档，当然这个文档会属于一个User的类型，各种各样的类型存在于一个索引当中。实际上有类似的关系：
关系数据库 ⇒ 数据库 ⇒ 表 ⇒ 行 ⇒ 列(Columns)
Elasticsearch ⇒ 索引(Index) ⇒ 类型(type) ⇒ 文档(Docments) ⇒ 字段(Fields)
一个 Elasticsearch 集群可以包含多个索引(数据库)，也就是说其中包含了很多类型(表)。这些类型中包含了很多的文档(行)，然后每个文档中又包含了很多的字段(列)。Elasticsearch的交互，可以使用Java API，也可以直接使用HTTP的Restful API方式，比如我们打算插入一条记录，可以简单发送一个HTTP的请求：
PUT /megacorp/employee/1
{
"name" : "John",
"sex" : "Male",
"age" : 25,
"about" : "I love to go rock climbing",
"interests": [ "sports", "music" ]
}
3.2 索引
Elasticsearch最关键的就是提供强大的索引能力。
Elasticsearch的精髓：
一切设计都是为了提高搜索的性能
另一层意思：为了提高搜索的性能，难免会牺牲某些其他方面，比如插入/更新，否则其他数据库不用混了。前面看到往Elasticsearch里插入一条记录，其实就是直接PUT一个json的对象，这个对象有多个fields，比如上面例子中的name, sex, age, about, interests，那么在插入这些数据到Elasticsearch的同时，Elasticsearch还默默的为这些字段建立索引--倒排索引，因为Elasticsearch最核心功能是搜索。
Elasticsearch的索引思路:
将磁盘里的东西尽量搬进内存，减少磁盘随机读取次数(同时也利用磁盘顺序读特性)，结合各种压缩算法，用很苛刻的态度使用内存。
对于使用Elasticsearch进行索引时需要注意:
- 不需要索引的字段，一定要明确定义出来，因为默认是自动建索引的
- 同样的道理，对于String类型的字段，不需要analysis的也需要明确定义出来，因为默认也是会analysis的
- 选择有规律的ID很重要，随机性太大的ID(比如java的UUID)不利于查询
3.3 相关术语及知识
Elasticsearch 是一个分布式、可扩展、实时的搜索与数据分析引擎。 它能从项目一开始就赋予数据以搜索、分析和探索的能力，这是通常没有预料到的。 为了解决原始数据如果只是躺在磁盘里面根本就毫无用处的处境。例如GitHub 使用 Elasticsearch 对1300亿行代码进行查询。
Elasticsearch 也是使用 Java 编写的，它的内部使用 Lucene 做索引与搜索，但是它的目的是使全文检索变得简单， 通过隐藏 Lucene 的复杂性，取而代之的提供一套简单一致的 RESTful API。Elasticsearch 将所有的功能打包成一个单独的服务，这样你可以通过程序与它提供的简单的 RESTful API 进行通信， 可以使用自己喜欢的编程语言充当 web 客户端，甚至可以使用命令行（去充当这个客户端）。
| Elasticsearch：存储、搜索和分析。 |
|---|
| Log stash：收集、丰富和传输。 |
| Beats：收集、解析和发送。 |
| Kibana可以实现交互式探索，实现可视化和共享数据，并管理和监视堆栈。 |
| Sense 是一个 Kibana 应用 它提供交互式的控制台，通过你的浏览器直接向 Elasticsearch 提交请求。 |
| 索引 这个词在 Elasticsearch 语境中有多种含义， 这里有必要做一些说明： |
|---|
| 索引（名词）： |
| 如前所述，一个 索引 类似于传统关系数据库中的一个 数据库 ，是一个存储关系型文档的地方。 索引 (index) 的复数词为 indices 或 indexes 。 |
| 索引（动词）： |
索引一个文档 就是存储一个文档到一个 索引 （名词）中以便被检索和查询。这非常类似于 SQL 语句中的 INSERT 关键词，除了文档已存在时，新文档会替换旧文档情况之外。 |
| 倒排索引： |
| 关系型数据库通过增加一个 索引 比如一个 B树（B-tree）索引 到指定的列上，以便提升数据检索速度。Elasticsearch 和 Lucene 使用了一个叫做 倒排索引 的结构来达到相同的目的。 |
| 默认的，一个文档中的每一个属性都是 被索引 的（有一个倒排索引）和可搜索的。一个没有倒排索引的属性是不能被搜索到的。我们将在 倒排索引 讨论倒排索引的更多细节。 |
Elasticsearch 默认按照相关性得分排序，即每个文档跟查询的匹配程度。
"_score"
以下为一个全文搜索的例子，查询语句如下：
GET /megacorp/employee/_search
{
"query" : {
"match" : {
"about" : "rock climbing"
}
}
}
返回结果如下：
{
...
"hits": {
"total": 2,
"max_score": 0.16273327,
"hits": [
{
...
"_score": 0.16273327,
"_source": {
"first_name": "John",
"last_name": "Smith",
"age": 25,
"about": "I love to go rock climbing",
"interests": [ "sports", "music" ]
}
},
{
...
"_score": 0.016878016,
"_source": {
"first_name": "Jane",
"last_name": "Smith",
"age": 32,
"about": "I like to collect rock albums",
"interests": [ "music" ]
}
}
]
}
}
4.服务容器信息
4.1 Filebeat概述
Filebeat 是一个轻量级的传送器，用于转发和集中日志数据。Filebeat 作为代理安装在服务器上，监控指定的日志文件或位置，收集日志事件，并将它们转发到Elasticsearch或 Logstash以进行索引。
Filebeat 的工作原理如下：当启动 Filebeat 时，它启动一个或多个输入，这些输入为查找您为日志数据指定的位置。对于 Filebeat 找到的每个日志，Filebeat 都会启动一个收割机。每个收割机读取新内容的单个日志，并将新日志数据发送到 libbeat，后者聚合事件并将聚合数据发送到 Filebeat输出。
推荐的解决方案
4.2 什么是ECS
Elastic Common Schema (ECS) 是一个开源规范，在 Elastic 用户社区的支持下开发。ECS 定义了在 Elasticsearch 中存储事件数据时要使用的一组通用字段，例如日志和指标。
ECS 为每个字段指定了字段名称和 Elasticsearch 数据类型，并提供了说明和示例用法。ECS 还将字段分组为 ECS 级别，这些级别用于表示预期字段存在的数量。您可以在指南和最佳实践了解有关 ECS 级别的更多信息。最后，ECS 还提供了一组用于添加自定义字段的命名指南。
ECS 的目标是支持和鼓励 Elasticsearch 用户规范化他们的事件数据，以便他们能够更好地分析、可视化和关联他们事件中表示的数据。ECS 的范围已确定可容纳各种事件，包括：
- Event sources（事件源）：您的事件源是 Elastic 产品、第三方产品还是您组织构建的自定义应用程序。
- Ingestion architectures（摄取架构）：您的事件的摄取路径是否涉及到了 Beats 处理器、Logstash、Elasticsearch 摄取节点
- Consumers： API, Kibana queries, dashboards, apps, 还是其他方式
4.3 什么是Kafka
Kafka中发布订阅的对象是topic。我们可以为每类数据创建一个topic，把向topic发布消息的客户端称作producer，从topic订阅消息的客户端称作consumer。Producers和consumers可以同时从多个topic读写数据。一个kafka集群由一个或多个broker服务器组成，它负责持久化和备份具体的kafka消息。
| Kafka部分名词解释 |
|---|
| Topic：一类消息，消息存放的目录即主题，例如page view日志、click日志等都可以以topic的形式存在，Kafka集群能够同时负责多个topic的分发。 |
| Partition： topic 物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列 |
| Segment： partition 物理上由多个segment组成，每个Segment存着message信息 |
| Producer : 生产message发送到topic |
| Consumer : 订阅topic消费message, consumer作为一个线程来消费 |
| Consumer Group：一个Consumer Group包含多个consumer, 这个是预先在配置文件中配置好的。各个consumer（consumer 线程）可以组成一个组（Consumer group ），partition中的每个message只能被组（Consumer group ） 中的一个consumer（consumer 线程 ）消费 |
| Broker： Kafka 节点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群。 |
4.3 服务容器信息实例
[
{
"_index": "filebeat-testbed-log-service-2021.07.11", //索引
"_type": "_doc", //类型
"_id": "HnGmlHoB6ORUDUEe5nJ3", //通过id找到文档
"_score": 1, //体现相关性的得分
"_source": {
//日志文件
"@timestamp": "2021-07-11T08:20:01.108Z",
//是从事件中提取的日期时间，通常表示源生成事件的时间。
"ecs": {
//Elastic Common Schema (ECS) 字段——在 Elasticsearch 中存储事件数据时要使用的一组常用字段。这是一个详尽的列表，此处列出的字段不一定被 Filebeat 使用。ECS 的目标是支持和鼓励 Elasticsearch 用户规范化他们的事件数据，以便他们能够更好地分析、可视化和关联他们事件中表示的数据。
"version": "1.5.0" //ECS字段的版本
},
"host": {//主机字段 主机定义为一个通用的计算实例。ECS主机。*字段应该要给出事件发生的主机的详细信息。主机类型包括硬件、虚拟机、Docker容器和Kubernetes节点。
"name": "testbed002"//主机名。
},
"agent": {//代理字段
"hostname": "testbed002",
//代理所在主机的主机名
"ephemeral_id": "162887a5-681e-4406-ad26-7ea6baac78c5",
//ephemeral[ɪˈfemərəl] 短暂的 此代理的临时标识符（如果存在）此 id 通常会在重新启动时更改，但agent.id不会更改。
"id": "8ad5c853-a2f6-40f1-bee3-0739c51b5400",
//此代理的唯一标识符（如果存在）。
"name": "testbed002",
//代理的自定义名称。这是可以赋予代理的名称。例如，如果两个 Filebeat 实例在同一主机上运行，需要对 Filebeat 实例数据的来源进行可读的区分。
"type": "filebeat",
//代理类型。代理类型始终保持不变，应由所使用的代理指定。在 Filebeat 的情况下，如果两个 Filebeat 实例在同一台机器上运行，代理也将始终是 Filebeat。
"version": "7.9.1"//代理版本
},
"message": "{\"@timestamp\":\"2021-07-11T08:20:01.108Z\",\"@metadata\":{\"beat\":\"filebeat\",\"type\":\"_doc\",\"version\":\"7.9.1\"},\"agent\":{\"name\":\"testbed00007\",\"type\":\"filebeat\",\"version\":\"7.9.1\",\"hostname\":\"testbed00007\",\"ephemeral_id\":\"af9ac1bb-6753-47fe-9183-1f6b60183978\",\"id\":\"a616877e-bcc6-41e1-afb0-ee1c4c37e5cf\"},\"log\":{\"offset\":3500936,\"file\":{\"path\":\"/var/log/pods/ts_cartservice-2-56d75d99fb-wdqkw_455b5be6-872f-4fc3-a9bf-c1e12ef9135b/server/160.log\"}},\"stream\":\"stdout\",\"message\":\" Request starting HTTP/2 POST http://cartservice-2:7070/hipstershop.CartService/GetCart application/grpc \",\"input\":{\"type\":\"container\"},\"fields\":{\"data_id\":\"log.cartservice.service.ts\",\"log_topic\":\"cartservice-service\",\"type\":\"service\"},\"ecs\":{\"version\":\"1.5.0\"},\"host\":{\"name\":\"testbed00007\"}}", //原始日志内容
"kafka": {//kafka是一个分布式、支持分区的分布式消息系统
"headers": [ ], //用来支持应用级别的扩展。
"topic": "testbed-log-service", //Topic相当于传统消息系统MQ中的一个队列queue，producer端发送的message必须指定是发送到哪个topic，但是不需要指定topic下的哪个partition，因为kafka会把收到的message进行load balance，均匀的分布在这个topic下的不同的partition上
"partition": 0, //由producer计算当前消息会发送到哪个partition
"offset": 2649715751, //kafka会为每条消息设置一个偏移量
"key": "" //key的作用是为消息选择存储分区，key可以为空，当指定key且不为空的时候，kafka是根据key的hash值与分区数取模来决定数据存储到那个分区
},
"tags": [
"json"//用于标记每个事件的关键字列表。
],
"input": {
"type": "kafka" //input类型是kafka
}
}
},
参考文献：