网络可观测性故障排除 - 网络可观测性 | 可观测性 | OpenShift 容器平台 4.17

使用must-gather工具
在OpenShift Container Platform控制台中配置网络流量菜单项
安装Kafka后，Flowlogs-Pipeline不消耗网络流量
无法从`br-int`和`br-ex`接口看到网络流量
网络可观测性控制器管理器Pod内存不足
运行自定义Loki查询
排查Loki ResourceExhausted错误
Loki空环错误
资源故障排除
LokiStack速率限制错误
运行大型查询导致Loki错误

为了帮助您排查网络可观测性问题，您可以执行一些故障排除操作。

使用must-gather工具

您可以使用must-gather工具收集有关网络可观测性操作符资源和集群范围资源（例如Pod日志、`FlowCollector`和`webhook`配置）的信息。

步骤

导航到要存储must-gather数据的目录。

运行以下命令以收集集群范围的must-gather资源

$ oc adm must-gather
 --image-stream=openshift/must-gather \
 --image=quay.io/netobserv/must-gather

在OpenShift Container Platform控制台中配置网络流量菜单项

当OpenShift Container Platform控制台的“观察”菜单中未列出网络流量菜单项时，请手动配置该菜单项。

先决条件

您已安装OpenShift Container Platform 4.10或更高版本。

步骤

通过运行以下命令检查`spec.consolePlugin.register`字段是否设置为`true`

$ oc -n netobserv get flowcollector cluster -o yaml

示例输出

apiVersion: flows.netobserv.io/v1alpha1
kind: FlowCollector
metadata:
  name: cluster
spec:
  consolePlugin:
    register: false

可选：通过手动编辑控制台操作符配置来添加`netobserv-plugin`插件
```
$ oc edit console.operator.openshift.io cluster
```
示例输出
```
...
spec:
  plugins:
  - netobserv-plugin
...
```

可选：通过运行以下命令将`spec.consolePlugin.register`字段设置为`true`

$ oc -n netobserv edit flowcollector cluster -o yaml

示例输出

apiVersion: flows.netobserv.io/v1alpha1
kind: FlowCollector
metadata:
  name: cluster
spec:
  consolePlugin:
    register: true

通过运行以下命令确保控制台Pod的状态为`running`
```
$ oc get pods -n openshift-console -l app=console
```

通过运行以下命令重启控制台Pod

$ oc delete pods -n openshift-console -l app=console

清除浏览器缓存和历史记录。

通过运行以下命令检查网络可观测性插件Pod的状态

$ oc get pods -n netobserv -l app=netobserv-plugin

示例输出

NAME                                READY   STATUS    RESTARTS   AGE
netobserv-plugin-68c7bbb9bb-b69q6   1/1     Running   0          21s

通过运行以下命令检查网络可观测性插件Pod的日志

$ oc logs -n netobserv -l app=netobserv-plugin

示例输出

time="2022-12-13T12:06:49Z" level=info msg="Starting netobserv-console-plugin [build version: , build date: 2022-10-21 15:15] at log level info" module=main
time="2022-12-13T12:06:49Z" level=info msg="listening on https://:9001" module=server

安装Kafka后，Flowlogs-Pipeline不消耗网络流量

如果您首先使用`deploymentModel: KAFKA`部署了流量收集器，然后部署了Kafka，则流量收集器可能无法正确连接到Kafka。手动重启Flowlogs-pipeline不从Kafka消耗网络流量的flow-pipeline Pod。

步骤

通过运行以下命令删除flow-pipeline Pod以重启它们

$ oc delete pods -n netobserv -l app=flowlogs-pipeline-transformer

无法从`br-int`和`br-ex`接口看到网络流量

`br-ex`和`br-int`是在OSI第2层运行的虚拟桥接设备。eBPF代理在IP和TCP层（分别为第3层和第4层）工作。当网络流量由其他接口（例如物理主机或虚拟Pod接口）处理时，您可以预期eBPF代理会捕获通过`br-ex`和`br-int`的网络流量。如果您将eBPF代理网络接口限制为仅附加到`br-ex`和`br-int`，则您将看不到任何网络流量。

手动删除`interfaces`或`excludeInterfaces`中限制网络接口为`br-int`和`br-ex`的部分。

步骤

