Vector 简介

Vector 是一种高性能的可观察性数据管道，可让组织控制其可观察性数据。收集、转换并将所有日志、指标和跟踪路由到SRE团队想展示或者存储的任何地方。由于 Vector 用 Rust 编写，提供了内存安全和效率保证，使其在其他现有工具中独树一帜。Vector 引入了单元测试框架，可以更轻松地维护复杂的日志收集工具拓扑。属于一款新型开源产品，比所有替代方案快 10 倍（引用官方话语）。

据官方显示 《Vector》 每月下载数百万次，T-Mobile、Comcast、Zendesk 和 Discord 等公司依赖 Vector 来拥有他们的可观察性数据。

相关概念

事件

Events（事件）代表 Vector 中的单个数据单元。

Data model

流经 Vector 的各个数据单元称为事件。事件必须属于 Vector 定义的一种可观察性类型。

Event types

Vector 定义事件的子类型。这对于建立特定领域的要求以实现与现有监控和可观察性系统的互操作性是必要的。

Log events

日志事件可以理解为就是通常的key/value。

以下是日志事件的示例（作为 JSON）

{
  "log": {
    "custom": "field",
    "host": "my.host.com",
    "message": "Hello world",
    "timestamp": "2020-11-01T21:15:47+00:00"
  }
}

Vector 日志事件是时间点事件的结构化表示。 它包含一组描述事件的任意字段。 Vector 的一个关键原则是保持架构中立。 这确保了 Vector 可以使用任何模式，随着需求发展支持旧模式和未来模式。 Vector 不需要任何特定的字段，每个组件都会记录它提供的字段。
Options：
------可以无限嵌套的任意一组键/值对。

示例：

{
  "custom": "field",
  "host": "my.host.com",
  "message": "Hello world",
  "timestamp": "2020-11-01T21:15:47+00:00"
}

字段类型官方链接🔗 https://vector.dev/docs/about/under-the-hood/architecture/data-model/log/#star

Metric events

Vector度量事件表示对时间序列执行的数值运算。与其他工具不同的是，Vector中的指标被视为一等公民，与不同的指标服务可以直接进行交互，无需任何转换即可与各种指标服务互相交互操作。Vector采用的度量数据模型强调准确性和正确性，而不是严格固定度量类型。因此，Vector中可以包含各种度量类型，例如Prometheus和StatsD，以确保不同系统之间的度量数据可以进行正确的互操作。

官方链接🔗 https://vector.dev/docs/about/under-the-hood/architecture/data-model/metric/

Why not just events?

据官方描述，他们很喜欢纯事件世界的想法，在这个世界中，每项服务都完美地配备了包含丰富数据和上下文的事件。但实际上，考虑到服务通常会发出质量参差不齐的日志和指标。通过设计 Vector 以满足它们所在的服务，我们充当通向更新标准的桥梁。这就是为什么我们将事件放在数据模型的顶部，而日志和指标是派生类别。
最后，考虑各种数据类型的复杂数据模型允许可观察性系统之间的正确互操作性。例如，如果没有正确的内部指标数据类型，则无法实现具有 statsd 源和 prometheus 接收器的管道。

Traces

可以将跟踪事件理解为一种特殊的日志事件。 在撰写本文时，支持跟踪事件的组件是：datadog_agent 源、datadog_traces 接收器以及示例和重新映射转换。

组件构成

组件是源、转换和接收器的通用术语。 组件摄取、转换和路由事件。可以依赖这些创建拓扑。
目前Vector支持的组件类型列表：https://vector.dev/components/

源

可以理解为Vector从哪可以采集到数据？源的示例包括file、syslog、statsd和stdin。例如采集docker容器的日志信息等等。
https://vector.dev/docs/reference/configuration/sources/

转换

转换负责在 Vector 传输时改变事件。这可能涉及解析、过滤、采样或聚合，其实跟Logstash组件类似，会借助于丰富的插件去实现。
https://vector.dev/docs/reference/configuration/transforms/

接收器

接收器是事件的目的地。 每个接收器的设计和传输方法由与其交互的下游服务决定。 例如，socket sink 用于流式传输单个事件，而 aws_s3 sink 用于缓冲和刷新数据。
https://vector.dev/docs/reference/configuration/sinks/

Pipeline

Vector 的管道模型基于有向无环图包含独立子图的组件。事件必须沿单一方向从源流向接收器，并且不能创建循环。图中的每个组件都可以产生零个或多个事件。
流水线模型

