openshift集群部署报错openshift_cluster_monitoring_operator: Wait for the ServiceMonitor CRD to be created

openshift集群部署在openshift_cluster_monitoring_operator: Wait for the ServiceMonitor CRD to be created 无法通过 - RETRYING: Wait for the ServiceMonitor CRD to be created (30 retries left). FALILED - RETRYING: Wait for the ServiceMonitor CRD to be created (29 retries left). FALILED - RETRYING: Wait for the ServiceMonitor CRD to be created (28 retries left). FALILED - RETRYING: Wait for the ServiceMonitor CRD to be created (27 retries left). 。。。

Prometheus-Operator使用ServiceMonitor监控配置时遇坑与解决总结

摘要 本文范围: Prometheus-Operator & kube-prometheus 安装；以及在解决使用ServiceMonitor时遇到的坑。 ServiceMonitor ServiceMonitor 自定义资源(CRD)能够声明如何监控一组动态服务的定义。它使用标签选择定义一组需要被监控的服务。 会因为 Kubenertes RBAC 集群权限问题，导致 ServiceMonitor不生效，表现为在Prometheus 的 targets 中看不到该 ServiceMonitor 的 targets 当然ServiceMonitor不生效的原因还有很多，比如ServiceMonitor的namespaceSelector和selector不匹配，或者ServiceMonitor的namespaceSelector 为什么配置的ServiceMonitor或PodMonitor未生效？

监控calico组件

创建ServiceMonitor kube-prometheus-stack在部署时会创建 Prometheus、PodMonitor、ServiceMonitor、AlertManager 和 PrometheusRule PodMonitor 和 ServiceMonitor 就是 exporter 的各种抽象，是用来提供专门提供指标数据接口的工具， Prometheus 就是通过 PodMonitor 和 ServiceMonitor 我们已经创建了对应的 service，所有使用 ServiceMonitor 来采集指标。使用以下 yaml 创建 ServiceMonitor 。 应用 ServiceMonitor 1 2 3 4 # kubectl apply -f prometheus-ServiceMonitorCalico.yaml servicemonitor.monitoring.coreos.com /felix-metrics created servicemonitor.monitoring.coreos.com/typha-metrics created servicemonitor.monitoring.coreos.com

TKE上自建prometheus如何不影响TMP监控数据采集

解决方案既然上面已经分析问题原因了，就是因为tmp自己部署一个serviceMonitor，然后自建的prometheus也有一个serviceMonitor，tmp将这2个都配置了，导致数据重复。 这里的解决方案就是不让tmp重复采集，不采集自建prometheus的serviceMonitor即可，那么怎么才能不采集自建prometheus的serviceMonitor呢？ 很多人会想觉得，控制台删除这些serviceMonitor就行了，这样确实能够解决tmp重复采集数据的问题，但是这里会有另外一个问题，就是控制删除serviceMonitor，会直接删除集群内的serviceMonitor 当然是可以的，其实从上面tmp的prometheus配置看就大概知道，要想不添加这些serviceMonitor，其实只需要serviceMonitor打上下面label，或者给serviceMonitor 其实不会，这里如果给命名空间打上true的label，那么整个命名空间下的serviceMonitor都不会采集，如果你要指定不采集哪几个serviceMonitor，则需要给serviceMonitor

Prometheus-Operator：自定义监控

Prometheues Opeartor 架构图 此架构图可以看出prometheus数据源主要是来自于ServiceMonitor，所以我们也按照该方案部署一个ServiceMonitor。 $ cat servicemonitor.yaml apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name : mysql-exporter # ServiceMonitor名称 namespace: monitoring # ServiceMonitor所在名称空间 spec: endpoints 表示监听所有符合selector所选择的svc selector: matchLabels: # 选择svc的标签 k8s-app: mysql-exporter # 创建servicemonitor 对象 $ kubectl apply -f servicemonitor.yaml 注：这里的namespaceSelector中我们也可以指定名称空间，如下： namespaceSelector:

prometheus-operator 监控 k8s 外部集群

现在 Prometheus 访问 etcd 集群的证书已经准备好了，接下来创建 ServiceMonitor 对象即可（prometheus-serviceMonitorEtcd.yaml） apiVersion : monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: etcd-k8s namespace: monitoring etcd namespaceSelector: matchNames: - kube-system 上面我们在 monitoring 命名空间下面创建了名为 etcd-k8s 的 ServiceMonitor 对象： # kubectl apply -f prometheus/prometheus-serviceMonitorEtcd.yaml servicemonitor.monitoring.coreos.com /etcd-k8s created 创建 service 和 endpoint ServiceMonitor 创建完成了，但是现在还没有关联的对应的 Service 对象，所以需要我们去手动创建一个 Service

Prometheus Operator心得

