2

如果我启动一个全新干净的空 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)
  • KubeScheduler 下:absent(up{job="kube-scheduler"} == 1)

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

另外两个警报:

  • DeadMansSwitch:报警表达式为vector(1)。我不知道这是什么。
  • TargetDown:触发此警报,该警报up{job="kubelet"}具有两个度量值,一个值为 1.0 的向上,一个值为 0.0 的向下。向上值是 for endpoint="http-metrics",向下值是 for 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"}
4

2 回答 2

4

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

旨在确保整个警报管道正常运行的警报。此警报始终在触发,因此它应该始终在 Alertmanager 中触发并始终针对接收器触发。

在 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.selectorkubeScheduler.selectorhelm 参数来匹配它们。

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

于 2019-03-28T14:31:05.977 回答
2

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

你可能会遇到这个问题,

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

希望这可以帮助。

于 2018-11-01T06:48:28.870 回答