包括如何配置、更改、重新加载等，官方均有相关说明 https://vector.dev/docs/about/under-the-hood/architecture/pipeline-model/

Buffers

接收器主要负责快速发送事件。 如果他们无法跟上，他们有一个可配置的缓冲区来保存事件，直到它们可以被发送。 默认情况下，Vector 使用内存缓冲区，但也可以使用磁盘缓冲区。 一旦缓冲区填满，行为是可配置的。

buffer.when_full = block  #默认配置。当缓冲区填满时，背压将应用于图中的先前组件。

buffer.when_full = drop_newest  #当缓冲区填满时，新事件将被丢弃。这不提供背压。

如何理解背压？
背压（Backpressure）是一种控制组件之间数据流速率的机制，它通过限制发送数据源的速率来保持数据消费者接收数据的速率。在一个数据流系统中，如果生产者（即数据源）产生数据的速度大于消费者（即数据接收方）的处理速度，那么未处理的数据将会在缓冲区内不断积累，最终导致系统崩溃。为避免这种情况，背压机制会在消费者缓慢处理数据时通过降低生产者数据生成速率的方式来平衡生产者和消费者之间的数据流量，从而保持整个系统的稳定性。上述所提到的背压作用，是指当缓冲区填满时，数据流系统通过背压机制对之前的组件进行限流，降低数据源的产生速率以协调整个数据流系统的各个组件处理速度，以避免引起系统崩溃。

Buffer配置链接🔗 https://vector.dev/docs/reference/configuration/sinks/vector/#buffer

Backpressure

如果接收器的缓冲区填满并配置为提供背压，则该背压将传播到任何连接的转换，这也将传播到源。源试图将背压传播到任何提供数据的系统。确切的机制因来源而异。例如，HTTP 源可能会拒绝带有 HTTP 429 错误（太多请求）的请求，或者基于拉取的源（例如 Kafka）可能会减慢获取新事件的速度。

源发送事件的速度与配置为提供背压的最慢接收器一样快（buffer.when_full = block）

例如，如果在此配置中有一个源发送到 3 个接收器，则源将开始从接收器 2（500 个事件/秒）提供背压，因为这是配置为提供背压的最慢接收器。 接收器 1 将丢弃多达 250 个事件/秒，而接收器 3 将未得到充分利用。
接收器 1：可以以 250 个事件/秒的速度发送 ( buffer.when_full = drop_newest)
接收器 2：可以以 500 个事件/秒的速度发送 ( buffer.when_full = block)
接收器 3：可以以 1000 个事件/秒的速度发送 ( buffer.when_full = block)

组件配置了多个数据源时，当组件在进行背压时，Vector无法保证哪个数据源会优先得到处理。为了确保所有输入都能够得到充分的处理，需要确认下游组件能够处理所有连接的数据源的数据量。这意味着，如果单个组件被配置了多个数据源并且同时从这些数据源接收数据，那么当进行背压处理时，Vector无法确定应该优先处理哪个数据源的数据。为了避免数据丢失和处理错误，需要确保下游组件能够处理所有连接的数据源的数据量。也就是说，如果一个组件同时处理多个数据来源，那么需要确保下游的组件可以处理所有数据流，以确保数据的完整性和正确性。

Roles

角色是 Vector 为创建端到端管道而填充的部署角色。

Agent

Daemon

作为守护进程角色旨在收集单个主机上的所有数据。 这是数据收集的推荐角色，因为它可以最有效地利用主机资源。 Vector 实现了有向无环图拓扑模型，支持从多个服务进行收集和处理。

Sidecar

sidecar 角色将 Vector 与每个服务耦合，只专注于为该单个服务收集数据。 虽然建议使用上述提到的守护进程角色，但如果想将数据收集的责任转移给服务所有者时，sidecar 角色会很有用。 而且，在某些情况下，它更易于管理。

Aggregator

聚合器角色设计用于中央处理，从多个上游源收集数据并执行跨主机聚合和分析。
对于 Vector，这个角色应该专门用于：跨主机聚合和分析。Vector 的独特之处在于它既可以作为代理也可以作为聚合器。这使得在边缘分布处理成为关键。我们强烈建议尽可能将处理推到边缘，因为它更高效且更易于管理。

Topology