删除`interfaces: [ 'br-int', 'br-ex' ]`字段。这允许代理从所有接口获取信息。或者，您可以指定第3层接口，例如`eth0`。运行以下命令

$ oc edit -n netobserv flowcollector.yaml -o yaml

示例输出

apiVersion: flows.netobserv.io/v1alpha1
kind: FlowCollector
metadata:
  name: cluster
spec:
  agent:
    type: EBPF
    ebpf:
      interfaces: [ 'br-int', 'br-ex' ] (1)

指定网络接口。

网络可观测性控制器管理器Pod内存不足

您可以通过编辑`Subscription`对象中的`spec.config.resources.limits.memory`规范来增加网络可观测性操作符的内存限制。

步骤

在Web控制台中，导航到**操作符**→**已安装的操作符**
单击**网络可观测性**，然后选择**订阅**。
在**操作**菜单中，单击**编辑订阅**。
1. 或者，您可以使用CLI通过运行以下命令打开`Subscription`对象的YAML配置
  $ oc edit subscription netobserv-operator -n openshift-netobserv-operator

编辑`Subscription`对象以添加`config.resources.limits.memory`规范并将值设置为满足您的内存需求。有关资源考虑的更多信息，请参阅其他资源

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: netobserv-operator
  namespace: openshift-netobserv-operator
spec:
  channel: stable
  config:
    resources:
      limits:
        memory: 800Mi     (1)
      requests:
        cpu: 100m
        memory: 100Mi
  installPlanApproval: Automatic
  name: netobserv-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: <network_observability_operator_latest_version> (2)

1	例如，您可以将内存限制增加到`800Mi`。
2	此值不应编辑，但请注意，它会根据操作符的最新版本而变化。

运行自定义 Loki 查询

为了进行故障排除，您可以运行自定义 Loki 查询。这里提供了两种方法示例，您可以根据需要进行调整，只需将``替换为您自己的 API 令牌。

这些示例使用 `netobserv` 命名空间用于网络可观测性操作符和 Loki 部署。此外，这些示例假设 LokiStack 的名称为 `loki`。您可以通过调整示例（特别是 `-n netobserv` 或 `loki-gateway` URL）来使用不同的命名空间和名称。

先决条件

已安装用于网络可观测性操作符的 Loki 操作符

步骤

要获取所有可用的标签，请运行以下命令：

$ oc exec deployment/netobserv-plugin -n netobserv -- curl -G -s -H 'X-Scope-OrgID:network' -H 'Authorization: Bearer <api_token>' -k https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network/loki/api/v1/labels | jq

要获取来自源命名空间 `my-namespace` 的所有流量，请运行以下命令：

$ oc exec deployment/netobserv-plugin -n netobserv -- curl -G -s -H 'X-Scope-OrgID:network' -H 'Authorization: Bearer <api_token>' -k https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network/loki/api/v1/query --data-urlencode 'query={SrcK8S_Namespace="my-namespace"}' | jq

其他资源

资源注意事项

排查 Loki ResourceExhausted 错误

当网络可观测性发送的网络流量数据超过配置的最大消息大小限制时，Loki 可能会返回 `ResourceExhausted` 错误。如果您使用的是 Red Hat Loki Operator，则此最大消息大小配置为 100 MiB。

步骤

导航到 **操作符** → **已安装的操作符**，从**项目**下拉菜单中查看**所有项目**。
在**提供的 API** 列表中，选择网络可观测性操作符。
点击**流量收集器**，然后点击**YAML 视图**选项卡。
1. 如果您使用的是 Loki Operator，请检查 `spec.loki.batchSize` 值是否不超过 98 MiB。
2. 如果您使用的是与 Red Hat Loki Operator 不同的 Loki 安装方法，例如 Grafana Loki，请验证 `grpc_server_max_recv_msg_size` Grafana Loki 服务器设置是否高于 `FlowCollector` 资源 `spec.loki.batchSize` 值。如果不是，则必须增加 `grpc_server_max_recv_msg_size` 值或减小 `spec.loki.batchSize` 值，使其低于限制。
如果您编辑了**流量收集器**，请点击**保存**。

Loki 空环错误

Loki 的“空环”错误会导致流量未存储在 Loki 中，并且不会显示在 Web 控制台中。此错误可能在各种情况下发生。目前尚不存在解决所有这些问题的单一解决方案。您可以采取一些措施来检查 Loki Pod 中的日志，并验证 `LokiStack` 是否健康且已准备就绪。

