OpenShift 4 监控技术栈解析

概述

红帽 OpenShift 4.6 最新版刚出来, 最新的监控技术栈经过了较大的调整并且 GA(生产可用)了.

架构长这样, 我们来看一下:

看起来还是非常复杂的, 第一次看到这个架构可能一脸懵逼.

之所以要做这么复杂, 我能理解的核心原因就 1 个:

• 在产品标准化和交付定制化之间找到平衡

这就包括:

1. 方便实施: 安装部署;

2. 方便升级

3. 方便撇清权责(非贬义)

下面我们来一起看一下.

了解 红帽 OpenShift 4 监控技术栈

概述

默认平台监控级别

OpenShift 4 包括一个预配置、预安装和自我更新的监控技术栈，用于监控核心平台组件。OpenShift 4 提供了与监控相关的现成的最佳实践。其中默认包括一组警报，可立即就集群问题通知集群管理员。OpenShift 4 控制台中的默认仪表板包括集群指标的直观表示，以帮助快速了解集群状态。

用户自定义级别

安装 OpenShift Container Platform 4.6 后，集群管理员可以选择性地为用户定义的项目启用监控。通过使用此功能，集群管理员、开发人员和其他用户可以指定在其自己的项目中如何监控服务和 Pod。然后，您可以在 OpenShift Container Platform web 控制台中查询指标、查看仪表板，并管理您自己的项目的警报规则和静默。

监控技术栈

OpenShift 4 监控堆栈基于 Prometheus 开源项目及其更广的生态系统。监控堆栈包括以下组件：

• 默认平台监控组件。在 OpenShift 4 安装过程中，默认会在 openshift-monitoring namespace(租户) 中安装一组平台监控组件。这为包括 Kubernetes 服务在内的 OpenShift 4 核心组件提供了监控。默认监控堆栈还为集群启用远程健康状态监控。上图中的默认安装部分说明了这些组件。

• 用于监控用户定义项目的组件。在选择性地为用户定义的项目启用监控后，会在 openshift-user-workload-monitoring 项目中安装其他监控组件。这为用户定义的项目提供了监控。上图中的用户部分说明了这些组件。

默认平台监控组件

默认情况下，OpenShift Container Platform 4.6 监控堆栈包括以下组件：

监控技术栈中的所有组件都由技术栈自监控，并在 OpenShift 更新时自动更新。

默认监控目标

除了监控技术栈本身的组件外，默认监控堆栈还监控：

• CoreDNS

• Elasticsearch（如果安装了 Logging 组件, 配置了日志监控全套.）

• etcd

• Fluentd（如果安装了 Logging）

• HAProxy (openshift 使用 HAProxy 作为 ingress)

• 镜像 registry

• Kubelets

• Kubernetes apiserver

• Kubernetes 控制器管理器

• Kubernetes 调度程序

• Metering（如果安装了 Metering）

• OpenShift apiserver (openshift 出了 k8s api server, 还有 openshift apiserver. 用于处理如 ImageStream, BuildConfig, DeploymentConfig 等 openshift 特有 resources)

• OpenShift 控制器管理器

• Operator Lifecycle Manager (OLM)

对于默认的监控目标, 如果有 bug, 是可以提的. 其他 OpenShift 框架组件也可能会公开指标, 这里不详细介绍。

用于监控用户定义的项目的组件

OpenShift 4.6 包括对监控堆栈的可选功能增强，已用于监控用户定义的项目中的服务和 Pod。此功能包括以下组件：

用户定义的项目的监控目标

为用户定义的项目启用监控后，您可以监控：

• 通过用户定义的项目中的服务端点提供的指标。

• 在用户定义的项目中运行的 Pod。

对于我这边来说, openshift-user-workload-monitoring自带的组件还不够. 还通过 Operator 或其他手段额外部署了以下组件:

1. Prometheus Adapter -- 公开用于 Pod 横向自动扩展的集群资源指标 API。比如: mq 的队列排队数, java 应用的 jdbc pending 数等;

2. Grafana -- openshift4 是严禁你乱动openshift-monitoring 这个租户的, 否则可能无法升级, 出问题不负责. 所以, 需要再在openshift-user-workload-monitoring中部署一个 Grafana. 这个 Grafana 就是给容器平台的使用人员看的. 有 2 个选择:

我这边, 生产通过openshift-user-workload-monitoring, 各类 Exporter, 以及Prometheus Operator的以下CustomeResources

• ServiceMonitor
  

• PodMonitor
  

• PrometheusRule
  

实现了对我们公司以下技术栈的监控:

• JAVA

• Python

• Nodejs

• Golang

• NGINX

• RabbitMQ

• Redis

• Kafka

总结

OpenShift 4 的监控技术栈, 说实话, 站在用户的角度来看: 1 套容器集群而已, 还用 2 套共 4 个 prometheus, 再加上 Thanos. 纯属简单事情复杂化. 秀技术.

但如果站在实施经理 交付角度来看, 确实较好地 在产品标准化和交付定制化之间找到平衡. 在不同国家, 不同行业, 各种各样复杂多变的用户环境下, 交付起来就很简单:

1. 默认平台监控给你备齐, 开箱即用, 都是最佳实践; 如果这能满足用户那就最好了. 万事大吉.

2. 什么? 还需要自定义的监控? 好, 几个 yaml 自定义的监控技术栈搭建好了. 接下来用嘛, 就是用户这边的事情了, 用户用崩了, 也没关系, 默认平台监控还是岁月静好, 在那里工作.