配置网络可观测性操作符 - 网络可观测性 | 可观测性 | OpenShift Container Platform 4.17

查看FlowCollector资源
使用Kafka配置Flow Collector资源
导出丰富的网络流量数据
更新Flow Collector资源
配置快速过滤器
资源管理和性能注意事项
- 资源注意事项
- 总平均内存和CPU使用率

您可以更新FlowCollector API资源以配置网络可观察性操作符及其管理的组件。FlowCollector在安装过程中被显式创建。由于此资源在集群范围内运行，因此只允许单个FlowCollector，并且它必须命名为cluster。有关更多信息，请参阅FlowCollector API参考。

查看FlowCollector资源

您可以直接在OpenShift Container Platform Web控制台中查看和编辑YAML。

步骤

在Web控制台中，导航到**操作符** → **已安装的操作符**。
在**NetObserv操作符**的**提供的API**标题下，选择**Flow Collector**。
选择**cluster**，然后选择**YAML**选项卡。在那里，您可以修改FlowCollector资源以配置网络可观察性操作符。

以下示例显示了OpenShift Container Platform网络可观察性操作符的示例FlowCollector资源

示例FlowCollector资源

apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  deploymentModel: Direct
  agent:
    type: eBPF                                (1)
    ebpf:
      sampling: 50                            (2)
      logLevel: info
      privileged: false
      resources:
        requests:
          memory: 50Mi
          cpu: 100m
        limits:
          memory: 800Mi
  processor:               (3)
    logLevel: info
    resources:
      requests:
        memory: 100Mi
        cpu: 100m
      limits:
        memory: 800Mi
    logTypes: Flows
    advanced:
      conversationEndTimeout: 10s
      conversationHeartbeatInterval: 30s
  loki:                     (4)
    mode: LokiStack         (5)
  consolePlugin:
    register: true
    logLevel: info
    portNaming:
      enable: true
      portNames:
        "3100": loki
    quickFilters:            (6)
    - name: Applications
      filter:
        src_namespace!: 'openshift-,netobserv'
        dst_namespace!: 'openshift-,netobserv'
      default: true
    - name: Infrastructure
      filter:
        src_namespace: 'openshift-,netobserv'
        dst_namespace: 'openshift-,netobserv'
    - name: Pods network
      filter:
        src_kind: 'Pod'
        dst_kind: 'Pod'
      default: true
    - name: Services network
      filter:
        dst_kind: 'Service'

1	Agent规范，`spec.agent.type`，必须为`EBPF`。eBPF是唯一受OpenShift Container Platform支持的选项。
2	您可以设置采样规范`spec.agent.ebpf.sampling`来管理资源。较低的采样值可能会消耗大量的计算、内存和存储资源。您可以通过指定采样比率值来减轻这种情况。值为100表示每100个流采样1个流。值为0或1表示捕获所有流。值越低，返回的流越多，派生指标的精度越高。默认情况下，eBPF采样设置为50，因此每50个流采样1个流。请注意，更多采样流也意味着需要更多存储空间。建议从默认值开始，并根据经验进行调整，以确定您的集群可以管理哪个设置。
3	处理器规范`spec.processor.`可以设置为启用会话跟踪。启用后，可以在 Web 控制台中查询会话事件。`spec.processor.logTypes` 值为 `Flows`。`spec.processor.advanced` 值为 `Conversations`、`EndedConversations` 或 `ALL`。存储需求对 `All` 最高，对 `EndedConversations` 最低。
4	Loki 规范 `spec.loki` 指定 Loki 客户端。默认值与“安装 Loki 运算符”部分中提到的 Loki 安装路径匹配。如果您使用其他方法安装 Loki，请指定安装的相应客户端信息。
5	`LokiStack` 模式会自动设置一些配置：`querierUrl`、`ingesterUrl` 和 `statusUrl`、`tenantID` 以及相应的 TLS 配置。将创建集群角色和集群角色绑定，用于读取和写入 Loki 日志。并且 `authToken` 设置为 `Forward`。您可以使用 `Manual` 模式手动设置这些值。
6	`spec.quickFilters` 规范定义了在 Web 控制台中显示的过滤器。“应用程序”过滤器的键 `src_namespace` 和 `dst_namespace` 被取反（`！`），因此“应用程序”过滤器显示所有不源于或目标为任何 `openshift-` 或 `netobserv` 命名空间的流量。有关更多信息，请参见下面的“配置快速过滤器”。

