Menu Close

第 7 章 Monitor

7.1. 在 OpenShift Serverless 中使用 OpenShift Logging

7.1.1. 关于部署 OpenShift Logging

OpenShift Container Platform 集群管理员可以使用 OpenShift Container Platform Web 控制台或 CLI 部署 OpenShift Logging 来安装 OpenShift Elasticsearch Operator 和 Operator and Red Hat OpenShift Logging Operator。安装 Operator 后,可创建 ClusterLogging 自定义资源(CR)以调度 OpenShift Logging pod 和支持 OpenShift Logging 所需的其他资源。Operator 负责部署、升级和维护 OpenShift Logging。

ClusterLogging CR 定义包括日志记录堆栈的所有组件在内的完整 OpenShift Logging 环境,以收集、存储和视觉化日志。Red Hat OpenShift Logging Operator 监视 OpenShift Logging CR 并相应地调整日志记录部署。

管理员和应用程序开发人员可以查看他们具有查看访问权限的项目的日志。

7.1.2. 关于部署和配置 OpenShift Logging

OpenShift Logging 旨在与默认配置一起使用,该配置针对中小型 OpenShift Container Platform 集群进行了调优。

以下安装说明包括一个示例 ClusterLogging 自定义资源(CR),您可以用它来创建 OpenShift Logging 实例并配置 OpenShift Logging 环境。

如果要使用默认的 OpenShift Logging 安装,可以直接使用示例 CR。

如果要自定义部署,请根据需要对示例 CR 进行更改。下面介绍了在安装 OpenShift Logging 实例或安装后修改时可以进行的配置。请参阅“配置”部分来了解有关使用各个组件的更多信息,包括可以在 ClusterLogging 自定义资源之外进行的修改。

7.1.2.1. 配置和调优 OpenShift Logging

您可以通过修改 openshift-logging 项目中部署的 ClusterLogging 自定义资源来配置 OpenShift Logging 环境。

您可以在安装时或安装后修改以下任何组件:

内存和 CPU
您可以使用有效的内存和 CPU 值修改 resources 块,以此调整各个组件的 CPU 和内存限值:
spec:
  logStore:
    elasticsearch:
      resources:
        limits:
          cpu:
          memory: 16Gi
        requests:
          cpu: 500m
          memory: 16Gi
      type: "elasticsearch"
  collection:
    logs:
      fluentd:
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
        type: "fluentd"
  visualization:
    kibana:
      resources:
        limits:
          cpu:
          memory:
        requests:
          cpu:
          memory:
      type: kibana
Elasticsearch 存储
您可以使用 storageClass namesize 参数,为 Elasticsearch 集群配置持久性存储类和大小。Red Hat OpenShift Logging Operator 基于这些参数,为 Elasticsearch 集群中的每个数据节点创建一个持久性卷声明(PVC)。
  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage:
          storageClassName: "gp2"
          size: "200G"

本例中指定,集群中的每个数据节点将绑定到请求 200G 的 gp2 存储的 PVC。每个主分片将由单个副本支持。

注意

省略 storage 块会导致部署中仅包含临时存储。

  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage: {}
Elasticsearch 复制策略

您可以通过设置策略来定义如何在集群中的数据节点之间复制 Elasticsearch 分片:

  • FullRedundancy。各个索引的分片完整复制到每个数据节点上。
  • MultipleRedundancy。各个索引的分片分布到一半数据节点上。
  • SingleRedundancy。各个分片具有单个副本。只要存在至少两个数据节点,日志就能始终可用且可恢复。
  • ZeroRedundancy。所有分片均无副本。如果节点关闭或发生故障, 则可能无法获得日志数据。

7.1.2.2. 修改后的 ClusterLogging 自定义资源示例

以下是使用前面描述的选项修改的 ClusterLogging 自定义资源的示例。

修改后的 ClusterLogging 自定义资源示例

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    retentionPolicy:
      application:
        maxAge: 1d
      infra:
        maxAge: 7d
      audit:
        maxAge: 7d
    elasticsearch:
      nodeCount: 3
      resources:
        limits:
          memory: 32Gi
        requests:
          cpu: 3
          memory: 32Gi
        storage:
          storageClassName: "gp2"
          size: "200G"
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources:
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      replicas: 1
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 1Gi

7.1.3. 使用 OpenShift Logging 查找 Knative Serving 组件的日志

流程

  1. 获取 Kibana 路由:

    $ oc -n openshift-logging get route kibana
  2. 使用路由的 URL 导航到 Kibana 仪表板并登录。
  3. 检查是否将索引设置为 .all。如果索引未设置为 .all,则只会列出 OpenShift Container Platform 系统日志。
  4. 使用 knative-serving 命名空间过滤日志。在搜索框中输入 kubernetes.namespace_name:knative-serving 以过滤结果。
注意

Knative Serving 默认使用结构化日志记录。您可以通过自定义 OpenShift Logging Fluentd 设置来启用这些日志的解析。这可使日志更易搜索,并且能够在日志级别进行过滤以快速识别问题。

7.1.4. 使用 OpenShift Logging 查找通过 Knative Serving 部署的服务的日志

使用 OpenShift Logging,应用程序写入控制台的日志将在 Elasticsearch 中收集。以下流程概述了如何使用 Knative Serving 将这些功能应用到所部署的应用程序中。

流程

  1. 获取 Kibana 路由:

    $ oc -n openshift-logging get route kibana
  2. 使用路由的 URL 导航到 Kibana 仪表板并登录。
  3. 检查是否将索引设置为 .all。如果索引未设置为 .all,则只会列出 OpenShift 系统日志。
  4. 使用 knative-serving 命名空间过滤日志。在搜索框中输入服务的过滤器来过滤结果。

    过滤器示例

    kubernetes.namespace_name:default AND kubernetes.labels.serving_knative_dev\/service:{service_name}

    除此之外还可使用 /configuration/revision 来过滤。

  5. 您可使用 kubernetes.container_name:<user-container> 来缩小搜索范围,只显示由您的应用程序生成的日志。否则,会显示来自 queue-proxy 的日志。
注意

在应用程序中使用基于 JSON 的结构化日志记录,以便在生产环境中快速过滤这些日志。