|
chunkLimitSize
每个块的最大值。当数据达到这个大小时，Fluentd 会停止将数据写入一个块。然后，Fluentd 将块发送到队列并打开一个新的块。
totalLimitSize
缓冲区的最大大小，即阶段（stage）和队列（stage）的总大小。如果缓冲区的大小超过这个值，Fluentd 会停止将数据添加到块，并显示错误失败。所有不在块中的数据都丢失。
flushInterval
块清除之间的间隔。您可以使用
s
（秒）、
m
（分钟）、
h
（小时）或
d
（天）。
flushMode
执行清除的方法：
lazy
:基于
timekey
参数对块进行清理。您无法修改
timekey
参数。
interval
：基于
flushInterval
参数清理块。
Immediate
: 在将数据添加到一个块后马上清理块。
interval
flushThreadCount
执行块清除（flushing）的线程数量。增加线程数量可提高冲刷吞吐量，这会隐藏网络延迟的情况。
overflowAction
当队列满时块的行为：
throw_exception
：发出一个异常并在日志中显示。
block
：停止对数据进行块除了，直到缓冲区已用完的问题被解决为止。
drop_oldest_chunk
：删除旧的块以接受新传入的块。旧块的价值比新块要小。
block
retryMaxInterval
exponential_backoff
重试方法的最大时间（以秒为单位）。
retryType
flushing 失败时重试的方法：
exponential_backoff
：增加每次重新清理操作的间隔时间。Fluentd 会加倍到下一次重试需要等待的时间，直到达到
retry_max_interval
参数指定的值。
periodic
：基于
retryWait
参数，定期重试清理操作。
exponential_backoff
retryWait
下一次块清除前的时间（以秒为单位）。
如需有关 Fluentd 块生命周期的更多信息，请参阅
Fluentd 文档
中的缓冲插件。
编辑
openshift-logging
项目中的
ClusterLogging
自定义资源（CR）：
$ oc edit ClusterLogging instance
添加或修改以下任何参数：
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
name: instance
namespace: openshift-logging
spec:
forwarder:
fluentd:
buffer:
chunkLimitSize: 8m 1
flushInterval: 5s 2
flushMode: interval 3
flushThreadCount: 3 4
overflowAction: throw_exception 5
retryMaxInterval: "300s" 6
retryType: periodic 7
retryWait: 1s 8
totalLimitSize: 32m 9
...
-
1
-
请指定每个块在排队进行清除前的最大大小。
指定块清除之间间隔。
指定执行块清除的方法：
lazy
、
interval
或
immediate
。
指定用于块清除的线程数量。
指定当队列满时的块行为：
throw_exception
、
block
或
drop_oldest_chunk
。
指定使用
exponential_backoff
块清理方法时的最大间隔时间（以秒为单位）。
指定当块清除失败时重试的类型：
exponential_backoff
或
periodic
。
指定下一次块清除前的时间（以秒为单位）。
指定块缓冲区的最大大小。
验证 Fluentd Pod 是否已重新部署：
$ oc get pods -n openshift-logging
检查
fluentd
配置映射中的新值：
$ oc extract configmap/fluentd --confirm
4.2.5. 如果不使用默认的 Elasticsearch 日志存储，请删除未使用的组件
作为管理员，在非常罕见的情况下，当您将日志转发到第三方日志存储且不使用默认的 Elasticsearch 存储时，您可以从日志集群中移除几个未使用的组件。
换句话说，如果没有使用默认的 Elasticsearch 日志存储，您可以从
ClusterLogging
自定义资源 (CR) 中删除内部 Elasticsearch
logStore
和 Kibana
visualization
组件。删除这些组件是可选的，但会保存资源。
验证您的日志转发程序没有将日志数据发送到默认的内部 Elasticsearch 集群。检查您用来配置日志转发的
ClusterLogForwarder
CR YAML 文件。验证它
没有
指定
default
的
outputRefs
元素。例如：
outputRefs:
- default
假定
ClusterLogForwarder
CR 将日志数据转发到内部 Elasticsearch 集群，并从
ClusterLogging
CR 中删除
logStore
组件。在这种情况下，内部 Elasticsearch 集群将不存在来存储日志数据。这会导致数据丢失。
编辑
openshift-logging
项目中的
ClusterLogging
自定义资源（CR）：
$ oc edit ClusterLogging instance
如果存在，请从
ClusterLogging
CR 中删除
logStore
和
visualization
小节。
保留
ClusterLogging
CR 的
collection
小节。结果应类似以下示例：
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
name: "instance"
namespace: "openshift-logging"
spec:
managementState: "Managed"
collection:
logs:
type: "fluentd"
fluentd: {}
验证 Fluentd Pod 是否已重新部署：
$ oc get pods -n openshift-logging
OpenShift Container Platform 使用 Elasticsearch 6（ES）来存储和整理日志数据。
您可以修改日志存储，包括：
Elasticsearch 集群的存储
在集群中的数据节点间复制分片，从完整复制到不复制
外部访问 Elasticsearch 数据
Elasticsearch 是内存密集型应用程序。每个 Elasticsearch 节点都需要至少 16G 内存来满足内存请求和限值的需要，除非
ClusterLogging
自定义资源中另有指定。最初的 OpenShift Container Platform 节点组可能不足以支持 Elasticsearch 集群。您必须在 OpenShift Container Platform 集群中添加额外的节点才能使用推荐或更高的内存运行，每个 Elasticsearch 节点最多可使用 64G 个内存。
每个 Elasticsearch 节点都可以在较低的内存设置下运行，但在生产环境中不建议这样做。
默认情况下，OpenShift Logging 不会将审计日志存储在内部 OpenShift Container Platform Elasticsearch 日志存储中。您可以将审计日志发送到此日志存储，例如，您可以在 Kibana 中查看它们。
要将审计日志发送到默认的内部 Elasticsearch 日志存储，例如要在 Kibana 中查看审计日志，您必须使用 Log Forwarding API。
内部 OpenShift Container Platform Elasticsearch 日志存储不为审计日志提供安全存储。验证您转发审计日志的系统是否符合您的机构和政府法规，并获得适当的保护。OpenShift Logging 不遵循这些规范。
使用 Log Forward API 将审计日志转发到内部 Elasticsearch 实例：
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件：
创建 CR 以将所有日志类型发送到内部 Elasticsearch 实例。您可以在不进行任何更改的情况下使用以下示例：
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
name: instance
namespace: openshift-logging
spec:
pipelines: 1
- name: all-to-default
inputRefs:
- infrastructure
- application
- audit
outputRefs:
- default
-
1
-
管道（pipeline）定义使用指定输出转发的日志类型。默认输出将日志转发到内部 Elasticsearch 实例。
您必须在管道中指定所有三种类型的日志：应用程序、基础架构和审核。如果没有指定日志类型，这些日志将不会被存储并丢失。
如果您有一个现有的
ClusterLogForwarder
CR，请将管道添加到审计日志的默认输出中。您不需要定义默认输出。例如：
apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
name: instance
namespace: openshift-logging
spec:
outputs:
- name: elasticsearch-insecure
type: "elasticsearch"
url: http://elasticsearch-insecure.messaging.svc.cluster.local
insecure: true
- name: elasticsearch-secure
type: "elasticsearch"
url: https://elasticsearch-secure.messaging.svc.cluster.local
secret:
name: es-audit
- name: secureforward-offcluster
type: "fluentdForward"
url: https://secureforward.offcluster.com:24224
secret:
name: secureforward
pipelines:
- name: container-logs
inputRefs:
- application
outputRefs:
- secureforward-offcluster
- name: infra-logs
inputRefs:
- infrastructure
outputRefs:
- elasticsearch-insecure
- name: audit-logs
inputRefs:
- audit
outputRefs:
- elasticsearch-secure
- default 1
您可以配置
保留策略
，指定默认 Elasticsearch 日志存储保留三个日志源的索引的时长：基础架构日志、应用程序日志和审计日志。
要配置保留策略，您需要为
ClusterLogging
自定义资源 (CR) 中的每个日志源设置
maxAge
参数。CR 将这些值应用到 Elasticsearch 滚动调度，它决定 Elasticsearch 何时删除滚动索引。
如果索引与以下条件之一匹配，Elasticsearch 会滚动索引，移动当前的索引并创建新索引：
索引早于
Elasticsearch
CR 中的
rollover.maxAge
值。
索引大小超过主分片数乘以 40GB 的值。
索引的 doc 数大于主分片数乘以 40960 KB 的值。
Elasticsearch 会根据您配置的保留策略删除滚动索引。如果您没有为任何日志源创建保留策略，则默认在 7 天后删除日志。
必须安装 OpenShift Logging 和 OpenShift Elasticsearch Operator。
配置日志保留时间：
编辑
ClusterLogging
CR，以添加或修改
reservedPolicy
参数：
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
spec:
managementState: "Managed"
logStore:
type: "elasticsearch"
retentionPolicy: 1
application:
maxAge: 1d
infra:
maxAge: 7d
audit:
maxAge: 7d
elasticsearch:
nodeCount: 3
...
-
1
-
指定 Elasticsearch 应该保留每个日志源的时间。输入一个整数和时间单位： 周(w)、小时(h/H)、分钟(m)和秒。例如，
1d
代表一天。时间超过
maxAge
的旧日志会被删除。默认情况下，日志会保留 7 天。
您可以验证
Elasticsearch
自定义资源（CR）中的设置。
例如，Red Hat OpenShift Logging Operator 更新了以下
Elasticsearch
CR 以配置保留策略，包括设置以每八小时滚动基础架构日志的活跃索引，并在滚动后 7 天删除滚动的索引。OpenShift Container Platform 每 15 分钟检查一次，以确定是否需要滚动索引。
apiVersion: "logging.openshift.io/v1"
kind: "Elasticsearch"
metadata:
name: "elasticsearch"
spec:
indexManagement:
policies: 1
- name: infra-policy
phases:
delete:
minAge: 7d 2
actions:
rollover:
maxAge: 8h 3
pollInterval: 15m 4
...
-
1
-
对于每个日志源，保留策略代表何时删除和滚动该源的日志。
什么时候 OpenShift Container Platform 删除滚动索引。此设置是在
ClusterLogging
CR 中设置的
maxAge
。
当滚动索引时，OpenShift Container Platform 需要考虑的索引年龄。此值由
ClusterLogging
CR 中的
maxAge
决定。
OpenShift Container Platform 什么时候检查应该检查滚动索引。这是默认设置，不可更改。
不支持修改
Elasticsearch
CR。对保留策略的所有更改都必须在
ClusterLogging
CR 中进行。
OpenShift Elasticsearch Operator 部署 cron job，以使用定义的策略为每个映射滚动索引,并使用
pollInterval
调度。
$ oc get cronjob
每个组件规格都允许调整 CPU 和内存请求。您不应该手动调整这些值，因为 OpenShift Elasticsearch Operator 会设置适当的值以满足环境的要求。
在大型集群中，Elasticsearch 代理容器的默认内存限值可能不足，从而导致代理容器被 OOMKilled。如果您遇到这个问题，请提高 Elasticsearch 代理的内存请求和限值。
每个 Elasticsearch 节点都可以在较低的内存设置下运行，但在生产部署中
不建议
这样做。对于生产环境，为每个 pod 应该分配的数量应不少于默认的 16Gi。最好为每个 pod 分配不超过 64Gi 的尽量多的数量。
必须安装 OpenShift Logging 和 Elasticsearch。
编辑
openshift-logging
项目中的
ClusterLogging
自定义资源（CR）：
$ oc edit ClusterLogging instance
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
name: "instance"
spec:
logStore:
type: "elasticsearch"
elasticsearch:1
resources:
limits: 2
memory: "32Gi"
requests: 3
cpu: "1"
memory: "16Gi"
proxy: 4
resources:
limits:
memory: 100Mi
requests:
memory: 100Mi
-
1
-
根据需要指定 Elasticsearch 的 CPU 和内存请求。如果这些值留白，则 OpenShift Elasticsearch Operator 会设置默认值，它们应足以满足大多数部署的需要。内存请求的默认值为
16Gi
，CPU 请求为
1
。
pod 可以使用的最大资源量。
调度 pod 所需的最小资源。
根据需要指定 Elasticsearch 代理的 CPU 和内存请求。如果这些值留白，则 OpenShift Elasticsearch Operator 会设置默认值，它们应足以满足大多数部署的需要。内存请求的默认值为
256Mi
，CPU 请求的默认值为
100m
。
在调整 Elasticsearch 内存量时，相同的值应该用于
请求
和
限值
。
resources:
limits: 1
memory: "32Gi"
requests: 2
cpu: "8"
memory: "32Gi"
-
1
-
资源的最大数量。
最低要求。
Kubernetes 一般遵循节点配置，不允许 Elasticsearch 使用指定的限值。为
请求（request）
和
限值（limit）
设置相同的值可确保 Elasticsearch 可以使用您想要的内存，假设节点具有可用内存。
您可以定义如何在集群中的数据节点之间复制 Elasticsearch 分片：
必须安装 OpenShift Logging 和 Elasticsearch。
编辑
openshift-logging
项目中的
ClusterLogging
自定义资源（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 数据节点的数目。
4.3.5. 缩减 Elasticsearch pod
减少集群中的 Elasticsearch pod 数量可能会导致数据丢失或 Elasticsearch 性能下降。
如果缩减，应该一次缩减一个 pod，并允许集群重新平衡分片和副本。Elasticsearch 健康状态返回
绿色
后，您可以根据另一个 pod 进行缩减。
如果 Elasticsearch 集群设置为
ZeroRedundancy
，则不应缩减 Elasticsearch pod。
Elasticsearch 需要持久性存储。存储速度越快，Elasticsearch 性能越高。
在 Elasticsearch 存储中不支持将 NFS 存储用作卷或持久性卷（或者通过 NAS 比如 Gluster），因为 Lucene 依赖于 NFS 不提供的文件系统行为。数据崩溃和其他问题可能会发生。
必须安装 OpenShift Logging 和 Elasticsearch。
编辑
ClusterLogging
CR，将集群中的每个数据节点指定为绑定到持久性卷声明。
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。
如果将本地卷用于持久性存储，请不要使用原始块卷，这在
LocalVolume
对象中的
volumeMode: block
描述。Elasticsearch 无法使用原始块卷。
4.3.7. 为 emptyDir 存储配置日志存储
您可以将 emptyDir 与 日志存储搭配使用来创建一个临时部署，临时部署一旦重启其中所有 Pod 的数据都会丢失。
使用 emptyDir 时，如果重启或重新部署日志存储，数据将会丢失。
必须安装 OpenShift Logging 和 Elasticsearch。
编辑
ClusterLogging
CR 以指定 emptyDir:
spec:
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 3
storage: {}
4.3.8. 执行 Elasticsearch 集群滚动重启
在更改
elasticsearch
配置映射或任何
elasticsearch-*
部署配置时，执行滚动重启。
此外，如果运行 Elasticsearch Pod 的节点需要重启，则建议滚动重启。
必须安装 OpenShift Logging 和 Elasticsearch。
执行集群滚动重启：
进入
openshift-logging
项目：
$ oc project openshift-logging
获取 Elasticsearch Pod 的名称：
$ oc get pods | grep elasticsearch-
缩减 Fluentd pod，以便它们停止向 Elasticsearch 发送新日志：
$ oc -n openshift-logging patch daemonset/logging-fluentd -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-fluentd": "false"}}}}}'
使用 OpenShift Container Platform
es_util
工具执行分片同步刷新，确保在关机之前没有等待写入磁盘的待定操作：
$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_flush/synced" -XPOST
$ oc exec -c elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_flush/synced" -XPOST
默认情况下，无法从日志记录集群外部访问部署了 OpenShift Logging 的日志存储。您可以启用一个 re-encryption termination 模式的路由，以实现外部对日志存储服务的访问来获取数据。
另外，还可以在外部创建一个重新加密路由，使用 OpenShift Container Platform 令牌和已安装的 Elasticsearch CA 证书以从外部访问日志存储。然后，使用包含以下内容的 cURL 请求访问托管日志存储服务的节点：
Authorization: Bearer ${token}
Elasticsearch 重新加密路由和
Elasticsearch API 请求
。
在内部，可以使用日志存储集群 IP 访问日志存储服务。您可以使用以下命令之一获取它：
$ oc get service elasticsearch -o jsonpath={.spec.clusterIP} -n openshift-logging
$ oc get service elasticsearch -n openshift-logging
OpenShift Container Platform 使用 Kibana 显示 OpenShift Logging 收集的日志数据。
您可以扩展 Kibana 来实现冗余性，并为 Kibana 节点配置 CPU 和内存。
OpenShift Logging 组件允许对 CPU 和内存限值进行调整。
编辑
openshift-logging
项目中的
ClusterLogging
自定义资源（CR）：
$ oc -n openshift-logging edit ClusterLogging instance
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
name: "instance"
namespace: openshift-logging
spec:
managementState: "Managed"
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 3
resources: 1
limits:
memory: 16Gi
requests:
cpu: 200m
memory: 16Gi
storage:
storageClassName: "gp2"
size: "200G"
redundancyPolicy: "SingleRedundancy"
visualization:
type: "kibana"
kibana:
resources: 2
limits:
memory: 1Gi
requests:
cpu: 500m
memory: 1Gi
proxy:
resources: 3
limits:
memory: 100Mi
requests:
cpu: 100m
memory: 100Mi
replicas: 2
collection:
logs:
type: "fluentd"
fluentd:
resources: 4
limits:
memory: 736Mi
requests:
cpu: 200m
memory: 736Mi
-
1
-
根据需要指定日志存储的 CPU 和内存限值及请求。对于 Elasticsearch，您必须调整请求值和限制值。
根据需要为日志 visualizer 指定 CPU 和内存限值和请求。
根据需要指定日志收集器的 CPU 和内存限值及请求。
您可以扩展托管日志视觉化器的 pod 以增加它的冗余性。
编辑
openshift-logging
项目中的
ClusterLogging
自定义资源（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
4.5. 配置 OpenShift Logging 存储
Elasticsearch 是内存密集型应用程序。默认 OpenShift Logging 安装为内存请求和内存限值部署 16G 内存。最初的 OpenShift Container Platform 节点组可能不足以支持 Elasticsearch 集群。您必须在 OpenShift Container Platform 集群中添加额外的节点，才能使用建议或更高的内存来运行。每个 Elasticsearch 节点都可以在较低的内存设置下运行，但在生产环境中不建议这样做。
4.5.1. OpenShift Logging 和 OpenShift Container Platform 的存储注意事项
每个 Elasticsearch 部署配置都需要一个持久性卷。在 OpenShift Container Platform 中，这可以使用 PVC 来实现。
如果将本地卷用于持久性存储，请不要使用原始块卷，这在
LocalVolume
对象中的
volumeMode: block
描述。Elasticsearch 无法使用原始块卷。
OpenShift Elasticsearch Operator 使用 Elasticsearch 资源名称为 PVC 命名。
Fluentd 将
systemd journal
和
/var/log/containers/
的所有日志都传输到 Elasticsearch。
Elasticsearch 需要足够内存来执行大型合并操作。如果没有足够的内存，它将会变得无响应。要避免这个问题，请评估应用程序日志数据的数量，并分配大约两倍的可用存储容量。
默认情况下，当存储容量为 85% 满时，Elasticsearch 会停止向节点分配新数据。90% 时，Elasticsearch 会在可能的情况下将现有分片重新定位到其他节点。但是，如果存储消耗低于 85％ 时无节点有可用存储空间，Elasticsearch 会拒绝创建新索引并且变为 RED。
这些高、低水位线值是当前版本中的 Elasticsearch 默认值。您可以修改这些默认值。虽然警报使用相同的默认值，但无法在警报中更改这些值。
4.6. 为 OpenShift Logging 组件配置 CPU 和内存限值
您可以根据需要配置每个 OpenShift Logging 组件的 CPU 和内存限值。
OpenShift Logging 组件允许对 CPU 和内存限值进行调整。
编辑
openshift-logging
项目中的
ClusterLogging
自定义资源（CR）：
$ oc -n openshift-logging edit ClusterLogging instance
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
name: "instance"
namespace: openshift-logging
spec:
managementState: "Managed"
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 3
resources: 1
limits:
memory: 16Gi
requests:
cpu: 200m
memory: 16Gi
storage:
storageClassName: "gp2"
size: "200G"
redundancyPolicy: "SingleRedundancy"
visualization:
type: "kibana"
kibana:
resources: 2
limits:
memory: 1Gi
requests:
cpu: 500m
memory: 1Gi
proxy:
resources: 3
limits:
memory: 100Mi
requests:
cpu: 100m
memory: 100Mi
replicas: 2
collection:
logs:
type: "fluentd"
fluentd:
resources: 4
limits:
memory: 736Mi
requests:
cpu: 200m
memory: 736Mi
-
1
-
根据需要指定日志存储的 CPU 和内存限值及请求。对于 Elasticsearch，您必须调整请求值和限制值。
根据需要为日志 visualizer 指定 CPU 和内存限值和请求。
根据需要指定日志收集器的 CPU 和内存限值及请求。
4.7. 使用容忍度来控制 OpenShift Logging pod 放置
您可以使用污点和容限来确保 OpenShift Logging pod 在特定节点上运行，并确保其他工作负载不在这些节点上运行。
污点和容忍度是简单的
key:value
对。节点上的污点指示节点排斥所有不容许该污点的 pod。
key
是最长为 253 个字符的任意字符串，
value
则是最长为 63 个字符的任意字符串。字符串必须以字母或数字开头，并且可以包含字母、数字、连字符、句点和下划线。
4.7.1. 使用容忍度来控制日志存储 pod 放置
您可以通过在 pod 上使用容忍度来控制日志存储 pod 在哪些节点上运行，并防止其他工作负载使用这些节点。
您可以通过
ClusterLogging
自定义资源（CR）将容限应用到日志存储 pod,并通过节点规格将污点应用到节点。节点上的污点是一个
key:value
对，它指示节点排斥所有不容许该污点的 pod。通过使用不在其他 pod 上的特定
key:value
对，可以确保仅日志存储 pod 能够在该节点上运行。
默认情况下，日志存储 pod 具有以下容忍度：
tolerations:
- effect: "NoExecute"
key: "node.kubernetes.io/disk-pressure"
operator: "Exists"
先决条件
-
必须安装 OpenShift Logging 和 Elasticsearch。
使用以下命令，将污点添加到要在其上调度 OpenShift Logging 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。
编辑
ClusterLogging
CR 的
logstore
部分，以配置 Elasticsearch Pod 的容忍度：
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 1
tolerations:
- key: "elasticsearch" 1
operator: "Exists" 2
effect: "NoExecute" 3
tolerationSeconds: 6000 4
-
1
-
指定添加到节点的键。
指定
Exists
operator 需要节点上有一个带有键为
elasticsearch
的污点。
指定
NoExecute
效果。
（可选）指定
tolerationSeconds
参数，以设置 pod 在被逐出前可以保持绑定到节点的时长。
此容忍度与
oc adm taint
命令创建的污点匹配。具有此容忍度的 pod 可以调度到
node1
上。
4.7.2. 使用容忍度来控制日志可视化 pod 放置
您可以通过在 pod 上使用容忍度来控制 Curator pod 在哪些节点上运行，并防止其他工作负载使用这些节点。
您可以通过
ClusterLogging
自定义资源（CR）将容忍度应用到日志视觉化 pod，并通过节点规格将污点应用到节点。节点上的污点是一个
key:value
对，它指示节点排斥所有不容许该污点的 pod。通过使用没有在其他 Pod 上使用的特定
key:value
对，可以确保仅 Kibana Pod 能够在该节点上运行。
必须安装 OpenShift Logging 和 Elasticsearch。
使用以下命令，将污点添加到要在其上调度日志可视化 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。
编辑
ClusterLogging
CR 的
visualization
部分，以配置 Kibana pod 的容忍度：
visualization:
type: "kibana"
kibana:
tolerations:
- key: "kibana" 1
operator: "Exists" 2
effect: "NoExecute" 3
tolerationSeconds: 6000 4
-
1
-
指定添加到节点的键。
指定
Exists
运算符，以要求匹配
key
/
value
/
effect
参数。
指定
NoExecute
效果。
（可选）指定
tolerationSeconds
参数，以设置 pod 在被逐出前可以保持绑定到节点的时长。
此容忍度与
oc adm taint
命令创建的污点匹配。具有此容限的 pod 可以调度到
node1
上。
4.7.3. 使用容忍度来控制日志收集器 pod 放置
您可以通过在 pod 上使用容忍度来确保日志记录收集器 pod 在哪些节点上运行，并防止其他工作负载使用这些节点。
您可以通过
ClusterLogging
自定义资源（CR）将容忍度应用到日志记录收集器 pod，并通过节点规格将污点应用到节点。您可以使用污点和容限来确保 pod 不会因为内存和 CPU 问题而被驱除。
默认情况下，日志记录收集器 pod 具有以下容忍度：
tolerations:
- key: "node-role.kubernetes.io/master"
operator: "Exists"
effect: "NoExecute"
先决条件
-
必须安装 OpenShift 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。
编辑
ClusterLogging
自定义资源（CR）的
collection
小节，以配置日志记录收集器 Pod 的容忍度：
collection:
logs:
type: "fluentd"
fluentd:
tolerations:
- key: "collector" 1
operator: "Exists" 2
effect: "NoExecute" 3
tolerationSeconds: 6000 4
-
1
-
指定添加到节点的键。
指定
Exists
运算符，以要求匹配
key
/
value
/
effect
参数。
指定
NoExecute
效果。
（可选）指定
tolerationSeconds
参数，以设置 pod 在被逐出前可以保持绑定到节点的时长。
此容忍度与
oc adm taint
命令创建的污点匹配。具有此容限的 pod 可以调度到
node1
上。
4.8. 使用节点选择器移动 OpenShift Logging 资源
您可以使用节点选择器将 Elasticsearch 和 Kibana Pod 部署到不同的节点上。
4.8.1. 移动 OpenShift Logging 资源
您可以配置 Cluster Logging Operator，将 OpenShift Logging 组件（如 Elasticsearch 和 Kibana）的 pod 部署到不同的节点上。您无法将 Cluster Logging Operator Pod 从其安装位置移走。
例如，您可以因为 CPU、内存和磁盘要求较高而将 Elasticsearch Pod 移到一个单独的节点上。
必须安装 OpenShift Logging 和 Elasticsearch。默认情况下没有安装这些功能。
编辑
openshift-logging
项目中的
ClusterLogging
自定义资源（CR）：
$ oc edit ClusterLogging instance
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
spec:
collection:
logs:
fluentd:
resources: null
type: fluentd
logStore:
elasticsearch:
nodeCount: 3
nodeSelector: 1
node-role.kubernetes.io/infra: ''
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
redundancyPolicy: SingleRedundancy
resources:
limits:
cpu: 500m
memory: 16Gi
requests:
cpu: 500m
memory: 16Gi
storage: {}
type: elasticsearch
managementState: Managed
visualization:
kibana:
nodeSelector: 2
node-role.kubernetes.io/infra: ''
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
proxy:
resources: null
replicas: 1
resources: null
type: kibana
...
-
1
2
-
添加
nodeSelector
参数，并设为适用于您想要移动的组件的值。您可以根据为节点指定的值，按所示格式使用
nodeSelector
或使用
<key>: <value>
对。如果您在 infrasructure 节点中添加了污点，还要添加匹配的容限。
要验证组件是否已移动，您可以使用
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
4.9. 配置 systemd-journald 和 Fluentd
Fluentd 需要从日志 (journal) 中读取数据。因为日志默认设置非常低，它可能无法跟上系统服务的日志记录率，所以日志条目可能会丢失。
我们推荐设置
RateLimitIntervalSec=30s
和
RateLimitBurst=10000
（如有必要甚至更高）以防止日志丢失条目。
4.9.1. 为 OpenShift Logging 配置 systemd-journald
随着项目的扩展，默认的日志记录环境可能需要进行一些调整。
例如，如果有缺少日志数据的情况，则可能需要提高 journald 的速率限制。您可以调整在指定时间段内保留的消息数量，以确保 OpenShift Logging 在不丢弃日志的情况下不使用过量资源。
您还可以确定是否压缩日志、日志需要保留的时间、如何存储日志，以及其他设置。
创建一个 Butane 配置文件
40-worker-custom-journald.bu
，其中包含带有所需设置的
/etc/systemd/journald.conf
文件。
有关 Butane 的信息，请参阅"使用 Butane 创建机器配置"。
variant: openshift
version: 4.8.0
metadata:
name: 40-worker-custom-journald
labels:
machineconfiguration.openshift.io/role: "worker"
storage:
files:
- path: /etc/systemd/journald.conf
mode: 0644 1
overwrite: true
contents:
inline: |
Compress=yes 2
ForwardToConsole=no 3
ForwardToSyslog=no
MaxRetentionSec=1month 4
RateLimitBurst=10000 5
RateLimitIntervalSec=30s
Storage=persistent 6
SyncIntervalSec=1s 7
SystemMaxUse=8G 8
SystemKeepFree=20% 9
SystemMaxFileSize=10M 10
-
1
-
为
journal.conf
文件设置权限 。建议把选项设置为
0644
。
指定是否要在将日志写入文件系统前压缩日志。指定
yes
来压缩消息，或指定
no
不压缩信息。默认为
yes
。
配置是否转发日志信息。每个默认值为
no
。指定：
ForwardToConsole
将日志转发到系统控制台。
ForwardToKsmg
将日志转发到内核日志缓冲。
ForwardToSyslog
将日志转发到 syslog 守护进程。
ForwardToWall
将信息作为墙信息转发给所有登录的用户。
指定存储日志条目的最长时间。输入秒数。或包括一个单位：" year" 、"month" 、"week" 、"day" 、"h" 或 "m"。输入
0
来禁用。默认值为
1month
。
配置速率限制。如果在
RateLimitIntervalSec
定义的时间间隔内收到
RateLimitBurst
中指定的日志数，则该时间段内的所有进一步信息都会被丢弃，直到间隔结束。建议您设置
RateLimitIntervalSec=30s
和
RateLimitBurst=10000
，它们是默认值。
指定日志的存储方式。默认为
persistent
：
volatile
在
/var/log/journal/
中存储内存中的日志数据。
persistent
把日志保存到磁盘的
/var/log/journal/
。如果这个目录步存在，systemd 将会创建这个目录。
auto
将日志存储在
/var/log/journal/
中 （如果存在这个目录）。如果不存在，systemd 会临时将日志保存在
/run/systemd/journal
中。
none
不存储日志。systemd 丢弃所有日志。
指定在将
ERR
,
WARNING
,
NOTICE
,
INFO
和
DEBUG
日志同步到磁盘上前等待的超时时间。systemd 在接收到
CRIT
,
ALERT
或
EMERG
日志后会立即进行同步。默认值为
1s
。
指定日志可以使用的最大值。默认值为
8G
。
指定 systemd 必须保留多少磁盘空间。默认值为
20%
。
指定保存在
/var/log/journal
中的独立日志文件的最大大小。默认值为
10M
。
如果删除速率限制，您可能会看到系统日志记录守护进程的 CPU 使用率增加，因为它需要处理在以前可以被限制掉的信息。
如需了解更多关于 systemd 设置的信息，请参阅
https://www.freedesktop.org/software/systemd/man/journald.conf.html
。该页面中列出的默认设置可能不适用于 OpenShift Container Platform。
使用 Butane 生成
MachineConfig
对象文件
40-worker-custom-journald.yaml
，它包含要提供给节点的配置：
$ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml
-
应用机器配置。例如：
$ oc apply -f 40-worker-custom-journald.yaml
控制器检测到新的
MachineConfig
对象，并生成新的
rendered-worker-<hash>
版本。
监控新配置在每个节点中的应用状态：
$ oc describe machineconfigpool/worker
配置 OpenShift Logging 的支持方法是使用本文档中介绍的选项进行配置。请勿使用其他配置，因为不受支持。各个 OpenShift Container Platform 发行版本的配置范例可能会有所变化，只有掌握了所有可能的配置，才能稳妥应对这样的配置变化。如果使用本文档中描述的配置以外的配置，您的更改可能会丢失，因为 OpenShift Elasticsearch Operator 和 Red Hat OpenShift Logging Operator 会调节差异。按照设计，Operator 会默认将一切还原到定义的状态。
如果
必须
执行 OpenShift Container Platform 文档中没有描述的配置，您
必须
将 Red Hat OpenShift Logging Operator 或 OpenShift Elasticsearch Operator 设置为
Unmanaged
。一个不受管理的 OpenShift Logging 环境
不被支持
，且不会接收更新，直到 OpenShift Logging 返回到
Managed
。
您必须将 Red Hat OpenShift Logging Operator 设置为非受管状态，才能修改以下组件：
Elasticsearch
CR
Kibana 部署
fluent.conf
文件
Fluentd 守护进程集
您必须将 OpenShift Elasticsearch Operator 设置为非受管状态才能修改以下组件：
Elasticsearch 部署文件。
明确不支持的情形包括：
配置默认日志轮转
。您无法修改默认的日志轮转配置。
配置所收集日志的位置
。您无法更改日志收集器输出文件的位置，默认为
/var/log/fluentd/fluentd.log
。
日志收集节流
。您不能减慢日志收集器读取日志的速度。
使用环境变量配置日志记录收集器
。您不能使用环境变量来修改日志收集器。
配置日志收集器规范日志的方式
。您无法修改默认日志规范化。
4.10.3. 非受管 Operator 的支持策略
Operator 的
管理状态
决定了一个 Operator 是否按设计积极管理集群中其相关组件的资源。如果 Operator 设置为
非受管（unmanaged）
状态，它不会响应配置更改，也不会收到更新。
虽然它可以在非生产环境集群或调试过程中使用，但处于非受管状态的 Operator 不被正式支持，集群管理员需要完全掌控各个组件的配置和升级。
可使用以下方法将 Operator 设置为非受管状态：
独立 Operator 配置
独立 Operator 的配置中具有
managementState
参数。这可以通过不同的方法来访问，具体取决于 Operator。例如，Red Hat OpenShift Logging Operator 通过修改它管理的自定义资源（CR）来达到此目的，而 Cluster Samples Operator 使用了集群范围配置资源。
将
managementState
参数更改为
Unmanaged
意味着 Operator 不会主动管理它的资源，也不会执行与相关组件相关的操作。一些 Operator 可能不支持此管理状态，因为它可能会损坏集群，需要手动恢复。
将独立 Operator 更改为
非受管
状态会导致不支持该特定组件和功能。报告的问题必须在
受管（Managed）
状态中可以重复出现才能继续获得支持。
Cluster Version Operator (CVO) 覆盖
可将
spec.overrides
参数添加到 CVO 配置中，以便管理员提供对组件的 CVO 行为覆盖的列表。将一个组件的
spec.overrides[].unmanaged
参数设置为
true
会阻止集群升级并在设置 CVO 覆盖后提醒管理员：
Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
设置 CVO 覆盖会使整个集群处于不受支持状态。在删除所有覆盖后，必须可以重现报告的问题方可获得支持。
您可以使用 OpenShift CLI（oc）和 Web 控制台查看各种资源的日志，如构建、部署和 pod。
资源日志是一个默认功能，可提供有限的日志查看功能。为增强日志检索和查看体验，建议您安装
OpenShift Logging
。OpenShift Logging 将 OpenShift Container Platform 集群中的所有日志（如节点系统审计日志、应用程序容器日志和基础架构日志）聚合到专用日志存储中。然后，您可以通过
Kibana 接口
查询、发现和视觉化日志数据。资源日志无法访问 OpenShift Logging 日志存储。
您可以在 OpenShift CLI（oc）和 Web 控制台中查看各种资源的日志。日志从日志的尾部或末尾读取。
访问 OpenShift CLI（oc）。
流程 (UI)
-
在 OpenShift Container Platform 控制台中，导航到
Workloads
→
Pods
，或通过您要调查的资源导航到 pod。
有些资源（如构建）没有直接查询的 pod。在这种情况下，您可以在资源的
Details
页面中找到
Logs
链接。
从下拉菜单中选择一个项目。
点您要调查的 pod 的名称。
点
Logs
。
OpenShift Logging 包括一个 Web 控制台，用于视觉化收集的日志数据。目前，OpenShift Container Platform 部署 Kibana 控制台以进行可视化。
通过日志可视化工具，您可以使用以下数据进行以下操作：
使用
Discover
标签页搜索并浏览数据。
使用
Visualize
标签页对数据进行图表显示。
使用
Dashboard
标签页创建并查看自定义仪表板。
使用并配置 Kibana 界面的内容超出了本文档的范围。相关信息，请参阅
Kibana 文档
。
默认情况下，审计日志不会存储在 OpenShift Container Platform 内部 Elasticsearch 实例中。要在 Kibana 中查看审计日志，您必须使用
Log Forwarding API
配置使用审计日志的
default
输出的管道。
索引模式定义了您要视觉化的 Elasticsearch 索引。要在 Kibana 中探索和视觉化数据，您必须创建索引模式。
用户必须具有
cluster-admin
角色、
cluster-reader
角色或这两个角色，才能在 Kibana 中查看
infra
和
audit
索引。默认
kubeadmin
用户具有查看这些索引的权限。
如果可以查看
default
、
kube-
和
openshift-
项目中的 pod 和日志，则应该可以访问这些索引。您可以使用以下命令检查当前用户是否有适当的权限：
$ oc auth can-i get pods/log -n <project>
您可以在 Kibana web 控制台中查看集群日志。在 Kibana 中查看和视觉化您的数据的方法，它们超出了本文档的范围。如需更多信息，请参阅
Kibana 文档
。
必须安装 OpenShift Logging 和 Elasticsearch。
Kibana 索引模式必须存在。
用户必须具有
cluster-admin
角色、
cluster-reader
角色或这两个角色，才能在 Kibana 中查看
infra
和
audit
索引。默认
kubeadmin
用户具有查看这些索引的权限。
如果可以查看
default
、
kube-
和
openshift-
项目中的 pod 和日志，则应该可以访问这些索引。您可以使用以下命令检查当前用户是否有适当的权限：
$ oc auth can-i get pods/log -n <project>
默认情况下，OpenShift Logging 将容器和基础架构日志发送到
ClusterLogging
自定义资源中定义的默认内部 Elasticsearch 日志存储。但是，它不会将审计日志发送到内部存储，因为它不提供安全存储。如果此默认配置满足您的需要，则不需要配置 Cluster Log Forwarder。
要将日志发送到其他日志聚合器，请使用 OpenShift Container Platform Cluster Log Forwarder。通过这个 API，您可以将容器、基础架构和审计日志发送到集群内部或外部的特定端点。另外，您可以向不同的系统发送不同类型的日志，这样不同个人就可以访问不同系统。您还可以根据机构的要求，启用传输层安全 (TLS) 支持来安全地发送日志。
要将审计日志发送到默认的内部 Elasticsearch 日志存储，请使用 Cluster Log Forwarder，如
将审计日志转发到日志存储
中所述。
将集群日志转发到外部第三方系统需要结合
ClusterLogForwarder
自定义资源（CR）中指定的
输出
和
管道
，将日志发送到 OpenShift Container Platform 集群内部和外部的特定端点。您还可以使用
输入
将与特定项目关联的应用程序日志转发到端点。
输出
是您定义的日志数据的目的地，或您希望发送日志的位置。输出可以是以下类型之一：
elasticsearch
.一个外部 Elasticsearch 实例。
elasticsearch
输出可以使用 TLS 连接。
fluentdForward
。一个支持 Fluentd 的外部日志聚合解决方案。这个选项使用 Fluentd
转发
协议。
fluentForward
输出可以使用 TCP 或 TLS 连接，并通过在 secret 中提供一个
shared_key
字段来支持共享密钥身份验证。共享密钥身份验证可在使用或不使用 TLS 的情况下使用。
syslog
。支持 syslog
RFC3164
或
RFC5424
协议的外部日志聚合解决方案。
syslog
输出可以使用 UDP、TCP 或 TLS 连接。
cloudwatch
。Amazon CloudWatch，一种由 Amazon Web Services (AWS) 托管的监控和日志存储服务。
loki
。Loki，一个可横向扩展的、高可用性、多租户日志聚合系统。
kafka
.Kafka 代理。
kafka
输出可以使用 TCP 或 TLS 连接。
default
.内部 OpenShift Container Platform Elasticsearch 实例。您不需要配置默认输出。如果配置
default
输出，您会收到出错信息，因为 Red Hat OpenShift Logging Operator 保留了
default
输出。
如果输出 URL 方案需要 TLS（HTTPS、TLS 或 UDPS）,则需要启用 TLS 服务器端的身份验证。为了同时启用客户端身份验证，输出必须在
openshift-logging
项目中命名一个 secret。secret 必须具有代表指向以下整数的键：
tls.crt
、
tls.key
和
ca-bundle.crt
。
管道(
pipeline
)定义从一个日志类型到一个或多个输出，或您要发送的日志的简单路由。日志类型是以下之一：
application
.由集群中运行的用户应用程序生成的容器日志（基础架构容器应用程序除外）。
infrastructure
.在
openshift*
、
kube*
或
default
项目中运行的容器日志，以及来源于节点文件系统的 journal 日志。
audit
.由节点审计系统、
auditd
、Kubernetes API 服务器、OpenShift API 服务器和 OVN 网络生成的审计日志。
您可以使用管道中的
key:value
对为出站日志消息添加标签。例如,您可以在转发给其他数据中心的消息中添加一个标签,或者根据类型为日志添加标签。添加到对象的标签也会通过日志消息转发。
input
会将与特定项目关联的应用程序日志转发到管道。
在管道中，您要定义使用
inputRef
参数转发哪些日志类型，以及将日志转发到使用
outputRef
参数的位置。
注意以下几点：
如果
ClusterLogForwarder
CR 对象存在，日志不会转发到默认的 Elasticsearch 实例，除非有带有
default
输出的管道。
默认情况下，OpenShift Logging 将容器和基础架构日志发送到
ClusterLogging
自定义资源中定义的默认内部 Elasticsearch 日志存储。但是，它不会将审计日志发送到内部存储，因为它不提供安全存储。如果此默认配置满足您的需要，则不需要配置 Log Forwarding API。
如果您没有为日志类型定义管道，则将丢弃未定义类型的日志。例如，如果您为
application
和
audit
类型指定管道，但没有为
infrastructure
类型指定管道，则
infrastructure
日志会丢弃。
您可以使用
ClusterLogForwarder
自定义资源（CR）中的多种输出类型将日志发送到支持不同协议的服务器。
内部 OpenShift Container Platform Elasticsearch 实例不会为审计日志提供安全存储。您需要自己确保转发审计日志的系统符合您所在机构及政府的相关要求，并具有适当的安全性。OpenShift Logging 不遵循这些规范。
您需要创建并维护外部目的地可能需要的额外配置，如密钥和 secret 、服务帐户、端口打开或全局代理服务器配置。
以下示例将审计日志转发到安全的外部 Elasticsearch 实例，基础架构日志发送到不安全的外部 Elasticsearch 实例，应用程序日志发送到 Kafka 代理，以及
my-apps-logs
项目中的应用程序日志发送到内部 Elasticsearch 实例。
当外部日志聚合器不可用时，Fluentd 日志处理
如果外部日志记录聚合器不可用且无法接收日志，Fluentd 会继续收集日志并将其存储在缓冲中。当日志聚合器可用时，日志转发会恢复，包括缓冲的日志。如果缓冲区已满，Fluentd 会停止收集日志。OpenShift Container Platform 轮转日志并删除日志。您无法调整缓冲区大小，或者将持久性卷声明（PVC）添加到 Fluentd 守护进程集或 Pod 中。
支持的授权密钥
这里提供了常见的密钥类型。某些输出类型支持额外的专用密钥，记录在特定于输出的配置字段中。所有 secret 密钥都是可选的。通过设置相关密钥来启用您想要的安全功能。您需要创建并维护外部目的地可能需要的额外配置，如密钥和 secret 、服务帐户、端口打开或全局代理服务器配置。Open Shift Logging 不会尝试验证授权组合间的不匹配。
-
传输层安全性(TLS)
-
使用没有 Secret 的 TLS URL（'http://…' 或 'ssl://…'）启用基本的 TLS 服务器端身份验证。可通过包含 Secret 并设置以下可选字段来启用额外的 TLS 功能：
tls.crt
: （字符串）包含客户端证书的文件名。启用 mutual 身份验证。需要
tls.key
。
tls.key
：（字符串）包含私钥的文件名，用于解锁客户端证书。需要
tls.crt
。
密码短语
：（字符串）对编码的 TLS 私钥进行解码。需要
tls.key
。
ca-bundle.crt
: （字符串）用于服务器身份验证的客户 CA 的文件名。
用户名和密码
-
username
：（字符串）身份验证用户名。需要
password
。
password
：（字符串）身份验证密码。需要
username
。
简单身份验证安全层(SASL)
-
sasl.enable
（布尔值）明确指定启用或禁用 SASL。如果缺失，则设置了任何其他
sasl.
密钥时自动启用 SASL。
sasl.mechanisms
：(array)允许的 SASL 机制名称列表。如果缺少或为空，则使用系统默认值。
sasl.allow-insecure
：（布尔值）允许发送明文密码的机制。默认为false。
您可以使用以下命令在包含您的证书和密钥文件的目录中创建 secret：
$ oc create secret generic -n openshift-logging <my-secret> \
--from-file=tls.key=<your_key_file>
--from-file=tls.crt=<your_crt_file>
--from-file=ca-bundle.crt=<your_bundle_file>
--from-literal=username=<your_username>
--from-literal=password=<your_password>
建议使用通用或不透明 secret 来获得最佳结果。
7.2. OpenShift Logging 5.1 中支持的日志数据输出类型
Red Hat OpenShift Logging 5.1 提供以下输出类型和协议，用于将日志数据发送到目标日志收集器。
红帽会测试下表中显示的每个组合。然而，您应该能够将日志数据发送到最接近这些协议的更大范围的目标日志收集器。
|
输出类型
|
协议
|
测试使用
|
|
elasticsearch
elasticsearch
Elasticsearch 6.8.1
Elasticsearch 6.8.4
Elasticsearch 7.12.2
fluentdForward
fluentd forward v1
fluentd 1.7.4
logstash 7.10.1
kafka
kafka 0.11
kafka 2.4.1
kafka 2.7.0
syslog
RFC-3164、RFC-5424
rsyslog-8.39.0
在以前的版本中，syslog 输出只支持 RFC-3164。当前的 syslog 输出添加了对 RFC-5424 的支持。
7.3. OpenShift Logging 5.2 中支持的日志数据输出类型
Red Hat OpenShift Logging 5.2 提供了以下输出类型和协议，用于将日志数据发送到目标日志收集器。
红帽会测试下表中显示的每个组合。然而，您应该能够将日志数据发送到最接近这些协议的更大范围的目标日志收集器。
|
输出类型
|
协议
|
测试使用
|
|
Amazon CloudWatch
通过 HTTPS 的 REST
Amazon CloudWatch 的当前版本
elasticsearch
elasticsearch
Elasticsearch 6.8.1
Elasticsearch 6.8.4
Elasticsearch 7.12.2
fluentdForward
fluentd forward v1
fluentd 1.7.4
logstash 7.10.1
使用 HTTP 和 HTTPS 的 REST
OCP 和 Grafana 实验中部署的 Loki 2.3.0
kafka
kafka 0.11
kafka 2.4.1
kafka 2.7.0
syslog
RFC-3164、RFC-5424
rsyslog-8.39.0
|
7.4. OpenShift Logging 5.3 中支持的日志数据输出类型
Red Hat OpenShift Logging 5.3 提供了以下输出类型和协议，用于将日志数据发送到目标日志收集器。
红帽会测试下表中显示的每个组合。然而，您应该能够将日志数据发送到最接近这些协议的更大范围的目标日志收集器。
|
输出类型
|
协议
|
测试使用
|
|
Amazon CloudWatch
通过 HTTPS 的 REST
Amazon CloudWatch 的当前版本
elasticsearch
elasticsearch
Elasticsearch 7.10.1
fluentdForward
fluentd forward v1
fluentd 1.7.4
logstash 7.10.1
使用 HTTP 和 HTTPS 的 REST
在 OCP 上部署的 Loki 2.2.1
kafka
kafka 0.11
kafka 2.7.0
syslog
RFC-3164、RFC-5424
rsyslog-8.39.0
|
7.5. OpenShift Logging 5.4 中支持的日志数据输出类型
Red Hat OpenShift Logging 5.4 提供了以下输出类型和协议，用于将日志数据发送到目标日志收集器。
红帽会测试下表中显示的每个组合。然而，您应该能够将日志数据发送到最接近这些协议的更大范围的目标日志收集器。
|
输出类型
|
协议
|
测试使用
|
|
Amazon CloudWatch
通过 HTTPS 的 REST
Amazon CloudWatch 的当前版本
elasticsearch
elasticsearch
Elasticsearch 7.10.1
fluentdForward
fluentd forward v1
fluentd 1.14.5
logstash 7.10.1
使用 HTTP 和 HTTPS 的 REST
在 OCP 上部署的 Loki 2.2.1
kafka
kafka 0.11
kafka 2.7.0
syslog
RFC-3164、RFC-5424
rsyslog-8.39.0
|
7.6. OpenShift Logging 5.5 中支持的日志数据输出类型
Red Hat OpenShift Logging 5.5 提供以下输出类型和协议，用于将日志数据发送到目标日志收集器。
红帽会测试下表中显示的每个组合。然而，您应该能够将日志数据发送到最接近这些协议的更大范围的目标日志收集器。
|
输出类型
|
协议
|
测试使用
|
|
Amazon CloudWatch
通过 HTTPS 的 REST
Amazon CloudWatch 的当前版本
elasticsearch
elasticsearch
Elasticsearch 7.10.1
fluentdForward
fluentd forward v1
fluentd 1.14.6
logstash 7.10.1
使用 HTTP 和 HTTPS 的 REST
OCP 上部署的 Loki 2.5.0
kafka
kafka 0.11
kafka 2.7.0
syslog
RFC-3164、RFC-5424
rsyslog-8.39.0
|
7.7. OpenShift Logging 5.6 中支持的日志数据输出类型
Red Hat OpenShift Logging 5.6 提供以下输出类型和协议，用于将日志数据发送到目标日志收集器。
红帽会测试下表中显示的每个组合。然而，您应该能够将日志数据发送到最接近这些协议的更大范围的目标日志收集器。
|
输出类型
|
协议
|
测试使用
|
|
Amazon CloudWatch
通过 HTTPS 的 REST
Amazon CloudWatch 的当前版本
elasticsearch
elasticsearch
Elasticsearch 6.8.23
Elasticsearch 7.10.1
Elasticsearch 8.6.1
fluentdForward
fluentd forward v1
fluentd 1.14.6
logstash 7.10.1
使用 HTTP 和 HTTPS 的 REST
OCP 上部署的 Loki 2.5.0
kafka
kafka 0.11
kafka 2.7.0
syslog
RFC-3164、RFC-5424
rsyslog-8.39.0
从 5.6.2 开始，Fluentd 不支持 Elasticsearch 8。向量不支持 5.7.0 之前的 fluentd/logstash/rsyslog。
7.8. 将日志转发到外部 Elasticsearch 实例
除了内部 OpenShift Container Platform Elasticsearch 实例外，您还可以将日志转发到外部 Elasticsearch 实例。您需要配置外部日志聚合器，以接收来自 OpenShift Container Platform 的日志数据。
要配置日志转发到外部 Elasticsearch 实例，请创建一个
ClusterLogForwarder
自定义资源（CR），其中包含输出到该实例的输出以及使用输出的管道。外部 Elasticsearch 输出可以使用 HTTP（不安全）或 HTTPS（安全 HTTP）连接。
要将日志转发到外部和内部 Elasticsearch 实例，请将输出和管道创建到外部实例，以及一个使用
default
输出将日志转发到内部实例的管道。您不需要创建
default
输出。如果配置
default
输出，您会收到出错信息，因为 Red Hat OpenShift Logging Operator 保留了
default
输出。
如果您
只
想将日志转发到内部 OpenShift Container Platform Elasticsearch 实例，则不需要创建一个
ClusterLogForwarder
CR。
您必须有配置为使用指定协议或格式接收日志数据的日志服务器。
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件：
apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
name: instance 1
namespace: openshift-logging 2
spec:
outputs:
- name: elasticsearch-insecure 3
type: "elasticsearch" 4
url: http://elasticsearch.insecure.com:9200 5
- name: elasticsearch-secure
type: "elasticsearch"
url: https://elasticsearch.secure.com:9200 6
secret:
name: es-secret 7
pipelines:
- name: application-logs 8
inputRefs: 9
- application
- audit
outputRefs:
- elasticsearch-secure 10
- default 11
parse: json 12
labels:
myLabel: "myValue" 13
- name: infrastructure-audit-logs 14
inputRefs:
- infrastructure
outputRefs:
- elasticsearch-insecure
labels:
logs: "audit-infra"
-
1
-
ClusterLogForwarder
CR 的名称必须是
instance
。
ClusterLogForwarder
CR 的命名空间必须是
openshift-logging
。
指定输出的名称。
指定
elasticsearch
类型。
指定外部 Elasticsearch 实例的 URL 和端口作为有效的绝对 URL。您可以使用
http
（不安全）或
https
（安全 HTTP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。
对于安全连接，您可以通过指定
secret
来指定您进行身份验证的
https
或
http
URL。
对于
https
前缀，请指定 TLS 通信端点所需的 secret 名称。secret 必须存在于
openshift-logging
项目中，且必须具有指向它们所代表的相应证书的：
tls.crt
、
tls.key
和
ca-bundle.crt
的密钥。否则，对于
http
和
https
前缀，您可以指定一个包含用户名和密码的 secret。如需更多信息，请参阅以下"示例：设置包含用户名和密码的 secret"。
可选：指定管道的名称。
使用管道指定要转发的日志类型：
application
、
infrastructure
或
audit
。
指定使用此管道转发日志时使用的输出名称。
可选：指定将日志发送到内部 Elasticsearch 实例的
default
输出。
可选：指定是否转发结构化 JSON 日志条目作为
structured
项中的 JSON 对象。日志条目必须包含有效的结构化 JSON；否则，OpenShift Logging 会删除
structured
字段，并将日志条目发送到默认索引
app-00000x
。
可选：字符串。要添加到日志中的一个或多个标签。
可选：配置多个输出，将日志转发到任何受支持类型的其他外部日志聚合器：
描述管道的名称。
inputRefs
是使用管道转发的日志类型：
application
、
infrastructure
或
audit
。
outputRefs
是要使用的输出名称。
可选：字符串。要添加到日志中的一个或多个标签。
创建 CR 对象。
$ oc create -f <file-name>.yaml
您可以使用 Fluentd
forward
协议将日志副本发送到配置为接受协议的外部日志聚合器，而非默认的 Elasticsearch 日志存储。您需要配置外部日志聚合器以接收来自 OpenShift Container Platform 的日志。
要使用
forward
协议配置日志转发，请创建一个
ClusterLogForwarder
自定义资源（CR），并将一个或多个输出输出到使用这些输出的 Fluentd 服务器和管道。Fluentd 输出可以使用 TCP（不安全）或 TLS（安全 TCP）连接。
另外，您可以通过配置映射来使用
forward
协议转发日志。但是，此方法在 OpenShift Container Platform 中已弃用，并将在以后的发行版本中删除。
您必须有配置为使用指定协议或格式接收日志数据的日志服务器。
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件：
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
name: instance 1
namespace: openshift-logging 2
spec:
outputs:
- name: fluentd-server-secure 3
type: fluentdForward 4
url: 'tls://fluentdserver.security.example.com:24224' 5
secret: 6
name: fluentd-secret
- name: fluentd-server-insecure
type: fluentdForward
url: 'tcp://fluentdserver.home.example.com:24224'
pipelines:
- name: forward-to-fluentd-secure 7
inputRefs: 8
- application
- audit
outputRefs:
- fluentd-server-secure 9
- default 10
parse: json 11
labels:
clusterId: "C1234" 12
- name: forward-to-fluentd-insecure 13
inputRefs:
- infrastructure
outputRefs:
- fluentd-server-insecure
labels:
clusterId: "C1234"
-
1
-
ClusterLogForwarder
CR 的名称必须是
instance
。
ClusterLogForwarder
CR 的命名空间必须是
openshift-logging
。
指定输出的名称。
指定
fluentdForward
类型。
指定外部 Fluentd 实例的 URL 和端口作为有效的绝对 URL。您可以使用
tcp
（不安全）或者
tls
（安全 TCP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。
如果使用
tls
前缀，您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于
openshift-logging
项目中，且必须具有指向它们所代表的相应证书的：
tls.crt
、
tls.key
和
ca-bundle.crt
的密钥。否则，对于 http 和 https 前缀，您可以指定一个包含用户名和密码的 secret。如需更多信息，请参阅以下"示例：设置包含用户名和密码的 secret"。
可选：指定管道的名称。
使用管道指定要转发的日志类型：
application
、
infrastructure
或
audit
。
指定使用此管道转发日志时使用的输出名称。
可选：指定将日志转发到内部 Elasticsearch 实例的
default
输出。
可选：指定是否转发结构化 JSON 日志条目作为
structured
项中的 JSON 对象。日志条目必须包含有效的结构化 JSON；否则，OpenShift Logging 会删除
structured
字段，并将日志条目发送到默认索引
app-00000x
。
可选：字符串。要添加到日志中的一个或多个标签。
可选：配置多个输出，将日志转发到任何受支持类型的其他外部日志聚合器：
描述管道的名称。
inputRefs
是使用管道转发的日志类型：
application
、
infrastructure
或
audit
。
outputRefs
是要使用的输出名称。
可选：字符串。要添加到日志中的一个或多个标签。
创建 CR 对象：
$ oc create -f <file-name>.yaml
7.9.1. 为 Logstash 启用 nanosecond 精度来从 fluentd 摄取数据
对于 Logstash 从 fluentd 摄取数据，您必须在 Logstash 配置文件中启用 nanosecond 精度。
在 Logstash 配置文件中，将
nanosecond_precision
设置为
true
。
您可以使用
syslog
RFC3164
或
RFC5424
协议将日志副本发送到配置为接受该协议的外部日志聚合器（替代默认的 Elasticsearch 日志存储或作为它的补充）。您需要配置外部日志聚合器（如 syslog 服务器）来接收来自 OpenShift Container Platform 的日志。
要使用
syslog
协议配置日志转，,请创建一个
ClusterLogForwarder
自定义资源（CR），并将一个或多个输出输出到使用这些输出的 syslog 服务器和管道。syslog 输出可以使用 UDP、TCP 或 TLS 连接。
另外，您可以使用配置映射使用
syslog
RFC3164 协议转发日志。但是，此方法在 OpenShift Container Platform 中已弃用，并将在以后的发行版本中删除。
您必须有配置为使用指定协议或格式接收日志数据的日志服务器。
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件：
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
name: instance 1
namespace: openshift-logging 2
spec:
outputs:
- name: rsyslog-east 3
type: syslog 4
syslog: 5
facility: local0
rfc: RFC3164
payloadKey: message
severity: informational
url: 'tls://rsyslogserver.east.example.com:514' 6
secret: 7
name: syslog-secret
- name: rsyslog-west
type: syslog
syslog:
appName: myapp
facility: user
msgID: mymsg
procID: myproc
rfc: RFC5424
severity: debug
url: 'udp://rsyslogserver.west.example.com:514'
pipelines:
- name: syslog-east 8
inputRefs: 9
- audit
- application
outputRefs: 10
- rsyslog-east
- default 11
parse: json 12
labels:
secure: "true" 13
syslog: "east"
- name: syslog-west 14
inputRefs:
- infrastructure
outputRefs:
- rsyslog-west
- default
labels:
syslog: "west"
-
1
-
ClusterLogForwarder
CR 的名称必须是
instance
。
ClusterLogForwarder
CR 的命名空间必须是
openshift-logging
。
指定输出的名称。
指定
syslog
类型。
可选：指定 syslog 参数，如下所列。
指定外部 syslog 实例的 URL 和端口。您可以使用
udp
（不安全）、
tcp
（不安全）或者
tls
（安全 TCP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。
如果使用
tls
前缀，您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于
openshift-logging
项目中，且必须具有指向它们所代表的相应证书的：
tls.crt
、
tls.key
和
ca-bundle.crt
的密钥。
可选：指定管道的名称。
使用管道指定要转发的日志类型：
application
、
infrastructure
或
audit
。
指定使用此管道转发日志时使用的输出名称。
可选：指定将日志转发到内部 Elasticsearch 实例的
default
输出。
可选：指定是否转发结构化 JSON 日志条目作为
structured
项中的 JSON 对象。日志条目必须包含有效的结构化 JSON；否则，OpenShift Logging 会删除
structured
字段，并将日志条目发送到默认索引
app-00000x
。
可选：字符串。要添加到日志中的一个或多个标签。对值加引号（如 "true"），以便它们被识别为字符串值，而不是作为布尔值。
可选：配置多个输出，将日志转发到任何受支持类型的其他外部日志聚合器：
描述管道的名称。
inputRefs
是使用管道转发的日志类型：
application
、
infrastructure
或
audit
。
outputRefs
是要使用的输出名称。
可选：字符串。要添加到日志中的一个或多个标签。
创建 CR 对象：
$ oc create -f <file-name>.yaml
您可以通过将
AddLogSource
字段添加到
ClusterLogForwarder
自定义资源(CR)将
namespace_name
、
pod_name
和
container_name
元素添加到记录的
message
字段中。
spec:
outputs:
- name: syslogout
syslog:
addLogSource: true
facility: user
payloadKey: message
rfc: RFC3164
severity: debug
tag: mytag
type: syslog
url: tls://syslog-receiver.openshift-logging.svc:24224
pipelines:
- inputRefs:
- application
name: test-app
outputRefs:
- syslogout
这个配置与 RFC3164 和 RFC5424 兼容。
您可以为
syslog
输出配置以下内容。如需更多信息,请参阅 syslog
RFC3164
或
RFC5424
RFC。
facility:
syslog facility
.该值可以是十进制整数，也可以是区分大小写的关键字：
0
或
kern
用于内核信息
1
或
user
代表用户级信息（默认）。
2
或
mail
用于邮件系统。
3
或
daemon
用于系统守护进程
4
或
auth
用于安全/身份验证信息
5
或
syslog
用于 syslogd 内部生成的信息
6
或
lpr
用于行打印机子系统
7
或
news
用于网络新闻子系统
8
或
uucp
用于 UUCP 子系统
9
或
cron
用于 clock 守护进程
10
或
authpriv
用于安全身份验证信息
11
或
ftp
用于 FTP 守护进程
12
或
ntp
用于 NTP 子系统
13
或
security
用于 syslog audit 日志
14
或
console
用于 syslog alert 日志
15
或
solaris-cron
用于 scheduling 守护进程
16
-
23
或
local0
-
local7
用于本地使用的工具
可选：
payloadKey
：用作 syslog 消息有效负载的记录字段。
配置
payloadKey
参数可防止将其他参数转发到 syslog。
RFC：用于使用 syslog 发送日志的 RFC。默认为 RFC5424。
severity：设置传出的 syslog 记录的
syslog 的严重性
。该值可以是十进制整数，也可以是区分大小写的关键字：
0
或
Emergency
用于代表系统不可用的信息
1
或
Alert
用于代表立即执行操作的信息
2
或
Critical
用于代表关键状况的信息
3
或
Error
用于代表错误状况的信息
4
或
Warning
用于代表警告条件的信息
5
或
Notice
用于代表正常但存在重要条件的信息
6
或
Informational
用于代表提示信息的信息
7
或
Debug
用于代表调试级别的信息（默认）
tag：Tag 指定记录字段，用作 syslog 消息上的标签。
trimPrefix：从标签中删除指定的前缀。
7.10.3. 其他 RFC5424 syslog 参数
以下参数适用于 RFC5424:
appName: APP-NAME 是一个自由文本字符串，用于标识发送日志的应用程序。必须为
RFC5424
指定。
msgID: MSGID 是一个用于标识消息类型的自由文本字符串。必须为
RFC5424
指定。
PROCID: PROCID 是一个自由文本字符串。该值的变化表示 syslog 报告不连续。必须为
RFC5424
指定。
7.11. 将日志转发到 Amazon CloudWatch
您可以将日志转发到 Amazon CloudWatch，这是由 Amazon Web Services (AWS) 托管的监控和日志存储服务。除了默认的 OpenShift Logging 管理的 Elasticsearch 日志存储外，您还可以将日志转发到 CloudWatch。
要配置日志转发到 CloudWatch，您必须创建一个
ClusterLogForwarder
自定义资源 (CR)，其中包含 CloudWatch 的输出，以及使用输出的管道。
创建一个
Secret
YAML 文件，它使用
aws_access_key_id
和
aws_secret_access_key
字段来指定您的 base64 编码的 AWS 凭证。例如：
apiVersion: v1
kind: Secret
metadata:
name: cw-secret
namespace: openshift-logging
data:
aws_access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK
aws_secret_access_key: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=
创建 secret.例如：
$ oc apply -f cw-secret.yaml
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件。在文件中，指定 secret 的名称。例如：
apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
name: instance 1
namespace: openshift-logging 2
spec:
outputs:
- name: cw 3
type: cloudwatch 4
cloudwatch:
groupBy: logType 5
groupPrefix: <group prefix> 6
region: us-east-2 7
secret:
name: cw-secret 8
pipelines:
- name: infra-logs 9
inputRefs: 10
- infrastructure
- audit
- application
outputRefs:
- cw 11
-
1
-
ClusterLogForwarder
CR 的名称必须是
instance
。
ClusterLogForwarder
CR 的命名空间必须是
openshift-logging
。
指定输出的名称。
指定
cloudwatch
类型。
可选：指定如何对日志进行分组：
logType
为每个日志类型创建日志组
namespaceName
为每个应用程序命名空间创建一个日志组。它还会为基础架构和审计日志创建单独的日志组。
namespaceUUID
为每个应用命名空间 UUID 创建一个新的日志组。它还会为基础架构和审计日志创建单独的日志组。
可选：指定一个字符串来替换日志组名称中的默认
infrastructureName
前缀。
指定 AWS 区域。
指定包含 AWS 凭证的 secret 名称。
可选：指定管道的名称。
使用管道指定要转发的日志类型：
application
、
infrastructure
或
audit
。
指定使用此管道转发日志时使用的输出名称。
创建 CR 对象。
$ oc create -f <file-name>.yaml
示例：在 Amazon CloudWatch 中使用 ClusterLogForwarder
在这里，您会看到
ClusterLogForwarder
自定义资源 (CR) 示例及其输出到 Amazon CloudWatch 的日志数据。
假设您正在运行名为
mycluster
的 OpenShift Container Platform 集群。以下命令返回集群的
infrastructureName
，稍后您将用它来编写
aws
命令：
$ oc get Infrastructure/cluster -ojson | jq .status.infrastructureName
"mycluster-7977k"
要为本例生成日志数据，您可以在名为
app
的命名空间中运行
busybox
pod。
busybox
pod 每隔三秒钟将消息写入 stdout：
$ oc run busybox --image=busybox -- sh -c 'while true; do echo "My life is my message"; sleep 3; done'
$ oc logs -f busybox
My life is my message
My life is my message
My life is my message
您可以查找 busybox pod 运行的 app 命名空间的 UUID：
$ oc get ns/app -ojson | jq .metadata.uid
"794e1e1a-b9f5-4958-a190-e76a9b53d7bf"
在 ClusterLogForwarder 自定义资源 (CR) 中，您可以将 infrastructure、audit 和 application 日志类型配置为 all-logs 管道的输入。您还可以将此管道连接到 cw 输出，输出将日志转发到 us-east-2 区域的 CloudWatch 实例：
apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
name: instance
namespace: openshift-logging
spec:
outputs:
- name: cw
type: cloudwatch
cloudwatch:
groupBy: logType
region: us-east-2
secret:
name: cw-secret
pipelines:
- name: all-logs
inputRefs:
- infrastructure
- audit
- application
outputRefs:
CloudWatch 中的每个地区都包含三个级别的对象：
使用 ClusterLogForwarding CR 中的 groupBy: logType，inputRefs 中的三种日志类型会在 Amazon Cloudwatch 中生成三个日志组：
$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"mycluster-7977k.application"
"mycluster-7977k.audit"
"mycluster-7977k.infrastructure"
每个日志组都包含日志流：
$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.application | jq .logStreams[].logStreamName
"kubernetes.var.log.containers.busybox_app_busybox-da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76.log" $ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.audit | jq .logStreams[].logStreamName
"ip-10-0-131-228.us-east-2.compute.internal.k8s-audit.log"
"ip-10-0-131-228.us-east-2.compute.internal.linux-audit.log"
"ip-10-0-131-228.us-east-2.compute.internal.openshift-audit.log"
... $ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.infrastructure | jq .logStreams[].logStreamName
"ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-69f9fd9b58-zqzw5_openshift-oauth-apiserver_oauth-apiserver-453c5c4ee026fe20a6139ba6b1cdd1bed25989c905bf5ac5ca211b7cbb5c3d7b.log"
"ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-797774f7c5-lftrx_openshift-apiserver_openshift-apiserver-ce51532df7d4e4d5f21c4f4be05f6575b93196336be0027067fd7d93d70f66a4.log"
"ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-797774f7c5-lftrx_openshift-apiserver_openshift-apiserver-check-endpoints-82a9096b5931b5c3b1d6dc4b66113252da4a6472c9fff48623baee761911a9ef.log"
每个日志流都包含日志事件。要查看 busybox Pod 的日志事件，您可以从 application 日志组中指定其日志流：
$ aws logs get-log-events --log-group-name mycluster-7977k.application --log-stream-name kubernetes.var.log.containers.busybox_app_busybox-da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76.log
"events": [
"timestamp": 1629422704178,
"message": "{\"docker\":{\"container_id\":\"da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76\"},\"kubernetes\":{\"container_name\":\"busybox\",\"namespace_name\":\"app\",\"pod_name\":\"busybox\",\"container_image\":\"docker.io/library/busybox:latest\",\"container_image_id\":\"docker.io/library/busybox@sha256:0f354ec1728d9ff32edcd7d1b8bbdfc798277ad36120dc3dc683be44524c8b60\",\"pod_id\":\"870be234-90a3-4258-b73f-4f4d6e2777c7\",\"host\":\"ip-10-0-216-3.us-east-2.compute.internal\",\"labels\":{\"run\":\"busybox\"},\"master_url\":\"https://kubernetes.default.svc\",\"namespace_id\":\"794e1e1a-b9f5-4958-a190-e76a9b53d7bf\",\"namespace_labels\":{\"kubernetes_io/metadata_name\":\"app\"}},\"message\":\"My life is my message\",\"level\":\"unknown\",\"hostname\":\"ip-10-0-216-3.us-east-2.compute.internal\",\"pipeline_metadata\":{\"collector\":{\"ipaddr4\":\"10.0.216.3\",\"inputname\":\"fluent-plugin-systemd\",\"name\":\"fluentd\",\"received_at\":\"2021-08-20T01:25:08.085760+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-20T01:25:04.178986+00:00\",\"viaq_index_name\":\"app-write\",\"viaq_msg_id\":\"NWRjZmUyMWQtZjgzNC00MjI4LTk3MjMtNTk3NmY3ZjU4NDk1\",\"log_type\":\"application\",\"time\":\"2021-08-20T01:25:04+00:00\"}",
"ingestionTime": 1629422744016
...cloudwatch:
groupBy: logType
groupPrefix: demo-group-prefix
region: us-east-2
groupPrefix 的值替换默认的 infrastructureName 前缀：
$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"demo-group-prefix.application"
"demo-group-prefix.audit"
"demo-group-prefix.infrastructure"
除了内部的默认 OpenShift Container Platform Elasticsearch 实例外，您还可以将日志转发到外部 Loki 日志记录系统。
要配置日志转发到 Loki，您必须创建一个
ClusterLogForwarder
自定义资源 (CR)，并创建一个输出到 Loki 的 ClusterLogForwarder 自定义资源 (CR)，以及使用输出的管道。到 Loki 的输出可以使用 HTTP（不安全）或 HTTPS（安全 HTTP）连接。
您必须有一个 Loki 日志记录系统在您通过 CR 中的
url
字段指定的 URL 中运行。
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件：
apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
name: instance 1
namespace: openshift-logging 2
spec:
outputs:
- name: loki-insecure 3
type: "loki" 4
url: http://loki.insecure.com:3100 5
- name: loki-secure
type: "loki"
url: https://loki.secure.com:3100 6
secret:
name: loki-secret 7
pipelines:
- name: application-logs 8
inputRefs: 9
- application
- audit
outputRefs:
- loki-secure 10
loki:
tenantKey: kubernetes.namespace_name 11
labelKeys: kubernetes.labels.foo 12
-
1
-
ClusterLogForwarder
CR 的名称必须是
instance
。
ClusterLogForwarder
CR 的命名空间必须是
openshift-logging
。
指定输出的名称。
将类型指定为
"loki"
。
将 Loki 系统的 URL 和端口指定为有效的绝对 URL。您可以使用
http
（不安全）或
https
（安全 HTTP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。
对于安全连接，您可以通过指定
secret
来指定您进行身份验证的
https
或
http
URL。
对于
https
前缀，请指定 TLS 通信端点所需的 secret 名称。secret 必须存在于
openshift-logging
项目中，且必须具有指向它们所代表的相应证书的：
tls.crt
、
tls.key
和
ca-bundle.crt
的密钥。否则，对于
http
和
https
前缀，您可以指定一个包含用户名和密码的 secret。如需更多信息，请参阅以下"示例：设置包含用户名和密码的 secret"。
可选：指定管道的名称。
使用管道指定要转发的日志类型：
application
、
infrastructure
或
audit
。
指定使用此管道转发日志时使用的输出名称。
可选：指定一个 meta-data key 字段，为 Loki 中的
TenantID
字段生成值。例如，设置
tenantKey: kubernetes.namespace_name
使用 Kubernetes 命名空间的名称作为 Loki 中的租户 ID 的值。要查看您可以指定的其他日志记录字段，请查看以下"Additional resources"部分中的"Log Record Fields"链接。
可选：指定一个 meta-data 字段键列表来替换默认的 Loki 标签。Loki 标签名称必须与正则表达式
[a-zA-Z_:][a-zA-Z0-9_:]*
匹配。元数据键中的非法字符会替换为
_
以组成标签名称。例如，
kubernetes.labels.foo
meta-data 键变成 Loki 标签
kubernetes_labels_foo
。如果没有设置
labelKeys
，则默认值为：
[log_type, kubernetes.namespace_name, kubernetes.pod_name, kubernetes_host]
。尽量保持标签数量少，因为 Loki 会限制允许标签的大小和数量。请参阅
配置 Loki、limit_config
。您仍然可以使用查询过滤器基于任何日志记录字段进行查询。
由于 Loki 要求按时间戳正确排序日志流，
labelKeys
始终包含
kubernetes_host
标签，即使您没有指定它。此包含确保每个流源自单一主机，这样可防止因为不同主机上的时钟差异而导致时间戳出现问题。
创建 CR 对象。
$ oc create -f <file-name>.yaml
7.12.1. 对 Loki "entry out of order" 进行故障排除
如果您的 Fluentd 将大量信息转发到超过速率限制的 Loki 日志记录系统，Locki 会生成 "entry out of order" 错误。要解决这个问题，您需要更新 Loki 服务器配置文件中
loki.yaml
中的一些值。
loki.yaml
在 Grafana 托管的 Loki 中不可用。本主题不适用于 Grafana 托管的 Loki 服务器。
Conditions
-
ClusterLogForwarder
自定义资源配置为将日志转发到 Loki。
您的系统向 Loki 发送大于 2 MB 的信息块，例如：
"values":[["1630410392689800468","{\"kind\":\"Event\",\"apiVersion\":\
.......
......
......
......
\"received_at\":\"2021-08-31T11:46:32.800278+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-31T11:46:32.799692+00:00\",\"viaq_index_name\":\"audit-write\",\"viaq_msg_id\":\"MzFjYjJkZjItNjY0MC00YWU4LWIwMTEtNGNmM2E5ZmViMGU4\",\"log_type\":\"audit\"}"]]}]}
-
当您进入
oc logs -c fluentd
时，OpenShift Logging 集群中的 Fluentd 日志会显示以下信息：
429 Too Many Requests Ingestion rate limit exceeded (limit: 8388608 bytes/sec) while attempting to ingest '2140' lines totaling '3285284' bytes
429 Too Many Requests Ingestion rate limit exceeded' or '500 Internal Server Error rpc error: code = ResourceExhausted desc = grpc: received message larger than max (5277702 vs. 4194304)'
-
当您在 Loki 服务器上打开日志时，它们会显示
entry out of order
信息，类似：
,\nentry with timestamp 2021-08-18 05:58:55.061936 +0000 UTC ignored, reason: 'entry out of order' for stream:
{fluentd_thread=\"flush_thread_0\", log_type=\"audit\"},\nentry with timestamp 2021-08-18 06:01:18.290229 +0000 UTC ignored, reason: 'entry out of order' for stream: {fluentd_thread="flush_thread_0", log_type="audit"}
流程
-
使用此处所示的值更新 Loki 服务器上的
loki.yaml
配置文件中的以下字段：
grpc_server_max_recv_msg_size: 8388608
chunk_target_size: 8388608
ingestion_rate_mb: 8
ingestion_burst_size_mb: 16
将
loki.yaml
中的更改应用到 Loki 服务器。
您可以使用 Cluster Log Forwarder 将应用日志的副本从特定项目发送到外部日志聚合器。除了使用默认的 Elasticsearch 日志存储外，您还可以进行此操作。您还必须配置外部日志聚合器，以接收来自 OpenShift Container Platform 的日志数据。
要从项目中配置转发应用程序日志，创建一个
ClusterLogForwarder
自定义资源（CR），其中至少从一个项目中输入，为其他日志聚合器提供可选输出，以及使用这些输入和输出的管道。
您必须有配置为使用指定协议或格式接收日志数据的日志服务器。
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件：
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
name: instance 1
namespace: openshift-logging 2
spec:
outputs:
- name: fluentd-server-secure 3
type: fluentdForward 4
url: 'tls://fluentdserver.security.example.com:24224' 5
secret: 6
name: fluentd-secret
- name: fluentd-server-insecure
type: fluentdForward
url: 'tcp://fluentdserver.home.example.com:24224'
inputs: 7
- name: my-app-logs
application:
namespaces:
- my-project
pipelines:
- name: forward-to-fluentd-insecure 8
inputRefs: 9
- my-app-logs
outputRefs: 10
- fluentd-server-insecure
parse: json 11
labels:
project: "my-project" 12
- name: forward-to-fluentd-secure 13
inputRefs:
- application
- audit
- infrastructure
outputRefs:
- fluentd-server-secure
- default
labels:
clusterId: "C1234"
-
1
-
ClusterLogForwarder
CR 的名称必须是
instance
。
ClusterLogForwarder
CR 的命名空间必须是
openshift-logging
。
指定输出的名称。
指定输出类型：
elasticsearch
、
fluentdForward
、
syslog
或
kafka
。
将外部日志聚合器的 URL 和端口指定为有效的绝对 URL。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。
如果使用
tls
前缀，您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于
openshift-logging
项目中，并具有每个指向它们所代表证书的
tls.crt
、
tls.key
和
ca-bundle.crt
密钥。
用于过滤指定项目的应用程序日志的输入配置。
管道配置，使用输入将项目应用程序日志发送到外部 Fluentd 实例。
my-app-logs
输入。
要使用的输出名称。
可选：指定是否转发结构化 JSON 日志条目作为
structured
项中的 JSON 对象。日志条目必须包含有效的结构化 JSON；否则，OpenShift Logging 会删除
structured
字段，并将日志条目发送到默认索引
app-00000x
。
可选：字符串。要添加到日志中的一个或多个标签。
管道配置，将日志发送到其他日志聚合器。
可选：指定管道的名称。
使用管道指定要转发的日志类型：
application
、
infrastructure
或
audit
。
指定使用此管道转发日志时使用的输出名称。
可选：指定将日志转发到内部 Elasticsearch 实例的
default
输出。
可选：字符串。要添加到日志中的一个或多个标签。
创建 CR 对象。
$ oc create -f <file-name>.yaml
作为集群管理员，您可以使用 Kubernetes pod 标签从特定 pod 收集日志数据并将其转发到日志收集器。
假设您的应用由容器集组成，并与不同命名空间中的其他容器集一起运行。如果这些 pod 具有标识应用程序标签，您可以收集和输出其日志数据到特定的日志收集器。
要指定 pod 标签，请使用一个或多个
matchLabels
键值对。如果指定了多个键值对，pod 必须与要选择的所有值匹配。
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件。在文件中，使用
inputs[].name.application.selector.matchLabels
下的简单基于平等的选择器来指定 pod 标签，如下例所示。
创建 CR 对象。
$ oc create -f <file-name>.yaml
其他资源
-
如需有关 Kubernetes 中
matchLabels
的更多信息，请参阅
支持基于集合的要求
的资源。
您可以从 OVN-Kubernetes pod 上的
/var/log/ovn/acl-audit-log.log
文件中收集 OVN 网络策略审计日志，并将它们转发到日志记录服务器。
您使用 OpenShift Container Platform 版本 4.8 或更高版本。
您使用集群日志记录 5.2 或更高版本。
您已设置了一个
ClusterLogForwarder
自定义资源 (CR) 对象。
OpenShift Container Platform 集群是为 OVN-Kubernetes 网络策略审计日志配置的。请参阅以下"附加资源"部分。
通常，存储审计数据的服务器必须符合企业及政府对合规性和安全性的要求。
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件，如将日志转发到第三方系统的其他主题中所述。
在 YAML 文件中，将
audit
日志类型添加到管道中的
inputRefs
元素中。例如：
pipelines:
- name: audit-logs
inputRefs:
- audit 1
outputRefs:
- secure-logging-server 2
-
1
-
将
audit
指定为要输入的日志类型之一。
指定连接到您的日志记录服务器的输出。
重新创建更新的 CR 对象：
$ oc create -f <file-name>.yaml
当您创建
ClusterLogForwarder
自定义资源 (CR) 时，如果 Red Hat OpenShift Logging Operator 没有自动重新部署 Fluentd Pod，您可以删除 Fluentd Pod 来强制重新部署它们。
您已创建了
ClusterLogForwarder
自定义资源 (CR) 对象。
删除 Fluentd Pod 以强制重新部署。
$ oc delete pod --selector logging-infra=collector
您可以配置 Log Forwarding API，将 JSON 字符串解析为结构化对象。
包含 JSON 日志的日志通常以
message
字段中的字符串表示。这使得用户难以查询 JSON 文档中的特定字段。OpenShift Logging 的 Log Forwarding API 可让您将 JSON 日志解析到结构化对象，并将其转发到 OpenShift Logging 管理的 Elasticsearch 或 Log Forwarding API 支持的任何其他第三方系统。
为了说明其工作原理，假定您有以下结构化 JSON 日志条目：
8.2. 为 Elasticsearch 配置 JSON 日志数据
如果您的 JSON 日志遵循多个模式，在单个索引中存储它们可能会导致类型冲突和卡性问题。要避免这种情况，您必须配置
ClusterLogForwarder
自定义资源 (CR)，将每个 schema 分组到单个输出定义中。这样，每个架构被转发到单独的索引。
如果您将 JSON 日志转发到 OpenShift Logging 管理的默认 Elasticsearch 实例，它会根据您的配置生成新的索引。为避免与索引数量过多相关的性能问题，请考虑通过标准化到常见模式来保持可能的模式数量较低。
您可以使用
ClusterLogForwarder
CR 中的以下结构类型来为 Elasticsearch 日志存储构建索引名称：
structTypeKey
（字符串，可选）是消息字段的名称。如果存在该字段的值，则用于构造索引名称。
kubernetes.labels.<key>
是 Kubernetes pod 标签，其值用于构造索引名称。
openshift.labels.<key>
是
ClusterLogForwarder
CR 中的
pipeline.label.<key>
元素，其值用于构造索引名称。
kubernetes.container_name
使用容器名称来构造索引名称。
structTypeName
：（字符串，可选）如果未设置
structTypeKey
，或者其键不存在，OpenShift Logging 将
structTypeName
的值用作结构化类型。当同时使用
structuredTypeKey
和
structuredTypeName
时，如果 JSON 日志数据中缺少
structuredTypeKey
中的键，则
structTypeName
提供一个回退索引名称。
虽然您可以将
structuredTypeKey
的值设置为 "Log Record Fields" 主题中显示的任何字段，但最有用的字段将显示在前面的结构类型列表中。
outputDefaults:
elasticsearch:
structuredTypeKey: kubernetes.labels.logFormat 1
structuredTypeName: nologformat
pipelines:
- inputRefs: <application>
outputRefs: default
parse: json 2
-
1
-
使用 Kubernetes
logFormat
标签形成的键值对值。
启用解析 JSON 日志。
在这种情况下，以下结构化日志记录进入
app-apache-write
索引：
"structured":{"name":"fred","home":"bedrock"},
"kubernetes":{"labels":{"logFormat": "apache", ...}}
以下结构化日志记录进入
app-google-write
索引中：
"structured":{"name":"wilma","home":"bedrock"},
"kubernetes":{"labels":{"logFormat": "google", ...}}
}
outputDefaults:
elasticsearch:
structuredTypeKey: openshift.labels.myLabel 1
structuredTypeName: nologformat
pipelines:
- name: application-logs
inputRefs:
- application
- audit
outputRefs:
- elasticsearch-secure
- default
parse: json
labels:
myLabel: myValue 2
-
1
-
使用由 OpenShift
myLabel
标签组成的键值对的值。
myLabel
元素将字符串值
myValue
提供给结构化日志消息。
在这种情况下，以下结构化日志记录进入
app-myValue-write
索引中：
"structured":{"name":"fred","home":"bedrock"},
"openshift":{"labels":{"myLabel": "myValue", ...}}
}
其他注意事项
-
结构化记录的 Elasticsearch
索引
通过将"app-"添加到结构化类型并附加 "-write" 来形成。
非结构化记录不会发送到结构化索引。在应用、基础架构或审计索引中，它们按照常态进行索引。
如果没有非空的结构化类型，则转发一个没有
structured
项的
unstructured
记录。
不要过载有太多索引的 Elasticsearch。仅对不同的日志
格式
使用不同的结构化类型，而
不用
为每个应用程序或命名空间都使用不同的结构化类型。例如，大多数 Apache 应用使用相同的 JSON 日志格式和结构化类型，如
LogApache
。
8.3. 将 JSON 日志转发到 Elasticsearch 日志存储
对于 Elasticsearch 日志存储，如果您的 JSON 日志条目
遵循不同的模式
，请将
ClusterLogForwarder
自定义资源 (CR) 配置为将每个 JSON 模式分组到单个输出定义中。这样，Elasticsearch 会为每个 schema 使用一个单独的索引。
因为将不同的模式转发到同一索引可能会导致类型冲突和卡化问题，所以您必须在将数据转发到 Elasticsearch 存储前执行此配置。
为避免与索引数量过多相关的性能问题，请考虑通过标准化到常见模式来保持可能的模式数量较低。
将以下代码片段添加到
ClusterLogForwarder
CR YAML 文件中。
outputDefaults:
elasticsearch:
structuredTypeKey: <log record field>
structuredTypeName: <name>
pipelines:
- inputRefs:
- application
outputRefs: default
parse: json
可选：使用
structTypeKey
指定其中一个日志记录字段，如前面的
为 Elasticsearch 配置 JSON 日志数据
所述。否则，删除此行。
可选：使用
structTypeName
指定
<name>
，如前面的
为 Elasticsearch 配置 JSON 日志数据
所述。否则，删除此行。
要解析 JSON 日志，您必须设置
structuredTypeKey
或
structuredTypeName
，或者同时设置
structuredTypeKey
和
structuredTypeName
。
对于
inputRefs
，指定要使用该管道转发哪些日志类型，如
application
、
infrastructure
或
audit
。
将
parse: json
元素添加到管道。
创建 CR 对象。
$ oc create -f <file-name>.yaml
Red Hat OpenShift Logging Operator 会重新部署 Fluentd Pod。但是，如果没有重新部署，请删除 Fluentd Pod 以强制重新部署。
$ oc delete pod --selector logging-infra=collector
第 9 章 收集并存储 Kubernetes 事件
OpenShift Container Platform 事件路由器是一个 pod，它监视 Kubernetes 事件，并将 OpenShift Logging 收集的数据记录到日志中。您必须手动部署 Event Router。
Event Router 从所有项目收集事件，并将其写入
STDOUT
。Fluentd 收集这些事件并将其转发到 OpenShift Container Platform Elasticsearch 实例。Elasticsearch 将事件索引到
infra
索引。
事件路由器为 Fluentd 增加额外的负载，并可能会影响其他可以被处理的日志消息数量。
使用以下步骤将事件路由器部署到集群中。您应该始终将 Event Router 部署到
openshift-logging
项目，以确保其从集群中收集事件。
以下 Template 对象创建事件路由器所需的服务帐户、集群角色和集群角色绑定。模板还会配置和部署 Event Router pod。您可以使用此模板而无需更改，或更改部署对象 CPU 和内存请求。
需要适当的权限，以便能创建服务帐户和更新集群角色绑定。例如，您可以使用具有
cluster-admin
角色的用户来运行以下模板。
必须安装 OpenShift Logging。
为事件路由器创建模板：
kind: Template
apiVersion: template.openshift.io/v1
metadata:
name: eventrouter-template
annotations:
description: "A pod forwarding kubernetes events to OpenShift Logging stack."
tags: "events,EFK,logging,cluster-logging"
objects:
- kind: ServiceAccount 1
apiVersion: v1
metadata:
name: eventrouter
namespace: ${NAMESPACE}
- kind: ClusterRole 2
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: event-reader
rules:
- apiGroups: [""]
resources: ["events"]
verbs: ["get", "watch", "list"]
- kind: ClusterRoleBinding 3
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: event-reader-binding
subjects:
- kind: ServiceAccount
name: eventrouter
namespace: ${NAMESPACE}
roleRef:
kind: ClusterRole
name: event-reader
- kind: ConfigMap 4
apiVersion: v1
metadata:
name: eventrouter
namespace: ${NAMESPACE}
data:
config.json: |-
"sink": "stdout"
- kind: Deployment 5
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:
requests:
cpu: ${CPU}
memory: ${MEMORY}
volumeMounts:
- name: config-volume
mountPath: /etc/eventrouter
volumes:
- name: config-volume
configMap:
name: eventrouter
parameters:
- name: IMAGE 6
displayName: Image
value: "registry.redhat.io/openshift-logging/eventrouter-rhel8:v0.3"
- name: CPU 7
displayName: CPU
value: "100m"
- name: MEMORY 8
displayName: Memory
value: "128Mi"
- name: NAMESPACE
displayName: Namespace
value: "openshift-logging" 9
-
1
-
在
openshift-logging
项目中为事件路由器创建一个服务帐户。
创建用于监控集群中事件的 ClusterRole。
创建一个 ClusterRoleBinding 将 ClusterRole 绑定到服务帐户。
在
openshift-logging
项目中创建一个配置映射来生成所需的
config.json
文件。
在
openshift-logging
项目中创建一个部署，以生成并配置 Event Router pod。
指定镜像，由标签标识，如
v0.3
。
指定分配给事件路由器 pod 的最小内存量。默认值为
128Mi
。
指定分配给事件路由器 pod 的最小 CPU 量。默认值为
100m
。
指定要在其中安装对象的
openshift-logging
项目。
使用以下命令来处理和应用模板：
$ oc process -f <templatefile> | oc apply -n openshift-logging -f -
$ oc process -f eventrouter.yaml | oc apply -n openshift-logging -f -
第 10 章 更新 OpenShift Logging
表 10.1. OpenShift Container Platform 版本支持 Red Hat OpenShift Logging (RHOL)
|
|
4.7
|
4.8
|
4.9
|
|
RHOL 5.1
RHOL 5.2
RHOL 5.3
要将 OpenShift Container Platform 版本 4.6 及更早版本的集群日志记录升级到 OpenShift Logging 5.x，您需要将 OpenShift Container Platform 集群更新至版本 4.7 或 4.8。然后，您更新以下 operator：
从 Elasticsearch Operator 4.x 到 OpenShift Elasticsearch Operator 5.x
从 Cluster Logging Operator 4.x 到 Red Hat OpenShift Logging Operator 5.x
要从 OpenShift Logging 的旧版本升级到当前版本，您需要将 OpenShift Elasticsearch Operator 和 Red Hat OpenShift Logging Operator 更新至当前版本。
10.1. 从 OpenShift Container Platform 4.6 或更早版本的集群日志记录升级到 OpenShift Logging 5.x
OpenShift Container Platform 4.7 进行了以下名称更改：
集群日志记录
功能成为
Red Hat OpenShift Logging
5.x 产品。
Cluster Logging
Operator 成为
Red Hat OpenShift Logging
Operator。
Elasticsearch
Operator 成为
OpenShift Elasticsearch
Operator。
要将 OpenShift Container Platform 版本 4.6 及更早版本的集群日志记录升级到 OpenShift Logging 5.x，您需要将 OpenShift Container Platform 集群更新至版本 4.7 或 4.8。然后，您更新以下 operator：
从 Elasticsearch Operator 4.x 到 OpenShift Elasticsearch Operator 5.x
从 Cluster Logging Operator 4.x 到 Red Hat OpenShift Logging Operator 5.x
在更新 Red Hat OpenShift Logging Operator
前
，您必须更新 OpenShift Elasticsearch Operator。您还必须将
两个
Operator 更新至同一版本。
如果您以错误的顺序更新 Operator，则 Kibana 不会更新，并且不会创建 Kibana 自定义资源 (CR)。要临时解决这个问题，请删除 Red Hat OpenShift Logging Operator pod。当 Red Hat OpenShift Logging Operator pod 重新部署时，它会创建 Kibana CR 和 Kibana 再次可用。
OpenShift Container Platform 版本为 4.7 或更高版本。
OpenShift Logging 处于健康状态：
所有 pod 都为
Ready
状态。
Elasticsearch 集群处于健康状态。
您的 Elasticsearch 和 Kibana 数据已被备份。
更新 OpenShift Elasticsearch Operator:
在 Web 控制台中，点
Operators
→
Installed Operators
。
选择
openshift-operators-redhat
项目。
点
OpenShift Elasticsearch Operator
。
点
Subscription
→
Channel
。
在
Change Subscription Update Channel
窗口中，选择
5.0
或
stable-5.x
并点
Save
。
等待几秒钟，然后点
Operators
→
Installed Operators
。
验证 OpenShift Elasticsearch Operator 版本是否为 5.x.x。
等待
Status
的值变为
Succeeded
。
更新 Cluster Logging Operator：
在 Web 控制台中，点
Operators
→
Installed Operators
。
选择
openshift-logging
项目。
点
Cluster Logging Operator
。
点
Subscription
→
Channel
。
在
Change Subscription Update Channel
窗口中，选择
5.0
或
stable-5.x
并点
Save
。
等待几秒钟，然后点
Operators
→
Installed Operators
。
验证 Red Hat OpenShift Logging Operator 版本是否为 5.0.x 或 5.x.x。
等待
Status
的值变为
Succeeded
。
检查日志记录组件：
确保所有 Elasticsearch pod 都处于
Ready
状态：
$ oc get pod -n openshift-logging --selector component=elasticsearch
10.2. 将 OpenShift Logging 更新至当前版本
要将 OpenShift Logging 从 5.x 更新至当前版本，您需要更改 OpenShift Elasticsearch Operator 和 Red Hat OpenShift Logging Operator 的订阅。
在更新 Red Hat OpenShift Logging Operator
前
，您必须更新 OpenShift Elasticsearch Operator。您还必须将
两个
Operator 更新至同一版本。
如果您以错误的顺序更新 Operator，则 Kibana 不会更新，并且不会创建 Kibana 自定义资源 (CR)。要临时解决这个问题，请删除 Red Hat OpenShift Logging Operator pod。当 Red Hat OpenShift Logging Operator pod 重新部署时，它会创建 Kibana CR 和 Kibana 再次可用。
OpenShift Container Platform 版本为 4.7 或更高版本。
OpenShift Logging 处于健康状态：
所有 pod 都为
Ready
状态。
Elasticsearch 集群处于健康状态。
您的 Elasticsearch 和 Kibana 数据已被备份。
更新 OpenShift Elasticsearch Operator:
在 Web 控制台中，点
Operators
→
Installed Operators
。
选择
openshift-operators-redhat
项目。
点
OpenShift Elasticsearch Operator
。
点
Subscription
→
Channel
。
在
Change Subscription Update Channel
窗口中，选择
stable-5.x
并点
Save
。
等待几秒钟，然后点
Operators
→
Installed Operators
。
验证 OpenShift Elasticsearch Operator 版本是否为 5.x.x。
等待
Status
的值变为
Succeeded
。
更新 Red Hat OpenShift Logging Operator：
在 Web 控制台中，点
Operators
→
Installed Operators
。
选择
openshift-logging
项目。
点
Red Hat OpenShift Logging Operator
。
点
Subscription
→
Channel
。
在
Change Subscription Update Channel
窗口中，选择
stable-5.x
并点
Save
。
等待几秒钟，然后点
Operators
→
Installed Operators
。
验证 Red Hat OpenShift Logging Operator 版本是否为 5.x.x。
等待
Status
的值变为
Succeeded
。
检查日志记录组件：
确保所有 Elasticsearch pod 都处于
Ready
状态：
$ oc get pod -n openshift-logging --selector component=elasticsearch
OpenShift Container Platform web 控制台中的
Logging/Elasticsearch Nodes
和
Openshift Logging
仪表板显示有关 Elasticsearch 实例以及用于防止和诊断问题的单个 Elasticsearch 节点的详细信息。
OpenShift Logging
仪表板包含 chart，在集群级别显示 Elasticsearch 实例的详情，包括集群资源、垃圾回收、集群中的分片和 Fluentd 统计。
Logging/Elasticsearch Nodes
仪表板包含 charts，显示 Elasticsearch 实例的详情，很多在节点级别，包括索引、分片、资源等详情。
如需更多详细数据，请点击仪表板中的
Grafana UI
链接来启动 Grafana 仪表板。Grafana 由
OpenShift 集群监控
提供。
11.1. 访问 Elastisearch 和 OpenShift Logging 仪表板
您可以在 OpenShift Container Platform web 控制台中查看
Logging/Elasticsearch Nodes
和
OpenShift Logging
仪表板。
启动仪表板：
在 OpenShift Container Platform web 控制台中点
Monitoring
→
Dashboards
。
在
Dashboards
页面中，从
Dashboard
菜单中选择
Logging/Elasticsearch Nodes
或
OpenShift Logging
。
对于
Logging/Elasticsearch Nodes
仪表板，可以选择您要查看的 Elasticsearch 节点并设置数据解析。
此时会显示正确的仪表板，显示多个数据图表。
可选：从
Time Range
和
Refresh Interval
菜单中选择不同时间范围来显示或刷新数据。
如需了解更多详细数据，请点
Grafana UI
链接来启动 Grafana 仪表板。
有关仪表板图表的信息，请参阅
关于 OpenShift Logging 仪表板
和
关于 Logging/Elastisearch Nodes 仪表板
。
11.2. 关于 OpenShift Logging 仪表板
OpenShift Logging
仪表板包含 chart，可在集群级别显示 Elasticsearch 实例的详情，用于诊断和预期问题。
表 11.1. OpenShift Logging chart
|
指标
|
描述
|
|
Elastic 集群状态
当前的 Elasticsearch 状态：
ONLINE - 表示 Elasticsearch 实例在线。
OFFLINE - 表示 Elasticsearch 实例离线。
Elasticsearch 实例中的 Elasticsearch 节点总数。
Elastic 分片
Elasticsearch 实例中的 Elasticsearch 分片的总数。
Elastic 文档
Elasticsearch 实例中的 Elasticsearch 文档总数。
磁盘上的总索引大小
正在用于 Elasticsearch 索引的总磁盘空间。
Elastic 待处理的任务
Elasticsearch 尚未完成的更改总数，如索引创建、索引映射、分片分配或分片失败。
Elastic JVM GC 时间
JVM 在集群中执行 Elasticsearch 垃圾回收操作所需的时间。
Elastic JVM GC 率
JVM 每秒执行垃圾操作的次数总数。
Elastic Query/Fetch Latency Sum
Query latency:Elasticsearch 搜索查询执行的平均时间。
获取延迟：每个 Elasticsearch 搜索查询的平均时间获取数据。
获取延迟的时间通常比查询延迟要短。如果抓取延迟持续增加，则代表磁盘、数据配置速度较慢，或者带有许多结果的大量请求。
Elastic 查询率
每个 Elasticsearch 节点每秒对 Elasticsearch 实例执行的查询总数。
Elasticsearch、Fluentd 和 Kibana 使用的 CPU 数量，显示了各个组件的 CPU 数量。
已使用的 Elastic JVM Heap
使用的 JVM 内存量。在一个健康的集群中，图形显示由 JVM 垃圾回收所释放的内存。
Elasticsearch 磁盘使用量
Elasticsearch 实例用于每个 Elasticsearch 节点的总磁盘空间。
使用中的文件描述符
Elasticsearch、Fluentd 和 Kibana 使用的文件描述符总数。
Fluentd emit 数量
Fluentd 默认输出每秒的 Fluentd 消息总数，以及默认输出的重试计数。
Fluentd 缓冲可用性
用于块的 Fluentd 缓冲的百分比。完整缓冲可能表示 Fluentd 无法处理收到的日志数量。
Elastic rx 字节
Elasticsearch 提供的 FluentD、Elasticsearch 节点和其它源的字节总数。
Elastic Index Failure Rate
Elasticsearch 索引失败的每秒总次数。高速率表示索引时出现问题。
Fluentd 输出错误率
FluentD 无法输出日志的每秒总次数。
|
11.3. Logging/Elasticsearch 节点仪表板上的图表
Logging/Elasticsearch Nodes
仪表板包含 charts，显示 Elasticsearch 实例的详情（很多在节点级别），以进行进一步诊断。
-
Elasticsearch 状态
-
Logging/Elasticsearch Nodes
仪表板包含有关 Elasticsearch 实例状态的以下图表。
表 11.2. Elasticsearch 状态字段
|
指标
|
描述
|
|
在所选时间段内的集群健康状态，使用 Elasticsearch 绿色、黄色和红色代表：
0 - 表示 Elasticsearch 实例处于绿色状态，这意味着分配了所有分片。
1 - 表示 Elasticsearch 实例处于黄色状态，这意味着至少一个分片的副本分片不会被分配。
2 - 表示 Elasticsearch 实例处于红色状态，这意味着至少不分配一个主分片及其副本。
集群中的 Elasticsearch 节点总数。
集群数据节点
集群中的 Elasticsearch 数据节点数量。
集群待定任务
集群状态更改的数量，这些更改尚未完成，并在集群队列中等待，例如索引创建、索引删除或分片分配。增长的倾向表示集群无法跟上变化。
|
-
Elasticsearch 集群索引分片状态
-
每个 Elasticsearch 索引都是一个或多个分片的逻辑组，它们是持久化数据的基本单元。索引分片有两种类型：主分片和副本分片。当将文档索引为索引时，会将其保存在其主分片中，并复制到该分片的每个副本中。当索引被创建时，主分片的数量会被指定，在索引生命周期内这个数量不能改变。您可以随时更改副本分片的数量。
索引分片可能处于几个状态，具体取决于其生命周期阶段或集群中发生的事件。当分片能够执行搜索和索引请求时，分片就是活跃的。如果分片无法执行这些请求，分片就不是活跃的。如果分片正在初始化、重新分配、取消分配等等，分片可能不是活跃的。
索引分片由多个较小的内部块组成，称为索引片段，它们是数据的物理表示。索引分段是一个相对较小的不可变 Lucene 索引，它是 Lucene 提交新索引数据时生成的。Lucene 是 Elasticsearch 使用的搜索库，将索引片段合并到后台里的较大片段，从而使片段总数较低。如果合并片段的过程比生成新网段的速度慢，则可能表明问题。
当 Lucene 执行数据操作（如搜索操作）时，Lucene 会根据相关索引中的索引片段执行操作。为此，每个片段都包含在内存中载入并映射的特定数据结构。索引映射会对片段数据结构使用的内存有重大影响。
Logging/Elasticsearch Nodes
仪表板包含有关 Elasticsearch 索引分片的以下图表。
表 11.3. Elasticsearch 集群分片状态 chart
|
指标
|
描述
|
|
集群活跃分片
集群中活跃的主分片的数量和分片（包括副本）的总数。如果分片数量增加，集群性能就可以启动它。
集群初始化分片
集群中的非活跃分片数量。非活跃分片是正在初始化、被重新分配到不同节点或未分配的分片。集群通常具有非活跃分片（non-active 分片）的短时间。较长时间的非活跃分片数量增加可能代表有问题。
集群重新定位分片
Elasticsearch 重新定位到新节点的分片数量。Elasticsearch 由于多个原因重新定位节点，如在一个节点上或向集群中添加新节点时使用高内存。
集群未分配分片
未分配分片的数量。由于添加新索引或节点失败等原因，Elasticsearch 分片可能没有被分配。
|
-
Elasticsearch 节点指标
-
每个 Elasticsearch 节点都有有限的资源，可用于处理任务。当所有资源都被已被使用，Elasticsearch 尝试执行新任务时，Elasticsearch 会将任务放入队列等待出现可用的资源。
Logging/Elasticsearch Nodes
仪表板包含以下有关所选节点的资源使用情况，以及 Elasticsearch 队列中等待的任务数量的图表。
表 11.4. Elasticsearch 节点指标图表
|
指标
|
描述
|
|
ThreadPool 任务
按任务类型显示的独立队列中等待的任务数量。在任何队列中的长期任务可能意味着节点资源短缺或其他问题。
CPU 用量
所选 Elasticsearch 节点使用的 CPU 量作为分配给主机容器的 CPU 总量的百分比。
所选 Elasticsearch 节点使用的内存量。
所选 Elasticsearch 节点上用于索引数据和元数据的总磁盘空间。
文档索引率
文档在所选 Elasticsearch 节点上索引的频率。
在所选 Elasticsearch 节点上索引文档所需时间。索引延迟会受到很多因素的影响，如 JVM Heap 内存和整个负载。延迟增加代表实例中资源容量不足。
在所选 Elasticsearch 节点上运行的搜索请求数量。
在所选 Elasticsearch 节点上完成搜索请求的时间。搜索延迟可能会受到很多因素的影响。延迟增加代表实例中资源容量不足。
文档计数（包括副本）
存储在所选 Elasticsearch 节点上的 Elasticsearch 文档数量，包括存储在主分片和节点上分配的副本分片中的文档。
文档删除速率
要从分配给所选 Elasticsearch 节点的任何索引分片中删除 Elasticsearch 文档的数量。
文档合并率
分配给所选 Elasticsearch 节点的任何索引分片中合并的 Elasticsearch 文档数量。
|
-
Elasticsearch 节点 fielddata
-
Fielddata
是一个 Elasticsearch 数据结构，它以索引形式保存术语列表，并保存在 JVM 堆中。因为 fielddata 构建非常昂贵，所以 Elasticsearch 会缓存 fielddata 结构。当底层索引分段被删除或合并时，或者没有足够 JVM HEAP 内存用于所有 fielddata 缓存时，Elasticsearch 可以驱除 fielddata 缓存,。
Logging/Elasticsearch Nodes
仪表板包含有关 Elasticsearch 字段数据的以下图表。
表 11.5. Elasticsearch 节点字段数据图表
|
指标
|
描述
|
|
Fielddata 内存大小
用于所选 Elasticsearch 节点上的 fielddata 缓存的 JVM 堆数量。
Fielddata 驱除
从所选 Elasticsearch 节点中删除的 fielddata 结构数量。
|
-
Elasticsearch 节点查询缓存
-
如果索引中存储的数据没有改变，搜索查询结果会在节点级别的查询缓存中缓存，以便 Elasticsearch 重复使用。
Logging/Elasticsearch Nodes
仪表板包含有关 Elasticsearch 节点查询缓存的以下图表。
表 11.6. Elasticsearch 节点查询图表
|
指标
|
描述
|
|
查询缓存大小
用于查询缓存的内存总量，用于分配给所选 Elasticsearch 节点的所有分片。
查询缓存驱除
所选 Elasticsearch 节点上的查询缓存驱除数量。
查询缓存点击
所选 Elasticsearch 节点上的查询缓存数量。
查询缓存丢失
所选 Elasticsearch 节点上丢失的查询缓存数。
|
-
Elasticsearch 索引节流
-
在索引文档时，Elasticsearch 将文档存储在索引片段中，这些部分是数据的物理表示。同时，Elasticsearch 会定期将较小的片段合并到较大的片段中，以优化资源使用。如果索引速度更快，那么合并过程就无法迅速完成，从而导致搜索和性能出现问题。为了防止这种情况，Elasticsearch 节流（throttles）的索引通常是通过减少分配给索引到单个线程的线程数量来实现的。
Logging/Elasticsearch Nodes
仪表板包含有关 Elasticsearch 索引节流的以下图表。
表 11.7. 索引节流图表
|
指标
|
描述
|
|
Elasticsearch 在所选 Elasticsearch 节点上节流索引操作的时间。
Elasticsearch 在所选 Elasticsearch 节点上节流部署片段合并操作的时间。
|
-
节点 JVM 堆统计
-
Logging/Elasticsearch Nodes
仪表板包含以下有关 JVM Heap 操作的图表。
表 11.8. JVM Heap 统计图表
|
指标
|
描述
|
|
所选 Elasticsearch 节点上分配的 JVM 堆空间量。
GC 计数
在所选 Elasticsearch 节点上运行的垃圾回收操作数量，包括旧垃圾回收量。
GC 时间
JVM 在所选 Elasticsearch 节点上运行垃圾回收操作的时间、旧的垃圾回收时间。
|
12.1. 查看 OpenShift Logging 状态
您可以查看 Red Hat OpenShift Logging Operator 的状态以及多个 OpenShift Logging 组件的状态。
12.1.1. 查看 Red Hat OpenShift Logging Operator 的状态
您可以查看 Red Hat OpenShift Logging Operator 的状态。
必须安装 OpenShift Logging 和 Elasticsearch。
进入
openshift-logging
项目。
$ oc project openshift-logging
查看 OpenShift Logging 状态：
获取 OpenShift Logging 状态：
$ oc get clusterlogging instance -o yaml
以下是来自 OpenShift Logging 实例的
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
类似于以下内容的状态消息表示无法调度 Fluentd Pod，因为节点选择器与任何节点都不匹配：
Status:
Collection:
Logs:
Fluentd Status:
Daemon Set: fluentd
Nodes:
Pods:
Failed:
Not Ready:
Ready:
12.1.2. 查看 OpenShift Logging 组件的状态
您可以查看多个 OpenShift Logging 组件的状态。
必须安装 OpenShift Logging 和 Elasticsearch。
进入
openshift-logging
项目。
$ oc project openshift-logging
查看 OpenShift Logging 环境的状态：
$ oc describe deployment cluster-logging-operator
12.2. 查看 Elasticsearch 日志存储的状态
您可以查看 OpenShift Elasticsearch Operator 的状态以及多个 Elasticsearch 组件的状态。
您可以查看日志存储的状态。
必须安装 OpenShift Logging 和 Elasticsearch。
进入
openshift-logging
项目。
$ oc project openshift-logging
查看状态：
获取日志存储实例的名称：
$ oc get Elasticsearch
以下是来自 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 中的日志存储节点选择器与集群中的任何节点都不匹配：
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
以下状态消息表示日志存储 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
以下状态消息表示日志存储集群没有足够的节点来支持冗余策略。
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
此状态消息表示集群有太多 control plane 节点（也称为 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: InvalidMasters
以下状态消息表示 Elasticsearch 存储不支持您尝试进行的更改。
status:
clusterHealth: green
conditions:
- lastTransitionTime: "2021-05-07T01:05:13Z"
message: Changing the storage structure for a custom resource is not supported
reason: StorageStructureChangeIgnored
status: 'True'
type: StorageStructureChangeIgnored
reason
和
type
类型字段指定不受支持的更改类型：
-
StorageClassNameChangeIgnored
-
不支持更改存储类名称。
-
StorageSizeChangeIgnored
-
不支持更改存储大小。
-
StorageStructureChangeIgnored
-
不支持在临时存储结构和持久性存储结构间更改。
如果您将
ClusterLogging
自定义资源 (CR ) 配置为从临时切换到持久性存储，OpenShift Elasticsearch Operator 会创建一个持久性卷声明 (PVC)，但不创建持久性卷 (PV)。要清除
StorageStructureChangeIgnored
状态，您必须恢复对
ClusterLogging
CR 的更改并删除 PVC。
您可以查看多个日志存储组件的状态。
-
Elasticsearch 索引
-
您可以查看 Elasticsearch 索引的状态。
获取 Elasticsearch Pod 的名称：
$ oc get pods --selector component=elasticsearch -o name
-
日志存储 pod
-
您可以查看托管日志存储的 pod 的状态。
获取 Pod 的名称：
$ oc get pods --selector component=elasticsearch -o name
日志存储 pod 部署配置
您可以查看日志存储部署配置的状态。
获取部署配置的名称：
$ oc get deployment --selector component=elasticsearch -o name
日志存储副本集
您可以查看日志存储副本集的状态。
获取副本集的名称：
$ 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/openshift-logging/elasticsearch6-rhel8@sha256:4265742c7cdd85359140e2d7d703e4311b6497eec7676957f455d6908e7b1c25
Readiness: exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3
Events: <none>
12.2.3. Elasticsearch 集群状态
OpenShift Container Platform Web 控制台的
Monitoring
部分中的 Grafana 仪表板显示 Elasticsearch 集群的状态。
要获取 OpenShift Elasticsearch 集群的状态，请访问位于
<cluster_url>/monitoring/dashboards/grafana-dashboard-cluster-logging
的 OpenShift Container Platform Web 控制台的
Monitoring
部分中的 Grafana 仪表板。
Elasticsearch 状态字段
-
eo_elasticsearch_cr_cluster_management_state
-
显示 Elasticsearch 集群是否处于受管状态或非受管状态。例如：
eo_elasticsearch_cr_cluster_management_state{state="managed"} 1
eo_elasticsearch_cr_cluster_management_state{state="unmanaged"} 0
-
eo_elasticsearch_cr_restart_total
-
显示 Elasticsearch 节点重启证书、滚动重启或调度重启的次数。例如：
eo_elasticsearch_cr_restart_total{reason="cert_restart"} 1
eo_elasticsearch_cr_restart_total{reason="rolling_restart"} 1
eo_elasticsearch_cr_restart_total{reason="scheduled_restart"} 3
-
es_index_namespaces_total
-
显示 Elasticsearch 索引命名空间的总数。例如：
Total number of Namespaces.
es_index_namespaces_total 5
-
es_index_document_count
-
显示每个命名空间的记录数。例如：
es_index_document_count{namespace="namespace_1"} 25
es_index_document_count{namespace="namespace_2"} 10
es_index_document_count{namespace="namespace_3"} 5
message": "Secret \"elasticsearch\" fields are either missing or empty: [admin-cert, admin-key, logging-es.crt, logging-es.key]",
"reason": "Missing Required Secrets",
12.3. 了解 OpenShift Logging 警报
所有日志记录收集器警报都列在 OpenShift Container Platform Web 控制台的 Alerting UI 中。
警报显示在 OpenShift Container Platform web 控制台中,在 Alerting UI 的
Alerts
选项卡中显示。警报处于以下状态之一：
Firing
：在超时期限内警报条件为 true。点击在触发警报末尾的
Options
菜单，以查看更多信息或使警告静音。
Pending
：警报条件当前为 true，但尚未达到超时时间。
Not Firing
：当前未触发警报。
查看 OpenShift Logging 和其他 OpenShift Container Platform 警报：
在 OpenShift Container Platform 控制台中点
Monitoring
→
Alerting
。
点击
Alerts
标签页。根据所选择的过滤器，列出警报。
如需有关 Alerting UI 的更多信息，请参阅
管理警报
。
以下警报由日志记录收集器生成。您可以在 OpenShift Container Platform web 控制台的 Alerting UI 的
Alerts
页面中查看这些警报。
表 12.1. Fluentd Prometheus 警报
|
警报
|
消息
|
描述
|
重要性
|
|
FluentDHighErrorRate
<value> of records have resulted in an error by fluentd <instance>.
FluentD 输出错误数量很高，在前 15 分钟中默认超过 10。
Warning
FluentdNodeDown
Prometheus could not scrape fluentd <instance> for more than 10m.
Fluentd 报告 Prometheus 可能无法抓取特定的 Fluentd 实例。
Critical
FluentdQueueLengthIncreasing
In the last 12h, fluentd <instance> buffer queue length constantly increased more than 1.Current value is <value>.
Fluentd 报告队列大小正在增加。
Critical
FluentDVeryHighErrorRate
<value> of records have resulted in an error by fluentd <instance>.
FluentD 输出错误的数量非常大，在之前的 15 分钟中，默认情况下超过 25 个。
Critical
|
12.3.3. 关于 Elasticsearch 警报规则
您可以在 Prometheus 中查看这些警报规则。
表 12.2. 警报规则
|
警报
|
描述
|
重要性
|
|
ElasticsearchClusterNotHealthy
集群健康状态处于 RED 至少 2 分钟。集群不接受写操作，分片可能缺失，或者master 节点尚未选定。
Critical
ElasticsearchClusterNotHealthy
集群健康状态为 YELLOW 至少 20 分钟。某些分片副本尚未分配。
ElasticsearchDiskSpaceRunningLow
集群预期在以后的 6 小时内处于磁盘空间之外。
Critical
ElasticsearchHighFileDescriptorUsage
在下一个小时内，集群预计会在下一个小时内消耗掉所有文件描述符。
ElasticsearchJVMHeapUseHigh
指定节点上的 JVM 堆使用率很高。
ElasticsearchNodeDiskWatermarkReached
由于可用磁盘空间较低，指定节点达到低水位线。分片无法再分配给此节点。应该考虑向节点添加更多磁盘空间。
ElasticsearchNodeDiskWatermarkReached
由于可用磁盘空间较低，指定节点达到高水位线。若有可能，某些分片将重新分配到其他节点。确保向节点添加更多磁盘空间，或者丢弃分配给此节点的旧索引。
ElasticsearchNodeDiskWatermarkReached
由于可用磁盘空间不足，指定节点达到洪水水位线。每个在这个节点上分配了分片的索引都会强制使用只读块。当磁盘使用低于高水位线时，索引块必须手动发布。
Critical
ElasticsearchJVMHeapUseHigh
指定节点上的 JVM 堆使用率太高。
ElasticsearchWriteRequestsRejectionJumps
Elasticsearch 在指定节点上的写入增加。此节点可能无法跟上索引速度。
AggregatedLoggingSystemCPUHigh
该系统在指定节点上使用的 CPU 太高。
ElasticsearchProcessCPUHigh
Elasticsearch 在指定节点上使用的 CPU 太高。
|
在提交问题单时同时提供您的集群信息，可以帮助红帽支持为您进行排除故障。
您可使用
must-gather
工具
来收集有关项目级别资源、集群级别资源和每个 OpenShift Logging 组件的诊断信息。
为了获得快速支持，请提供 OpenShift Container Platform 和 OpenShift Logging 的诊断信息。
不要使用
hack/logging-dump.sh
脚本。这个脚本不再被支持且不收集数据。
12.4.1. 关于 must-gather 工具
oc adm must-gather
CLI 命令会收集最有助于解决问题的集群信息。
对于 OpenShift Logging 环境，
must-gather
会收集以下信息：
项目级别资源，包括 Pod、配置映射、服务帐户、角色、角色绑定和事件
集群级资源，包括集群级别的节点、角色和角色绑定
openshift-logging
和
openshift-operators-redhat
命名空间中的 OpenShift Logging 资源，包括日志收集器的健康状况、日志存储和日志可视化工具
在运行
oc adm must-gather
时，集群上会创建一个新 pod。在该 pod 上收集数据，并保存至以
must-gather.local
开头的一个新目录中。此目录在当前工作目录中创建。
-
必须安装 OpenShift Logging 和 Elasticsearch。
12.4.3. 收集 OpenShift Logging 数据
您可以使用
oc adm must-gather
CLI 命令来收集有关 OpenShift Logging 环境的信息。
使用
must-gather
来收集 OpenShift Logging 信息：
进入要存储
must-gather
信息的目录。
针对 OpenShift Logging 镜像运行
oc adm must-gather
命令：
$ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}')
must-gather
工具会创建一个以当前目录中
must-gather.local
开头的新目录。例如：
must-gather.local.4157245944708210408
。
从刚刚创建的
must-gather
目录创建一个压缩文件。例如，在使用 Linux 操作系统的计算机上运行以下命令：
$ tar -cvaf must-gather.tar.gz must-gather.local.4157245944708210408
在
红帽客户门户
中为您的问题单附上压缩文件。
12.5.1. Elasticsearch Cluster Health 是红色
至少一个主分片及其副本没有分配给节点。
检查 Elasticsearch 集群健康状态，并验证集群的
status
是否为红色。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- health
列出已加入集群的节点。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cat/nodes?v
列出 Elasticsearch Pod，并将它们与上一步中命令输出中的节点进行比较。
oc -n openshift-logging get pods -l component=elasticsearch
如果某些 Elasticsearch 节点没有加入集群，请执行以下步骤。
确认 Elasticsearch 已选定 control plane 节点。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cat/master?v
检查所选 control plane 节点的 pod 日志问题。
oc logs <elasticsearch_master_pod_name> -c elasticsearch -n openshift-logging
检查尚未加入集群的节点日志。
oc logs <elasticsearch_node_name> -c elasticsearch -n openshift-logging
如果所有节点都加入集群，请执行以下步骤，检查集群是否正在进行恢复。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cat/recovery?active_only=true
如果没有命令输出，恢复过程可能会因为待处理的任务而延迟或停止。
检查是否有待处理的任务。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- health |grep number_of_pending_tasks
如果有待处理的任务，请监控其状态。
如果它们的状态发生变化，并且表示集群正在恢复，请继续等待。恢复时间因集群大小和其它因素而异。
否则，如果待处理任务的状态没有改变，这表示恢复已停止。
如果恢复似乎已停止，请检查
cluster.routing.allocation.enable
是否设置为
none
。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cluster/settings?pretty
如果
cluster.routing.allocation.enable
设为
none
，请将它设置为
all
。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cluster/settings?pretty -X PUT -d '{"persistent": {"cluster.routing.allocation.enable":"all"}}'
检查哪些索引仍然是红色的。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cat/indices?v
如果有任何索引仍然是红色的，请尝试通过执行以下步骤清除它们。
清除缓存。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name>/_cache/clear?pretty
增加最大分配重试数。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name>/_settings?pretty -X PUT -d '{"index.allocation.max_retries":10}'
删除所有滚动项目。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_search/scroll/_all -X DELETE
增加超时时间。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name>/_settings?pretty -X PUT -d '{"index.unassigned.node_left.delayed_timeout":"10m"}'
如果前面的步骤没有清除红色索引，请单独删除索引。
标识红色索引名称。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cat/indices?v
删除红色索引。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_red_index_name> -X DELETE
如果没有红色索引且集群状态为红色，请在数据节点上检查是否有连续重量处理负载。
检查 Elasticsearch JVM 堆使用量是否很高。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_nodes/stats?pretty
在命令输出中，检查
node_name.jvm.mem.heap_used_percent
字段，以确定 JVM Heap 使用量。
检查高 CPU 使用率。
在 Elasticsearch 中搜索 "Free up or increase disk space"，
Fix a red or yellow cluster status
。
12.5.3. 已达到 Elasticsearch 节点磁盘低水位线
Elasticsearch 不将分片分配给
达到低水位线
的节点。
识别要在其上部署 Elasticsearch 的节点。
oc -n openshift-logging get po -o wide
检查是否有
未分配的分片
。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cluster/health?pretty | grep unassigned_shards
如果存在未分配的分片，请检查每个节点上的磁盘空间。
for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod -- df -h /elasticsearch/persistent; done
检查
nodes.node_name.fs
字段，以确定该节点上的可用磁盘空间。
如果使用的磁盘百分比超过 85%，则节点已超过低水位线，并且分片无法再分配给此节点。
尝试增加所有节点上的磁盘空间。
如果无法增加磁盘空间，请尝试向集群添加新数据节点。
如果添加新数据节点有问题，请减少集群冗余策略总数。
检查当前的
redundancyPolicy
。
oc -n openshift-logging get es elasticsearch -o jsonpath='{.spec.redundancyPolicy}'
如果使用
ClusterLogging
CR，请输入：
oc -n openshift-logging get cl -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'
如果集群
redundancyPolicy
大于
SingleRedundancy
，将其设置为
SingleRedundancy
并保存这个更改。
如果前面的步骤没有解决这个问题，请删除旧的索引。
检查 Elasticsearch 上所有索引的状态。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- indices
确定可以删除的旧索引。
删除索引。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name> -X DELETE
12.5.4. 已达到 Elasticsearch 节点磁盘高水位线
Elasticsearch 会尝试从
已达到高水位线
的节点中重新定位分片。
识别要在其上部署 Elasticsearch 的节点。
oc -n openshift-logging get po -o wide
检查每个节点上的磁盘空间。
for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod -- df -h /elasticsearch/persistent; done
检查集群是否重新平衡。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cluster/health?pretty | grep relocating_shards
如果命令输出显示重新定位分片，则代表超过了高水位线（High Watermark）。High Watermark 的默认值为 90%。
分片重新定位到磁盘使用率较低且未超过任何水位线阈值的节点。
若要将分片分配到特定节点，请释放一些空间。
尝试增加所有节点上的磁盘空间。
如果无法增加磁盘空间，请尝试向集群添加新数据节点。
如果添加新数据节点有问题，请减少集群冗余策略总数。
检查当前的
redundancyPolicy
。
oc -n openshift-logging get es elasticsearch -o jsonpath='{.spec.redundancyPolicy}'
如果使用
ClusterLogging
CR，请输入：
oc -n openshift-logging get cl -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'
如果集群
redundancyPolicy
大于
SingleRedundancy
，将其设置为
SingleRedundancy
并保存这个更改。
如果前面的步骤没有解决这个问题，请删除旧的索引。
检查 Elasticsearch 上所有索引的状态。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- indices
确定可以删除的旧索引。
删除索引。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name> -X DELETE
12.5.5. 已达到 Elasticsearch 节点磁盘的洪水水位线
Elasticsearch 在每个具有这两个条件的索引中强制使用只读索引块：
为节点分配一个或多个分片。
一个个或多个磁盘超过
flood stage
。
检查 Elasticsearch 节点的磁盘空间。
for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod -- df -h /elasticsearch/persistent; done
检查
nodes.node_name.fs
字段，以确定该节点上的可用磁盘空间。
如果使用的磁盘百分比超过 95%，这表明该节点已跨过洪水水位线。对于在此特定节点上分配的分片，写入被阻止。
尝试增加所有节点上的磁盘空间。
如果无法增加磁盘空间，请尝试向集群添加新数据节点。
如果添加新数据节点有问题，请减少集群冗余策略总数。
检查当前的
redundancyPolicy
。
oc -n openshift-logging get es elasticsearch -o jsonpath='{.spec.redundancyPolicy}'
如果使用
ClusterLogging
CR，请输入：
oc -n openshift-logging get cl -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'
如果集群
redundancyPolicy
大于
SingleRedundancy
，将其设置为
SingleRedundancy
并保存这个更改。
如果前面的步骤没有解决这个问题，请删除旧的索引。
检查 Elasticsearch 上所有索引的状态。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- indices
确定可以删除的旧索引。
删除索引。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name> -X DELETE
继续释放和监控磁盘空间，直到使用的磁盘空间下降到 90% 以下。然后，取消阻塞写入此特定节点。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_all/_settings?pretty -X PUT -d '{"index.blocks.read_only_allow_delete": null}'
12.5.6. Elasticsearch JVM 堆使用率是高
使用的 Elasticsearch 节点 JVM Heap 内存超过 75%。
考虑
增大堆大小
。
节点上的系统 CPU 使用率高。
检查集群节点的 CPU。考虑向节点分配更多 CPU 资源。
12.5.8. Elasticsearch 进程 CPU 为高
节点上的 Elasticsearch 进程 CPU 使用率很高。
检查集群节点的 CPU。考虑向节点分配更多 CPU 资源。
12.5.9. Elasticsearch 磁盘空间现为低
根据当前的磁盘使用情况，Elasticsearch 集群预计在以后的 6 小时内会耗尽磁盘空间。
获取 Elasticsearch 节点的磁盘空间。
for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod -- df -h /elasticsearch/persistent; done
在命令输出中，检查
nodes.node_name.fs
字段以确定该节点上的可用磁盘空间。
尝试增加所有节点上的磁盘空间。
如果无法增加磁盘空间，请尝试向集群添加新数据节点。
如果添加新数据节点有问题，请减少集群冗余策略总数。
检查当前的
redundancyPolicy
。
oc -n openshift-logging get es elasticsearch -o jsonpath='{.spec.redundancyPolicy}'
如果使用
ClusterLogging
CR，请输入：
oc -n openshift-logging get cl -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'
如果集群
redundancyPolicy
大于
SingleRedundancy
，将其设置为
SingleRedundancy
并保存这个更改。
如果前面的步骤没有解决这个问题，请删除旧的索引。
检查 Elasticsearch 上所有索引的状态。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- indices
确定可以删除的旧索引。
删除索引。
oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name> -X DELETE
12.5.10. Elasticsearch FileDescriptor 使用为高
根据当前的使用趋势，预计节点上的文件描述符数量不足。
检查并根据需要为每个节点配置
max_file_descriptors
的值，如 Elasticsearch
文件描述符
主题中所述。
在
关于 Elasticsearch 警报规则
中搜索 "ElasticsearchHighFileDescriptorUsage"。
在
OpenShift Logging 仪表板
中搜索 "使用中的文件描述符"。
第 13 章 卸载 OpenShift Logging
您可以从 OpenShift Container Platform 集群中删除 OpenShift Logging。
13.1. 从 OpenShift Container Platform 卸载 OpenShift Logging
您可以通过删除
ClusterLogging
自定义资源(CR)来停止日志聚合。在删除 CR 后，还有其他 OpenShift Logging 组件保留下来，您可以选择将其删除。
删除
ClusterLogging
CR 不会删除持久性卷声明（PVC）。要保留或删除剩余的 PVC、持久性卷（PV）和相关数据，您必须执行进一步操作。
必须安装 OpenShift Logging 和 Elasticsearch。
删除 OpenShift Logging:
使用 OpenShift Container Platform Web 控制台删除
ClusterLogging
CR:
切换到
Administration
→
Custom Resource Definitions
页面。
在
Custom Resource Definitions
页面上，点
ClusterLogging
。
在
Custom Resource Definition Details
页面中点
Instances
。
点击实例旁的 Options 菜单
,然后选择
Delete ClusterLogging
。
可选：删除自定义资源定义(CRD):
切换到
Administration
→
Custom Resource Definitions
页面。
点击
ClusterLogForwarder
旁边的 Options 菜单
,然后选择
Delete Custom Resource Definition
。
点击
ClusterLogging
旁边的 Options 菜单
,然后选择
Delete Custom Resource Definition
。
点击
Elasticsearch
旁边的 Options 菜单
,然后选择
Delete Custom Resource Definition
。
可选：删除 Red Hat OpenShift Logging Operator 和 OpenShift Elasticsearch Operator：
切换到
Operators
→
Installed Operators
页面。
点 Red Hat OpenShift Logging Operator
旁边的 Options 菜单并选择
Uninstall Operator
。
点击 OpenShift Elasticsearch Operator
旁边的 Options 菜单并选择
Uninstall Operator
。
可选：删除 OpenShift Logging 和 Elasticsearch 项目。
切换到
Home
→
Projects
页面。
点击
openshift-logging
项目
旁的 Options 菜单,然后选择
Delete Project
。
在对话框中输入
openshift-logging
并点
Delete
来确认删除。
点击
openshift-operators-redhat
项目
旁的 Options 菜单并选择
Delete Project
。
如果在此命名空间中安装了其他全局 Operator，请不要删除
openshift-operators-redhat
项目。
通过在对话框中输入
openshift-operators-redhat
并点
Delete
来确认删除。
要保留 PVC 以便与其他 pod 重复使用，保留标签或 PVC 名称，以便重新声明 PVC。
可选：如果您不想保留 PVC，可以删除它们。
释放或删除 PVC 可能会导致 PV 删除并导致数据丢失。
切换到
Storage
→
Persistent Volume Claims
页面。
点击每个 PVC
旁边的 Options 菜单，然后选择
Delete Persistent Volume Claim
。
如果要恢复存储空间，可以删除 PV。
手动重新声明持久性卷
以下字段可出现在 OpenShift Logging 导出的日志记录中。虽然日志记录通常格式为 JSON 对象，但相同的数据模型可以应用到其他编码。
要从 Elasticsearch 和 Kibana 搜索这些字段，在搜索时使用完整的点号字段名称。例如，使用 Elasticsearch
/_search URL
，若要查找 Kubernetes pod 名称，请使用
/_search/q=kubernetes.pod_name:name-of-my-pod
。
顶级字段可以出现在每条记录中。
原始日志条目文本 UTF-8 编码。如果存在非空的
structured
字段，则此字段可能不存在或为空。请参见关于
结构化
的描述，了解更多。
HAPPY
|
原始日志条目作为结构化对象.如果转发器配置为解析结构化 JSON 日志，则可能存在此字段。如果原始日志条目是有效的结构化日志，此字段将包含等同的 JSON 结构。否则此字段为空或不存在，
message
字段将包含原始日志消息。
structured
字段可以包含日志消息中包含的任何子字段，此处没有定义任何限制。
group
map[message:starting fluentd worker pid=21631 ppid=21618 worker=0 pid:21631 ppid:21618 worker:0]
|
一个 UTC 值，用于标记日志有效负载创建的时间，如果创建时间未知，则标记首次收集日志有效负载的时间。"@"前缀表示为特定用途保留的字段。默认情况下，大多数工具都通过 ElasticSearch 来查找 "@timestamp"。
2015-01-24 14:06:05.071000000 Z
|
此日志消息的来源主机的名称。在 Kubernetes 集群中，这与
kubernetes.host
相同。
|