其他资源

使用 Kafka 配置 Flow Collector 资源

您可以将 `FlowCollector` 资源配置为使用 Kafka 进行高吞吐量和低延迟数据馈送。需要运行 Kafka 实例，并且必须在该实例中创建一个专用于 OpenShift Container Platform 网络可观测性的 Kafka 主题。有关更多信息，请参见使用 AMQ Streams 的 Kafka 文档。

先决条件

Kafka 已安装。Red Hat 支持使用 AMQ Streams Operator 的 Kafka。

步骤

在Web控制台中，导航到**操作符** → **已安装的操作符**。
在网络可观测性运算符的“提供的 API”标题下，选择“Flow Collector”。
选择集群，然后单击“YAML”选项卡。
修改 OpenShift Container Platform 网络可观测性运算符的 `FlowCollector` 资源以使用 Kafka，如下面的示例 YAML 中所示

`FlowCollector` 资源中的示例 Kafka 配置

apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  deploymentModel: Kafka                                    (1)
  kafka:
    address: "kafka-cluster-kafka-bootstrap.netobserv"      (2)
    topic: network-flows                                    (3)
    tls:
      enable: false                                         (4)

1	将 `spec.deploymentModel` 设置为 `Kafka` 而不是 `Direct` 以启用 Kafka 部署模型。
2	`spec.kafka.address` 指的是 Kafka bootstrap 服务器地址。如果需要，可以指定端口，例如 `kafka-cluster-kafka-bootstrap.netobserv:9093` 用于在端口 9093 上使用 TLS。
3	`spec.kafka.topic` 应与在 Kafka 中创建的主题名称匹配。
4	`spec.kafka.tls` 可用于使用 TLS 或 mTLS 加密与 Kafka 之间的所有通信。启用后，Kafka CA 证书必须作为 ConfigMap 或 Secret 可用，两者都位于部署 `flowlogs-pipeline` 处理器组件的命名空间（默认：`netobserv`）和部署 eBPF 代理的命名空间（默认：`netobserv-privileged`）中。它必须使用 `spec.kafka.tls.caCert` 引用。使用 mTLS 时，客户端密钥也必须在这些命名空间中可用（例如，可以使用 AMQ Streams 用户运算符生成它们），并使用 `spec.kafka.tls.userCert` 引用。

导出丰富的网络流量数据

您可以将网络流量发送到 Kafka、IPFIX、Red Hat 版本的 OpenTelemetry 或同时发送到这三个目标。对于 Kafka 或 IPFIX，任何支持这些输入的处理器或存储（例如 Splunk、Elasticsearch 或 Fluentd）都可以使用丰富的网络流量数据。对于 OpenTelemetry，网络流量数据和指标可以导出到兼容的 OpenTelemetry 端点，例如 Red Hat 版本的 OpenTelemetry、Jaeger 或 Prometheus。

先决条件

您的 Kafka、IPFIX 或 OpenTelemetry 收集器端点可从网络可观测性 `flowlogs-pipeline` pod 获取。

步骤

在Web控制台中，导航到**操作符** → **已安装的操作符**。
在**NetObserv操作符**的**提供的API**标题下，选择**Flow Collector**。
选择 **集群**，然后选择 **YAML** 选项卡。

编辑 `FlowCollector` 以配置 `spec.exporters`，如下所示

apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  exporters:
  - type: Kafka                         (1)
      kafka:
        address: "kafka-cluster-kafka-bootstrap.netobserv"
        topic: netobserv-flows-export   (2)
        tls:
          enable: false                 (3)
  - type: IPFIX                         (1)
      ipfix:
        targetHost: "ipfix-collector.ipfix.svc.cluster.local"
        targetPort: 4739
        transport: tcp or udp           (4)
 -  type: OpenTelemetry                 (1)
      openTelemetry:
        targetHost: my-otelcol-collector-headless.otlp.svc
        targetPort: 4317
        type: grpc                      (5)
        logs:                           (6)
          enable: true
        metrics:                        (7)
          enable: true
          prefix: netobserv
          pushTimeInterval: 20s         (8)
          expiryTime: 2m
   #    fieldsMapping:                  (9)
   #      input: SrcAddr
   #      output: source.address

1	您可以单独或同时将流量导出到 IPFIX、OpenTelemetry 和 Kafka。
2	网络可观测性运算符将所有流量导出到配置的 Kafka 主题。
3	您可以使用 SSL/TLS 或 mTLS 加密与 Kafka 之间的所有通信。启用后，Kafka CA 证书必须作为 ConfigMap 或 Secret 可用，两者都位于部署 `flowlogs-pipeline` 处理器组件的命名空间（默认：netobserv）中。它必须使用 `spec.exporters.tls.caCert` 引用。使用 mTLS 时，客户端密钥也必须在这些命名空间中可用（例如，可以使用 AMQ Streams 用户运算符生成它们），并使用 `spec.exporters.tls.userCert` 引用。
4	您可以选择指定传输方式。默认值为 `tcp`，但您也可以指定 `udp`。
5	OpenTelemetry 连接的协议。可用选项为 `http` 和 `grpc`。
6	导出日志的 OpenTelemetry 配置，与为 Loki 创建的日志相同。
7	导出指标的 OpenTelemetry 配置，与为 Prometheus 创建的指标相同。这些配置在 `FlowCollector` 自定义资源的 `spec.processor.metrics.includeList` 参数中指定，以及您使用 `FlowMetrics` 自定义资源定义的任何自定义指标。
8	将指标发送到 OpenTelemetry 收集器的时间间隔。
9	可选：网络可观测性网络流量格式会自动重命名为 OpenTelemetry 兼容格式。`fieldsMapping` 规范使您可以自定义 OpenTelemetry 格式输出。例如，在 YAML 示例中，`SrcAddr` 是网络可观测性输入字段，它在 OpenTelemetry 输出中被重命名为 `source.address`。您可以在“网络流量格式参考”中看到网络可观测性和 OpenTelemetry 格式。

配置后，网络流量数据可以 JSON 格式发送到可用的输出。有关更多信息，请参见“网络流量格式参考”。

其他资源

网络流量格式参考.

更新 Flow Collector 资源

作为在 OpenShift Container Platform Web 控制台中编辑 YAML 的替代方法，您可以通过修补 `flowcollector` 自定义资源 (CR) 来配置规范，例如 eBPF 采样。

步骤

运行以下命令来修补 `flowcollector` CR 并更新 `spec.agent.ebpf.sampling` 值

$ oc patch flowcollector cluster --type=json -p "[{"op": "replace", "path": "/spec/agent/ebpf/sampling", "value": <new value>}] -n netobserv"

配置快速过滤器

您可以修改FlowCollector资源中的过滤器。使用双引号括住值可以实现精确匹配。否则，对于文本值将使用部分匹配。在键的末尾添加感叹号 (!) 表示否定。有关修改 YAML 的更多上下文，请参见示例FlowCollector资源。

“全部匹配”或“任意匹配”的过滤器匹配类型是用户可以在查询选项中修改的 UI 设置。它不是此资源配置的一部分。

以下是所有可用过滤器键的列表