拓扑是将 Vector 部署到基础架构中的最终结果。 拓扑可能像将 Vector 部署为代理一样简单，也可能像将 Vector 部署为代理并通过多个 Vector 聚合器路由数据一样复杂。

分布式

可以称之为“最简单的拓扑”，在分布式架构中，Vector 从客户端节点直接与下游服务通信。

【优点】

• 简单。运行组件更少。
• 具有弹性扩展能力（资源随着您的扩展而增长）。

【缺点】

• 效率较低。根据管道的复杂性，这将使用更多的本地资源，这可能会影响同一主机上其他应用程序的性能。
• 不太耐用。因为数据是在主机上缓冲的，所以在发生不可恢复的故障时，很可能会丢失缓冲的数据。可能也是最重要和有用的数据。
• 下游压力更大。下游服务将收到更多负载更小的请求，这可能会影响这些服务的稳定性。
• 下游稳定性降低。如果需要快速扩展或超出下游服务可以处理的容量，就有可能使下游服务过载。
• 缺少多主机上下文。缺乏对其他主机的感知并消除了跨主机执行操作的能力，例如将日志减少到全局指标。对于单个主机指标不太有用的超大型部署，这通常是一个问题。

集中式

简单性、稳定性和控制之间的良好平衡。对于很多用例，集中式部署拓扑是分布式拓扑和基于流的拓扑之间的良好折衷，因为它提供了基于流的拓扑的许多优点，例如职责的清晰分离，而不会因基于流的设置，通常涉及将 Vector 与Apache Kafka或Apache Pulsar等系统结合使用。

【优点】

• 更有效率。集中式拓扑通常对客户端节点和下游服务更有效。vector代理做的工作更少，因此使用的资源更少。此外，在此拓扑中，集中式 Vector 服务缓冲数据，提供更好的压缩，并向下游发送优化的请求。
• 更可靠。Vector 通过以平滑的时间间隔缓冲和刷新数据来保护下游服务免受流量峰值的影响。
• 具有多主机上下文。因为数据是集中的，所以可以跨主机执行操作，例如将日志减少到全局指标。这对于大型架构部署是有利的，在大型部署中，跨许多主机聚合的指标比孤立的每个主机指标更能提供信息。

【缺点】

• 比较复杂。在网状网络拓扑中，每个节点都作为代理角色和聚合器角色运行Vector，这意味着每个节点都可以收集和聚合日志数据。相比之下，集中式网络拓扑具有更多的运行部件，因为需要在代理和聚合器角色中都运行Vector。这意味着，需要设计并维护代理和聚合器之间的网络通信，以确保聚合器可以从代理节点中正确地接收和处理日志数据，同时确保代理节点能够正确地发送数据给聚合器以进行处理和存储。这就增加了系统的管理难度和复杂性。因此，相比之下，集中式网络拓扑可能需要更多的维护工作。
• 不太耐用。代理节点旨在尽快从机器上获取数据。虽然这对于某些用例来说很好，但它确实存在数据丢失的可能性，因为中央 Vector 服务可能会出现故障，从而丢失任何缓冲数据。如果这种类型的中断对于业务要求来说是不可接受的，官方建议改为运行基于流的拓扑。

基于流

最持久和最有弹性的拓扑结构。这种拓扑结构通常用于非常大的流，团队熟悉运行基于流的服务，例如 Kafka。

优点

• 最耐用可靠。流服务，如 Kafka，旨在实现高持久性和可靠性，跨多个节点复制数据。
• 最有效率。Vector agents 做得更少，使它们更有效率，并且 Vector 服务不必担心持久性，可以针对性能进行调整。
• 重新流式传输的能力。根据流的保留期限重新流式传输您的数据。
• 更清晰的职责分离。Vector 仅用作路由层，不负责持久性。持久性委托给一个专门构建的服务，您可以随着时间的推移进行切换和发展。

缺点

• 增加了管理开销。管理流服务（例如 Kafka）是一项复杂的工作，通常需要经验丰富的团队来正确配置和管理。
• 比较复杂。这种拓扑结构很复杂，需要对管理生产级流有更深入的了解。
• 比较贵。除了管理成本之外，添加的流集群将需要更多资源，这将增加运营成本。

附开源日志采集器性能测评：
链接🔗 https://mp.weixin.qq.com/s/8mCVk3gvXPOijTlcRjUR_w

如何选择合适的开源日志收集器？
链接🔗 https://mp.weixin.qq.com/s/yZh3LDmMW7EQurj0W-9wGA