自动服务发现：利用ServiceMonitor和PodMonitor，Prometheus Operator能够自动发现并监控Kubernetes集群中的服务和Pod，无需手动配置监控目标。 Prometheus 实例 Alertmanager：配置和管理 Alertmanager 实例，用于处理告警 ThanosRuler：配置和管理 Thanos Ruler 实例，用于规则评估和告警 ServiceMonitor 03、ServiceMonitor的配置 在前面提到ServiceMonitor用于服务发现，我理解的工作原理是，ServiceMonitor借助标签选择器（selector）和命名空间选择器（namespaceSelector ）去发现服务，然后通过定义的端点（endpoint）和路径（path）来收集监控指标数据，下面是一个配置示例： ServiceMonitor会去kube-system命名空间下找到带有app: pvc-monitor 标签的服务，然后从定义的端点+路径/metrics采集监控指标数据 apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata:

kubernetes集群全栈监控报警方案kube-prometheus

adapter [root@elasticsearch01 manifests]# mv *-serviceMonitor* serviceMonitor/ etheus/[root@elasticsearch01 / servicemonitor.monitoring.coreos.com/prometheus-operator created servicemonitor.monitoring.coreos.com /alertmanager created servicemonitor.monitoring.coreos.com/grafana created servicemonitor.monitoring.coreos.com /prometheus created servicemonitor.monitoring.coreos.com/kube-apiserver created servicemonitor.monitoring.coreos.com /coredns created servicemonitor.monitoring.coreos.com/kube-controller-manager created servicemonitor.monitoring.coreos.com

prometheus-operator 监控 k8s 外部集群

现在 Prometheus 访问 etcd 集群的证书已经准备好了，接下来创建 ServiceMonitor 对象即可（prometheus-serviceMonitorEtcd.yaml） apiVersion : monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: etcd-k8s namespace: monitoring 关于 ServiceMonitor 属性的更多用法可以查看文档：https://github.com/coreos/prometheus-operator/blob/master/Documentation servicemonitor.monitoring.coreos.com/etcd-k8s created 创建 service 和 endpoint ServiceMonitor 创建完成了，但是现在还没有关联的对应的 监空集群外部主机信息 其实道理和上面的大大致相同，总结大概的几个步骤 1，在需要监控的机器上部署 exporter 2，在 k8s 集群内部创建 serviceMonitor 3，然后创建 svc ，创建

OpenShift Prometheus(Operator)对接应用监控数据实践

Operator为我们提供了哪些自定义的Kubernetes资源，列出了Prometheus Operator目前提供的️4类资源： Prometheus：声明式创建和管理Prometheus Server实例； ServiceMonitor 配置ServiceMonitor 当我们需要添加一个监控项，就添加ServiceMonitor就可以了，operator就会自动的去reload我们新添加的监控项了。 配置项简介 metadata.name：这个ServiceMonitor的名称 spec.endpoints.interval: 采集数据的间隔 spec.endpoints.port：采集数据的端口 namespaceSelector: matchNames: - xxx-poc selector: matchLabels: prometheus: k8s 查看servicemonitor 11d $ oc get servicemonitors xxx-product-service -o yaml apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor

如何用 Prometheus Operator 监控 K8s 集群外服务?

Prometheus Operator CR - prometheus spec;1.这种方案和 Prometheus 其他配置耦合性较高;2.通过 external name Service + ServiceMonitor1 .这种方案有个前提, 即: 被监控的服务是域名;3.通过 Service + Endpoint + ServiceMonitor1.这种方案的适应性较强, 耦合性也较低. : apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: gpu-metrics-sm labels endpoints: - port: metrics interval: 10s honorLabels: true 方案三: Service + Endpoint + ServiceMonitor 即可: apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: elasticsearch spec:

使用Operator的方式部署Prometheus