表 1. 过滤器键
通用*	源	目标	描述
命名空间	`源命名空间`	`目标命名空间`	过滤与特定命名空间相关的流量。
名称	`源名称`	`目标名称`	过滤与给定叶子资源名称相关的流量，例如特定的 Pod、服务或节点（对于主机网络流量）。
类型	`源类型`	`目标类型`	过滤与给定资源类型相关的流量。资源类型包括叶子资源（Pod、服务或节点）或所有者资源（Deployment 和 StatefulSet）。
所有者名称	`源所有者名称`	`目标所有者名称`	过滤与给定资源所有者相关的流量；也就是说，工作负载或一组 Pod。例如，它可以是 Deployment 名称、StatefulSet 名称等。
资源	`源资源`	`目标资源`	过滤与特定资源相关的流量，该资源由其规范名称表示，该名称唯一标识它。对于命名空间类型，规范表示法为`kind.namespace.name`，对于节点，规范表示法为`node.name`。例如，`Deployment.my-namespace.my-web-server`。
地址	`源地址`	`目标地址`	过滤与 IP 地址相关的流量。支持 IPv4 和 IPv6。也支持 CIDR 范围。
MAC 地址	`源 MAC 地址`	`目标 MAC 地址`	过滤与 MAC 地址相关的流量。
端口	`源端口`	`目标端口`	过滤与特定端口相关的流量。
主机地址	`源主机地址`	`目标主机地址`	过滤与 Pod 运行所在的主机 IP 地址相关的流量。
协议	N/A	N/A	过滤与协议相关的流量，例如 TCP 或 UDP。

通用键过滤源或目标中的任意一个。例如，过滤name: 'my-pod'表示来自my-pod的所有流量和到my-pod的所有流量，无论使用哪种匹配类型，无论是**全部匹配**还是**任意匹配**。

资源管理和性能注意事项

网络可观测性所需的资源量取决于集群的大小以及集群摄取和存储可观测性数据的要求。要管理资源并为集群设置性能标准，请考虑配置以下设置。配置这些设置可能会满足您的最佳设置和可观测性需求。

以下设置可以帮助您从一开始就管理资源和性能

eBPF 采样: 您可以设置采样规范spec.agent.ebpf.sampling来管理资源。较小的采样值可能会消耗大量的计算、内存和存储资源。您可以通过指定采样率值来减轻这种情况。值为100表示每 100 个流采样 1 个流。值为0或1表示捕获所有流。较小的值会导致返回的流增加以及派生指标的准确性提高。默认情况下，eBPF 采样设置为 50，因此每 50 个流采样 1 个流。请注意，采样的流越多，所需的存储空间也越多。考虑从默认值开始，并根据经验进行优化，以确定您的集群可以管理哪个设置。
限制或排除接口: 通过设置spec.agent.ebpf.interfaces和spec.agent.ebpf.excludeInterfaces的值来减少观察到的总流量。默认情况下，代理会获取系统中的所有接口，除了excludeInterfaces和lo（本地接口）中列出的接口。请注意，接口名称可能会根据使用的容器网络接口 (CNI) 而有所不同。

网络可观测性运行一段时间后，可以使用以下设置来微调性能

资源需求和限制: 使用spec.agent.ebpf.resources和spec.processor.resources规范，根据您预计的集群负载和内存使用情况调整资源需求和限制。对于大多数中等规模的集群，默认限制 800MB 可能就足够了。
缓存最大流超时: 使用 eBPF 代理的spec.agent.ebpf.cacheMaxFlows和spec.agent.ebpf.cacheActiveTimeout规范来控制代理报告流的频率。较大的值会导致代理生成的流量减少，这与较低的 CPU 负载相关。但是，较大的值会导致内存消耗略高，并可能导致流收集的延迟增加。

资源注意事项

下表概述了具有特定工作负载大小的集群的资源注意事项示例。

表中概述的示例演示了针对特定工作负载量身定制的场景。仅将每个示例视为可以进行调整以适应您的工作负载需求的基线。

表 2. 资源建议
	特小 (10 个节点)	小型 (25 个节点)	中型 (65 个节点) ^[2]	大型 (120 个节点) ^[2]
