Prometheus Operator + 新的 Kubernetes Minikube = DeadMansSwitch + KubeControllerManagerDown + KubeSchedulerDown + TargetDown

Question

如果我启动一个全新的干净的空 minikube 和 helm install 最新的 stable/prometheus-operator 使用严格的默认设置，我会看到四个活动的 Prometheus 警报。

在这个超级简化的场景中，我有一个干净的新 minikube，运行除了 Prometheus 什么都没有，应该没有问题，也没有警报。这些警报是假的还是损坏的？我的设置有问题还是我应该提交错误报告并暂时禁用这些警报？

这是我的基本设置步骤：

minikube delete
# Any lower memory/cpu settings will experience problems
minikube start --memory 10240 --cpus 4 --kubernetes-version v1.12.2
eval $(minikube docker-env)
helm init
helm repo update
# wait a minute for Helm Tiller to start up.
helm install --name my-prom stable/prometheus-operator

等待几分钟让一切启动，然后运行 Prometheus 服务器和 Grafana 上的端口转发：

kubectl port-forward service/my-prom-prometheus-operato-prometheus 9090:9090
kubectl port-forward service/my-prom-grafana 8080:80

然后去http://localhost:9090/alerts看看：

DeadMansSwitch (1 active)
KubeControllerManagerDown (1 active)
KubeSchedulerDown (1 active)
TargetDown (1 active)

这些是假的吗？真的有问题吗？我应该禁用这些吗？

其中两个警报缺少指标：

KubeControllerManagerDown: absent(up{job="kube-controller-manager"} == 1)
KubeSchedulerDown: absent(up{job="kube-scheduler"} == 1)

在 http://localhost:9090/config 中，我没有看到任何配置的作业，但我确实看到与 job_name 值 default/my-prom-prometheus-operato-kube-controller-manager/0 和 default/my-prom-prometheus-operato-kube-scheduler/0 密切相关的作业。这表明 job_name 值应该匹配，但存在不匹配的错误。我也没有看到这两项工作的任何收集指标。职位名称中是否允许使用斜线？

另外两个闹钟：

DeadMansSwitch：报警表达式为vector(1)。我不知道这是什么。
TargetDown：此警报是在 up{job="kubelet"} 上触发的，它有两个指标值，一个值为 1.0，一个值为 0.0。上值对应 endpoint="http-metrics"，下值对应 endpoint="cadvisor"。后一个端点应该启动吗？为什么不呢？

我转到 http://localhost:9090/graph 和运行 sum(up) by (job) 我看到 1.0 所有值：

{job="node-exporter"}
{job="my-prom-prometheus-operato-prometheus"}
{job="my-prom-prometheus-operato-operator"}
{job="my-prom-prometheus-operato-alertmanager"}
{job="kubelet"}
{job="kube-state-metrics"}
{job="apiserver"}

仅供参考，kubectl version 显示：

Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.2", GitCommit:"17c77c7898218073f14c8d573582e8d2313dc740", GitTreeState:"clean", BuildDate:"2018-10-30T21:39:16Z", GoVersion:"go1.11.1", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.2", GitCommit:"17c77c7898218073f14c8d573582e8d2313dc740", GitTreeState:"clean", BuildDate:"2018-10-24T06:43:59Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}

Answer 1

DeadManSwitchAlarm 是 vector(1)，它是一个总是触发的警报，它通常用于测试您的 alertmanager 是否正在工作。

您可能遇到了这个问题，

https://github.com/coreos/prometheus-operator/issues/1001

希望对您有所帮助。

Answer 2

Watchdog 警报（以前命名为 DeadManSwitch）是：

An alert meant to ensure that the entire alerting pipeline is functional. This alert is always firing, therefore it should always be firing in Alertmanager and always fire against a receiver.

在 Minikube 中，kube-controller-manager 和 kube-scheduler 默认侦听 127.0.0.1，因此 Prometheus 无法从中获取指标。您需要启动 Minikube，并在所有接口上监听这些组件：

minikube start --kubernetes-version v1.12.2 \
--bootstrapper=kubeadm \
--extra-config=scheduler.address=0.0.0.0 \
--extra-config=controller-manager.address=0.0.0.0

TargetDown 的另一个原因是 Prometheus Operator helm chart 创建的默认服务选择器与 Minikube 组件使用的标签不匹配。您需要通过设置 kubeControllerManager.selector 和 kubeScheduler.selector helm 参数来匹配它们。

看看这篇文章：Trying Prometheus Operator with Helm + Minikube。它解决了所有这些问题，以及如何解决这些问题等等。

Prometheus Operator + 新的 Kubernetes Minikube = DeadMansSwitch + KubeControllerManagerDown + KubeSchedulerDown + TargetDown

Prometheus Operator + New Kubernetes Minikube = DeadMansSwitch + KubeControllerManagerDown + KubeSchedulerDown + TargetDown

kubernetes

prometheus

minikube

prometheus-operator