Prometheus抓取.NET Core微服务/health_metrics时返回503错误求助

问题描述 #

浏览器能正常访问http://192.168.161.74:2011/health_metrics查看GC回收次数、进程启动时间等指标，但Prometheus抓取该端点时返回503 Service Unavailable。

Prometheus配置片段如下：

global:
  scrape_interval: 15s

scrape_configs:

  - job_name: 'health-metrics'
    metrics_path: /health_metrics
    static_configs:
      - targets: ['192.168.161.74:2011']

补充信息 #

• 微服务包含GraphQL Client Tools（Portal Banana、Portal Voyager等）、Swagger、Hangfire Dashboard、Health Check等组件；
• Windows环境下的同类型.NET Core微服务也出现相同问题；
• 使用Golang编写代理程序转发指标后，Prometheus可正常抓取，推测可能存在延迟相关问题。

已完成的排查步骤 #

• 验证Prometheus服务器内外均可正常访问该指标端点；
• 确认无防火墙规则阻断Prometheus与微服务的通信；
• 检查Docker日志未发现/health_metrics相关错误记录。

针对疑问的解答与排查思路 #

1. 为何浏览器可访问但Prometheus返回503？ #

浏览器与Prometheus的请求特征存在差异，核心原因可能包括：

• 请求头差异：浏览器自动携带User-Agent等标准头信息，而Prometheus默认请求头可能被.NET Core的健康检查中间件或安全拦截规则识别为非可信请求；
• 健康检查状态波动：/health_metrics可能依赖服务健康检查状态，Prometheus抓取时刚好触发了健康检查的临时失败（如依赖服务短暂不可用），而浏览器访问时状态已恢复；
• 超时阈值差异：Prometheus默认抓取超时时间较短（10s），若指标生成耗时超过该阈值会触发503；浏览器对超时的容忍度更高，或请求时系统资源充足，指标生成速度更快。

2. Prometheus或Docker需调整哪些特定配置？ #

Prometheus端配置调整

• 延长抓取超时时间：在对应的scrape job中添加scrape_timeout参数，给指标生成留足时间：

  - job_name: 'health-metrics'
    metrics_path: /health_metrics
    scrape_timeout: 30s # 延长至30s，根据实际情况调整
    static_configs:
      - targets: ['192.168.161.74:2011']
  

• 模拟浏览器请求头：添加与浏览器一致的User-Agent，规避可能的拦截规则：

  - job_name: 'health-metrics'
    metrics_path: /health_metrics
    scrape_timeout: 30s
    headers:
      User-Agent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36"
    static_configs:
      - targets: ['192.168.161.74:2011']
  

Docker端配置调整

• 调整容器资源配额：若容器CPU/内存不足导致指标生成延迟，可通过docker run命令或docker-compose文件增加资源限制：

  # 示例：给容器分配2核CPU和2GB内存
  docker run --cpus=2 --memory=2g [你的镜像名]
  

• 确认网络连通性：若使用自定义Docker网络，确保Prometheus所在网络与容器网络互通（已验证可访问的话优先级较低）。

3. 是否因资源限制或超时设置导致该问题？ #

大概率是。从Golang代理转发后可正常抓取的现象来看，代理可能间接增加了请求缓冲或延长了超时时间，掩盖了原始请求的超时问题：

• 资源限制：Docker容器资源不足时，.NET Core进程生成GC统计、进程信息等指标的速度会变慢，超过Prometheus默认的10s超时阈值；
• 超时设置：Prometheus默认scrape_timeout为10s，若指标生成耗时超过该值，Prometheus会终止请求并返回503，而浏览器没有这么严格的超时限制。

4. 如何获取Prometheus更详细日志以定位根因？ #

• 提升Prometheus日志级别：启动Prometheus时添加--log.level=debug参数，可查看抓取过程的详细日志，包括请求发送、响应接收的具体细节；
• 查看Prometheus Targets页面：访问Prometheus的/targets端点，查看该job的错误详情，比如是否显示context deadline exceeded（超时）等提示；
• 添加.NET Core请求日志：配置ASP.NET Core日志系统，记录/health_metrics端点的所有请求头、响应状态码和处理耗时，对比浏览器与Prometheus请求的差异。

额外排查建议 #

• 模拟Prometheus请求并统计耗时：用curl命令模拟Prometheus的请求，同时记录耗时，对比带浏览器User-Agent的请求差异：

  # 模拟Prometheus请求
  time curl -H "User-Agent: Prometheus/2.47.0" http://192.168.161.74:2011/health_metrics
  # 模拟浏览器请求
  time curl -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" http://192.168.161.74:2011/health_metrics
  

• 检查.NET Core健康检查配置：若/health_metrics通过Health Checks的AddMetrics生成，确认是否存在自定义健康检查策略导致临时失败；
• 查看Windows事件日志：Windows环境下的.NET Core服务，可查看应用程序事件日志，是否有请求处理异常的记录。

内容的提问来源于stack exchange，提问作者saber tabatabaee yazdi