日志记录
在 OpenShift Container Platform 4.2 中配置集群日志记录
摘要
第 1 章 关于集群日志记录和 OpenShift Container Platform
作为集群管理员，您可以部署集群日志记录来聚合 OpenShift Container Platform 集群中的所有日志，如节点系统日志、应用程序容器日志等。
1.1. 关于集群日志记录
OpenShift Container Platform 集群管理员可以使用一些 CLI 命令和 OpenShift Container Platform Web 控制台安装 Elasticsearch Operator 和 Cluster Logging Operator，以此部署集群日志记录。安装 Operator 后，可创建集群日志记录自定义资源 (CR) 以调度集群日志记录 pod 和支持集群日志记录所需的其他资源。Operator 负责部署、升级和维护集群日志记录。
您可以通过修改集群日志记录自定义资源 (CR)（名为 instance）来配置集群日志记录。CR 定义包括日志记录堆栈的所有组件在内的完整集群日志记录部署，以收集、存储和视觉化日志。Cluster Logging Operator 监控 ClusterLogging 自定义资源并相应地调整日志记录部署。
管理员和应用程序开发人员可以查看他们具有查看访问权限的项目的日志。
1.1.1. 关于集群日志记录组件
集群日志记录组件基于 Elasticsearch、Fluentd 或 Rsyslog 以及 Kibana（EFK）。收集器 Fluentd 部署到 OpenShift Container Platform 集群中的每个节点。它收集所有节点和容器日志，并将它们写入 Elasticsearch (ES)。Kibana 是一个集中式 Web UI，用户和管理员可以在其中使用汇总的数据创建丰富的视觉化和仪表板。
目前有 5 种不同类型的集群日志记录组件：
- logStore（存储） - 存储日志的位置。当前的实现是 Elasticsearch。
- collection（收集） - 此组件从节点收集日志，将日志格式化并存储到 logStore 中。当前的实现是 Fluentd。
- visualization（可视化） - 此 UI 组件用于查看日志、图形和图表等。当前的实现是 Kibana。
- curation（策展） - 此组件按日志时间进行筛检。当前的实现是 Curator。
- event routing - 用来把 OpenShift Container Platform 的事件转发到集群日志记录的组件。当前的实现是 Event Router。
除非特别说明，在本文中我们可能会互换使用日志存储或 Elasticsearch、视觉化或 Kibana、策展或 Curator、收集或 Fluentd。
1.1.2. 关于日志存储
OpenShift Container Platform 使用 Elasticsearch (ES) 将日志数据从 Fluentd 整理到数据存储或索引中。
Elasticsearch 将各个索引进一步划分成多个碎片（称为分片），分散到 Elasticsearch 集群中的一组 Elasticsearch 节点上。您可以配置 Elasticsearch 来为分片制作拷贝（称为副本）。Elasticsearch 也将这些副本分散到多个 Elasticsearch 节点上。借助 ClusterLogging 自定义资源，您可以在自定义资源定义 (CRD) 中指定复制策略，以提供数据冗余和故障恢复能力。
索引模板的主分片数量等于 Elasticsearch 数据节点的数目。
Cluster Logging Operator 和相应的 Elasticsearch Operator 确保每个 Elasticsearch 节点都使用带有自身存储卷的唯一 Deployment 来进行部署。您可以使用集群日志记录自定义资源 (CR) 来增加 Elasticsearch 节点的数量。如需有关选择存储和网络位置的注意事项，请参考 Elastic 文档，如下所示。
高可用性 Elasticsearch 环境需要至少三个 Elasticsearch 节点，各自在不同的主机上。
Elasticsearch 索引中应用的基于角色的访问控制 (RBAC) 可让开发人员控制对日志的访问。使用 project.{project_name}.{project_uuid}.* 格式对索引进行访问将会根据特定项目中的用户权限进行限制。
如需更多信息，请参阅 Elasticsearch (ES)。
1.1.3. 关于日志记录收集器
OpenShift Container Platform 使用 Fluentd 来收集集群的相关数据。
日志记录收集器部署为 OpenShift Container Platform 中的 DaemonSet，将各个 Pod 部署到每个 OpenShift Container Platform 节点中。journald 是系统日志源，提供来自操作系统、容器运行时和 OpenShift Container Platform 的日志消息。
容器运行时提供少许信息来标识日志消息的来源，如项目、容器名称和容器 ID。这不足以唯一地标识日志来源。如果在日志收集器开始处理日志之前删除了具有指定名称和项目的 Pod，则来自 API 服务器的信息（如标签和注解）可能会不可用。可能没有办法区分来自名称相似的 Pod 和项目的日志消息，也无法追溯日志的来源。这种局限性意味着日志收集和规范化仅属于尽力而为。
可用的容器运行时提供少许信息来标识日志消息来源，无法确保唯一的个别日志消息，也不能保证可以追溯这些消息的来源。
如需更多信息，请参阅 Fluentd。
1.1.4. 关于日志记录视觉化
OpenShift Container Platform 使用 Kibana 显示由 Fluentd 收集并由 Elasticsearch 索引的日志数据。
Kibana 是基于浏览器的控制台界面，可通过直方图、折线图、饼图、热图、内置地理空间支持和其他视觉化方式，来查询、探索和视觉化您的 Elasticsearch 数据。
如需更多信息，请参阅 Kibana。
1.1.5. 关于日志记录策展
Elasticsearch Curator 工具在全局范围和/或以项目为基础执行调度的维护操作。Curator 根据其配置执行操作。建议每个 Elasticsearch 集群仅使用一个 Curator Pod。
spec:
curation:
type: "curator"
resources:
curator:
schedule: "30 3 * * *" 1如需更多信息，请参阅 Curator。
1.1.6. 关于事件路由
Event Router 是一个 pod，它将 OpenShift Container Platform 事件转发到集群日志记录系统。您必须手动部署 Event Router。
Event Router 收集事件并将其转换为 JSON 格式，并将其输出到 STDOUT。Fluentd 将事件编制成 .operations 索引。
1.1.7. 集群日志记录自定义资源 (CR)
要更改集群日志记录部署，请创建并修改集群日志记录自定义资源 (CR) 。本文根据需要提供了有关创建或修改 CR 的说明。
以下是集群日志记录的典型自定义资源的示例。
集群日志记录 CR 示例
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
name: "instance"
namespace: openshift-logging
spec:
managementState: "Managed"
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 2
resources:
limits:
memory: 2Gi
requests:
cpu: 200m
memory: 2Gi
storage:
storageClassName: "gp2"
size: "200G"
redundancyPolicy: "SingleRedundancy"
visualization:
type: "kibana"
kibana:
resources:
limits:
memory: 1Gi
requests:
cpu: 500m
memory: 1Gi
proxy:
resources:
limits:
memory: 100Mi
requests:
cpu: 100m
memory: 100Mi
replicas: 2
curation:
type: "curator"
curator:
resources:
limits:
memory: 200Mi
requests:
cpu: 200m
memory: 200Mi
schedule: "*/10 * * * *"
collection:
logs:
type: "fluentd"
fluentd:
resources:
limits:
memory: 1Gi
requests:
cpu: 200m
memory: 1Gi
第 2 章 关于部署集群日志记录
在将集群日志记录安装到 OpenShift Container Platform 集群前，请先查阅以下小节。
2.1. 关于部署和配置集群日志记录
OpenShift Container Platform 集群日志记录已设计为可搭配默认配置使用，该配置针对中小型 OpenShift Container Platform 集群进行了调优。
以下安装说明包括一个示例集群日志记录自定义资源 (CR)，您可以用它来创建集群日志记录实例并配置集群日志记录部署。
如果要使用默认集群日志记录安装，可直接使用示例 CR。
如果要自定义部署，请根据需要对示例 CR 进行更改。下文介绍了在安装集群日志记录实例或安装后修改时可以进行的配置。请参阅“配置”部分来了解有关使用各个组件的更多信息，包括可以在集群日志记录自定义资源之外进行的修改。
2.1.1. 配置和调优集群日志记录
您可以通过修改 openshift-logging 项目中部署的集群日志记录自定义资源来配置集群日志记录环境。
您可以在安装时或安装后修改以下任何组件：
- 内存和 CPU
-
您可以使用有效的内存和 CPU 值修改
resources块，以此调整各个组件的 CPU 和内存限值：
spec:
logStore:
elasticsearch:
resources:
limits:
cpu:
memory:
requests:
cpu: 1
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
curation:
curator:
resources:
limits:
memory: 200Mi
requests:
cpu: 200m
memory: 200Mi
type: "curator"- Elasticsearch 存储
-
您可以使用
storageClassname和size参数，为 Elasticsearch 集群配置持久性存储类和大小。Cluster Logging Operator 基于这些参数为 Elasticsearch 集群中的每个数据节点创建PersistentVolumeClaim。
spec:
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 3
storage:
storageClassName: "gp2"
size: "200G"
本例中指定，集群中的每个数据节点将绑定到请求 200G 的 gp2 存储的 PersistentVolumeClaim。每个主分片将由单个副本支持。
省略 storage 块会导致部署中仅包含临时存储。
spec:
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 3
storage: {}- Elasticsearch 复制策略
您可以通过设置策略来定义如何在集群中的数据节点之间复制 Elasticsearch 分片：
-
FullRedundancy。各个索引的分片完整复制到每个数据节点上。 -
MultipleRedundancy。各个索引的分片分布到一半数据节点上。 -
SingleRedundancy。各个分片具有单个副本。只要存在至少两个数据节点，日志就能始终可用且可恢复。 -
ZeroRedundancy。所有分片均无副本。如果节点关闭或发生故障， 则可能无法获得日志数据。
-
- Curator 调度
- 以 cron 格式指定 Curator 的调度。
spec:
curation:
type: "curator"
resources:
curator:
schedule: "30 3 * * *"2.1.2. 修改后集群日志记录自定义资源示例
以下是使用前述选项修改的集群日志记录自定义资源的示例。
修改后集群日志记录自定义资源示例
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
name: "instance"
namespace: "openshift-logging"
spec:
managementState: "Managed"
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 2
resources:
limits:
memory: 2Gi
requests:
cpu: 200m
memory: 2Gi
storage: {}
redundancyPolicy: "SingleRedundancy"
visualization:
type: "kibana"
kibana:
resources:
limits:
memory: 1Gi
requests:
cpu: 500m
memory: 1Gi
replicas: 1
curation:
type: "curator"
curator:
resources:
limits:
memory: 200Mi
requests:
cpu: 200m
memory: 200Mi
schedule: "*/5 * * * *"
collection:
logs:
type: "fluentd"
fluentd:
resources:
limits:
memory: 1Gi
requests:
cpu: 200m
memory: 1Gi
2.2. 集群日志记录和 OpenShift Container Platform 的存储注意事项
每个 Elasticsearch 部署都需要一个持久性卷，以便每个数据节点均有一个数据卷。在 OpenShift Container Platform 中，这可以使用 PVC 来实现。
Elasticsearch Operator 使用 Elasticsearch 资源名称来命名 PVC。如需更多详细信息，请参阅“Elasticsearch 持久性存储”。
Fluentd 将 systemd journal 和 /var/log/containers/ 的所有日志都传输到 Elasticsearch。
因此，请提前考虑需要的数据量，并且注意要聚合应用程序的日志数据。一些 Elasticsearch 用户发现，有必要使绝对存储消耗始终保持在 50％ 左右并处于 70％ 以下。这有助于避免 Elasticsearch 在进行大型数据合并操作期间变得无响应。
默认情况下，达到 85％时 Elasticsearch 会停止向节点分配新数据，达到 90％ 时 Elasticsearch 会尝试将现有分片从节点重新定位到其他节点（若有可能）。但是，如果存储消耗低于 85％ 时无节点有可用存储空间，Elasticsearch 会拒绝创建新索引并且变为 RED。
这些高、低水位线值是当前版本中的 Elasticsearch 默认值。您可以修改这些值，但需要同时将修改应用到警报。警报基于这些默认值。
2.3. 其他资源
如需有关安装 Operator 的更多信息，请参阅从 OperatorHub 安装 Operator。
第 3 章 部署集群日志记录
您可以通过部署 Elasticsearch 和 Cluster Logging Operator 来安装集群日志记录。Elasticsearch Operator 负责创建并管理由集群日志记录使用的 Elasticsearch 集群。Cluster Logging Operator 负责创建并管理日志记录堆栈的组件。
将集群日志记录部署到 OpenShift Container Platform 的过程涉及以下任务：
- 查阅关于部署集群日志记录中的安装选项。
- 查阅集群日志记录存储注意事项。
- 安装 Elasticsearch Operator 和 Cluster Logging Operator。
3.1. 使用 CLI 安装 Elasticsearch Operator
您必须按照以下说明来使用 CLI 安装 Elasticsearch Operator。
先决条件
确保具有 Elasticsearch 所需的持久性存储。注意每个 Elasticsearch 节点都需要自己的存储卷。
Elasticsearch 是内存密集型应用程序。每个 Elasticsearch 节点都需要 16G 内存来满足内存请求和限值。最初的 OpenShift Container Platform 节点组可能不足以支持 Elasticsearch 集群。您必须在 OpenShift Container Platform 集群中添加额外的节点，才能使用建议或更高的内存来运行。每个 Elasticsearch 节点都可以在较低的内存设置下运行，但在生产部署中不建议这样做。
流程
使用 CLI 安装 Elasticsearch Operator：
为 Elasticsearch Operator 创建一个命名空间。
为 Elasticsearch Operator 创建一个命名空间对象 YAML 文件（例如
eo-namespace.yaml）：apiVersion: v1 kind: Namespace metadata: name: openshift-operators-redhat 1 annotations: openshift.io/node-selector: "" labels: openshift.io/cluster-monitoring: "true" 2
- 1
- 您必须指定
openshift-operators-redhat命名空间。为了防止可能与指标（metrics）冲突，您应该将 Prometheus Cluster Monitoring 堆栈配置为从openshift-operators-redhat命名空间中提取指标数据，而不是从openshift-operators命名空间中提取。openshift-operators命名空间可能会包含社区提供的 operator。这些 operator 不被信任，其发布的 metric 可能与 OpenShift Container Platform metric 的名称相同，从而导致冲突。 - 2
- 您必须按照所示指定该标签，以确保集群监控提取
openshift-operators-redhat命名空间。
创建命名空间：
$ oc create -f <file-name>.yaml
例如：
$ oc create -f eo-namespace.yaml
通过创建以下对象来安装 Elasticsearch Operator：
为 Elasticsearch Operator 创建 Operator Group 对象 YAML 文件（例如
eo-og.yaml）：apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-operators-redhat namespace: openshift-operators-redhat 1 spec: {}- 1
- 您必须指定
openshift-operators-redhat命名空间。
创建 Operator Group 对象：
$ oc create -f <file-name>.yaml
例如：
$ oc create -f eo-og.yaml
创建 Subscription 对象 YAML 文件（例如
eo-sub.yaml）来订阅 Operator 的命名空间。订阅示例
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: "elasticsearch-operator" namespace: "openshift-operators-redhat" 1 spec: channel: "4.2" 2 installPlanApproval: "Automatic" source: "redhat-operators" 3 sourceNamespace: "openshift-marketplace" name: "elasticsearch-operator"
创建订阅对象：
$ oc create -f <file-name>.yaml
例如：
$ oc create -f eo-sub.yaml
更改到
openshift-operators-redhat项目：$ oc project openshift-operators-redhat Now using project "openshift-operators-redhat"
创建基于角色的访问控制 (RBAC) 对象文件（例如
eo-rbac.yaml），向 Prometheus 授予openshift-operators-redhat命名空间的访问权限：apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: prometheus-k8s namespace: openshift-operators-redhat rules: - apiGroups: - "" resources: - services - endpoints - pods verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: prometheus-k8s namespace: openshift-operators-redhat roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: prometheus-k8s subjects: - kind: ServiceAccount name: prometheus-k8s namespace: openshift-operators-redhat
创建 RBAC 对象：
$ oc create -f <file-name>.yaml
例如：
$ oc create -f eo-rbac.yaml
Elasticsearch Operator 已安装到
openshift-operators-redhat命名空间，并且复制到集群中的每个项目。
验证 Operator 安装：
oc get csv --all-namespaces NAMESPACE NAME DISPLAY VERSION REPLACES PHASE default elasticsearch-operator.4.2.1-202002032140 Elasticsearch Operator 4.2.1-202002032140 Succeeded kube-node-lease elasticsearch-operator.4.2.1-202002032140 Elasticsearch Operator 4.2.1-202002032140 Succeeded kube-public elasticsearch-operator.4.2.1-202002032140 Elasticsearch Operator 4.2.1-202002032140 Succeeded kube-system elasticsearch-operator.4.2.1-202002032140 Elasticsearch Operator 4.2.1-202002032140 Succeeded openshift-apiserver-operator elasticsearch-operator.4.2.1-202002032140 Elasticsearch Operator 4.2.1-202002032140 Succeeded openshift-apiserver elasticsearch-operator.4.2.1-202002032140 Elasticsearch Operator 4.2.1-202002032140 Succeeded openshift-authentication-operator elasticsearch-operator.4.2.1-202002032140 Elasticsearch Operator 4.2.1-202002032140 Succeeded openshift-authentication elasticsearch-operator.4.2.1-202002032140 Elasticsearch Operator 4.2.1-202002032140 Succeeded ...
每个命名空间中都应该有一个 Elasticsearch Operator。版本号可能与所示不同。
后续步骤
使用控制台或 CLI 安装 Cluster Logging Operator。
3.2. 使用 web 控制台安装 Cluster Logging Operator。
使用 OpenShift Container Platform web 控制台安装 Cluster Logging Operator。
您不能通过 web 控制台或使用 oc new-project 命令创建名称以 openshift- 开始的项目。您必须使用一个 YAML 对象文件创建一个命名空间（Namespace），并运行 oc create -f <file-name>.yaml 命令，如下所示。
流程
使用 OpenShift Container Platform web 控制台安装 Cluster Logging Operator：
为 Cluster Logging Operator 创建一个命名空间。您必须使用 CLI 创建命名空间。
为 Cluster Logging Operator 创建一个命名空间对象 YAML 文件（例如，
clo-namespace.yaml）：apiVersion: v1 kind: Namespace metadata: name: openshift-logging 1 annotations: openshift.io/node-selector: "" 2 labels: openshift.io/cluster-logging: "true" openshift.io/cluster-monitoring: "true"
创建命名空间：
$ oc create -f <file-name>.yaml
例如：
$ oc create -f clo-namespace.yaml
安装 Cluster Logging Operator：
- 在 OpenShift Container Platform Web 控制台中，点击 Operators → OperatorHub。
- 从可用 Operator 列表中选择 Cluster Logging，再点击 Install。
- 在 Create Operator Subscription 页面中，在 A specific namespace on the cluster 下选择 openshift-logging。然后，点击 Subscribe。
验证 Cluster Logging Operator 已被安装。
- 切换到 Operators → Installed Operators 页面。
确保 openshift-logging 项目中列出的 Cluster Logging 的 Status 为 InstallSucceeded。
注意在安装过程中，Operator 可能会显示 Failed 状态。如果 Operator 随后被安装并显示 InstallSucceeded 信息，则可以忽略 Failed 信息。
如果 Operator 没有被成功安装，请按照以下步骤进行故障排除：
- 切换到 Operators → Installed Operators 页面，并检查 Status 列中是否有任何错误或故障。
-
切换到 Workloads → Pods 页面，并检查
openshift-logging和openshift-operators-redhat项目中报告问题的 Pod 的日志。
创建集群日志记录实例：
- 切换到 Administration → Custom Resource Definitions 页面。
- 在 Custom Resource Definitions 页面上，点 ClusterLogging。
- 在 Custom Resource Definition Overview 页面上，从 Actions 菜单中选择 View Instances。
在 Cluster Loggings 页面上，点击 Create Cluster Logging。
您可能需要刷新页面来加载数据。
将 YAML 项中的代码替换为以下内容：
注意此默认集群日志记录配置应该可以支持不同的环境。请参考有关调优和配置集群日志记录组件的主题，以了解有关可对集群日志记录集群进行修改的信息。
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" 1 namespace: "openshift-logging" spec: managementState: "Managed" 2 logStore: type: "elasticsearch" 3 elasticsearch: nodeCount: 3 4 storage: storageClassName: gp2 5 size: 200G redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" 6 kibana: replicas: 1 curation: type: "curator" 7 curator: schedule: "30 3 * * *" collection: logs: type: "fluentd" 8 fluentd: {}
- 1
- 名称必须是
instance。 - 2
- 集群日志记录管理状态。在大多数情况下，如果更改了集群日志记录的默认值，则必须将其设置为
Unmanaged。但是，非受管部署不接收更新，直到集群日志记录重新变为受管状态为止。如需更多信息，请参阅更改集群日志记录管理状态。 - 3
- 用于配置 Elasticsearch 的设置。通过使用 CR，您可以配置分片复制策略和持久性存储。如需更多信息，请参阅配置 Elasticsearch。
- 4
- 指定 Elasticsearch 节点的数量。请参阅此列表后面的备注。
- 5
- 指定集群中的每个 Elasticsearch 节点都绑定到持久性卷声明。
- 6
- 用于配置 Kibana 的设置。通过使用 CR，您可以扩展 Kibana 来实现冗余性，并为 Kibana 节点配置 CPU 和内存。如需更多信息，请参阅配置 Kibana。
- 7
- 用于配置 Curator 的设置。通过使用 CR，您可以设置 Curator 调度。如需更多信息，请参阅配置 Curator。
- 8
- 用于配置 Fluentd 的设置。通过使用 CR，您可以配置 Fluentd CPU 和内存限值。如需更多信息，请参阅配置 Fluentd。
注意Elasticsearch master 节点的最大数量为三个。如果您将
nodeCount指定为大于3，OpenShift Container Platform 只会创建三个符合 Master 节点条件的 Elasticsearch 节点（具有 master、client 和 data 角色）。其余 Elasticsearch 节点创建为“仅数据”节点，使用 client 和 data 角色。Master 节点执行集群范围的操作，如创建或删除索引、分配分片和跟踪节点等。数据节点保管分片，并执行与数据相关的操作，如 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。这将创建集群日志记录自定义资源和 Elasticsearch 自定义资源，您可以通过编辑它们来更改用于集群日志记录的集群。
验证安装：
- 切换到 Workloads → Pods 页面。
选择 openshift-logging 项目。
您应该会看到几个用于集群日志记录、Elasticsearch、Fluentd 和 Kibana 的 Pod，类似于以下列表：
- cluster-logging-operator-cb795f8dc-xkckc
- elasticsearch-cdm-b3nqzchd-1-5c6797-67kfz
- elasticsearch-cdm-b3nqzchd-2-6657f4-wtprv
- elasticsearch-cdm-b3nqzchd-3-588c65-clg7g
- fluentd-2c7dg
- fluentd-9z7kk
- fluentd-br7r2
- fluentd-fn2sb
- fluentd-pb2f8
- fluentd-zqgqx
- kibana-7fb4fd4cc9-bvt4p
3.3. 使用 CLI 安装 Cluster Logging Operator
您可以使用 OpenShift Container Platform CLI 安装 Cluster Logging Operator。Cluster Logging Operator 负责创建并管理日志记录堆栈的组件。
流程
使用 CLI 安装 Cluster Logging Operator：
为 Cluster Logging Operator 创建命名空间：
为 Cluster Logging Operator 创建一个命名空间对象 YAML 文件（例如，
clo-namespace.yaml）：apiVersion: v1 kind: Namespace metadata: name: openshift-logging annotations: openshift.io/node-selector: "" labels: openshift.io/cluster-logging: "true" openshift.io/cluster-monitoring: "true"创建命名空间：
$ oc create -f <file-name>.yaml
例如：
$ oc create -f clo-namespace.yaml
通过创建以下对象来安装 Cluster Logging Operator：
为 Cluster Logging Operator 创建一个 OperatorGroup 对象 YAML 文件（例如，
clo-og.yaml）：apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: cluster-logging namespace: openshift-logging 1 spec: targetNamespaces: - openshift-logging 2
创建 OperatorGroup 对象：
$ oc create -f <file-name>.yaml
例如：
$ oc create -f clo-og.yaml
创建一个 Subscription 对象 YAML 文件（例如，
clo-sub.yaml）来向 Operator 订阅一个 Namespace。订阅示例
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: cluster-logging namespace: openshift-logging 1 spec: channel: "4.2" 2 name: cluster-logging source: redhat-operators 3 sourceNamespace: openshift-marketplace
创建订阅对象：
$ oc create -f <file-name>.yaml
例如：
$ oc create -f clo-sub.yaml
Cluster Logging Operator 已安装到
openshift-logging命名空间。
验证 Operator 安装：
在
openshift-logging命名空间中应该有一个 Cluster Logging Operator。版本号可能与所示不同。oc get csv --all-namespaces NAMESPACE NAME DISPLAY VERSION REPLACES PHASE ... openshift-logging clusterlogging.4.2.1-202002032140 Cluster Logging 4.2.1-202002032140 Succeeded ...
创建集群日志记录（Cluster Logging）实例：
为 Cluster Logging Operator 创建实例对象 YAML 文件（如
clo-instance.yaml）：注意此默认集群日志记录配置应该可以支持不同的环境。请参考有关调优和配置集群日志记录组件的主题，以了解有关可对集群日志记录集群进行修改的信息。
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" 1 namespace: "openshift-logging" spec: managementState: "Managed" 2 logStore: type: "elasticsearch" 3 elasticsearch: nodeCount: 3 4 storage: storageClassName: gp2 5 size: 200G redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" 6 kibana: replicas: 1 curation: type: "curator" 7 curator: schedule: "30 3 * * *" collection: logs: type: "fluentd" 8 fluentd: {}
- 1
- 名称必须是
instance。 - 2
- 集群日志记录管理状态。在大多数情况下，如果更改了集群日志记录的默认值，则必须将其设置为
Unmanaged。但是，在 Cluster Logging 返回到Managed状态前，非受管部署不接收更新。如需更多信息，请参阅更改集群日志记录管理状态。 - 3
- 用于配置 Elasticsearch 的设置。通过使用子定义资源（CR），您可以配置分片复制策略和持久性存储。如需更多信息，请参阅配置 Elasticsearch。
- 4
- 指定 Elasticsearch 节点的数量。请参阅此列表后面的备注。
- 5
- 指定集群中的每个 Elasticsearch 节点都绑定到持久性卷声明。
- 6
- 用于配置 Kibana 的设置。通过使用 CR，您可以扩展 Kibana 来实现冗余性，并为 Kibana 节点配置 CPU 和内存。如需更多信息，请参阅配置 Kibana。
- 7
- 用于配置 Curator 的设置。通过使用 CR，您可以设置 Curator 调度。如需更多信息，请参阅配置 Curator。
- 8
- 用于配置 Fluentd 的设置。通过使用 CR，您可以配置 Fluentd CPU 和内存限值。如需更多信息，请参阅配置 Fluentd。
注意Elasticsearch master 节点的最大数量为三个。如果您将
nodeCount指定为大于3，OpenShift Container Platform 只会创建三个符合 Master 节点条件的 Elasticsearch 节点（具有 master、client 和 data 角色）。其余 Elasticsearch 节点创建为“仅数据”节点，使用 client 和 data 角色。Master 节点执行集群范围的操作，如创建或删除索引、分配分片和跟踪节点等。数据节点保管分片，并执行与数据相关的操作，如 CRUD、搜索和聚合等。与数据相关的操作会占用大量 I/O、内存和 CPU。务必要监控这些资源，并在当前节点过载时添加更多数据节点。例如，如果
nodeCount = 4，则创建以下节点：$ oc get deployment cluster-logging-operator 1/1 1 1 18h elasticsearch-cd-x6kdekli-1 1/1 1 0 6m54s elasticsearch-cdm-x6kdekli-1 1/1 1 1 18h elasticsearch-cdm-x6kdekli-2 1/1 1 0 6m49s elasticsearch-cdm-x6kdekli-3 1/1 1 0 6m44s
索引模板的主分片数量等于 Elasticsearch 数据节点的数目。
创建实例：
$ oc create -f <file-name>.yaml
例如：
$ oc create -f clo-instance.yaml
通过列出 openshift-logging 项目中的 Pod 来验证安装。
您应该会看到几个用于 Cluster Logging、Elasticsearch、Fluentd 和 Kibana 的 Pod，类似于以下内容：
oc get pods -n openshift-logging NAME READY STATUS RESTARTS AGE cluster-logging-operator-66f77ffccb-ppzbg 1/1 Running 0 7m elasticsearch-cdm-ftuhduuw-1-ffc4b9566-q6bhp 2/2 Running 0 2m40s elasticsearch-cdm-ftuhduuw-2-7b4994dbfc-rd2gc 2/2 Running 0 2m36s elasticsearch-cdm-ftuhduuw-3-84b5ff7ff8-gqnm2 2/2 Running 0 2m4s fluentd-587vb 1/1 Running 0 2m26s fluentd-7mpb9 1/1 Running 0 2m30s fluentd-flm6j 1/1 Running 0 2m33s fluentd-gn4rn 1/1 Running 0 2m26s fluentd-nlgb6 1/1 Running 0 2m30s fluentd-snpkt 1/1 Running 0 2m28s kibana-d6d5668c5-rppqm 2/2 Running 0 2m39s
3.4. 其他资源
如需有关安装 Operator 的更多信息，请参阅从 OperatorHub 安装 Operator。
第 4 章 升级集群日志记录
在将 OpenShift Container Platform 集群从 4.1 升级到 4.2 后，必须将集群日志记录从 4.1 升级到 4.2。
由于 默认的全局目录命名空间和 Catalog Source 发生变化，如果您根据 Elasticsearch 安装所述，从 YAML 文件手动创建 CatalogSourceConfig 和 Subscription 对象，您需要更新这些对象，以便在升级前指向新的目录命名空间和源，如下所示。
4.1. 更新集群日志记录
升级 OpenShift Container Platform 集群后，您可以通过更新 Elasticsearch Operator 和 Cluster Logging Operator 将集群日志记录从 4.1 升级到 4.2。
先决条件
- 将集群从 4.1 升级到 4.2。
确保集群日志记录健康：
-
所有 Pod 都为
Ready状态。 - Elasticsearch 集群处于健康状态。
-
所有 Pod 都为
流程
编辑 CatalogSourceConfig (CSC) 和 Subscription 对象，以指向新的 Namespace 和 Cource:
通过 CLI，获取 Elasticsearch CSC 的名称：
$ oc get csc --all-namespaces NAMESPACE NAME STATUS MESSAGE AGE openshift-marketplace certified-operators Succeeded The object has been successfully reconciled 42m openshift-marketplace community-operators Succeeded The object has been successfully reconciled 42m openshift-marketplace elasticsearch Succeeded The object has been successfully reconciled 27m openshift-marketplace installed-redhat-default Succeeded The object has been successfully reconciled 26m openshift-marketplace installed-redhat-openshift-logging Succeeded The object has been successfully reconciled 18m openshift-marketplace redhat-operators Succeeded The object has been successfully reconciled 42m
按如下方式编辑该文件：
$ oc edit csc elasticsearch -n openshift-marketplace apiVersion: operators.coreos.com/v1 kind: CatalogSourceConfig metadata: creationTimestamp: "2020-02-18T15:09:00Z" finalizers: - finalizer.catalogsourceconfigs.operators.coreos.com generation: 3 name: elasticsearch namespace: openshift-marketplace resourceVersion: "17694" selfLink: /apis/operators.coreos.com/v1/namespaces/openshift-marketplace/catalogsourceconfigs/elasticsearch uid: 97c0cd55-5260-11ea-873c-02939b2f528f spec: csDisplayName: Custom csPublisher: Custom packages: elasticsearch-operator targetNamespace: openshift-operators-redhat source: redhat-operators 1- 1
- 将当前值改为
redhat-operators。
获取 Elasticsearch Subscription 对象的名称：
$ oc get sub NAME PACKAGE SOURCE CHANNEL elasticsearch-pj7pf elasticsearch-operator elasticsearch preview
按如下方式编辑该文件：
$ oc edit sub elasticsearch-pj7pf apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: creationTimestamp: "2020-02-17T17:51:18Z" generateName: elasticsearch- generation: 2 name: elasticsearch-p5k7n namespace: openshift-operators-redhat resourceVersion: "38098" selfLink: /apis/operators.coreos.com/v1alpha1/namespaces/openshift-operators-redhat/subscriptions/elasticsearch-p5k7n uid: 19f6df33-51ae-11ea-82b9-027dfdb65ec2 spec: channel: "4.2" installPlanApproval: Automatic name: elasticsearch-operator source: redhat-operators 1 sourceNamespace: openshift-marketplace 2 ....
升级 Elasticsearch Operator：
- 在 Web 控制台中点击 Operator Management。
- 将项目更改为 all projects。
- 点与 Elasticsearch 订阅名称相同的 Elasticsearch Operator。
- 点 Subscription → Channel。
- 在 Change Subscription Update Channel 窗口中，选择 4.2 并点 Save。
等待几秒钟，然后点 Operators → Installed Operators。
Elasticsearch Operator 显示为 4.2 版本。例如：
Elasticsearch Operator 4.2.0-201909201915 provided by Red Hat, Inc
升级 Cluster Logging Operator：
- 在 Web 控制台中点击 Operator Management。
- 将项目更改为 all projects。
- 点 Cluster Logging Operator。
- 点 Subscription → Channel。
- 在 Change Subscription Update Channel 窗口中，选择 4.2 并点 Save。
等待几秒钟，然后点 Operators → Installed Operators。
Cluster Logging Operator 显示为 4.2 版本。例如：
Cluster Logging 4.2.0-201909201915 provided by Red Hat, Inc
检查日志记录组件：
确保 Elasticsearch Pod 使用的是 4.2 镜像：
$ oc get pod -o yaml -n openshift-logging --selector component=elasticsearch |grep 'image:' image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915
确保所有 Elasticsearch Pod 都处于 Ready 状态：
$ oc get pod -n openshift-logging --selector component=elasticsearch NAME READY STATUS RESTARTS AGE elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk 2/2 Running 0 31m elasticsearch-cdm-1pbrl44l-2-5c6d87589f-gx5hk 2/2 Running 0 30m elasticsearch-cdm-1pbrl44l-3-88df5d47-m45jc 2/2 Running 0 29m
确保 Elasticsearch 集群健康：
oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk -- es_cluster_health { "cluster_name" : "elasticsearch", "status" : "green", ....确保日志记录收集器 Pod 使用的是 4.2 镜像：
$ oc get pod -n openshift-logging --selector logging-infra=fluentd -o yaml |grep 'image:' image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915
确保 Kibana Pod 使用的是 4.2 镜像：
$ oc get pod -n openshift-logging --selector logging-infra=kibana -o yaml |grep 'image:' image: registry.redhat.io/openshift4/ose-logging-kibana5:v4.2.0-201909210748 image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915 image: registry.redhat.io/openshift4/ose-logging-kibana5:v4.2.0-201909210748 image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915
确保 Curator CronJob 使用的是 4.2 镜像：
$ $ oc get CronJob curator -n openshift-logging -o yaml |grep 'image:' image: registry.redhat.io/openshift4/ose-logging-curator5:v4.2.0-201909201915
第 5 章 使用事件路由器
事件路由器（Event Router）与 OpenShift Container Platform 通信，并将 OpenShift Container Platform 事件输出到发生事件的 Pod 的日志中。
如果部署了集群日志记录，您可以在 Kibana 中查看 OpenShift Container Platform 事件。
5.1. 部署和配置事件路由器
使用以下步骤将事件路由器部署到集群中。
以下 Template 对象创建事件路由器所需的服务帐户、ClusterRole 和 ClusterRoleBinding。
先决条件
- 需要适当的权限，以便能创建服务帐户和更新集群角色绑定。例如，您可以使用具有 cluster-admin 角色的用户来运行以下模板。
设置
TRANSFORM_EVENTS=true，以便在 Elasticsearch 中处理和存储事件路由器事件。- 将集群日志记录设置为非受管状态。
启用
TRANSFORM_EVENTS功能。$ oc set env ds/fluentd TRANSFORM_EVENTS=true
流程
为事件路由器创建模板：
kind: Template apiVersion: v1 metadata: name: eventrouter-template annotations: description: "A pod forwarding kubernetes events to cluster logging stack." tags: "events,EFK,logging,cluster-logging" objects: - kind: ServiceAccount 1 apiVersion: v1 metadata: name: eventrouter namespace: ${NAMESPACE} - kind: ClusterRole 2 apiVersion: v1 metadata: name: event-reader rules: 3 - apiGroups: [""] resources: ["events"] verbs: ["get", "watch", "list"] - kind: ClusterRoleBinding 4 apiVersion: v1 metadata: name: event-reader-binding subjects: - kind: ServiceAccount name: eventrouter namespace: ${NAMESPACE} roleRef: kind: ClusterRole name: event-reader - kind: ConfigMap apiVersion: v1 metadata: name: eventrouter namespace: ${NAMESPACE} data: config.json: |- { "sink": "stdout" } - kind: Deployment apiVersion: apps/v1 metadata: name: eventrouter namespace: ${NAMESPACE} labels: component: eventrouter logging-infra: eventrouter provider: openshift spec: selector: matchLabels: component: eventrouter logging-infra: eventrouter provider: openshift replicas: 1 template: metadata: labels: component: eventrouter logging-infra: eventrouter provider: openshift name: eventrouter spec: serviceAccount: eventrouter containers: - name: kube-eventrouter image: ${IMAGE} imagePullPolicy: IfNotPresent resources: limits: memory: ${MEMORY} requests: cpu: ${CPU} memory: ${MEMORY} volumeMounts: - name: config-volume mountPath: /etc/eventrouter volumes: - name: config-volume configMap: name: eventrouter parameters: - name: IMAGE 5 displayName: Image value: "registry.redhat.io/openshift4/ose-logging-eventrouter:latest" - name: MEMORY 6 displayName: Memory value: "128Mi" - name: CPU 7 displayName: CPU value: "100m" - name: NAMESPACE 8 displayName: Namespace value: "openshift-logging"- 1
- 为事件路由器创建服务帐户。
- 2
- 创建用于监控集群中事件的集群角色。
- 3
- 授予
events资源get、watch和list权限。 - 4
- 创建一个 ClusterRoleBinding 将 ClusterRole 绑定到 ServiceAccount。
- 5
- 为事件路由器指定镜像版本。
- 6
- 为事件路由器 Pod 指定内存限值。默认值为“128Mi”。
- 7
- 指定分配给事件路由器的最小 CPU 数量。默认值为“100m”。
- 8
- 指定要部署事件路由器的命名空间。默认值为
openshift-logging。该值必须与为 ServiceAccount 和 ClusterRoleBinding 指定的值相同。该项目指示您可以在 Kibana 中查找事件的位置：-
如果事件路由器 Pod 部署到默认项目中，如
kube-*和openshift-*，您可以在 .operation 索引下查找事件。 - 如果事件路由器 Pod 部署到其他项目中，您可以在使用项目命名空间的索引下查找事件。
-
如果事件路由器 Pod 部署到默认项目中，如
使用以下命令来处理和应用模板：
$ oc process -f <templatefile> | oc apply -f -
例如：
$ oc process -f eventrouter.yaml | oc apply -f - serviceaccount/logging-eventrouter created clusterrole.authorization.openshift.io/event-reader created clusterrolebinding.authorization.openshift.io/event-reader-binding created configmap/logging-eventrouter created deployment.apps/logging-eventrouter created
验证是否安装了事件路由器：
$ oc get pods --selector component=eventrouter -o name pod/logging-eventrouter-d649f97c8-qvv8r
$ oc logs logging-eventrouter-d649f97c8-qvv8r {"verb":"ADDED","event":{"metadata":{"name":"elasticsearch-operator.v0.0.1.158f402e25397146","namespace":"openshift-operators","selfLink":"/api/v1/namespaces/openshift-operators/events/elasticsearch-operator.v0.0.1.158f402e25397146","uid":"37b7ff11-4f1a-11e9-a7ad-0271b2ca69f0","resourceVersion":"523264","creationTimestamp":"2019-03-25T16:22:43Z"},"involvedObject":{"kind":"ClusterServiceVersion","namespace":"openshift-operators","name":"elasticsearch-operator.v0.0.1","uid":"27b2ca6d-4f1a-11e9-8fba-0ea949ad61f6","apiVersion":"operators.coreos.com/v1alpha1","resourceVersion":"523096"},"reason":"InstallSucceeded","message":"waiting for install components to report healthy","source":{"component":"operator-lifecycle-manager"},"firstTimestamp":"2019-03-25T16:22:43Z","lastTimestamp":"2019-03-25T16:22:43Z","count":1,"type":"Normal"}}
第 6 章 查看集群日志
您可以使用 CLI 或通过 OpenShift Container Platform web 控制台查看 OpenShift Container Platform 集群的日志。
6.1. 查看集群日志
您可以在 CLI 中查看集群日志。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
查看集群日志：
确定日志位置是文件还是
CONSOLE(stdout)。$ oc -n openshift-logging set env daemonset/fluentd --list | grep LOGGING_FILE_PATH
根据日志位置来执行日志记录命令：
如果
LOGGING_FILE_PATH指向某一文件（默认设置），请从 Pod 所在的项目中使用 logs 程序来打印 Fluentd 日志文件的内容：$ oc exec <any-fluentd-pod> -- logs 1- 1
- 指定日志收集器 Pod 的名称。注意
logs前面的空格。
例如：
$ oc exec fluentd-ht42r -n openshift-logging -- logs
如果使用的是
LOGGING_FILE_PATH=console，日志收集器会将日志记录写入到 stdout/stderr`。您可以使用oc logs [-f] <pod_name>命令来检索日志，其中-f可选。$ oc logs -f <any-fluentd-pod> -n openshift-logging 1- 1
- 指定日志收集器 Pod 的名称。使用
-f选项可以跟踪正在写进日志中的内容。
例如：
$ oc logs -f fluentd-ht42r -n openshift-logging
输出的日志文件内容。
默认情况下，Fluentd 从日志的末尾开始读取日志。
6.2. 在 OpenShift Container Platform Web 控制台中查看集群日志
您可以在 OpenShift Container Platform Web 控制台中查看集群日志。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
查看集群日志：
- 在 OpenShift Container Platform 控制台中，进入 Workloads → Pods。
-
从下拉菜单中选择
openshift-logging项目。 -
点带有
fluentd前缀的某一个日志记录收集器 Pod。 - 点击 Logs。
默认情况下，Fluentd 从日志的末尾开始读取日志。
第 7 章 使用 Kibana 查看集群日志
在安装集群日志记录时会部署 Kibana web 控制台。
7.1. 启动 Kibana
Kibana 是基于浏览器的控制台界面，可通过直方图、折线图、饼图、热图、内置地理空间支持和其他视觉化方式，来查询、探索和视觉化您的日志数据。
流程
启动 Kibana：
- 在 OpenShift Container Platform 控制台中点 Monitoring → Logging。
使用用来登录到 OpenShift Container Platform 控制台的相同凭证进行登录。
Kibana 界面将出现。您现在可以：
- 使用 Discover 页面搜索并浏览您的数据。
- 使用 Visualize 页面对数据进行图表显示。
使用 Dashboard 页面创建并查看自定义仪表板。
使用并配置 Kibana 界面的内容超出了本文档的范围。相关信息，请参阅 Kibana 文档。
第 8 章 配置集群日志记录部署
8.1. 关于配置集群日志记录
将集群日志记录安装到 OpenShift Container Platform 集群中后，您可以进行以下配置。
除非另有说明，否则在执行这些配置之前，必须将集群日志记录设置为非受管状态。如需更多信息，请参阅更改集群日志记录管理状态。
处于非受管状态的 Operator 不被正式支持，集群管理员需要完全掌控各个组件的配置和升级。如需了解更多信息，请参阅非受管 Operator 的支持策略
8.1.1. 关于部署和配置集群日志记录
OpenShift Container Platform 集群日志记录已设计为可搭配默认配置使用，该配置针对中小型 OpenShift Container Platform 集群进行了调优。
以下安装说明包括一个示例集群日志记录自定义资源 (CR)，您可以用它来创建集群日志记录实例并配置集群日志记录部署。
如果要使用默认集群日志记录安装，可直接使用示例 CR。
如果要自定义部署，请根据需要对示例 CR 进行更改。下文介绍了在安装集群日志记录实例或安装后修改时可以进行的配置。请参阅“配置”部分来了解有关使用各个组件的更多信息，包括可以在集群日志记录自定义资源之外进行的修改。
8.1.1.1. 配置和调优集群日志记录
您可以通过修改 openshift-logging 项目中部署的集群日志记录自定义资源来配置集群日志记录环境。
您可以在安装时或安装后修改以下任何组件：
- 内存和 CPU
-
您可以使用有效的内存和 CPU 值修改
resources块，以此调整各个组件的 CPU 和内存限值：
spec:
logStore:
elasticsearch:
resources:
limits:
cpu:
memory:
requests:
cpu: 1
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
curation:
curator:
resources:
limits:
memory: 200Mi
requests:
cpu: 200m
memory: 200Mi
type: "curator"- Elasticsearch 存储
-
您可以使用
storageClassname和size参数，为 Elasticsearch 集群配置持久性存储类和大小。Cluster Logging Operator 基于这些参数为 Elasticsearch 集群中的每个数据节点创建PersistentVolumeClaim。
spec:
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 3
storage:
storageClassName: "gp2"
size: "200G"
本例中指定，集群中的每个数据节点将绑定到请求 200G 的 gp2 存储的 PersistentVolumeClaim。每个主分片将由单个副本支持。
省略 storage 块会导致部署中仅包含临时存储。
spec:
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 3
storage: {}- Elasticsearch 复制策略
您可以通过设置策略来定义如何在集群中的数据节点之间复制 Elasticsearch 分片：
-
FullRedundancy。各个索引的分片完整复制到每个数据节点上。 -
MultipleRedundancy。各个索引的分片分布到一半数据节点上。 -
SingleRedundancy。各个分片具有单个副本。只要存在至少两个数据节点，日志就能始终可用且可恢复。 -
ZeroRedundancy。所有分片均无副本。如果节点关闭或发生故障， 则可能无法获得日志数据。
-
- Curator 调度
- 以 cron 格式指定 Curator 的调度。
spec:
curation:
type: "curator"
resources:
curator:
schedule: "30 3 * * *"8.1.1.2. 修改后集群日志记录自定义资源示例
以下是使用前述选项修改的集群日志记录自定义资源的示例。
修改后集群日志记录自定义资源示例
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
name: "instance"
namespace: "openshift-logging"
spec:
managementState: "Managed"
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 2
resources:
limits:
memory: 2Gi
requests:
cpu: 200m
memory: 2Gi
storage: {}
redundancyPolicy: "SingleRedundancy"
visualization:
type: "kibana"
kibana:
resources:
limits:
memory: 1Gi
requests:
cpu: 500m
memory: 1Gi
replicas: 1
curation:
type: "curator"
curator:
resources:
limits:
memory: 200Mi
requests:
cpu: 200m
memory: 200Mi
schedule: "*/5 * * * *"
collection:
logs:
type: "fluentd"
fluentd:
resources:
limits:
memory: 1Gi
requests:
cpu: 200m
memory: 1Gi
8.2. 更改集群日志记录管理状态
若要修改由 Cluster Logging Operator 或 Elasticsearch Operator 管理的特定组件，您必须将 Operator 设置为非受管状态。
在非受管状态下，Operator 不响应 CR 中的变化。处于非托管状态时，管理员完全掌控各个组件的配置和升级。
处于非受管状态的 Operator 不被正式支持，集群管理员需要完全掌控各个组件的配置和升级。如需了解更多信息，请参阅非受管 Operator 的支持策略
在受管状态下，Cluster Logging Operator (CLO) 会对集群日志记录自定义资源 (CR) 中的更改进行相应，并对日志部署进行相应的调整。
OpenShift Container Platform 文档在预备步骤中指明何时您必须将 OpenShift Container Platform 集群设置为“非受管（Unmanaged）”状态。
如果将 Elasticsearch Operator (EO) 设置为非受管状态，并将 Cluster Logging Operator (CLO) 保留为受管状态，则 CLO 会还原您对 EO 进行的更改，因为 EO 由 CLO 进行管理。
8.2.1. 更改集群日志记录管理状态
您必须将 Cluster Logging Operator 设置为非受管状态，才能修改由此 Operator 管理的组件：
- Curator CronJob；
- Elasticsearch CR；
- Kibana Deployment；
- 日志收集器 DaemonSet。
如果您在受管状态下对这些组件进行更改，则 Cluster Logging Operator 将还原这些更改。
在 Cluster Logging Operator 返回到受管状态之前，非受管集群日志记录环境不会接收更新。
先决条件
- 必须安装 Cluster Logging Operator。
流程
在
openshift-logging项目中编辑集群日志记录自定义资源 (CR)：$ oc edit ClusterLogging instance
$ oc edit ClusterLogging instance apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" .... spec: managementState: "Managed" 1- 1
- 将管理状态指定为
Managed或Unmanaged。
8.2.2. 更改 Elasticsearch 管理状态
您必须将 Elasticsearch Operator 设置为非受管状态，才能修改由此 Operator 管理的 Elasticsearch 部署文件：
如果您在受管状态下对这些组件进行更改，则 Elasticsearch Operator 将还原这些更改。
在 Elasticsearch Operator 返回到受管状态之前，非受管 Elasticsearch 集群不会接收更新。
先决条件
- 必须安装 Elasticsearch Operator。
具有
openshift-logging项目中 Elasticsearch CR 的名称：$ oc get -n openshift-logging Elasticsearch NAME AGE elasticsearch 28h
流程
编辑 openshift-logging 项目中的 Elasticsearch 自定义资源 (CR)：
$ oc edit Elasticsearch elasticsearch
apiVersion: logging.openshift.io/v1
kind: Elasticsearch
metadata:
name: elasticsearch
....
spec:
managementState: "Managed" 1- 1
- 将管理状态指定为
Managed或Unmanaged。
如果将 Elasticsearch Operator (EO) 设置为非受管状态，并将 Cluster Logging Operator (CLO) 保留为受管状态，则 CLO 会还原您对 EO 进行的更改，因为 EO 由 CLO 进行管理。
8.3. 配置集群日志记录
可以使用部署在 openshift-logging 项目中的集群日志记录自定义资源 (CR) 来配置集群日志记录。
Cluster Logging Operator 会监控集群日志记录 CR 的更改，创建任何缺少的日志记录组件，并相应地调整日志记录部署。
集群日志记录 CR 基于集群日志记录自定义资源定义 (CRD)，后者定义完整的集群日志记录部署，包括日志记录堆栈中用于收集、存储和视觉化日志的所有组件。
集群日志记录自定义资源 (CR) 示例
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
creationTimestamp: '2019-03-20T18:07:02Z'
generation: 1
name: instance
namespace: openshift-logging
spec:
collection:
logs:
fluentd:
resources: null
type: fluentd
curation:
curator:
resources: null
schedule: 30 3 * * *
type: curator
logStore:
elasticsearch:
nodeCount: 3
redundancyPolicy: SingleRedundancy
resources:
limits:
cpu:
memory:
requests:
cpu:
memory:
storage: {}
type: elasticsearch
managementState: Managed
visualization:
kibana:
proxy:
resources: null
replicas: 1
resources: null
type: kibana
您可以对集群日志记录进行以下配置：
- 可以将集群日志记录置于非受管状态，使管理员能够完全掌控各个组件的配置和升级。
-
可以通过在
cluster-logging-operator部署中修改适当的环境变量，覆盖每个集群日志记录组件的镜像。 - 可以使用节点选择器为日志记录组件指定特定的节点。
8.3.1. 了解集群日志记录组件镜像
集群日志记录中有多个组件，各自通过一个或多个镜像实施。每个镜像都由 openshift-logging 项目的 cluster-logging-operator 部署中定义的环境变量指定的，并且不应更改。
您可以通过运行以下命令来查看镜像：
$ oc -n openshift-logging set env deployment/cluster-logging-operator --list | grep _IMAGE
ELASTICSEARCH_IMAGE=registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.2 1 FLUENTD_IMAGE=registry.redhat.io/openshift4/ose-logging-fluentd:v4.2 2 KIBANA_IMAGE=registry.redhat.io/openshift4/ose-logging-kibana5:v4.2 3 CURATOR_IMAGE=registry.redhat.io/openshift4/ose-logging-curator5:v4.2 4 OAUTH_PROXY_IMAGE=registry.redhat.io/openshift4/ose-oauth-proxy:v4.2 5
这些值可能视您的环境而异。
日志记录路由由 Cluster Logging Operator 管理，用户无法修改它。
8.4. 配置 Elasticsearch 以存储和整理日志数据
OpenShift Container Platform 使用 Elasticsearch (ES) 来存储和整理日志数据。
您可以对 Elasticsearch 部署进行的一些修改包括：
- Elasticsearch 集群存储；
- 如何在集群中的数据节点之间复制分片，包括从完整复制到不复制；
- 允许外部对 Elasticsearch 数据进行访问。
不支持缩减 Elasticsearch 节点。缩减规模时，Elasticsearch Pod 可能会被意外删除，这可能导致未分配分片，并且丢失副本分片。
Elasticsearch 是内存密集型应用程序。每个 Elasticsearch 节点需要 16G 内存来满足内存请求（requests）和限值（limits）的需要，除非集群日志记录自定义资源中另有指定。最初的 OpenShift Container Platform 节点组可能不足以支持 Elasticsearch 集群。您必须在 OpenShift Container Platform 集群中添加额外的节点，才能使用建议或更高的内存来运行。
每个 Elasticsearch 节点都可以在较低的内存设置下运行，但在生产部署中不建议这样做。
如果将 Elasticsearch Operator (EO) 设置为非受管状态，并将 Cluster Logging Operator (CLO) 保留为受管状态，则 CLO 会还原您对 EO 进行的更改，因为 EO 由 CLO 进行管理。
8.4.1. 配置 Elasticsearch CPU 和内存限值
每个组件规格都允许调整 CPU 和内存限值。您应该无需手动调整这些值，因为 Elasticsearch Operator 会设置适当的值以满足环境的要求。
每个 Elasticsearch 节点都可以在较低的内存设置下运行，但在生产部署中不建议这样做。对于生产环境，为每个 Pod 应该分配的数量应不少于默认的 16Gi。最好为每个 Pod 分配不超过 64Gi 的尽量多的数量。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
在
openshift-logging项目中编辑集群日志记录自定义资源 (CR)：$ oc edit ClusterLogging instance
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" .... spec: logStore: type: "elasticsearch" elasticsearch: resources: 1 limits: memory: "16Gi" requests: cpu: "1" memory: "16Gi"- 1
- 根据需要指定 CPU 和内存限值。如果这些值留白，则 Elasticsearch Operator 会设置默认值，它们应足以满足大多数部署的需要。
如果调整了 Elasticsearch CPU 和内存的数量，您必须同时更改请求值和限制值。
例如：
resources: limits: cpu: "8" memory: "32Gi" requests: cpu: "8" memory: "32Gi"Kubernetes 一般遵循节点 CPU 配置，DOES 不允许 Elasticsearch 使用指定的限制。为
requests和limits设置相同的值可以确保 Elasticseach 可以使用您需要它们使用的 CPU 和内存数量（假定节点有足够可用 CPU 和内存）。
8.4.2. 配置 Elasticsearch 复制策略
您可以定义如何在集群中的数据节点之间复制 Elasticsearch 分片：
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
在
openshift-logging项目中编辑集群日志记录自定义资源 (CR)：oc edit clusterlogging instance
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" .... spec: logStore: type: "elasticsearch" elasticsearch: redundancyPolicy: "SingleRedundancy" 1- 1
- 为分片指定冗余策略。更改会在保存后应用。
- FullRedundancy：Elasticsearch 将每个索引的主分片完整复制到每个数据节点。这可提供最高的安全性，但代价是需要最大数量的磁盘并且性能最差。
- MultipleRedundancy：Elasticsearch 将每个索引的主分片完整复制到一半的数据节点。这可在安全性和性能之间提供很好的折衷。
- SingleRedundancy：Elasticsearch 为每个索引的主分片制作一个副本。只要存在至少两个数据节点，日志就能始终可用且可恢复。使用 5 个或更多节点时，性能胜过 MultipleRedundancy。您不能将此策略应用于单个 Elasticsearch 节点的部署。
- ZeroRedundancy：Elasticsearch 不制作主分片的副本。如果节点关闭或发生故障， 则可能无法获得日志数据。如果您更关注性能而非安全性，或者实施了自己的磁盘/PVC 备份/恢复策略，可以考虑使用此模式。
索引模板的主分片数量等于 Elasticsearch 数据节点的数目。
8.4.3. 配置 Elasticsearch 存储
Elasticsearch 需要持久性存储。存储速度越快，Elasticsearch 性能越高。
在 Elasticsearch 存储中不支持将 NFS 存储用作卷或持久性卷（或者通过 NAS 比如 Gluster），因为 Lucene 依赖于 NFS 不提供的文件系统行为。数据崩溃和其他问题可能会发生。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
编辑集群日志记录 CR，将集群中的每个数据节点指定为绑定到 PVC。
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" .... spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: storageClassName: "gp2" size: "200G"
本例中指定，集群中的每个数据节点都绑定到请求“200G”的 AWS 通用 SSD (gp2) 存储的 PVC。
8.4.4. 为 Elasticsearch 配置 emptyDir 存储
您可以将 emptyDir 与 Elasticsearch 搭配使用来创建一个临时部署，临时部署一旦重启其中所有 Pod 的数据都会丢失。
使用 emptyDir 时，如果重启或重新部署 Elasticsearch，数据将会丢失。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
编辑集群日志记录 CR 以指定 emptyDir：
spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: {}
8.4.5. 将 Elasticsearch 公开为路由
默认情况下，无法从日志记录集群外部访问部署了集群日志记录的 Elasticsearch。您可以启用一个 re-encryption termination 模式的路由，以实现外部对 Elasticsearch 的访问来获取数据。
另外，还可以在外部创建一个重新加密路由，使用 OpenShift Container Platform 令牌和已安装的 Elasticsearch CA 证书以从外部访问 Elasticsearch。然后，使用包含以下信息的 cURL 请求来访问 Elasticsearch 节点：
-
Authorization: Bearer ${token} - Elasticsearch 重新加密路由和 Elasticsearch API 请求。
在内部，您可以使用 Elasticsearch 集群 IP 访问 Elastiscearch：
您可以使用以下命令之一获取 Elasticsearch 集群 IP：
$ oc get service elasticsearch -o jsonpath={.spec.clusterIP} -n openshift-logging
172.30.183.229oc get service elasticsearch
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
elasticsearch ClusterIP 172.30.183.229 <none> 9200/TCP 22h
$ oc exec elasticsearch-cdm-oplnhinv-1-5746475887-fj2f8 -- curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://172.30.183.229:9200/_cat/health"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 29 100 29 0 0 108 0 --:--:-- --:--:-- --:--:-- 108先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
- 您必须具有项目的访问权限，以便能访问其日志。
流程
对外部公开 Elasticsearch：
进入
openshift-logging项目：$ oc project openshift-logging
从 Elasticsearch 提取 CA 证书并写入 admin-ca 文件：
$ oc extract secret/elasticsearch --to=. --keys=admin-ca admin-ca
以 YAML 文件形式创建 Elasticsearch 服务的路由：
使用以下内容创建一个 YAML文件：
apiVersion: route.openshift.io/v1 kind: Route metadata: name: elasticsearch namespace: openshift-logging spec: host: to: kind: Service name: elasticsearch tls: termination: reencrypt destinationCACertificate: | 1- 1
- 添加 Elasticsearch CA 证书或使用下一步中的命令。您不必设置一些重新加密路由所需的
spec.tls.key、spec.tls.certificate和spec.tls.caCertificate参数。
运行以下命令将 Elasticsearch CA 证书添加到您创建的路由 YAML 中：
cat ./admin-ca | sed -e "s/^/ /" >> <file-name>.yaml
创建路由：
$ oc create -f <file-name>.yaml route.route.openshift.io/elasticsearch created
检查是否公开了 Elasticsearch 服务：
获取此 ServiceAccount 的令牌，以便在请求中使用：
$ token=$(oc whoami -t)
将您创建的 Elasticsearch 路由设置为环境变量。
$ routeES=`oc get route elasticsearch -o jsonpath={.spec.host}`要验证路由是否创建成功，请运行以下命令来通过公开的路由访问 Elasticsearch：
curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://${routeES}/.operations.*/_search?size=1" | jq其响应类似于如下：
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 944 100 944 0 0 62 0 0:00:15 0:00:15 --:--:-- 204 { "took": 441, "timed_out": false, "_shards": { "total": 3, "successful": 3, "skipped": 0, "failed": 0 }, "hits": { "total": 89157, "max_score": 1, "hits": [ { "_index": ".operations.2019.03.15", "_type": "com.example.viaq.common", "_id": "ODdiNWIyYzAtMjg5Ni0TAtNWE3MDY1MjMzNTc3", "_score": 1, "_source": { "_SOURCE_MONOTONIC_TIMESTAMP": "673396", "systemd": { "t": { "BOOT_ID": "246c34ee9cdeecb41a608e94", "MACHINE_ID": "e904a0bb5efd3e36badee0c", "TRANSPORT": "kernel" }, "u": { "SYSLOG_FACILITY": "0", "SYSLOG_IDENTIFIER": "kernel" } }, "level": "info", "message": "acpiphp: Slot [30] registered", "hostname": "localhost.localdomain", "pipeline_metadata": { "collector": { "ipaddr4": "10.128.2.12", "ipaddr6": "fe80::xx:xxxx:fe4c:5b09", "inputname": "fluent-plugin-systemd", "name": "fluentd", "received_at": "2019-03-15T20:25:06.273017+00:00", "version": "1.3.2 1.6.0" } }, "@timestamp": "2019-03-15T20:00:13.808226+00:00", "viaq_msg_id": "ODdiNWIyYzAtMYTAtNWE3MDY1MjMzNTc3" } } ] } }
8.4.6. 关于 Elasticsearch 警报规则
您可以在 Prometheus 中查看这些警报规则。
| 警报 | 描述 | 重要性 |
|---|---|---|
| ElasticsearchClusterNotHealthy | 集群健康状态为 RED 至少有 2 分钟。集群不接受写操作，分片可能缺失或者 master 节点尚未选定。 | critical |
| ElasticsearchClusterNotHealthy | 集群健康状态为 YELLOW 至少有 20 分钟。某些分片副本尚未分配。 | warning |
| ElasticsearchBulkRequestsRejectionJumps | 集群中节点的批量拒绝率高。此节点可能无法跟上索引速度。 | warning |
| ElasticsearchNodeDiskWatermarkReached | 集群中节点已达到磁盘低水位线。分片无法再分配给此节点。应该考虑向节点添加更多磁盘空间。 | alert |
| ElasticsearchNodeDiskWatermarkReached | 集群中节点已达到磁盘高水位线。若有可能，某些分片将重新分配到其他节点。确保向节点添加更多磁盘空间，或者丢弃分配给此节点的旧索引。 | high |
| ElasticsearchJVMHeapUseHigh | 集群中节点上的 JVM 堆使用量为 <value> | alert |
| AggregatedLoggingSystemCPUHigh | 集群中节点上的系统 CPU 使用率是 <value> | alert |
| ElasticsearchProcessCPUHigh | 集群中节点上的 ES 进程 CPU 使用率是 <value> | alert |
8.5. 配置 Kibana
OpenShift Container Platform 使用 Kibana 显示由 Fluentd 收集并由 Elasticsearch 索引的日志数据。
您可以扩展 Kibana 来实现冗余性，并为 Kibana 节点配置 CPU 和内存。
除非另有说明，否则在执行这些配置之前，必须将集群日志记录设置为非受管状态。如需更多信息，请参阅更改集群日志记录管理状态。
处于非受管状态的 Operator 不被正式支持，集群管理员需要完全掌控各个组件的配置和升级。如需了解更多信息，请参阅非受管 Operator 的支持策略
8.5.1. 配置 Kibana CPU 和 内存限值
每个组件规格都允许调整 CPU 和内存限值。
流程
在
openshift-logging项目中编辑集群日志记录自定义资源 (CR)：$ oc edit ClusterLogging instance
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" .... spec: visualization: type: "kibana" kibana: replicas: resources: 1 limits: memory: 1Gi requests: cpu: 500m memory: 1Gi proxy: 2 resources: limits: memory: 100Mi requests: cpu: 100m memory: 100Mi
8.5.2. 扩展 Kibana 以实现冗余
您可以扩展 Kibana 部署以实现冗余。
流程
在
openshift-logging项目中编辑集群日志记录自定义资源 (CR)：$ oc edit ClusterLogging instance
$ oc edit ClusterLogging instance apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" .... spec: visualization: type: "kibana" kibana: replicas: 1 1- 1
- 指定 Kibana 节点的数量。
8.5.3. 使用容忍度（toleration）来控制 Kibana Pod 放置
您可以通过在 Pod 上使用容限（toleration）来控制 Kibana Pod 在哪些节点上运行，并防止其他工作负载使用这些节点。
您可以通过集群日志记录自定义资源 (CR) 将容限应用到 Kibana Pod，并通过节点规格将污点（taint）应用到节点。节点上的污点是一个 key:value 对，它指示节点排斥所有不容许该污点的 Pod。通过使用没有在其他 Pod 上使用的特定 key:value 对，可以确保仅 Kibana Pod 能够在该节点上运行。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
使用以下命令，将污点添加到要在其上调度 Kibana Pod 的节点：
$ oc adm taint nodes <node-name> <key>=<value>:<effect>
例如：
$ oc adm taint nodes node1 kibana=node:NoExecute
本例在
node1上放置一个键为kibana且值为node的污点，污点效果是NoExecute。您必须使用NoExecute污点设置。NoExecute仅调度与污点匹配的 Pod，并删除不匹配的现有 Pod。编辑集群日志记录自定义资源 (CR) 的
visualization部分，以配置 Kibana Pod 的容忍度：visualization: type: "kibana" kibana: tolerations: - key: "kibana" 1 operator: "Exists" 2 effect: "NoExecute" 3 tolerationSeconds: 6000 4
此容忍度与 oc adm taint 命令创建的污点匹配。具有此容限的 Pod 能够调度到 node1 上。
8.5.4. 安装 Kibana Visualize 工具
借助 Kibana 的 Visualize 选项卡，您可以创建用于监控容器日志的视觉化和仪表板，让管理员用户（cluster-admin 或 cluster-reader）能够按照部署、命名空间、Pod 和容器来查看日志。
流程
加载仪表板和其他 Kibana UI 对象：
若有必要，可获取安装 Cluster Logging Operator 时默认创建的 Kibana 路由：
$ oc get routes -n openshift-logging NAMESPACE NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD openshift-logging kibana kibana-openshift-logging.apps.openshift.com kibana <all> reencrypt/Redirect None
获取 Elasticsearch Pod 的名称。
$ oc get pods -l component=elasticsearch NAME READY STATUS RESTARTS AGE elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6k 2/2 Running 0 22h elasticsearch-cdm-5ceex6ts-2-f799564cb-l9mj7 2/2 Running 0 22h elasticsearch-cdm-5ceex6ts-3-585968dc68-k7kjr 2/2 Running 0 22h
创建此过程需要的用户级配置：
以您想要添加仪表板的用户身份登录到 Kibana 仪表板。
https://kibana-openshift-logging.apps.openshift.com 1- 1
- Kibana 路由所在的 URL。
- 如果显示 Authorize Access 页面，请选择所有权限，再点 Allow selected permissions。
- 退出 Kibana 仪表板。
使用任何 Elastiscearch Pod 的名称，从 Pod 所在的项目运行以下命令：
$ oc exec <es-pod> -- es_load_kibana_ui_objects <user-name>
例如：
$ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6k -- es_load_kibana_ui_objects <user-name>
Kibana 对象（如视觉化、仪表板等）的元数据以 .kibana.{user_hash} 索引格式保存在 Elasticsearch 中。您可以使用 userhash=$(echo -n $username | sha1sum | awk '{print $1}') 命令获取 user_hash。默认情况下，Kibana shared_ops 索引模式允许具有集群管理员角色的所有用户共享索引，并将这个 Kibana 对象元数据保存到 .kibana 索引中。
任何自定义仪表板都可以通过使用导入/导出功能，或通过使用 curl 命令将元数据插入 Elasticsearch 索引来为特定用户导入。
8.6. Elasticsearch 数据策展
Elasticsearch Curator 工具在全局范围和/或以项目为基础执行调度的维护操作。Curator 根据其配置执行操作。
Cluster Logging Operator 将安装 Curator 及其配置。您可以使用集群日志记录自定义资源配置 Curator cron 计划，其他配置选项则可在 openshift-logging 项目中的 Curator ConfigMap curator（融合了 Curator 配置文件 curator5.yaml 以及 OpenShift Container Platform 自定义配置文件 config.yaml）中找到。
OpenShift Container Platform 在内部使用 config.yaml 来生成 Curator action 文件。
（可选）您可以直接使用此 action 文件。通过编辑此文件，您可以使用 Curator 提供的可定期运行的任何操作。但是，仅建议高级用户使用此功能，因为修改文件可能会对集群造成破坏，并可能导致从 Elasticsearch 中删除必要的索引/设置。大多数用户仅需修改 Curator 配置映射，无需编辑 action 文件。
8.6.1. 配置 Curator 计划
您可以使用由集群日志记录安装创建的集群日志记录自定义资源来指定 Curator 的调度。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
配置 Curator 调度：
8.6.2. 配置 Curator 索引删除
您可以配置 Curator，以根据保留设置删除 Elasticsearch 数据。您可以配置在特定项目范围内的设置，也可以配置全局范围的设置。全局设置应用到任何未指定的项目。特定项目范围内的设置会覆盖全局设置。
先决条件
- 必须安装集群日志记录。
流程
删除索引：
编辑 OpenShift Container Platform 自定义 Curator 配置文件：
$ oc edit configmap/curator
根据需要设置以下参数：
config.yaml: | project_name: action unit:value可用的参数如下：
表 8.1. 项目选项
变量名称 描述 project_name项目的实际名称，例如 myapp-devel。对于 OpenShift Container Platform operations 日志，请使用
.operations作为项目名称。action当前只支持
delete。unit用于删除的期限，可以是
days、weeks或months。value单位数。
表 8.2. 过滤选项
变量名称 描述 .defaults使用
.defaults作为project_name，可为尚未指定的项目设置默认值。.regex与项目名称匹配的正则表达式列表。
pattern有效且正确转义的正则表达式，用单引号括起。
例如，要将 Curator 配置为：
-
删除 myapp-dev 项目中存在时间超过
1 天的索引 -
删除 myapp-qe 项目中存在时间超过
1 个星期的索引 -
删除存在时间超过
8 个星期的operations日志 -
删除所有其他项目中存在时间超过
31 天的索引 -
删除与
^project\..+\-dev.*$正则表达式匹配且存在时间超过 1 天的索引 -
删除与
^project\..+\-test.*$正则表达式匹配且存在时间超过 2 天的索引
使用：
config.yaml: |
.defaults:
delete:
days: 31
.operations:
delete:
weeks: 8
myapp-dev:
delete:
days: 1
myapp-qe:
delete:
weeks: 1
.regex:
- pattern: '^project\..+\-dev\..*$'
delete:
days: 1
- pattern: '^project\..+\-test\..*$'
delete:
days: 2
当您将 months 用作操作的 $UNIT 时，Curator 会从当月的第一天开始计算，而不是当月的当天。例如，如果今天是 4 月 15 日，并且您想要删除目前存在时间已达 2 个月的索引 (delete: months: 2)，Curator 不会删除日期在 2 月 15 日前的索引，而是会删除日期在 2 月 1 日前的索引。也就是说，它会退回到当前月份的第一天，然后从该日期起返回两个整月。如果您想使 Curator 准确一些，则最好使用 days（例如 delete: days: 30）。
8.6.3. Curator 故障排除
您可以参照本节中的信息来调试 Curator。例如，如果 Curator 处于失败状态，但日志消息未提供原因，您可以提高日志级别并触发新任务，而不必等待另一次调度运行 cron 任务。
先决条件
必须安装 Cluster Logging 和 Elasticsearch。
流程
启用 Curator 调试日志并手动触发下一次 Curator 操作
启用 Curator 的调试日志：
$ oc set env cronjob/curator CURATOR_LOG_LEVEL=DEBUG CURATOR_SCRIPT_LOG_LEVEL=DEBUG
指定日志级别：
- CRITICAL：Curator 仅显示严重消息。
- ERROR：Curator 仅显示错误和严重消息。
- WARNING：Curator 仅显示错误、警告和严重消息。
- INFO：Curator 仅显示参考、错误、警告和严重消息。
DEBUG：除上述所有消息外，Curator 仅显示调试消息。
默认值为 INFO。
集群日志记录在 OpenShift Container Platform 打包程序脚本（run.sh 和 convert.py）中使用 OpenShift Container Platform 自定义环境变量 CURATOR_SCRIPT_LOG_LEVEL。根据需要，环境变量采用与 CURATOR_LOG_LEVEL 相同的值进行脚本调试。
触发下一次 Curator 迭代：
$ oc create job --from=cronjob/curator <job_name>
使用以下命令来控制 CronJob：
8.6.4. 在脚本化部署中配置 Curator
如果必须在脚本化部署中配置 Curator，请使用本节中的信息。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
- 将集群日志记录设置为非受管状态。
流程
在脚本中使用以下代码片段配置 Curator：
如果是脚本化部署
创建并修改配置：
从 Curator 配置映射中复制 Curator 配置文件和 OpenShift Container Platform 自定义配置文件，并为它们分别创建单独的文件：
$ oc extract configmap/curator --keys=curator5.yaml,config.yaml --to=/my/config
- 编辑 /my/config/curator5.yaml 和 /my/config/config.yaml 文件。
删除现有的 Curator 配置映射，并将编辑后的 YAML 文件添加到新 Curator 配置映射中。
$ oc delete configmap curator ; sleep 1 $ oc create configmap curator \ --from-file=curator5.yaml=/my/config/curator5.yaml \ --from-file=config.yaml=/my/config/config.yaml \ ; sleep 1下一次操作将使用此配置。
如果使用 action 文件：
创建并修改配置：
从 Curator 配置映射中复制 Curator 配置文件和 action 文件，并为它们分别创建单独的文件：
$ oc extract configmap/curator --keys=curator5.yaml,actions.yaml --to=/my/config
- 编辑 /my/config/curator5.yaml 和 /my/config/actions.yaml 文件。
删除现有的 Curator 配置映射，并将编辑后的 YAML 文件添加到新 Curator 配置映射中。
$ oc delete configmap curator ; sleep 1 $ oc create configmap curator \ --from-file=curator5.yaml=/my/config/curator5.yaml \ --from-file=actions.yaml=/my/config/actions.yaml \ ; sleep 1下一次操作将使用此配置。
8.6.5. 使用 Curator Action 文件
openshift-logging 项目中的 Curator ConfigMap 包含一个 Curator action 文件，您可以在其中配置任何要定期运行的 Curator 操作。
不过，使用 action 文件时，OpenShift Container Platform 会忽略 curator ConfigMap 中的 config.yaml 部分，它配置为用于确保不误删重要的内部索引。若要使用 action 文件，您应在配置中添加排除规则来保留这些索引。您还必须按照本主题中的步骤，手动添加所有其他模式。
action 和 config.yaml 是互斥的配置文件。一旦存在 action 文件，OpenShift Container Platform 就会忽略 config.yaml 文件。仅建议高级用户使用 action 文件，因为使用该文件可能会对集群造成破坏，并可能导致从 Elasticsearch 中删除必要的索引/设置。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
- 将集群日志记录设置为非受管状态。处于非受管状态的 Operator 不被正式支持，集群管理员需要完全掌控各个组件的配置和升级。
流程
配置 Curator 以删除索引：
编辑 Curator ConfigMap：
oc edit cm/curator -n openshift-logging
对
action文件进行以下更改：actions: 1: action: delete_indices 1 description: >- Delete .operations indices older than 30 days. Ignore the error if the filter does not result in an actionable list of indices (ignore_empty_list). See https://www.elastic.co/guide/en/elasticsearch/client/curator/5.2/ex_delete_indices.html options: # Swallow curator.exception.NoIndices exception ignore_empty_list: True # In seconds, default is 300 timeout_override: ${CURATOR_TIMEOUT} # Don't swallow any other exceptions continue_if_exception: False # Optionally disable action, useful for debugging disable_action: False # All filters are bound by logical AND filters: 2 - filtertype: pattern kind: regex value: '^\.operations\..*$' exclude: False 3 - filtertype: age # Parse timestamp from index name source: name direction: older timestring: '%Y.%m.%d' unit: days unit_count: 30 exclude: False- 1
- 指定
delete_indices以删除指定的索引。 - 2
- 使用
filers参数以指定要删除的索引。如需这些参数的信息，请参阅 Elasticsearch Curator 文档。 - 3
- 指定
false以允许删除索引。
8.7. 配置日志记录收集器
OpenShift Container Platform 使用 Fluentd 从集群中收集操作和应用程序日志，并借助 Kubernetes Pod 和命名空间元数据丰富这些日志。
您可以配置日志轮转和日志位置，使用外部日志聚合器，以及为日志收集器进行其他配置。
除非另有说明，否则在执行这些配置之前，必须将集群日志记录设置为非受管状态。如需更多信息，请参阅更改集群日志记录管理状态。
处于非受管状态的 Operator 不被正式支持，集群管理员需要完全掌控各个组件的配置和升级。如需了解更多信息，请参阅非受管 Operator 的支持策略
8.7.1. 查看日志记录收集器 Pod
您可以使用 oc get pods --all-namespaces -o wide 命令查看部署了 Fluentd 的节点。
流程
在 openshift-logging 项目中运行以下命令：
$ oc get pods --all-namespaces -o wide | grep fluentd NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES fluentd-5mr28 1/1 Running 0 4m56s 10.129.2.12 ip-10-0-164-233.ec2.internal <none> <none> fluentd-cnc4c 1/1 Running 0 4m56s 10.128.2.13 ip-10-0-155-142.ec2.internal <none> <none> fluentd-nlp8z 1/1 Running 0 4m56s 10.131.0.13 ip-10-0-138-77.ec2.internal <none> <none> fluentd-rknlk 1/1 Running 0 4m56s 10.128.0.33 ip-10-0-128-130.ec2.internal <none> <none> fluentd-rsm49 1/1 Running 0 4m56s 10.129.0.37 ip-10-0-163-191.ec2.internal <none> <none> fluentd-wjt8s 1/1 Running 0 4m56s 10.130.0.42 ip-10-0-156-251.ec2.internal <none> <none>
8.7.2. 配置日志收集器 CPU 和内存限值
日志收集器允许对 CPU 和内存限值进行调整。
流程
在
openshift-logging项目中编辑集群日志记录自定义资源 (CR)：$ oc edit ClusterLogging instance
$ oc edit ClusterLogging instance apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" .... spec: collection: logs: fluentd: resources: limits: 1 cpu: 250m memory: 1Gi requests: cpu: 250m memory: 1Gi- 1
- 根据需要指定 CPU 和内存限值及请求。显示的值是默认值。
8.7.3. 配置所收集日志的位置
日志收集器根据 LOGGING_FILE_PATH 环境变量，将日志写入到指定的文件或默认位置 /var/log/fluentd/fluentd.log。
先决条件
- 将集群日志记录设置为非受管状态。处于非受管状态的 Operator 不被正式支持，集群管理员需要完全掌控各个组件的配置和升级。
流程
设置 Fluentd 日志的输出位置：
编辑
fluentdDaemonset 中的LOGGING_FILE_PATH参数。您可以指定特定的文件或console：spec: template: spec: containers: env: - name: LOGGING_FILE_PATH value: console 1- 1
- 指定日志输出方法：
-
通过
console利用 Fluentd 默认位置。使用oc logs [-f] <pod_name>命令来检索日志。 使用
<path-to-log/fluentd.log>将日志输出发送到指定的文件。使用oc exec <pod_name> — logs命令获取日志数据。这是默认的设置。或者，使用 CLI：
$ oc -n openshift-logging set env daemonset/fluentd LOGGING_FILE_PATH=/logs/fluentd.log
-
通过
8.7.4. 日志收集节流
对于特别冗长的项目，管理员可以减慢日志收集器在处理日志之前读取日志的速度。使用节流时，您有意减慢读取日志的速度，因此 Kibana 可能需要更长的时间才会显示记录。
节流可能会导致日志聚合落后于配置的项目；如果在 Fluentd 赶上之前删除了 Pod，则日志条目可能会丢失。
使用 systemd 系统日志作为日志源时，节流不起作用。节流的实施取决于各个项目中个别日志文件是否能够减慢读取速度。从系统日志中读取时，只有一个日志源，而没有日志文件，因此无法使用基于文件的节流。没有办法可以限制读取到 Fluentd 进程中的日志条目。
先决条件
将集群日志记录设置为非受管状态。
流程
要配置 Fluentd 以限制特定项目，请于部署后在 Fluentd ConfigMap 中编辑节流配置：
$ oc edit configmap/fluentd
throttle-config.yaml 键的格式是 YAML 文件，其包含项目名称以及各个节点上希望读取日志的速度。默认值为每个节点一次读取 1000 行。例如：
throttle-config.yaml: | - opensift-logging: read_lines_limit: 10 - .operations: read_lines_limit: 100
8.7.5. 了解 Fluentd 的缓冲数据块限制
如果 Fluentd 日志记录器无法满足大量日志的需求，则需要切换到文件缓冲来降低内存用量并防止数据丢失。
Fluentd 文件缓冲以数据块的形式存储记录。数据块存储在缓冲区中。
要按如下修改 Fluentd daemonset 中的 FILE_BUFFER_LIMIT 或 BUFFER_SIZE_LIMIT 参数，您需要把集群日志系统设置为未管理（unmanaged）状态。处于非受管状态的 Operator 不被正式支持，集群管理员需要完全掌控各个组件的配置和升级。
Fluentd buffer_chunk_limit 由环境变量 BUFFER_SIZE_LIMIT 决定，其默认值为 8m。每个输出的文件缓冲区大小由环境变量 FILE_BUFFER_LIMIT 决定，其默认值为 256Mi。持久性卷大小必须大于 FILE_BUFFER_LIMIT 与输出相乘的结果。
例如，Fluentd pod 上应通过 PVC 或主机挂载准备持久性卷 /var/lib/fluentd。然后，将该区域用作文件缓冲区。
buffer_type 和 buffer_path 在 Fluentd 配置文件中进行配置，如下所示：
$ egrep "buffer_type|buffer_path" *.conf output-es-config.conf: buffer_type file buffer_path `/var/lib/fluentd/buffer-output-es-config` output-es-ops-config.conf: buffer_type file buffer_path `/var/lib/fluentd/buffer-output-es-ops-config`
Fluentd buffer_queue_limit 是变量 BUFFER_QUEUE_LIMIT 的值。默认值为 32。
环境变量 BUFFER_QUEUE_LIMIT 计算为 (FILE_BUFFER_LIMIT / (number_of_outputs * BUFFER_SIZE_LIMIT))。
如果 BUFFER_QUEUE_LIMIT 变量具有默认值：
-
FILE_BUFFER_LIMIT = 256Mi -
number_of_outputs = 1 -
BUFFER_SIZE_LIMIT = 8Mi
buffer_queue_limit 的值为 32。若要更改 buffer_queue_limit，您必须更改 FILE_BUFFER_LIMIT 的值。
在这个公式中，如果所有日志都发送到单个资源，则 number_of_outputs 为 1，否则每多一个资源就会递增 1。例如，number_of_outputs 的值为：
-
1- 如果所有日志都发送到单个 Elasticsearch pod -
2- 如果应用程序日志发送到 Elasticsearch pod，并且 ops 日志发送到另一个 Elasticsearch pod -
4- 如果应用程序日志发送到一个 Elasticsearch pod，ops 日志发送到另一个 Elasticsearch pod，并且这两者都转发到其他 Fluentd 实例
8.7.6. 使用环境变量配置日志记录收集器
您可以使用环境变量来修改 Fluentd 日志收集器的配置。
如需可用环境变量的列表，请参见 Github 中的 Fluentd README。
先决条件
- 将集群日志记录设置为非受管状态。处于非受管状态的 Operator 不被正式支持，集群管理员需要完全掌控各个组件的配置和升级。
流程
根据需要设置任何 Fluentd 环境变量：
oc set env ds/fluentd <env-var>=<value>
例如：
oc set env ds/fluentd LOGGING_FILE_AGE=30
8.7.7. 关于日志记录收集器警报
以下警报由日志记录收集器生成，可以在 Prometheus UI 的 Alerts 选项卡上查看。
所有日志记录收集器警报都列在 OpenShift Container Platform Web 控制台的 Monitoring → Alerts 页面中。警报处于以下状态之一：
- Firing：在超时期限内警报条件为 true。点击在触发警报末尾的 Options 菜单，以查看更多信息或使警告静音。
- Pending：警报条件当前为 true，但尚未达到超时时间。
- Not Firing：当前未触发警报。
表 8.3. Fluentd Prometheus 警报
| 警报 | 消息 | 描述 | 重要性 |
|---|---|---|---|
|
|
| Fluentd 报告的问题数量超过了指定数量（默认值为 10）。 | Critical |
|
|
| Fluentd 报告 Prometheus 可能无法抓取特定的 Fluentd 实例。 | Critical |
|
|
| Fluentd 报告自己已不堪重负。 | Warning |
|
|
| Fluentd 报告队列使用方法问题。 | Critical |
8.8. 使用容忍度来控制集群日志记录 Pod 放置
您可以使用污点和容忍度来确保集群日志记录 Pod 在特定节点上运行，并确保其他工作负载不在这些节点上运行。
污点和容忍度是简单的 key:value 对。节点上的污点指示节点排斥所有不容许该污点的 Pod。
key 是最长为 253 个字符的任意字符串，value 则是最长为 63 个字符的任意字符串。字符串必须以字母或数字开头，并且可以包含字母、数字、连字符、句点和下划线。
具有容忍度的集群日志记录 CR 的示例
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
name: "instance"
namespace: openshift-logging
spec:
managementState: "Managed"
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 1
tolerations: 1
- key: "logging"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 6000
resources:
limits:
memory: 8Gi
requests:
cpu: 100m
memory: 1Gi
storage: {}
redundancyPolicy: "ZeroRedundancy"
visualization:
type: "kibana"
kibana:
tolerations: 2
- key: "logging"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 6000
resources:
limits:
memory: 2Gi
requests:
cpu: 100m
memory: 1Gi
replicas: 1
curation:
type: "curator"
curator:
tolerations: 3
- key: "logging"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 6000
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 100Mi
schedule: "*/5 * * * *"
collection:
logs:
type: "fluentd"
fluentd:
tolerations: 4
- key: "logging"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 6000
resources:
limits:
memory: 2Gi
requests:
cpu: 100m
memory: 1Gi
8.8.1. 使用容忍度来控制 Elasticsearch Pod 放置
您可以通过在 Pod 上使用容忍度来控制 Elasticsearch Pod 在哪些节点上运行，并防止其他工作负载使用这些节点。
您可以通过集群日志记录自定义资源 (CR) 将容忍度应用到 Elasticsearch Pod，并通过节点规格将污点应用到节点。节点上的污点是一个 key:value 对，它指示节点排斥所有不容许该污点的 Pod。通过使用不在其他 Pod 上的特定 key:value 对，可以确保仅 Elasticseach Pod 能够在该节点上运行。
默认情况下，Elasticsearch Pod 具有以下容忍度：
tolerations: - effect: "NoExecute" key: "node.kubernetes.io/disk-pressure" operator: "Exists"
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
使用以下命令，将污点添加到要在其上调度集群日志记录 Pod 的节点：
$ oc adm taint nodes <node-name> <key>=<value>:<effect>
例如：
$ oc adm taint nodes node1 elasticsearch=node:NoExecute
本例在
node1上放置一个键为elasticsearch且值为node的污点，污点效果是NoExecute。具有NoExecute效果的节点仅调度与污点匹配的 Pod，并删除不匹配的现有 Pod。编辑集群日志记录自定义资源 (CR) 的
logstore部分，以配置 Elasticsearch Pod 的容忍度：logStore: type: "elasticsearch" elasticsearch: nodeCount: 1 tolerations: - key: "elasticsearch" 1 operator: "Exists" 2 effect: "NoExecute" 3 tolerationSeconds: 6000 4
此容忍度与 oc adm taint 命令创建的污点匹配。具有此容忍度的 Pod 可以调度到 node1 上。
8.8.2. 使用容忍度（toleration）来控制 Kibana Pod 放置
您可以通过在 Pod 上使用容限（toleration）来控制 Kibana Pod 在哪些节点上运行，并防止其他工作负载使用这些节点。
您可以通过集群日志记录自定义资源 (CR) 将容限应用到 Kibana Pod，并通过节点规格将污点（taint）应用到节点。节点上的污点是一个 key:value 对，它指示节点排斥所有不容许该污点的 Pod。通过使用没有在其他 Pod 上使用的特定 key:value 对，可以确保仅 Kibana Pod 能够在该节点上运行。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
使用以下命令，将污点添加到要在其上调度 Kibana Pod 的节点：
$ oc adm taint nodes <node-name> <key>=<value>:<effect>
例如：
$ oc adm taint nodes node1 kibana=node:NoExecute
本例在
node1上放置一个键为kibana且值为node的污点，污点效果是NoExecute。您必须使用NoExecute污点设置。NoExecute仅调度与污点匹配的 Pod，并删除不匹配的现有 Pod。编辑集群日志记录自定义资源 (CR) 的
visualization部分，以配置 Kibana Pod 的容忍度：visualization: type: "kibana" kibana: tolerations: - key: "kibana" 1 operator: "Exists" 2 effect: "NoExecute" 3 tolerationSeconds: 6000 4
此容忍度与 oc adm taint 命令创建的污点匹配。具有此容限的 Pod 能够调度到 node1 上。
8.8.3. 使用容忍度来控制 Curator Pod 放置
您可以通过在 Pod 上使用容忍度来控制 Curator Pod 在哪些节点上运行，并防止其他工作负载使用这些节点。
您可以通过集群日志记录自定义资源 (CR) 将容忍度应用到 Curator Pod，并通过节点规格将污点应用到节点。节点上的污点是一个 key:value 对，它指示节点排斥所有不容许该污点的 Pod。通过使用没有在其他 Pod 上使用的特定 key:value 对，可以确保仅 Curator Pod 能够在该节点上运行。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
使用以下命令，将污点添加到要在其上调度 Curator Pod 的节点：
$ oc adm taint nodes <node-name> <key>=<value>:<effect>
例如：
$ oc adm taint nodes node1 curator=node:NoExecute
本例在
node1上放置一个键为curator且值为node的污点，污点效果是NoExecute。您必须使用NoExecute污点设置。NoExecute仅调度与污点匹配的 Pod，并删除不匹配的现有 Pod。编辑集群日志记录自定义资源 (CR) 的
curation部分，以配置 Curator Pod 的容忍度：curation: type: "curator" curator: tolerations: - key: "curator" 1 operator: "Exists" 2 effect: "NoExecute" 3 tolerationSeconds: 6000 4
此容忍度与 oc adm taint 命令创建的污点匹配。具有此容限的 Pod 能够调度到 node1 上。
8.8.4. 使用容忍度来控制日志收集器 Pod 放置
您可以通过在 Pod 上使用容忍度来确保日志记录收集器 Pod 在哪些节点上运行，并防止其他工作负载使用这些节点。
您可以通过集群日志记录自定义资源 (CR) 将容忍度应用到日志记录收集器 Pod，并通过节点规格将污点应用到节点。您可以使用污点和容限来确保 Pod 不会因为内存和 CPU 问题而被驱除。
默认情况下，日志记录收集器 Pod 具有以下容忍度：
tolerations: - key: "node-role.kubernetes.io/master" operator: "Exists" effect: "NoExecute"
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
使用以下命令，将污点添加到要在其上调度日志记录收集器 Pod 的节点：
$ oc adm taint nodes <node-name> <key>=<value>:<effect>
例如：
$ oc adm taint nodes node1 collector=node:NoExecute
本例在
node1上放置一个键为collector且值为node的污点，污点效果是NoExecute。您必须使用NoExecute污点设置。NoExecute仅调度与污点匹配的 Pod，并删除不匹配的现有 Pod。编辑集群日志记录自定义资源 (CR) 的
collection部分，以配置日志记录收集器 Pod 的容忍度：collection: logs: type: "fluentd" rsyslog: tolerations: - key: "collector" 1 operator: "Exists" 2 effect: "NoExecute" 3 tolerationSeconds: 6000 4
此容忍度与 oc adm taint 命令创建的污点匹配。具有此容限的 Pod 能够调度到 node1 上。
8.8.5. 其他资源
如需有关污点和容忍度的更多信息，请参见使用节点污点控制 Pod 位置。
8.9. 将 OpenShift Container Platform 日志发送到外部设备
您可以将 Elasticsearch 日志发送到外部设备，如外部托管的 Elasticsearch 实例或外部 syslog 服务器。还可以配置 Fluentd，使其将日志发送到外部日志聚合器。
除非另有说明，否则在执行这些配置之前，必须将集群日志记录设置为非受管状态。如需更多信息，请参阅更改集群日志记录管理状态。
8.9.1. 配置日志收集器以将日志发送到外部 Elasticsearch 实例
日志收集器将日志发送到 Elasticsearch 部署配置的 ES_HOST、ES_PORT、OPS_HOST 和 OPS_PORT 环境变量的值。应用程序日志定向到 ES_HOST 目的地，操作日志则定向到 OPS_HOST。
不支持将日志直接发送到 AWS Elasticsearch 实例。使用 Fluentd Secure Forward 将日志定向到由您控制并且配置了 fluent-plugin-aws-Elasticsearch-service 插件的 Fluentd 实例。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
- 将集群日志记录设置为非受管状态。
流程
将日志定向到特定的 Elasticsearch 实例：
在 openshift-logging 项目中编辑
fluentdDaemonSet。$ oc edit ds/fluentd spec: template: spec: containers: env: - name: ES_HOST value: elasticsearch - name: ES_PORT value: '9200' - name: ES_CLIENT_CERT value: /etc/fluent/keys/app-cert - name: ES_CLIENT_KEY value: /etc/fluent/keys/app-key - name: ES_CA value: /etc/fluent/keys/app-ca - name: OPS_HOST value: elasticsearch - name: OPS_PORT value: '9200' - name: OPS_CLIENT_CERT value: /etc/fluent/keys/infra-cert - name: OPS_CLIENT_KEY value: /etc/fluent/keys/infra-key - name: OPS_CA value: /etc/fluent/keys/infra-ca-
将
ES_HOST和OPS_HOST设为相同的目的地，同时确保ES_PORT和OPS_PORT也具有相同的值，使外部 Elasticsearch 实例同时包含应用程序日志和操作日志。 - 为 TLS 配置外部托管的 Elasticsearch 实例。仅允许使用相互 TLS 的外部托管 Elasticsearch 实例。
如果不使用提供的 Kibana 和 Elasticsearch 镜像，您将没有同样的多租户功能，您的数据也不会由用户访问权限限制到特定的项目。
8.9.2. 配置日志收集器以将日志发送到外部 syslog 服务器
在主机上使用 fluent-plugin-remote-syslog 插件，将日志发送到外部 syslog 服务器。
先决条件
将集群日志记录设置为非受管状态。
流程
在
openshift-logging项目中设置fluentdDaemonSet 的环境变量。spec: template: spec: containers: - name: fluentd image: 'registry.redhat.io/openshift4/ose-logging-fluentd:v4.2' env: - name: REMOTE_SYSLOG_HOST 1 value: host1 - name: REMOTE_SYSLOG_HOST_BACKUP value: host2 - name: REMOTE_SYSLOG_PORT_BACKUP value: 5555- 1
- 所需的远程 syslog 主机。每个主机都需要。
这将建立两个目的地。
host1上的 syslog 服务器将在默认端口514上接收消息，host2则在端口5555上接收相同的消息。或者，您可以在
openshift-logging项目中自行配置自定义fluentdDaemonSet。Fluentd 环境变量
参数 描述 USE_REMOTE_SYSLOG默认值为
false。设置为true可启用fluent-plugin-remote-sysloggemREMOTE_SYSLOG_HOST（必需）远程 syslog 服务器的主机名或 IP 地址。
REMOTE_SYSLOG_PORT要连接的端口号。默认值为
514。REMOTE_SYSLOG_SEVERITY设置 syslog 严重性级别。默认值为
debug。REMOTE_SYSLOG_FACILITY设置 syslog 工具。默认值为
local0。REMOTE_SYSLOG_USE_RECORD默认值为
false。设置为true可使用记录的严重性和工具字段对 syslog 消息进行设置。REMOTE_SYSLOG_REMOVE_TAG_PREFIX从标签中删除前缀，默认为
''（空白）。REMOTE_SYSLOG_TAG_KEY如果指定，则使用此字段作为要在记录上查看的键，以对 syslog 消息设置标签。
REMOTE_SYSLOG_PAYLOAD_KEY如果指定，则使用此字段作为要在记录上查看的键，以对 syslog 消息设置有效负载。
REMOTE_SYSLOG_TYPE设置传输层协议类型。默认为
syslog_buffered，它设定 TCP 协议。要切换到 UDP，请将其设定为syslog。警告这种实施是不安全的，应当仅在能保证不嗅探连接的环境中使用。
8.9.3. 配置 Fluentd 将日志发送到外部日志聚合器
您可以使用 out_forward 插件，将 Fluentd 配置为将其日志的副本发送到外部日志聚合器，而不是默认的 Elasticsearch。在本地托管的 Fluentd 处理日志记录之后，您可以从那里进一步处理日志记录。
forward 插件仅被 Fluentd 支持 。out_forward 插件实现客户端（发送方），in_forward 实现服务器端（接收方）。
要将 OpenShift Container Platform 配置为使用 out_forward 来发送日志，在 openshift-logging 命名空间内创建一个名为 secure-forward 的 ConfigMap 来指向一个接收器。在接收器上，配置 in_forward 插件来接收来自 OpenShift Container Platform 的日志。有关使用 in_forward 插件的详情，请参考 Fluentd 文档。
默认 secure-forward.conf 部分
# <store>
# @type forward
# <security>
# self_hostname ${hostname} # ${hostname} is a placeholder.
# shared_key <shared_key_between_forwarder_and_forwardee>
# </security>
# transport tls
# tls_verify_hostname true # Set false to ignore server cert hostname.
# tls_cert_path /path/for/certificate/ca_cert.pem
# <buffer>
# @type file
# path '/var/lib/fluentd/forward'
# queued_chunks_limit_size "#{ENV['BUFFER_QUEUE_LIMIT'] || '1024' }"
# chunk_limit_size "#{ENV['BUFFER_SIZE_LIMIT'] || '1m' }"
# flush_interval "#{ENV['FORWARD_FLUSH_INTERVAL'] || '5s'}"
# flush_at_shutdown "#{ENV['FLUSH_AT_SHUTDOWN'] || 'false'}"
# flush_thread_count "#{ENV['FLUSH_THREAD_COUNT'] || 2}"
# retry_max_interval "#{ENV['FORWARD_RETRY_WAIT'] || '300'}"
# retry_forever true
# # the systemd journald 0.0.8 input plugin will just throw away records if the buffer
# # queue limit is hit - 'block' will halt further reads and keep retrying to flush the
# # buffer to the remote - default is 'exception' because in_tail handles that case
# overflow_action "#{ENV['BUFFER_QUEUE_FULL_ACTION'] || 'exception'}"
# </buffer>
# <server>
# host server.fqdn.example.com # or IP
# port 24284
# </server>
# <server>
# host 203.0.113.8 # ip address to connect
# name server.fqdn.example.com # The name of the server. Used for logging and certificate verification in TLS transport (when host is address).
# </server>
# </store>
流程
将 Fluentd 日志的副本发送到外部日志聚合器：
编辑 Fluentd 配置映射的
secure-forward.conf部分：$ oc edit configmap/fluentd -n openshift-logging
输入外部 Fluentd 服务器的名称、主机和端口。
# <server> # host server.fqdn.example.com # or IP # port 24284 # </server> # <server> # host 203.0.113.8 # ip address to connect # name server.fqdn.example.com # The name of the server. Used for logging and certificate verification in TLS transport (when host is address). # </server>
例如：
<server> name externalserver1 1 host 192.168.1.1 2 port 24224 3 </server> <server> 4 name externalserver1 host 192.168.1.2 port 24224 </server> </store>将您的 CA 证书和私钥的路径添加到
secure-forward.conf部分：# <security> # self_hostname ${hostname} # ${hostname} is a placeholder. 1 # shared_key <shared_key_between_forwarder_and_forwardee> 2 # </security> # tls_cert_path /path/for/certificate/ca_cert.pem 3例如：
<security> self_hostname client.fqdn.local shared_key cluster_logging_key </security> tls_cert_path /etc/fluent/keys/ca.crt要使用 mTLS，请参阅 Fluentd 文档 来获取有关客户端证书和密钥参数及其他设置的信息。
将用于
secure-forward.conf的证书添加到 Fluentd Pod 上挂载的现有 secret 中。your_ca_cert和your_private_key值必须与configmap/fluentd的secure-forward.conf中指定的值匹配：$ oc patch secrets/fluentd --type=json \ --patch "[{'op':'add','path':'/data/your_ca_cert','value':'$(base64 -w0 /path/to/your_ca_cert.pem)'}]" $ oc patch secrets/fluentd --type=json \ --patch "[{'op':'add','path':'/data/your_private_key','value':'$(base64 -w0 /path/to/your_private_key.pem)'}]"注意将
your_private_key替换为一个通用名称。这个链接指向 JSON 路径，而不是主机系统上的路径。例如：
$ oc patch secrets/fluentd --type=json \ --patch "[{'op':'add','path':'/data/ca.crt','value':'$(base64 -w0 /etc/fluent/keys/ca.crt)'}]" $ oc patch secrets/fluentd --type=json \ --patch "[{'op':'add','path':'/data/ext-agg','value':'$(base64 -w0 /etc/fluent/keys/ext-agg.pem)'}]"在外部聚合器上配置
secure-forward.conf文件，以安全地接受来自 Fluentd 的信息。配置外部聚合器时，它必须能够安全地接受来自 Fluentd 的消息。
您可以参阅 如何设置 inforward 插件 及 out_forward 插件。
8.10. 配置 systemd-journald 和 Fluentd
Fluentd 需要从日志 (journal) 中读取数据。因为日志默认设置非常低，它可能无法跟上系统服务的日志记录率，所以日志条目可能会丢失。
我们推荐设置 RateLimitInterval=1s 和 RateLimitBurst=10000 （如有必要甚至更高）以防止日志丢失条目。
8.10.1. 为集群日志记录配置 systemd-journald
随着项目的扩展，默认的日志记录环境可能需要进行一些调整。
例如，如果有缺少日志数据的情况，则可能需要提高 journald 的速率限制。您可以调整在指定时间段内保留的消息数量，以确保集群日志记录在不丢弃日志的情况下不会使用过量资源。
您还可以确定是否压缩日志、日志需要保留的时间、如何存储日志，以及其他设置。
流程
使用所需设置创建
journald.conf文件：Compress=no 1 ForwardToConsole=yes 2 ForwardToSyslog=no 3 MaxRetentionSec=30 4 RateLimitBurst=10000 5 RateLimitInterval=1s 6 Storage=volatile 7 SyncIntervalSec=1s 8 SystemMaxUse=8g 9 SystemKeepFree=20% 10 SystemMaxFileSize10M 11
- 1
- 指定是否要在将日志写入文件系统前压缩日志。指定
yes来压缩消息，或指定no不压缩信息。默认为yes。 - 2 3
- 配置是否转发日志信息。每个默认值为
no。指定：-
ForwardToConsole将日志转发到系统控制台。 -
ForwardToKsmg将日志转发到内核日志缓冲。 -
ForwardToSyslog将日志转发到 syslog 守护进程。 -
ForwardToWall将信息作为墙信息转发给所有登录的用户。
-
- 4
- 指定存储日志条目的最长时间。输入秒数。或包括一个单位：" year" 、"month" 、"week" 、"day" 、"h" 或 "m"。输入
0来禁用。默认值为1month。 - 5 6
- 配置速率限制。在
RateLimitIntervalSec定义的时间段内，如果接收的日志数量超过了RateLimitBurst指定的值，则以后的所有信息都会被丢弃，直到该时间段结束。建议您设置RateLimitInterval=1s和RateLimitBurst=10000，它们是默认值。 - 7
- 指定日志的存储方式。默认为
persistent：-
volatile在/var/log/journal/中存储内存中的日志数据。 -
persistent把日志保存到磁盘的/var/log/journal/。如果这个目录步存在，systemd 将会创建这个目录。 -
auto如果目录存在，把日志保存在/var/log/journal/中。如果不存在，systemd 会临时将日志保存在/run/systemd/journal中。 -
none不存储日志。systemd 丢弃所有日志。
-
- 8
- 指定在将 ERR, WARNING, NOTICE, INFO 和 DEBUG 日志同步到磁盘上前等待的超时时间。systemd 在接收到 CRIT, ALERT 或 EMERG 日志后会立即进行同步。默认值为
1s。 - 9
- 指定日志可以使用的最大值。默认值为
8g。 - 10
- 指定 systemd 必须保留多少磁盘空间。默认值为
20%。 - 11
- 指定保存在
/var/log/journal中的独立日志文件的最大大小。默认值为10M。注意如果删除速率限制，您可能会看到系统日志记录守护进程的 CPU 使用率增加，因为它需要处理在以前可以被限制掉的信息。
如需了解更多关于 systemd 设置的信息，请参阅 https://www.freedesktop.org/software/systemd/man/journald.conf.html。该页面中列出的默认设置可能不适用于 OpenShift Container Platform。
将
journal.conf文件转换为 base64：$ export jrnl_cnf=$( cat /journald.conf | base64 -w0 )
为 master 或 worker 创建新的 MachineConfig，并添加
journal.conf参数：例如：
... config: storage: files: - contents: source: data:text/plain;charset=utf-8;base64,${jrnl_cnf} verification: {} filesystem: root mode: 0644 1 path: /etc/systemd/journald.conf 2 systemd: {}创建 MachineConfig：
$ oc apply -f <filename>.yaml
控制器会检测新的 MachineConfig，并生成新的
rendered-worker-<hash>版本。监控新配置在每个节点中的应用状态：
$ oc describe machineconfigpool/worker Name: worker Namespace: Labels: machineconfiguration.openshift.io/mco-built-in= Annotations: <none> API Version: machineconfiguration.openshift.io/v1 Kind: MachineConfigPool ... Conditions: Message: Reason: All nodes are updating to rendered-worker-913514517bcea7c93bd446f4830bc64e
第 9 章 查看 Elasticsearch 状态
您可以查看 Elasticsearch Operator 的状态，以及多个 Elasticsearch 组件的状态。
9.1. 查看 Elasticsearch 状态
您可以查看 Elasticsearch 集群的状态。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
进入
openshift-logging项目。$ oc project openshift-logging
查看 Elasticsearch 集群状态：
获取 Elasticsearch 实例的名称：
$ oc get Elasticsearch NAME AGE elasticsearch 5h9m
获取 Elasticsearch 状态：
$ oc get Elasticsearch <Elasticsearch-instance> -o yaml
例如：
$ oc get Elasticsearch elasticsearch -n openshift-logging -o yaml
输出中包含类似于如下的信息：
status: 1 cluster: 2 activePrimaryShards: 30 activeShards: 60 initializingShards: 0 numDataNodes: 3 numNodes: 3 pendingTasks: 0 relocatingShards: 0 status: green unassignedShards: 0 clusterHealth: "" conditions: [] 3 nodes: 4 - deploymentName: elasticsearch-cdm-zjf34ved-1 upgradeStatus: {} - deploymentName: elasticsearch-cdm-zjf34ved-2 upgradeStatus: {} - deploymentName: elasticsearch-cdm-zjf34ved-3 upgradeStatus: {} pods: 5 client: failed: [] notReady: [] ready: - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422 - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt data: failed: [] notReady: [] ready: - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422 - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt master: failed: [] notReady: [] ready: - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422 - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt shardAllocationEnabled: all
- 1
- 在输出中，集群状态字段显示在
status小节中。 - 2
- Elasticsearch 集群的状态：
- 活跃的主分片的数量。
- 活跃分片的数量。
- 正在初始化的分片的数量。
- Elasticsearch 数据节点的数量。
- Elasticsearch 节点的总数。
- 待处理的任务数量。
-
Elasticsearch 状态：
green、red或yellow。 - 未分配分片的数量。
- 3
- 任何状态条件（若存在）。Elasticsearch 集群状态代表了当无法放置容器时来自于调度程序的原因。显示与以下情况有关的所有事件：
- 容器正在等待 Elasticsearch 和代理容器。
- 容器因 Elasticsearch 和代理容器而终止。
- Pod 不可调度。此外还显示适用于多个问题的情况，具体请参阅情况消息示例。
- 4
- 集群中的 Elasticsearch 节点，以及
upgradeStatus。 - 5
- 集群中的 Elasticsearch 客户端、数据和 master 节点，列在 failed、
notReady或ready状态下。
9.1.1. 情况消息示例
以下是来自 Elasticsearch 实例的 Status 部分的一些情况消息的示例。
此状态消息表示节点已超过配置的低水位线，并且没有分片将分配给此节点。
status:
nodes:
- conditions:
- lastTransitionTime: 2019-03-15T15:57:22Z
message: Disk storage usage for node is 27.5gb (36.74%). Shards will be not
be allocated on this node.
reason: Disk Watermark Low
status: "True"
type: NodeStorage
deploymentName: example-elasticsearch-cdm-0-1
upgradeStatus: {}此状态消息表示节点已超过配置的高水位线，并且分片将重新定位到其他节点。
status:
nodes:
- conditions:
- lastTransitionTime: 2019-03-15T16:04:45Z
message: Disk storage usage for node is 27.5gb (36.74%). Shards will be relocated
from this node.
reason: Disk Watermark High
status: "True"
type: NodeStorage
deploymentName: example-elasticsearch-cdm-0-1
upgradeStatus: {}此状态消息表示 CR 中的 Elasticsearch 节点选择器与集群中的任何节点都不匹配：
status:
nodes:
- conditions:
- lastTransitionTime: 2019-04-10T02:26:24Z
message: '0/8 nodes are available: 8 node(s) didn''t match node selector.'
reason: Unschedulable
status: "True"
type: Unschedulable此状态消息表示 Elasticsearch CR 使用了不存在的 PVC。
status:
nodes:
- conditions:
- last Transition Time: 2019-04-10T05:55:51Z
message: pod has unbound immediate PersistentVolumeClaims (repeated 5 times)
reason: Unschedulable
status: True
type: Unschedulable此状态消息表示 Elasticsearch 集群没有足够的节点来支持 Elasticsearch 冗余策略。
status:
clusterHealth: ""
conditions:
- lastTransitionTime: 2019-04-17T20:01:31Z
message: Wrong RedundancyPolicy selected. Choose different RedundancyPolicy or
add more nodes with data roles
reason: Invalid Settings
status: "True"
type: InvalidRedundancy此状态消息表示集群中包含太多 master 节点：
status:
clusterHealth: green
conditions:
- lastTransitionTime: '2019-04-17T20:12:34Z'
message: >-
Invalid master nodes count. Please ensure there are no more than 3 total
nodes with master roles
reason: Invalid Settings
status: 'True'
type: InvalidMasters9.2. 查看 Elasticsearch 组件状态
您可以查看多个 Elasticsearch 组件的状态。
- Elasticsearch 索引
您可以查看 Elasticsearch 索引的状态。
获取 Elasticsearch Pod 的名称：
$ oc get pods --selector component=elasticsearch -o name pod/elasticsearch-cdm-1godmszn-1-6f8495-vp4lw pod/elasticsearch-cdm-1godmszn-2-5769cf-9ms2n pod/elasticsearch-cdm-1godmszn-3-f66f7d-zqkz7
获取索引的状态：
$ oc exec elasticsearch-cdm-1godmszn-1-6f8495-vp4lw -- indices Defaulting container name to elasticsearch. Use 'oc describe pod/elasticsearch-cdm-1godmszn-1-6f8495-vp4lw -n openshift-logging' to see all of the containers in this pod. Wed Apr 10 05:42:12 UTC 2019 health status index uuid pri rep docs.count docs.deleted store.size pri.store.size red open .kibana.647a750f1787408bf50088234ec0edd5a6a9b2ac N7iCbRjSSc2bGhn8Cpc7Jg 2 1 green open .operations.2019.04.10 GTewEJEzQjaus9QjvBBnGg 3 1 2176114 0 3929 1956 green open .operations.2019.04.11 ausZHoKxTNOoBvv9RlXfrw 3 1 1494624 0 2947 1475 green open .kibana 9Fltn1D0QHSnFMXpphZ--Q 1 1 1 0 0 0 green open .searchguard chOwDnQlSsqhfSPcot1Yiw 1 1 5 1 0 0
- Elasticsearch Pod
您可以查看 Elasticsearch Pod 的状态。
获取 Pod 的名称：
$ oc get pods --selector component=elasticsearch -o name pod/elasticsearch-cdm-1godmszn-1-6f8495-vp4lw pod/elasticsearch-cdm-1godmszn-2-5769cf-9ms2n pod/elasticsearch-cdm-1godmszn-3-f66f7d-zqkz7
获取 Pod 的状态：
oc describe pod elasticsearch-cdm-1godmszn-1-6f8495-vp4lw
输出中包括以下状态信息：
.... Status: Running .... Containers: elasticsearch: Container ID: cri-o://b7d44e0a9ea486e27f47763f5bb4c39dfd2 State: Running Started: Mon, 08 Apr 2019 10:17:56 -0400 Ready: True Restart Count: 0 Readiness: exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3 .... proxy: Container ID: cri-o://3f77032abaddbb1652c116278652908dc01860320b8a4e741d06894b2f8f9aa1 State: Running Started: Mon, 08 Apr 2019 10:18:38 -0400 Ready: True Restart Count: 0 .... Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True .... Events: <none>
- Elasticsearch 部署配置
您可以查看 Elasticsearch 部署配置的状态。
获取部署配置的名称：
$ oc get deployment --selector component=elasticsearch -o name deployment.extensions/elasticsearch-cdm-1gon-1 deployment.extensions/elasticsearch-cdm-1gon-2 deployment.extensions/elasticsearch-cdm-1gon-3
获取部署配置状态：
$ oc describe deployment elasticsearch-cdm-1gon-1
输出中包括以下状态信息：
.... Containers: elasticsearch: Image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.2 Readiness: exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3 .... Conditions: Type Status Reason ---- ------ ------ Progressing Unknown DeploymentPaused Available True MinimumReplicasAvailable .... Events: <none>
- Elasticsearch ReplicaSet
您可以查看 Elasticsearch ReplicaSet 的状态。
获取副本集的名称：
$ oc get replicaSet --selector component=elasticsearch -o name replicaset.extensions/elasticsearch-cdm-1gon-1-6f8495 replicaset.extensions/elasticsearch-cdm-1gon-2-5769cf replicaset.extensions/elasticsearch-cdm-1gon-3-f66f7d
获取副本集的状态：
$ oc describe replicaSet elasticsearch-cdm-1gon-1-6f8495
输出中包括以下状态信息：
.... Containers: elasticsearch: Image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.2 Readiness: exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3 .... Events: <none>
第 10 章 查看集群日志记录状态
您可以查看 Cluster Logging Operator 的状态以及多个集群日志记录组件的状态。
10.1. 查看 Cluster Logging Operator 的状态
您可以查看 Cluster Logging Operator 的状态。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
进入
openshift-logging项目。$ oc project openshift-logging
查看集群日志记录状态：
获取集群日志记录状态：
$ oc get clusterlogging instance -o yaml
输出中包含类似于如下的信息：
apiVersion: logging.openshift.io/v1 kind: ClusterLogging .... status: 1 collection: logs: fluentdStatus: daemonSet: fluentd 2 nodes: fluentd-2rhqp: ip-10-0-169-13.ec2.internal fluentd-6fgjh: ip-10-0-165-244.ec2.internal fluentd-6l2ff: ip-10-0-128-218.ec2.internal fluentd-54nx5: ip-10-0-139-30.ec2.internal fluentd-flpnn: ip-10-0-147-228.ec2.internal fluentd-n2frh: ip-10-0-157-45.ec2.internal pods: failed: [] notReady: [] ready: - fluentd-2rhqp - fluentd-54nx5 - fluentd-6fgjh - fluentd-6l2ff - fluentd-flpnn - fluentd-n2frh curation: 3 curatorStatus: - cronJobs: curator schedules: 30 3 * * * suspended: false logstore: 4 elasticsearchStatus: - ShardAllocationEnabled: all cluster: activePrimaryShards: 5 activeShards: 5 initializingShards: 0 numDataNodes: 1 numNodes: 1 pendingTasks: 0 relocatingShards: 0 status: green unassignedShards: 0 clusterName: elasticsearch nodeConditions: elasticsearch-cdm-mkkdys93-1: nodeCount: 1 pods: client: failed: notReady: ready: - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c data: failed: notReady: ready: - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c master: failed: notReady: ready: - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c visualization: 5 kibanaStatus: - deployment: kibana pods: failed: [] notReady: [] ready: - kibana-7fb4fd4cc9-f2nls replicaSets: - kibana-7fb4fd4cc9 replicas: 1
10.1.1. 情况消息示例
以下示例是来自集群日志记录实例的 Status.Nodes 部分的一些情况消息。
类似于以下内容的状态消息表示节点已超过配置的低水位线，并且没有分片将分配给此节点：
nodes:
- conditions:
- lastTransitionTime: 2019-03-15T15:57:22Z
message: Disk storage usage for node is 27.5gb (36.74%). Shards will be not
be allocated on this node.
reason: Disk Watermark Low
status: "True"
type: NodeStorage
deploymentName: example-elasticsearch-clientdatamaster-0-1
upgradeStatus: {}类似于以下内容的状态消息表示节点已超过配置的高水位线，并且分片将重新定位到其他节点：
nodes:
- conditions:
- lastTransitionTime: 2019-03-15T16:04:45Z
message: Disk storage usage for node is 27.5gb (36.74%). Shards will be relocated
from this node.
reason: Disk Watermark High
status: "True"
type: NodeStorage
deploymentName: cluster-logging-operator
upgradeStatus: {}类似于以下内容的状态消息表示 CR 中的 Elasticsearch 节点选择器与集群中的任何节点都不匹配：
Elasticsearch Status:
Shard Allocation Enabled: shard allocation unknown
Cluster:
Active Primary Shards: 0
Active Shards: 0
Initializing Shards: 0
Num Data Nodes: 0
Num Nodes: 0
Pending Tasks: 0
Relocating Shards: 0
Status: cluster health unknown
Unassigned Shards: 0
Cluster Name: elasticsearch
Node Conditions:
elasticsearch-cdm-mkkdys93-1:
Last Transition Time: 2019-06-26T03:37:32Z
Message: 0/5 nodes are available: 5 node(s) didn't match node selector.
Reason: Unschedulable
Status: True
Type: Unschedulable
elasticsearch-cdm-mkkdys93-2:
Node Count: 2
Pods:
Client:
Failed:
Not Ready:
elasticsearch-cdm-mkkdys93-1-75dd69dccd-f7f49
elasticsearch-cdm-mkkdys93-2-67c64f5f4c-n58vl
Ready:
Data:
Failed:
Not Ready:
elasticsearch-cdm-mkkdys93-1-75dd69dccd-f7f49
elasticsearch-cdm-mkkdys93-2-67c64f5f4c-n58vl
Ready:
Master:
Failed:
Not Ready:
elasticsearch-cdm-mkkdys93-1-75dd69dccd-f7f49
elasticsearch-cdm-mkkdys93-2-67c64f5f4c-n58vl
Ready:类似于以下内容的状态消息表示请求的 PVC 无法绑定到 PV：
Node Conditions:
elasticsearch-cdm-mkkdys93-1:
Last Transition Time: 2019-06-26T03:37:32Z
Message: pod has unbound immediate PersistentVolumeClaims (repeated 5 times)
Reason: Unschedulable
Status: True
Type: Unschedulable类似于以下内容的状态消息表示无法调度 Curator Pod，因为节点选择器与任何节点都不匹配：
Curation:
Curator Status:
Cluster Condition:
curator-1561518900-cjx8d:
Last Transition Time: 2019-06-26T03:20:08Z
Reason: Completed
Status: True
Type: ContainerTerminated
curator-1561519200-zqxxj:
Last Transition Time: 2019-06-26T03:20:01Z
Message: 0/5 nodes are available: 1 Insufficient cpu, 5 node(s) didn't match node selector.
Reason: Unschedulable
Status: True
Type: Unschedulable
Cron Jobs: curator
Schedules: */5 * * * *
Suspended: false类似于以下内容的状态消息表示无法调度 Fluentd Pod，因为节点选择器与任何节点都不匹配：
Status:
Collection:
Logs:
Fluentd Status:
Daemon Set: fluentd
Nodes:
Pods:
Failed:
Not Ready:
Ready:10.2. 查看集群日志记录组件的状态
您可以查看多个集群日志记录组件的状态。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
进入
openshift-logging项目。$ oc project openshift-logging
查看集群日志记录部署的状态：
$ oc describe deployment cluster-logging-operator
输出中包括以下状态信息：
Name: cluster-logging-operator .... Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable .... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 62m deployment-controller Scaled up replica set cluster-logging-operator-574b8987df to 1----
查看集群日志记录 ReplicaSet 的状态：
获取 ReplicaSet 的名称：
$ oc get replicaset NAME DESIRED CURRENT READY AGE cluster-logging-operator-574b8987df 1 1 1 159m elasticsearch-cdm-uhr537yu-1-6869694fb 1 1 1 157m elasticsearch-cdm-uhr537yu-2-857b6d676f 1 1 1 156m elasticsearch-cdm-uhr537yu-3-5b6fdd8cfd 1 1 1 155m kibana-5bd5544f87 1 1 1 157m
获取 ReplicaSet 的状态：
$ oc describe replicaset cluster-logging-operator-574b8987df
输出中包括以下状态信息：
Name: cluster-logging-operator-574b8987df .... Replicas: 1 current / 1 desired Pods Status: 1 Running / 0 Waiting / 0 Succeeded / 0 Failed .... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 66m replicaset-controller Created pod: cluster-logging-operator-574b8987df-qjhqv----
第 11 章 使用节点选择器移动集群日志记录资源
您可以使用节点选择器，将 Elasticsearch、Kibana 和 Curator Pod 部署到不同的节点上。
11.1. 移动集群日志记录资源
您可以配置 Cluster Logging Operator，以将任何或所有 Cluster Logging 组件、Elasticsearch、Kibana 和 Curator 的 Pod 部署到不同的节点上。您无法将 Cluster Logging Operator Pod 从其安装位置移走。
例如，您可以因为 CPU、内存和磁盘要求较高而将 Elasticsearch Pod 移到一个单独的节点上。
您应该将 MachineSet 设置为至少使用 6 个副本。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。默认情况下没有安装这些功能。
流程
编辑
openshift-logging项目中的集群日志记录自定义资源：$ oc edit ClusterLogging instance
apiVersion: logging.openshift.io/v1 kind: ClusterLogging .... spec: collection: logs: fluentd: resources: null type: fluentd curation: curator: nodeSelector: 1 node-role.kubernetes.io/infra: '' resources: null schedule: 30 3 * * * type: curator logStore: elasticsearch: nodeCount: 3 nodeSelector: 2 node-role.kubernetes.io/infra: '' redundancyPolicy: SingleRedundancy resources: limits: cpu: 500m memory: 16Gi requests: cpu: 500m memory: 16Gi storage: {} type: elasticsearch managementState: Managed visualization: kibana: nodeSelector: 3 node-role.kubernetes.io/infra: '' 4 proxy: resources: null replicas: 1 resources: null type: kibana ....
验证步骤
要验证组件是否已移动，您可以使用 oc get pod -o wide 命令。
例如：
您需要移动来自
ip-10-0-147-79.us-east-2.compute.internal节点上的 Kibana pod：$ oc get pod kibana-5b8bdf44f9-ccpq9 -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kibana-5b8bdf44f9-ccpq9 2/2 Running 0 27s 10.129.2.18 ip-10-0-147-79.us-east-2.compute.internal <none> <none>
您需要将 Kibana Pod 移到
ip-10-0-139-48.us-east-2.compute.internal节点，该节点是一个专用的基础架构节点：$ oc get nodes NAME STATUS ROLES AGE VERSION ip-10-0-133-216.us-east-2.compute.internal Ready master 60m v1.16.2 ip-10-0-139-146.us-east-2.compute.internal Ready master 60m v1.16.2 ip-10-0-139-192.us-east-2.compute.internal Ready worker 51m v1.16.2 ip-10-0-139-241.us-east-2.compute.internal Ready worker 51m v1.16.2 ip-10-0-147-79.us-east-2.compute.internal Ready worker 51m v1.16.2 ip-10-0-152-241.us-east-2.compute.internal Ready master 60m v1.16.2 ip-10-0-139-48.us-east-2.compute.internal Ready infra 51m v1.16.2
请注意，该节点具有
node-role.kubernetes.io/infra: "label:$ oc get node ip-10-0-139-48.us-east-2.compute.internal -o yaml kind: Node apiVersion: v1 metadata: name: ip-10-0-139-48.us-east-2.compute.internal selfLink: /api/v1/nodes/ip-10-0-139-48.us-east-2.compute.internal uid: 62038aa9-661f-41d7-ba93-b5f1b6ef8751 resourceVersion: '39083' creationTimestamp: '2020-04-13T19:07:55Z' labels: node-role.kubernetes.io/infra: '' ....要移动 Kibana Pod，请编辑集群日志记录 CR 以添加节点选择器：
apiVersion: logging.openshift.io/v1 kind: ClusterLogging .... spec: .... visualization: kibana: nodeSelector: 1 node-role.kubernetes.io/infra: '' 2 proxy: resources: null replicas: 1 resources: null type: kibana保存 CR 后，当前 Kibana Pod 将被终止，新的 Pod 会被部署：
$ oc get pods NAME READY STATUS RESTARTS AGE cluster-logging-operator-84d98649c4-zb9g7 1/1 Running 0 29m elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg 2/2 Running 0 28m elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj 2/2 Running 0 28m elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78 2/2 Running 0 28m fluentd-42dzz 1/1 Running 0 28m fluentd-d74rq 1/1 Running 0 28m fluentd-m5vr9 1/1 Running 0 28m fluentd-nkxl7 1/1 Running 0 28m fluentd-pdvqb 1/1 Running 0 28m fluentd-tflh6 1/1 Running 0 28m kibana-5b8bdf44f9-ccpq9 2/2 Terminating 0 4m11s kibana-7d85dcffc8-bfpfp 2/2 Running 0 33s
新 pod 位于
ip-10-0-139-48.us-east-2.compute.internal节点上 :$ oc get pod kibana-7d85dcffc8-bfpfp -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kibana-7d85dcffc8-bfpfp 2/2 Running 0 43s 10.131.0.22 ip-10-0-139-48.us-east-2.compute.internal <none> <none>
片刻后，原始 Kibana Pod 将被删除。
$ oc get pods NAME READY STATUS RESTARTS AGE cluster-logging-operator-84d98649c4-zb9g7 1/1 Running 0 30m elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg 2/2 Running 0 29m elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj 2/2 Running 0 29m elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78 2/2 Running 0 29m fluentd-42dzz 1/1 Running 0 29m fluentd-d74rq 1/1 Running 0 29m fluentd-m5vr9 1/1 Running 0 29m fluentd-nkxl7 1/1 Running 0 29m fluentd-pdvqb 1/1 Running 0 29m fluentd-tflh6 1/1 Running 0 29m kibana-7d85dcffc8-bfpfp 2/2 Running 0 62s
第 12 章 手动滚动部署 Elasticsearch
OpenShift Container Platform 支持 Elasticsearch 集群滚动重启。滚动重启可以在不需要 Elasticsearch 集群下线的情况下，将适用的更改应用到 Elasticsearch 集群（这需要已配置了三个 master）。Elasticsearch 集群保持联机和可运行状态，节点则逐一脱机。
12.1. 执行 Elasticsearch 集群滚动重启
在更改 elasticsearch ConfigMap 或任何 elasticsearch-* 部署配置时，执行滚动重启。
此外，如果运行 Elasticsearch Pod 的节点需要重启，则建议滚动重启。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
执行集群滚动重启：
进入
openshift-logging项目：$ oc project openshift-logging
使用以下命令，从 Elasticsearch 提取 CA 证书并写入到 admin-ca 文件：
$ oc extract secret/elasticsearch --to=. --keys=admin-ca admin-ca
执行分片同步刷新，确保在关机之前没有等待写入磁盘的待定操作：
$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- curl -s --cacert /etc/elasticsearch/secret/admin-ca --cert /etc/elasticsearch/secret/admin-cert --key /etc/elasticsearch/secret/admin-key -XPOST 'https://localhost:9200/_flush/synced'
例如：
oc exec -c elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -- curl -s --cacert /etc/elasticsearch/secret/admin-ca --cert /etc/elasticsearch/secret/admin-cert --key /etc/elasticsearch/secret/admin-key -XPOST 'https://localhost:9200/_flush/synced'
使用 OpenShift Container Platform es_util 工具防止在有意关闭节点时进行分片平衡：
$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/settings -XPUT 'https://localhost:9200/_cluster/settings' -d '{ "transient": { "cluster.routing.allocation.enable" : "none" } }'例如：
$ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/settings?pretty=true -XPUT 'https://localhost:9200/_cluster/settings' -d '{ "transient": { "cluster.routing.allocation.enable" : "none" } }' { "acknowledged" : true, "persistent" : { }, "transient" : { "cluster" : { "routing" : { "allocation" : { "enable" : "none" } } } }完成后，会在每个部署中都有一个 ES 集群：
默认情况下，OpenShift Container Platform Elasticsearch 集群会阻止向其节点推出部署。使用以下命令来允许推出部署并允许 Pod 获取更改：
$ oc rollout resume deployment/<deployment-name>
例如：
$ oc rollout resume deployment/elasticsearch-cdm-0-1 deployment.extensions/elasticsearch-cdm-0-1 resumed
部署了一个新 Pod。当 Pod 具有就绪的容器后，就能继续进行下一部署。
$ oc get pods | grep elasticsearch-* NAME READY STATUS RESTARTS AGE elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6k 2/2 Running 0 22h elasticsearch-cdm-5ceex6ts-2-f799564cb-l9mj7 2/2 Running 0 22h elasticsearch-cdm-5ceex6ts-3-585968dc68-k7kjr 2/2 Running 0 22h
完成后，重置 Pod 以禁止推出部署：
$ oc rollout pause deployment/<deployment-name>
例如：
$ oc rollout pause deployment/elasticsearch-cdm-0-1 deployment.extensions/elasticsearch-cdm-0-1 paused
检查 Elasticsearch 集群是否处于
green状态：$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/health?pretty=true
注意如果您对先前命令中使用的 Elasticsearch Pod 执行了推出部署，该 Pod 将不再存在，并且此处需要使用新的 Pod 名称。
例如：
$ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/health?pretty=true { "cluster_name" : "elasticsearch", "status" : "green", 1 "timed_out" : false, "number_of_nodes" : 3, "number_of_data_nodes" : 3, "active_primary_shards" : 8, "active_shards" : 16, "relocating_shards" : 0, "initializing_shards" : 0, "unassigned_shards" : 1, "delayed_unassigned_shards" : 0, "number_of_pending_tasks" : 0, "number_of_in_flight_fetch" : 0, "task_max_waiting_in_queue_millis" : 0, "active_shards_percent_as_number" : 100.0 }- 1
- 在继续操作之前，请确保此参数为
green。
- 如果更改了 Elasticsearch 配置映射，请对每个 Elasticsearch Pod 重复这些步骤。
推出集群的所有部署后，重新启用分片平衡：
$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/settings -XPUT 'https://localhost:9200/_cluster/settings' -d '{ "transient": { "cluster.routing.allocation.enable" : "none" } }'例如：
$ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/settings?pretty=true -XPUT 'https://localhost:9200/_cluster/settings' -d '{ "transient": { "cluster.routing.allocation.enable" : "all" } }' { "acknowledged" : true, "persistent" : { }, "transient" : { "cluster" : { "routing" : { "allocation" : { "enable" : "all" } } } } }
第 13 章 Kibana 故障排除
将 Kibana 控制台与 OpenShift Container Platform 搭配使用可能导致一些问题。这些问题容易解决，但在出现问题时没有提供有用的错误消息。如果在 OpenShift Container Platform 中部署 Kibana 时遇到任何问题，请检查以下故障排除章节。
13.1. Kubernetes 登录循环故障排除
Kibana 控制台上的 OAuth2 代理必须与 master 主机的 OAuth2 服务器共享一个 secret。如果两台服务器上的 secret 不相同，则可能导致登录循环，造成您不断重定向到 Kibana 登录页面。
流程
解决此问题的步骤：
运行以下命令以删除当前的 OAuthClient：
$ oc delete oauthclient/kibana-proxy
13.2. 排查查看 Kibana 控制台时的 Kubernetes 密码错误
尝试访问 Kibana 控制台时，您可能会收到浏览器错误：
{"error":"invalid_request","error_description":"The request is missing a required parameter,
includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed."}这可能是由 OAuth2 客户端与服务器之间不匹配造成的。客户端的返回地址必须在白名单中，这样服务器才能在登录后安全地重定向回此地址。
通过替换 OAuthClient 条目来解决此问题。
流程
替换 OAuthClient 条目：
运行以下命令以删除当前的 OAuthClient：
$ oc delete oauthclient/kibana-proxy
如果问题仍然存在，请检查您是否通过 OAuth 客户端中列出的 URL 来访问 Kibana。通过转发端口（例如 1443）而非标准的 443 HTTPS 端口访问 URL 可能会造成此问题。您可以通过编辑 OAuth 客户端来调整服务器白名单：
$ oc edit oauthclient/kibana-proxy
13.3. 排查查看 Kibana 控制台时的 Kubernetes 503 错误
如果在查看 Kibana 控制台时收到代理错误，原因可能是以下两个问题之一：
Kibana 可能无法识别 Pod。如果 Elasticsearch 启动缓慢，则 Kibana 可能会在尝试访问它时超时。检查相关服务是否具有任何端点：
$ oc describe service kibana Name: kibana [...] Endpoints: <none>
如果有任何 Kibana Pod 处于活动状态，则会列出端点。如果没有，请检查 Kibana Pod 和部署的状态。您可能需要缩减部署，然后再次备份。
用于访问 Kibana 服务的路由已被屏蔽。如果您在一个项目中执行测试部署，然后在另一项目中进行部署，但没有彻底删除第一个部署，可能会发生这种情况。当多个路由发送到同一目的地时，默认路由器将仅路由到最先创建的路由。检查有问题的路由，以查看是否在多个位置定义了该路由：
$ oc get route --all-namespaces --selector logging-infra=support
第 14 章 导出字段
这些字段由日志记录系统导出，可从 Elasticsearch 和 Kibana 搜索。在搜索时，请使用完整的带句点字段名称。例如，对于 Elasticsearch /_search URL，若要查找 Kubernetes Pod 名称，请使用 /_search/q=kubernetes.pod_name:name-of-my-pod。
以下小节中描述的字段可能不出现在您的日志记录存储中。并非所有这些字段都会出现在每条记录中。这些字段划分为如下类别：
-
exported-fields-Default -
exported-fields-systemd -
exported-fields-kubernetes -
exported-fields-pipeline_metadata -
exported-fields-ovirt -
exported-fields-aushape -
exported-fields-tlog
14.1. 默认导出的字段
这些默认字段由日志记录系统导出，Elasticsearch 和 Kibana 可从对它们进行搜索。默认字段是顶级字段和 collectd* 字段
顶级字段
顶级字段对于每个应用程序都是通用的，并且可能会出现在每条记录中。对于 Elasticsearch 模板，顶级字段在模板的映射部分中填充 default 的实际映射。
| 参数 | 描述 |
|---|---|
|
|
此 UTC 值标记日志有效负载的创建时间，如果创建时间未知，则标记首次收集日志有效负载的时间。这是日志处理管道尽力确定何时生成日志有效负载的方法。添加 |
|
| 这是机器的 geo-ip。 |
|
|
|
|
| 源服务器的 IPv4 地址，可以是数组。 |
|
| 源服务器的 IPv6 地址（若有）。 |
|
|
由 python 的日志记录模块 rsyslog（severitytext 属性）提供的日志记录级别。
.只有在日志记录系统获取了不理解的值时，才应使用
通常可以使用 misc/sys/syslog.h 上列出的优先级值来映射 其他日志记录系统的日志级别和优先级应映射到最接近的匹配项。请参阅python 日志记录中的示例。 |
|
| 典型的日志条目消息或有效负载。可以从中剥离由收集器或规范化程序提取的元数据，这些元数据采用 UTF-8 编码。 |
|
| 这是日志记录实体（若有）的进程 ID。 |
|
|
与日志记录实体（若有）关联的服务的名称。例如， |
|
| （可选）由 Operator 定义的标签的列表，这些标签由收集器或规范化程序放置在每个日志上。有效负载可以是含有空格分隔字符串令牌的字符串，也可以是字符串令牌的 JSON 列表。 |
|
|
文件的可选路径，该文件包含对文件路径的收集器 |
|
| 偏移值可以表示文件中日志行开头的字节数（从零或一算起），或者表示日志行号（从零或一算起），只要这些值在单个日志的上下文中严格单调递增。允许对这些值换行，以表示日志文件的新版本（轮转）。 |
|
|
将这条记录与共享其名称的 |
|
|
与 |
collectd 字段
以下字段代表命名空间指标元数据。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：字符串
|
|
| 类型：字符串
|
|
| 类型：字符串
|
|
| 类型：字符串
|
|
| 类型：字符串
|
collectd.processes 字段。
以下字段对应于 collectd 进程插件。
| 参数 | 描述 |
|---|---|
|
|
类型：整数。 |
collectd.processes.ps_disk_ops 字段
collectd ps_disk_ops 型进程插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
collectd.processes.ps_cputime 字段
collectd ps_cputime 型进程插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.processes.ps_count 字段
collectd ps_count 型进程插件。
| 参数 | 描述 |
|---|---|
|
| 类型：整数
|
|
| 类型：整数
|
collectd.processes.ps_pagefaults 字段
collectd ps_pagefaults 型进程插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.processes.ps_disk_octets 字段
collectd ps_disk_octets 型进程插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.disk 字段
对应于 collectd 磁盘插件。
collectd.disk.disk_merged 字段
collectd disk_merged 型磁盘插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.disk.disk_octets 字段
collectd disk_octets 型磁盘插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.disk.disk_time 字段
collectd disk_time 型磁盘插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.disk.disk_ops 字段
collectd disk_ops 型磁盘插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
|
| 类型：整数
|
collectd.disk.disk_io_time 字段
collectd disk_io_time 型磁盘插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.interface 字段
对应于 collectd 接口插件。
collectd.interface.if_octets 字段
collectd if_octets 型接口插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.interface.if_packets 字段
collectd if_packets 型接口插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.interface.if_errors 字段
collectd if_errors 型接口插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.interface.if_dropped 字段
collectd if_dropped 型接口插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.virt 字段
对应于 collectd virt 插件。
collectd.virt.if_octets 字段
collectd if_octets 型 virt 插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.virt.if_packets 字段
collectd if_packets 型 virt 插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.virt.if_errors 字段
collectd if_errors 型 virt 插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.virt.if_dropped 字段
collectd if_dropped 型 virt 插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.virt.disk_ops 字段
collectd disk_ops 型 virt 插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.virt.disk_octets 字段
collectd disk_octets 型 virt 插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.CPU 字段
对应于 collectd CPU 插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
collectd.df 字段
对应于 collectd df 插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.entropy 字段
对应于 collectd 熵插件。
| 参数 | 描述 |
|---|---|
|
| 类型：整数
|
collectd.memory 字段
对应于 collectd 内存插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.swap 字段
对应于 collectd 交换插件。
| 参数 | 描述 |
|---|---|
|
| 类型：整数
|
|
| 类型：整数
|
collectd.load 字段
对应于 collectd 负载插件。
collectd.load.load 字段
collectd 负载型负载插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
|
| 类型：浮点数
|
collectd.aggregation 字段
对应于 collectd 聚合插件。
| 参数 | 描述 |
|---|---|
|
| 类型：浮点数
|
collectd.statsd 字段
对应于 collectd statsd 插件。
| 参数 | 描述 |
|---|---|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
collectd.postgresql 字段
对应于 collectd postgresql 插件。
| 参数 | 描述 |
|---|---|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
|
| 类型：整数
|
14.2. systemd 导出字段
以下 systemd 字段由 OpenShift Container Platform 集群日志记录导出，可从 Elasticsearch 和 Kibana 搜索。
包括特定于 systemd 系统日志的常用字段。应用程序可能会向系统日志写入自己的字段。这些字段在 systemd.u 命名空间下提供。RESULT 和 UNIT 就是这样的两个字段。
systemd.k 字段
下表包含 systemd 内核相关的元数据。
| 参数 | 描述 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
systemd.t 字段
systemd.t 字段是可信的系统日志字段，由系统日志隐式添加，无法通过客户端代码更改。
| 参数 | 描述 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
systemd.u 字段
systemd.u Fields 直接从客户端传递，并存入在系统日志中。
| 参数 | 描述 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 仅供私下使用。 |
|
| 仅供私下使用。 |
14.3. Kubernetes 导出字段
以下 Kubernetes 字段由 OpenShift Container Platform 集群日志记录导出，可从 Elasticsearch 和 Kibana 搜索。
特定于 Kubernetes 元数据的命名空间。kubernetes.pod_name 是 Pod 的名称。
kubernetes.labels 字段
附加至 OpenShift 对象的标签是 kubernetes.labels。每个标签名都是标签字段的子字段。每个标签名称都会进行去句点处理，即名称中的句点都被替换成下划线。
| 参数 | 描述 |
|---|---|
|
| Pod 的 Kubernetes ID。 |
|
| Kubernetes 中命名空间的名称。 |
|
| Kubernetes 中命名空间的 ID。 |
|
| Kubernetes 节点名称。 |
|
| Kubernetes 中容器的名称。 |
|
| 与 Kubernetes 对象关联的部署。 |
|
| 与 Kubernetes 对象关联的部署配置。 |
|
| 与 Kubernetes 对象关联的组件。 |
|
| 与 Kubernetes 对象关联的提供程序。 |
kubernetes.annotations 字段
与 OpenShift 对象关联的注解是 kubernetes.annotations 字段。
14.4. 容器导出字段
以下 Docker 字段由 OpenShift Container Platform 集群日志记录导出，可被 Elasticsearch 和 Kibana 搜索。特定于 docker 容器的元数据的命名空间。docker.container_id 是 Docker 容器 ID。
pipeline_metadata.collector 字段
本节包含与收集器相关的元数据。
| 参数 | 描述 |
|---|---|
|
| 收集器的 FQDN。可能与日志的实际发出者的 FQDN 不同。 |
|
| 收集器的名称。 |
|
| 收集器的版本。 |
|
| 收集器服务器的 IPv4 地址，可以是一个数组。 |
|
| 收集器服务器的 IPv6 地址，可以是一个数组。 |
|
| 收集器接收日志消息的方式，可以是 TCP/UDP 或 imjournal/imfile。 |
|
| 收集器收到消息的时间。 |
|
| 原始的未解析日志消息，由收集器收集或者尽可能与源接近。 |
pipeline_metadata.normalizer 字段
本节包含与规范化程序相关的元数据。
| 参数 | 描述 |
|---|---|
|
| 规范化程序的 FQDN。 |
|
| 规范化程序的名称。 |
|
| 规范化程序的版本。 |
|
| 规范化程序服务器的 IPv4 地址，可以是数组。 |
|
| 规范化程序服务器的 IPv6 地址，可以是数组。 |
|
| 规范化程序接收日志消息的方式，可以是 TCP/UDP。 |
|
| 规范化程序收到消息的时间。 |
|
| 原始的未解析日志消息，与规范化程序收到的一致。 |
|
| 该字段记录消息的轨迹。每个收集器和规范化程序都会附加关于自身的信息，以及处理消息的日期和时间。 |
14.5. oVirt 导出字段
以下 oVirt 字段由 OpenShift Container Platform 集群日志记录导出，可从 Elasticsearch 和 Kibana 搜索。
oVirt 元数据的命名空间。
| 参数 | 描述 |
|---|---|
|
| 数据源、主机、VMS 和引擎的类型。 |
|
| oVirt 主机 UUID。 |
ovirt.engine 字段
oVirt 引擎相关元数据的命名空间。oVirt 引擎的 FQDN 是 ovirt.engine.fqdn
14.6. Aushape 导出字段
以下 Aushape 字段由 OpenShift Container Platform 集群日志记录导出，可从 Elasticsearch 和 Kibana 搜索。
通过 Aushape 转换的审计事件。如需更多信息，请参阅 Aushape。
| 参数 | 描述 |
|---|---|
|
| 审计事件序列号。 |
|
| 发生审计事件的主机的名称。 |
|
| 在转换事件时 Aushape 遇到的错误。 |
|
| 相对于事件对象的 JSONPath 表达式的数组，用于指定因为事件大小限制而删除了内容的对象或数组。空字符串表示事件删除了内容，空数组表示裁剪是由未指定的对象和数组造成的。 |
|
| 代表原始审计事件的一组日志记录字符串。 |
aushape.data 字段
与 Aushape 相关的已解析审计事件数据。
| 参数 | 描述 |
|---|---|
|
| 类型：嵌套 |
|
| 类型：字符串 |
|
| 类型：嵌套 |
|
| 类型：嵌套 |
|
| 类型：嵌套 |
14.7. Tlog 导出字段
以下 Tlog 字段由 OpenShift Container Platform 集群日志记录系统导出，可从 Elasticsearch 和 Kibana 搜索。
记录消息的 Tlog 终端 I/O。如需更多信息，请参阅 Tlog。
| 参数 | 描述 |
|---|---|
|
| 消息格式版本号。 |
|
| 记录的用户名。 |
|
| 终端类型名称。 |
|
| 所记录会话的审计会话 ID。 |
|
| 会话内消息的 ID。 |
|
| 消息在会话内的位置，以毫秒为单位。 |
|
| 此消息的事件的时间分布。 |
|
| 清理掉无效字符的输入文本。 |
|
| 清理掉的无效输入字符，以字节数为单位。 |
|
| 清理掉无效字符的输出文本。 |
|
| 清理掉的无效输出字符，以字节数为单位。 |
第 15 章 卸载集群日志记录
您可以从 OpenShift Container Platform 集群中移除集群日志记录。
15.1. 从 OpenShift Container Platform 卸载集群日志记录
您可以从集群中移除集群日志记录。
先决条件
- 必须安装 Cluster Logging 和 Elasticsearch。
流程
移除集群日志记录：
使用以下命令，移除部署期间生成的一切内容。
$ oc delete clusterlogging instance -n openshift-logging
使用以下命令，删除 Operator 实例已被删除后保留的持久性卷声明（PVC）：
$ oc delete pvc --all -n openshift-logging
