9.3. 使用 OpenShift Serverless 的集群日志记录
9.3.1. 集群日志记录
OpenShift Container Platform 集群管理员可以使用一些 CLI 命令和 OpenShift Container Platform Web 控制台安装 Elasticsearch Operator 和 Cluster Logging Operator,以此部署集群日志记录。安装 Operator 后,创建一个 ClusterLogging
自定义资源(CR)来调度集群日志记录 Pod 以及支持集群日志记录所需的其他资源。Operator 负责部署、升级和维护集群日志记录。
您可以通过修改名为 instance
的 ClusterLogging
自定义资源(CR)来配置集群日志记录。CR 定义包括日志记录堆栈的所有组件在内的完整集群日志记录部署,以收集、存储和视觉化日志。Cluster Logging Operator 监控 ClusterLogging
自定义资源并相应地调整日志记录部署。
管理员和应用程序开发人员可以查看他们具有查看访问权限的项目的日志。
9.3.2. 关于部署和配置集群日志记录
OpenShift Container Platform 集群日志记录已设计为可搭配默认配置使用,该配置针对中小型 OpenShift Container Platform 集群进行了调优。
以下安装说明包括一个示例 ClusterLogging
自定义资源(CR),您可以使用它来创建集群日志记录实例并配置集群日志记录部署。
如果要使用默认集群日志记录安装,可直接使用示例 CR。
如果要自定义部署,请根据需要对示例 CR 进行更改。下文介绍了在安装集群日志记录实例或安装后修改时可以进行的配置。请参阅“配置”部分来了解有关使用各个组件的更多信息,包括可以在 ClusterLogging
自定义资源之外进行的修改。
9.3.2.1. 配置和调优集群日志记录
您可以通过修改 openshift-logging
项目中部署的 ClusterLogging
自定义资源来配置集群日志记录环境。
您可以在安装时或安装后修改以下任何组件:
- 内存和 CPU
-
您可以使用有效的内存和 CPU 值修改
resources
块,以此调整各个组件的 CPU 和内存限值:
spec: logStore: elasticsearch: resources: limits: cpu: memory: 16Gi requests: cpu: 500m memory: 16Gi type: "elasticsearch" collection: logs: fluentd: resources: limits: cpu: memory: requests: cpu: memory: type: "fluentd" visualization: kibana: resources: limits: cpu: memory: requests: cpu: memory: type: kibana curation: curator: resources: limits: memory: 200Mi requests: cpu: 200m memory: 200Mi type: "curator"
- Elasticsearch 存储
-
您可以使用
storageClass
name
和size
参数,为 Elasticsearch 集群配置持久性存储类和大小。Cluster Logging Operator 基于这些参数为 Elasticsearch 集群中的每个数据节点创建PersistentVolumeClaim
。
spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: storageClassName: "gp2" size: "200G"
本例中指定,集群中的每个数据节点将绑定到请求 200G 的 gp2 存储的 PersistentVolumeClaim
。每个主分片将由单个副本支持。
省略 storage
块会导致部署中仅包含临时存储。
spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: {}
- Elasticsearch 复制策略
您可以通过设置策略来定义如何在集群中的数据节点之间复制 Elasticsearch 分片:
-
FullRedundancy
。各个索引的分片完整复制到每个数据节点上。 -
MultipleRedundancy
。各个索引的分片分布到一半数据节点上。 -
SingleRedundancy
。各个分片具有单个副本。只要存在至少两个数据节点,日志就能始终可用且可恢复。 -
ZeroRedundancy
。所有分片均无副本。如果节点关闭或发生故障, 则可能无法获得日志数据。
-
- Curator 调度
- 以 cron 格式指定 Curator 的调度。
spec: curation: type: "curator" resources: curator: schedule: "30 3 * * *"
9.3.2.2. 修改后的 ClusterLogging
自定义资源示例
以下是使用前面描述的选项修改的 ClusterLogging
自定义资源的示例。
修改后的 ClusterLogging
自定义资源示例
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: "openshift-logging" spec: managementState: "Managed" logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 resources: limits: memory: 32Gi requests: cpu: 3 memory: 32Gi storage: {} redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" kibana: resources: limits: memory: 1Gi requests: cpu: 500m memory: 1Gi replicas: 1 curation: type: "curator" curator: resources: limits: memory: 200Mi requests: cpu: 200m memory: 200Mi schedule: "*/5 * * * *" collection: logs: type: "fluentd" fluentd: resources: limits: memory: 1Gi requests: cpu: 200m memory: 1Gi
9.3.3. 使用集群日志来查找 Knative Serving 组件的日志
流程
要访问 Kibana UI(Elasticsearch 的可视化工具),请使用以下命令获取 Kibana 路由:
$ oc -n openshift-logging get route kibana
- 使用路由的 URL 导航到 Kibana 仪表板并登录。
- 确保将索引设置为 .all。如果索引未设置为 .all,则只会列出 OpenShift Container Platform 系统日志。
您可使用
knative-serving
命名空间来过滤日志。在搜索框中输入kubernetes.namespace_name:knative-serving
以过滤结果。注意Knative Serving 默认使用结构化日志记录。您可以通过自定义集群日志记录 Fluentd 设置来启用这些日志的解析。这允许在日志级别过滤来快速发现问题。
9.3.4. 使用集群日志来查找通过 Knative Serving 部署的服务的日志
使用 OpenShift Container Platform 集群日志记录时,应用程序写入控制台的日志将在 Elasticsearch 中收集。以下流程概述了如何使用 Knative Serving 将这些功能应用到所部署的应用程序中。
流程
查找 Kibana URL:
$ oc -n cluster-logging get route kibana
- 在浏览器中输入 URL 以打开 Kibana UI。
- 确保将索引设置为 .all。如果索引未设置为 .all,则只会列出 OpenShift Container Platform 系统日志。
通过使用服务部署到的 Kubernetes 命名空间来过滤日志。添加过滤条件以识别服务本身:
kubernetes.namespace_name:default AND kubernetes.labels.serving_knative_dev\/service:{SERVICE_NAME}
。注意除此之外还可使用
/configuration
或/revision
来过滤。您可使用
kubernetes.container_name:<user-container>
来缩小搜索范围,只显示由您的应用程序生成的日志。否则,会显示来自 queue-proxy 的日志。注意在应用程序中使用基于 JSON 的结构化日志记录,以便在生产环境中快速过滤这些日志。