工作节点 vCPU 和内存	4 个 vCPU \| 16 GiB 内存 ^[1]	16 个 vCPU \| 64 GiB 内存 ^[1]	16 个 vCPU \| 64 GiB 内存 ^[1]	16 个 vCPU \| 64 GiB 内存 ^[1]
Loki 堆栈大小	`1x.特小`	`1x.小型`	`1x.小型`	`1x.中型`
网络可观测性控制器内存限制	400Mi（默认）	400Mi（默认）	400Mi（默认）	400Mi（默认）
eBPF 采样率	50（默认）	50（默认）	50（默认）	50（默认）
eBPF 内存限制	800Mi（默认）	800Mi（默认）	800Mi（默认）	1600Mi
cacheMaxSize	50,000	100,000（默认）	100,000（默认）	100,000（默认）
FLP 内存限制	800Mi（默认）	800Mi（默认）	800Mi（默认）	800Mi（默认）
FLP Kafka 分区	N/A	48	48	48
Kafka 消费者副本	N/A	6	12	18
Kafka 代理	N/A	3（默认）	3（默认）	3（默认）

使用 AWS M6i 实例进行了测试。
除了这个工作节点及其控制器之外，还测试了 3 个基础设施节点（大小为M6i.12xlarge）和 1 个工作负载节点（大小为M6i.8xlarge）。

总平均内存和 CPU 使用率

下表概述了针对 3 个不同测试（测试 1、测试 2 和测试 3）的采样值为 1、50 和 400 的集群的总资源使用率平均值。这些测试的不同之处在于：

测试 1考虑了 OpenShift Container Platform 集群中的命名空间、Pod 和服务的总数，对 eBPF 代理施加负载，并表示给定集群大小下具有大量工作负载的用例。例如，测试 1包含 76 个命名空间、5153 个 Pod 和 2305 个服务。
测试 2考虑了高入口流量。
测试 3考虑了 OpenShift Container Platform 集群中的命名空间、Pod 和服务的总数，对 eBPF 代理施加的负载比测试 1更大，并表示给定集群大小下具有大量工作负载的用例。例如，测试 3包含 553 个命名空间、6998 个 Pod 和 2508 个服务。

由于不同测试中示例的集群用例类型各异，本表中的数字不能进行线性比较，而是旨在作为评估您个人集群用法的基准。表中概述的示例演示了针对特定工作负载量身定制的场景。请仅将每个示例视为基线，您可以根据需要对其进行调整以适应您的工作负载。

导出到 Prometheus 的指标会影响资源使用情况。指标的基数值可以帮助确定资源的影响程度。有关更多信息，请参阅“附加资源”部分中的“网络流量格式”。

表 3. 平均总资源使用情况
采样值	参数	测试 1（25 个节点）	测试 2（65 个节点）	测试 3（120 个节点）
采样 = 1	启用 Loki
	NetObserv 总 CPU 使用率	3.24	3.42	7.30
	NetObserv 总 RSS（内存）使用率	14.09 GB	22.56 GB	36.46 GB
	未启用 Loki
	NetObserv 总 CPU 使用率	2.40	2.43	5.59
	NetObserv 总 RSS（内存）使用率	6.85 GB	10.39 GB	13.92 GB
采样 = 50	启用 Loki
	NetObserv 总 CPU 使用率	2.04	2.36	3.31
	NetObserv 总 RSS（内存）使用率	8.79 GB	19.14 GB	21.07 GB
	未启用 Loki
	NetObserv 总 CPU 使用率	1.55	1.64	2.70
	NetObserv 总 RSS（内存）使用率	6.71 GB	10.15 GB	14.82 GB
采样 = 400	启用 Loki
	NetObserv 总 CPU 使用率	1.71	1.44	2.36
	NetObserv 总 RSS（内存）使用率	8.21 GB	16.02 GB	17.44 GB
	未启用 Loki
	NetObserv 总 CPU 使用率	1.31	1.06	1.83
	NetObserv 总 RSS（内存）使用率	7.01 GB	10.70 GB	13.26 GB

摘要：此表显示网络可观测性（Agent + FLP + Kafka + Loki）的平均总资源使用情况。

其他资源

网络流量格式参考.