第 4 章 安装日志记录
您可以通过部署 Red Hat OpenShift Logging Operator 为 Red Hat OpenShift 安装日志记录子系统。Logging 子系统 Operator 会创建和管理日志记录堆栈的组件。
对于新的安装,建议使用 Vector 和 LokiStack。有关日志记录的文档正在更新,以反映这些底层组件更改。
从日志记录版本 5.6 Fluentd 开始,计划在以后的发行版本中删除。红帽将在当前发行生命周期中提供对这个功能的程序漏洞修复和支持,但这个功能将不再获得改进,并将被删除。作为 Fluentd 的替代选择,您可以使用 Vector。
4.1. 使用 Web 控制台为 Red Hat OpenShift 安装 logging 子系统
如果您不希望使用默认的 Elasticsearch 日志存储,您可以从 ClusterLogging
自定义资源 (CR) 中删除内部 Elasticsearch logStore
和 Kibana visualization
组件。删除这些组件是可选的,但会保存资源。
日志记录作为可安装的组件提供,它与 Red Hat OpenShift Service on AWS 核心不同。Red Hat OpenShift Container Platform 生命周期政策 概述了发行版本兼容性。
流程
-
在 Red Hat OpenShift Service on AWS web 控制台中,点 Operators
OperatorHub。 - 从可用的 Operator 列表中选择 Red Hat OpenShift Logging,然后点 Install。
- 确定在 Installation mode 下选择了 A specific namespace on the cluster。
- 确定在 Installed Namespace 下的 Operator recommended namespace 是 openshift-logging。
选择 Enable operator recommended cluster monitoring on this namespace。
这个选项在 Namespace 对象中设置
openshift.io/cluster-monitoring: "true"
标识。您必须选择这个选项,以确保集群监控提取openshift-logging
命名空间。选择 stable-5.x 作为 更新频道。
注意stable
频道只为日志记录的最新版本提供更新。要继续获得之前版本的更新,您必须将订阅频道改为stable-X
,其中X
是您安装的日志记录版本。选择一个 Update approval。
- Automatic 策略允许 Operator Lifecycle Manager(OLM)在有新版本可用时自动更新 Operator。
- Manual 策略需要拥有适当凭证的用户批准 Operator 更新。
- 为 Console 插件选择 Enable 或 Disable。
- 点 Install。
验证
通过切换到 Operators
Installed Operators 页来验证 Red Hat OpenShift Logging Operator 是否已安装。 - 确保 openshift-logging 项目中列出的 Red Hat OpenShift Logging 的 Status 为 InstallSucceeded。
-
通过切换到 Operators
Installed Operators 页来验证 Red Hat OpenShift Logging Operator 已被安装。 确保 openshift-logging 项目中列出的 Red Hat OpenShift Logging 的 Status 为 InstallSucceeded。
如果 Operator 没有被成功安装,请按照以下步骤进行故障排除:
-
切换到 Operators
Installed Operators 页面,并检查 Status 列中是否有任何错误或故障。 -
切换到 Workloads
Pods 页面,并检查 openshift-logging
项目中报告问题的 pod 的日志。
-
切换到 Operators
创建 ClusterLogging 实例。
注意Web 控制台的表单视图不包括所有可用的选项。建议您使用 YAML 视图 来完成您的设置。
在 collection 部分中,选择一个 Collector Implementation。
注意从日志记录版本 5.6 Fluentd 开始,计划在以后的发行版本中删除。红帽将在当前发行生命周期中提供对这个功能的程序漏洞修复和支持,但这个功能将不再获得改进,并将被删除。作为 Fluentd 的替代选择,您可以使用 Vector。
在 logStore 部分中,选择一个类型。
注意自日志记录版本 5.4.3 起,OpenShift Elasticsearch Operator 已被弃用,计划在以后的发行版本中删除。红帽将在当前发行生命周期中提供对这个功能的程序漏洞修复和支持,但这个功能将不再获得改进,并将被删除。您可以使用 Loki Operator 作为 OpenShift Elasticsearch Operator 的替代方案来管理默认日志存储。
- 点击 Create。
创建 OpenShift Logging 实例:
-
切换到 Administration
Custom Resource Definitions 页面。 - 在 Custom Resource Definitions 页面上,点 ClusterLogging。
- 在 Custom Resource Definition details 页中,从 Actions 菜单中选择 View Instances。
在 ClusterLoggings 页中,点 Create ClusterLogging。
您可能需要刷新页面来加载数据。
将 YAML 项中的代码替换为以下内容:
注意此默认 OpenShift Logging 配置应该可以支持各种环境。参阅有关调优和配置日志记录子系统组件的主题,以了解有关可对 OpenShift Logging 集群进行修改的信息。
apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance 1 namespace: openshift-logging spec: managementState: Managed 2 logStore: type: elasticsearch 3 retentionPolicy: 4 application: maxAge: 1d infra: maxAge: 7d audit: maxAge: 7d elasticsearch: nodeCount: 3 5 storage: storageClassName: <storage_class_name> 6 size: 200G resources: 7 limits: memory: 16Gi requests: memory: 16Gi proxy: 8 resources: limits: memory: 256Mi requests: memory: 256Mi redundancyPolicy: SingleRedundancy visualization: type: kibana 9 kibana: replicas: 1 collection: logs: type: fluentd 10 fluentd: {}
- 1
- 名称必须是
instance
。 - 2
- OpenShift Logging 管理状态。在一些数情况下,如果更改了 OpenShift Logging 的默认值,则必须将其设置为
Unmanaged
。但是,非受管部署不接收更新,直到 OpenShift Logging 重新变为受管状态为止。 - 3
- 用于配置 Elasticsearch 的设置。通过使用 CR,您可以配置分片复制策略和持久性存储。
- 4
- 指定 Elasticsearch 应该保留每个日志源的时间长度。输入一个整数和时间单位: 周(w)、小时(h/H)、分钟(m)和秒。例如,
7d
代表 7 天。时间超过maxAge
的旧日志会被删除。您必须为每个日志源指定一个保留策略,否则不会为该源创建 Elasticsearch 索引。 - 5
- 指定 Elasticsearch 节点的数量。请参阅此列表后面的备注。
- 6
- 为 Elasticsearch 存储输入现有存储类的名称。为获得最佳性能,请指定分配块存储的存储类。如果没有指定存储类,OpenShift Logging 将使用临时存储。
- 7
- 根据需要指定 Elasticsearch 的 CPU 和内存请求。如果这些值留白,则 OpenShift Elasticsearch Operator 会设置默认值,它们应足以满足大多数部署的需要。内存请求的默认值为
16Gi
,CPU 请求为1
。 - 8
- 根据需要指定 Elasticsearch 代理的 CPU 和内存请求。如果这些值留白,则 OpenShift Elasticsearch Operator 会设置默认值,它们应足以满足大多数部署的需要。内存请求的默认值为
256Mi
,CPU 请求的默认值为100m
。 - 9
- 用于配置 Kibana 的设置。通过使用 CR,您可以扩展 Kibana 来实现冗余性,并为 Kibana 节点配置 CPU 和内存。如需更多信息,请参阅配置日志可视化工具。
- 10
- 用于配置 Fluentd 的设置。通过使用 CR,您可以配置 Fluentd CPU 和内存限值。如需更多信息,请参阅配置 Fluentd。
注意Elasticsearch control plane 节点的最大数量为三个。如果您指定大于
3
的nodeCount
,Red Hat OpenShift Service on AWS 会创建三个符合 Master 的节点的 Elasticsearch 节点,具有 master、client 和 data 角色。其余 Elasticsearch 节点创建为“仅数据”节点,使用 client 和 data 角色。control plane 节点执行集群范围的操作,如创建或删除索引、分片分配和跟踪节点。数据节点保管分片,并执行与数据相关的操作,如 CRUD、搜索和聚合等。与数据相关的操作会占用大量 I/O、内存和 CPU。务必要监控这些资源,并在当前节点过载时添加更多数据节点。例如,如果
nodeCount = 4
,则创建以下节点:$ oc get deployment
输出示例
cluster-logging-operator 1/1 1 1 18h elasticsearch-cd-x6kdekli-1 0/1 1 0 6m54s elasticsearch-cdm-x6kdekli-1 1/1 1 1 18h elasticsearch-cdm-x6kdekli-2 0/1 1 0 6m49s elasticsearch-cdm-x6kdekli-3 0/1 1 0 6m44s
索引模板的主分片数量等于 Elasticsearch 数据节点的数目。
-
点击 Create。这会创建 logging 子系统组件、
Elasticsearch
自定义资源和组件以及 Kibana 接口。
-
切换到 Administration
验证安装:
-
切换到 Workloads
Pods 页面。 选择 openshift-logging 项目。
确认 Operator 和 Elasticsearch、收集器和 Kibana 组件的 pod 已存在:
- cluster-logging-operator-595f9bf9c4-txrp4
- collector-29bw8
- collector-4kvnl
- collector-7rr7w
- collector-9m2xp
- collector-xt45j
- elasticsearch-cdm-g559ha9u-1-659fd594bf-pcm2f
- elasticsearch-cdm-g559ha9u-2-66455f68db-v46n6
- elasticsearch-cdm-g559ha9u-3-85696bcf55-g7tf8
- elasticsearch-im-app-27934020-9ltxl
- elasticsearch-im-audit-27934020-86cdt
- elasticsearch-im-infra-27934020-6lrgm
- kibana-5c6b7cd56-66c9l
-
切换到 Workloads
故障排除
-
如果 Alertmanager 日志记录
Prometheus 等警报无法提取超过 10m 的 fluentd
,请确保 OpenShift Elasticsearch Operator 和 OpenShift Logging Operator 的openshift.io/cluster-monitoring
设置为"true
"。如需更多信息,请参阅 Red Hat knowledgeBase: Prometheus could not scrape fluentd for more than 10m alert in Alertmanager