Prometheus运算符+新的Kubernetes Minikube = DeadMansSwitch + KubeControllerManagerDown + KubeSchedulerDown + TargetDown

时间:2018-10-31 14:55:45

标签: kubernetes prometheus minikube prometheus-operator

如果我使用严格的默认设置启动全新的干净的空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_namedefault/my-prom-prometheus-operato-kube-controller-manager/0default/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"}

fyi,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"}

2 个答案:

答案 0 :(得分:2)

DeadManSwitchAlarm是vector(1),它是始终触发的警报,通常用于测试您的alertmanager是否正常工作。

您可能遇到了这个问题,

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

希望这会有所帮助。

答案 1 :(得分:2)

Watchdog警报(以前称为DeadManSwitch)是:

  

警报,旨在确保整个警报管道正常运行。             此警报始终处于触发状态,因此应始终在Alertmanager中触发             并始终向接收方射击。

在Minikube中,默认情况下kube-controller-managerkube-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舵图创建的默认服务选择器与Minikube组件使用的标签不匹配。您需要通过设置kubeControllerManager.selectorkubeScheduler.selector掌舵参数来匹配它们。

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