问题标签 [prometheus-operator]

我正在使用 Prometheus 工具来监控我的 Kubernetes 集群。

我在我的部署中设置了资源限制（内存限制），需要配置一个面板来显示可用的总内存。请让我知道在 Prometheus 中运行以获取可用于我的部署的总内存限制所需的查询。

我使用kops在 AWS 上运行了一个 kubernetes 集群。我还使用kube-prometheus设置了 prometheus 和 grafana 。

我想要做的是将普罗米修斯收集的指标存储在 EBS 上。我的持久卷声明 yaml 是：

prometheus.yaml 是：

正在创建 10Gi EBS 卷，但它的状态仍然可用。我还尝试删除 prometheus pod，希望能保留数据。不幸的是，情况并非如此。

我已经在 prometheus 中配置了节点内存使用警报。我的警报模板如下：

当单个节点的阈值超过时（此处的节点名称为nodes-3z4c），我收到警报中的节点名称，如下所示：

但问题是，当多个节点超过阈值时，多个节点的名称没有在警报通知中指定并得到如下通知：

有人可以帮我解决这个问题吗？

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

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

这是我的基本设置步骤：

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

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

这些是假的吗？真的有什么不对吗？我应该禁用这些吗？

其中两个警报缺少指标：

• 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所有的值：

仅供参考，kubectl version显示：

我有一个干净的 AKS 集群，我部署了 prometheus-operator 图表。Grafana pod 显示了大量的重新启动。我的集群版本是 1.11.3。Grafana 日志如下。还有其他人遇到这个问题吗？

我正在尝试为我的 Kubernetes 集群设置 AlertManager。我已遵循此文档（https://github.com/coreos/prometheus-operator/blob/master/Documentation/user-guides/getting-started.md）-> 一切正常。

为了设置 AlertManager，我正在研究这个文档（https://github.com/coreos/prometheus-operator/blob/master/Documentation/user-guides/alerting.md）

我得到了CrashLoopBackOfffor alertmanager-example-0。请检查随附的日志：

第一张图片：$ kubectl logs -f prometheus-operator-88fcf6d95-zctgw -n monitoring

第二张图片：$ kubectl describe pod alertmanager-example-0

谁能指出我做错了什么？提前致谢。

Kubernetes 版本：1.10

我们在 Kubernetes 集群上运行 Prometheus（在裸机上运行）。Kubernetes 仅使用一个 POD 运行。

ISSUE - 如果 POD 重新启动，Prometheus 指标不会保留。我们还尝试将持久性卷配置为local。现在，如果该 pod 被重新调度到集群的任何其他节点，那么它将丢失所有先前保存在前一个节点上的数据。我们还尝试将 Prometheus 远程存储配置为读写，但是由于速度很慢，所以没有成功。是否有任何其他选项可以将数据持久保存在裸机上的 Kubernetes 上？

这是默认值，一个全新的，否则为空的 minikube。我怀疑有什么东西坏了？

仅供参考，我尝试回滚到 Kubernetes v1.12.3 并得到相同的错误结果。

我的服务在 2 个端口上运行 - 80 和 9000 现在我只需要监视端口 80，我使用下面的配置来实现这一点。

上述解决方案在 Prometheus 中添加了两个服务端点

为了只抓取端口 80，我在配置下面添加了但它现在无法抓取任何服务端点。

有没有办法只限制特定的端口号？

根据定义，kube_pod_container_status_waiting_reason应该捕获 Pod 处于 Waiting 状态的原因。

我的 kubernetes 集群中有几个 pod，它们位于 CrashLoopBackOff 中，但我没有看到kube_pod_container_status_waiting_reason. 它只捕获了两个原因 - ErrImagePull 和 ContainerCreating。

sum by (reason) (kube_pod_container_status_waiting_reason)在 prometheus 中运行会产生结果：

我正在运行quay.io/coreos/kube-state-metrics:v1.2.0kube-state-metrics 的图像。

我错过了什么？为什么 CrashLoopBackOff 原因没有出现在查询中？我想设置一个警报，查找处于等待状态的 pod 并说明原因。所以考虑合并kube_pod_container_status_waiting以找到处于等待状态的 pod 并kube_pod_container_status_waiting_reason找到确切的原因。

请协助。谢谢！