monitoring Command
Prometheus 配置检查和 Target 排查命令
Prometheus 配置校验和 target 排查的常用命令，promtool check config 排除 prometheus.yml 语法错误，从 Prometheus 所在网络位置 curl target /metrics 复现抓取，Kubernetes 场景 kubectl describe servicemonitor 检查 selector 和端口名匹配。
Prometheus target down 先看 Last Error，再从 Prometheus 同网络位置 curl /metrics，不要只在本机测试。
Scenario
什么时候用这组命令
这组命令适合在处理“Prometheus 配置检查和 Target 排查命令”时作为第一轮检查模板。使用时先替换占位符，再在目标机器或目标 namespace 中执行，避免在错误环境里得到误导结论。
Input
你需要先准备什么
- 先确认是监控系统自身不可用，还是 target/exporter 不可抓取。
- 从 Prometheus 所在网络位置测试 metrics，而不是只在本机 curl。
- 记录 Targets 页面的 Last Error、endpoint、labels 和 scrape pool。
Risk Notes
执行风险
- 不要只改 Prometheus 配置而不验证生成后的 target，这可能导致监控盲区。
- 不要在业务高峰临时打开大量高基数指标，这可能导致 Prometheus OOM 或抓取超时。
- 不要依赖单一 Prometheus 实例做高可用，应考虑 Thanos 或 VictoriaMetrics 等方案。
Commands
命令详解
命令 1: 执行 promtool
用于补充“Prometheus 配置检查和 Target 排查命令”的排查证据链。promtool 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
promtool check config prometheus.yml命令 2: 发起 HTTP/网络探测
用于从指定位置模拟真实请求。加 -v 可以看到 DNS、TCP、TLS、HTTP 头和代理连接过程，是定位链路阶段的关键证据。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
curl -v http://target:9100/metrics命令 3: 读取 Kubernetes 状态
用于补充“Prometheus 配置检查和 Target 排查命令”的排查证据链。kubectl 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
kubectl port-forward svc/prometheus 9090:9090 -n monitoring命令 4: 读取 Kubernetes 状态
用于读取 Kubernetes 当前资源状态和 Events。重点看 STATUS、RESTARTS 和 Events 中的调度、探针、镜像错误。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
kubectl get servicemonitor,podmonitor -A命令 5: 读取 Kubernetes 状态
用于读取 Kubernetes Events、状态变化和资源引用关系。排查 Pod、Service、Ingress 时，它通常能直接暴露调度、拉镜像、探针或后端错误。
- 先替换尖括号占位符，不要原样执行。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
kubectl describe servicemonitor <name> -n <namespace>Workflow
建议执行顺序
按顺序执行，不要跳过确认类命令
先用只读命令确认状态，再执行会改变状态的命令。Prometheus target down 先看 Last Error，再从 Prometheus 同网络位置 curl /metrics，不要只在本机测试。
- 用 promtool 先排除配置语法错误。
- 在 Targets 页面记录失败原因。
- 从 Prometheus 运行环境测试 metrics URL。
- Kubernetes 场景检查 ServiceMonitor selector 和端口名。
- TLS/认证失败时检查证书、token 和 scheme。
promtool check config prometheus.yml
curl -v http://target:9100/metrics
kubectl port-forward svc/prometheus 9090:9090 -n monitoring把命令输出变成结论
命令本身不是结论。每次执行后要回答：目标是否存在、状态是否异常、异常是否能解释用户看到的现象。
- 记录关键字段，而不是整屏复制
- 把正常路径和异常路径输出对比
- 输出为空也要解释：是确实没有，还是权限/过滤条件不对
curl -v http://target:9100/metrics
kubectl port-forward svc/prometheus 9090:9090 -n monitoring
kubectl get servicemonitor,podmonitor -A执行前替换占位符并控制影响范围
包含 <service>、<pod>、<namespace>、<pid>、<container> 的命令必须先替换。涉及 reload、restart、KILL、vacuum、prune 的命令要确认影响范围。
- 优先在测试环境或只读模式验证
- 生产执行前保留回滚路径
- 把最终可用命令写入工单或 runbook
kubectl get servicemonitor,podmonitor -A
kubectl describe servicemonitor <name> -n <namespace>Verification
怎么判断命令有效
- 命令已在正确机器、正确用户、正确 namespace 或正确仓库下执行。
- 输出能支撑明确判断：正常、异常、权限不足、目标不存在或需要下一跳排查。
- 对有副作用的命令，已确认执行窗口、影响范围和回滚方式。
Prevention
沉淀到日常流程
- 为 Prometheus 自身、target down 和 scrape error 建立告警，确保监控系统自身健康。
- ServiceMonitor 标签和端口名形成固定约定，减少服务发现配置错误。
- 上线 exporter 前检查 metrics 体积和高基数标签，避免抓取性能问题。
- 定期审查 Prometheus 配置和告警规则，确保覆盖新增服务的监控需求。
常见问题
为什么 ServiceMonitor 有但 Prometheus 没 target？
selector、namespaceSelector、release 标签或端口名不匹配都会导致 target 不生成。
Long-tail SEO
你可能正在搜索这些报错
下面这些错误原文、场景词和中英文搜索词，都是排查同类问题时常见的入口。
- prometheus 检查配置
- promtool check config
- prometheus target down 排查
- promtool test rules
- prometheus 配置验证
- prometheus 监控目标排查
Need More Help
这组命令还不够贴合你的场景？
把你的系统环境、目标操作和报错贴过来，我会优先补充更具体的命令模板。