其架构图如下： 其中核心部分是Operator，它会去创建Prometheus、ServiceMonitor、AlertManager、PrometheusRule这4个CRD对象，然后会一直监控并维护这 Prometheus：作为Prometheus Server的抽象ServiceMonitor：就是exporter的各种抽象AlertManager：作为Prometheus AlertManager 的抽象PrometheusRule：实现报警规则的文件上图中的 Service 和 ServiceMonitor 都是 Kubernetes 的资源，一个 ServiceMonitor 可以通过 labelSelector 的方式去匹配一类 Service，Prometheus 也可以通过 labelSelector 去匹配多个ServiceMonitor。 的定义有关系了，我们先来查看下 kube-scheduler 组件对应的 ServiceMonitor 资源的定义：(prometheus-serviceMonitorKubeScheduler.yaml

使用 Prometheus 监控 Kubernetes 集群

、管理工作，而且基于 K8s 中的 CRD，Prometheus Operator 新引入了若干 CR（自定义资源）： Prometheus：描述将要部署的 Prometheus Server 集群 ServiceMonitor ，而 ServiceMonitor 通过定义选择 Service 的 label selector 来选定需要监控的 Service ，并通过该 Service 对应的 Endpoints 获得需要监控的 部署监控 根据 Service 中定义的 Label，我们可以定义 ServiceMonitor： apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor team: frontend spec: selector: matchLabels: app: example-app endpoints: - port: web ServiceMonitor 定义了 team=frontend 的 label，这也是 Prometheus 选择 ServiceMonitor 的依据。

如何通过TMP监控TKE独立集群的etcd

通过secret挂载etcd证书因为etcd这里都是有证书鉴权的 ，这里通过serviceMonitor采集etcd监控需要配置证书才行，serviceMonitor是可以直接读取后端prometheus scrape-mount=true这个时候我们到tmp后端eks集群登陆对应独立集群的file-sync是否能看到证书文件图片这里证书已经正常挂载到后端promethues的pod里面了，下面我们来配置serviceMonitor 但是这里遇到一个问题，就是当我创建完ServiceMonitor后，tmp控制台的采集配置显示target都是空的，这是什么原因呢？ 图片tmp关机tke集群会默认创建一个prometheuses对象，这里会定义采集那些ServiceMonitor，这里看下集群的prometheuses配置，是不是有特殊的配置。 加上这个label才行kubectl label serviceMonitor etcd-k8s -n prom-86rajg7v prom_id=prom-86rajg7v图片图片加上label后，这里就能正常获取

Kubernetes 集群监控 ETCD 组件

Kubernetes 集群中的一些资源对象、节点以及组件需要监控，有的时候我们可能还需要根据实际的业务需求去添加自定义的监控项，添加一个自定义监控的步骤也是非常简单的，主要有以下三个步骤： 第一步建立一个 ServiceMonitor 对象，用于 Prometheus 添加监控项； 第二步为 ServiceMonitor 对象关联 metrics 数据接口的一个 Service 对象； 第三步确保 Service 对象可以正确获取到 三、创建 ServiceMonitor 创建 Prometheus 监控资源，配置用于监控 ETCD 参数： $ vi prometheus-serviceMonitorEtcd.yaml apiVersion : monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: etcd-k8s namespace: monitoring 但实际上现在并不能监控到 ETCD 集群，因为并没有一个满足 ServiceMonitor 条件的 Service 对象与之关联： $ kubectl get svc -n kube-system -

Kubernetes 集群监控 controller-manager & scheduler 组件

❞ 二、问题分析 1、kube-scheduler 这其实就和 ServiceMonitor 的定义有关系了，我们先来查看下 kube-scheduler 组件对应的 ServiceMonitor 资源的定义 ： $ vi serviceMonitor/prometheus-serviceMonitorKubeScheduler.yaml apiVersion: monitoring.coreos.com/ 所以我们需要去创建一个对应的 Service 对象，才能核 ServiceMonitor 进行关联。 所以我们同样需要去创建一个对应的 Service 对象，才能核 ServiceMonitor 进行关联。 通过对比，我们发现 ServiceMonitor 的资源在新版 v0.6.0 中的改动较大，于是我创建了两个旧版本的资源定义。

Docker 限速不用怕，因为我有 Grafana

如果你使用 Prometheus Operator 来部署管理 Prometheus，可以直接创建 ServiceMonitor 来抓取指标： servicemonitor.yaml apiVersion : monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: docker-hub-rate-limit-exporter namespace docker-hub-rate-limit-exporter namespaceSelector: matchNames: - monitoring 使用上面的部署清单创建 ServiceMonitor ： $ kubectl apply -f servicemonitor.yaml 在浏览器中输入 Prometheus Server 的 URL 打开 Web 页面（这个就不用我教了吧？

CentOS7.7部署k8s + Prometheus（1 master + 2 node）

alertmanager-main created service/alertmanager-main created serviceaccount/alertmanager-main created servicemonitor.monitoring.coreos.com kube-state-metrics created service/kube-state-metrics created serviceaccount/kube-state-metrics created servicemonitor.monitoring.coreos.com /prometheus created servicemonitor.monitoring.coreos.com/kube-apiserver created servicemonitor.monitoring.coreos.com /coredns created servicemonitor.monitoring.coreos.com/kube-controller-manager created servicemonitor.monitoring.coreos.com /kube-scheduler created servicemonitor.monitoring.coreos.com/kubelet created # kubectl get all -n monitoring

配置 Windows 节点组

Add-WindowsFeature Web-Server; Invoke-WebRequest -UseBasicParsing -Uri 'https://dotnetbinaries.blob.core.windows.net/servicemonitor /2.0.1.6/ServiceMonitor.exe' -OutFile 'C:\\ServiceMonitor.exe'; echo '<html><body>

<marquee>

<marquee></body><html>' > C:\\inetpub\\wwwroot\\default.html; C:\\ServiceMonitor.exe 'w3svc'; "

使用Prometheus Operator 监控Kubernetes

"grafana" created configmap "prometheus-k8s-rules" created serviceaccount "prometheus-k8s" created servicemonitor "alertmanager" created servicemonitor "kube-apiserver" created servicemonitor "kube-controller-manager " created servicemonitor "kube-scheduler" created servicemonitor "kube-state-metrics" created servicemonitor "kubelet" created servicemonitor "node-exporter" created servicemonitor "prometheus-operator" created servicemonitor "prometheus" created service "prometheus-k8s" created prometheus "k8s" created role "