观察到此错误的一些情况如下：

在同一命名空间中卸载并重新安装 `LokiStack` 后，旧的 PVC 未删除，这可能会导致此错误。
- **操作：**您可以尝试再次删除 `LokiStack`，删除 PVC，然后重新安装 `LokiStack`。
证书轮换后，此错误可能会阻止与 `flowlogs-pipeline` 和 `console-plugin` Pod 的通信。
- **操作：**您可以重新启动 Pod 以恢复连接。

资源故障排除

LokiStack 速率限制错误

对 Loki 租户实施的速率限制可能会导致潜在的临时数据丢失和 429 错误：`Per stream rate limit exceeded (limit:xMB/sec) while attempting to ingest for stream`。您可能需要设置警报来通知您此错误。有关更多信息，请参阅本节“其他资源”中的“为 NetObserv 仪表板创建 Loki 速率限制警报”。

您可以使用 `perStreamRateLimit` 和 `perStreamRateLimitBurst` 规范更新 LokiStack CRD，如下所示。

步骤

导航到 **操作符** → **已安装的操作符**，从**项目**下拉菜单中查看**所有项目**。
查找**Loki Operator**，然后选择**LokiStack**选项卡。

使用**YAML 视图**创建或编辑现有的**LokiStack**实例，以添加 `perStreamRateLimit` 和 `perStreamRateLimitBurst` 规范。

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: loki
  namespace: netobserv
spec:
  limits:
    global:
      ingestion:
        perStreamRateLimit: 6        (1)
        perStreamRateLimitBurst: 30  (2)
  tenants:
    mode: openshift-network
  managementState: Managed

1	`perStreamRateLimit` 的默认值为 `3`。
2	`perStreamRateLimitBurst` 的默认值为 `15`。

点击**保存**。

验证

更新 `perStreamRateLimit` 和 `perStreamRateLimitBurst` 规范后，集群中的 Pod 将重新启动，并且不再出现 429 速率限制错误。

运行大型查询导致 Loki 错误

运行大型查询较长时间时，可能会出现 Loki 错误，例如 `timeout` 或 `too many outstanding requests`。此问题没有完整的纠正方法，但有一些方法可以减轻其影响。

调整您的查询以添加索引过滤器

使用 Loki 查询，您可以查询索引字段和非索引字段或标签。包含标签过滤器的查询性能更好。例如，如果您查询特定 Pod（它不是索引字段），则可以向查询中添加其命名空间。索引字段列表可在“网络流量格式参考”中的“Loki 标签”列中找到。

考虑查询 Prometheus 而不是 Loki

对于查询较长时间范围的数据，Prometheus 比 Loki 更合适。但是，您是否可以使用 Prometheus 代替 Loki 取决于用例。例如，Prometheus 上的查询比 Loki 上的查询快得多，并且较长时间范围不会影响性能。但是，Prometheus 指标包含的信息不如 Loki 中的流量日志多。如果查询兼容，网络可观测性 OpenShift Web 控制台会自动优先选择 Prometheus 而不是 Loki；否则，它默认为 Loki。如果您的查询未针对 Prometheus 运行，您可以更改某些过滤器或聚合以进行切换。在 OpenShift Web 控制台中，您可以强制使用 Prometheus。当不兼容的查询失败时，会显示错误消息，这可以帮助您找出要更改哪些标签以使查询兼容。例如，将过滤器或聚合从**资源**或**Pod**更改为**所有者**。

考虑使用 FlowMetrics API 创建您自己的指标

如果您需要的數據未作为 Prometheus 指标提供，则可以使用 FlowMetrics API 创建您自己的指标。有关更多信息，请参阅“FlowMetrics API 参考”和“使用 FlowMetric API 配置自定义指标”。

配置 Loki 以提高查询性能

如果问题仍然存在，您可以考虑配置 Loki 以提高查询性能。某些选项取决于您用于 Loki 的安装模式，例如使用 Operator 和 `LokiStack`，或 `Monolithic` 模式或 `Microservices` 模式。

在 `LokiStack` 或 `Microservices` 模式下，尝试增加查询器副本数量。
增加查询超时时间。您还必须在FlowCollector的spec.loki.readTimeout中增加网络可观测性读取Loki的超时时间。

其他资源