作为业务开发就不需要懂Prometheus么

<think>好的，用户问的是Prometheus针对业务应用需要监控哪些方面。首先，我需要回想一下Prometheus的基本功能和适用场景。Prometheus主要是做监控和告警的，特别适合云原生环境，但也能监控传统应用。业务应用监控的话，可能需要关注几个关键点：比如服务是否存活、性能指标、业务相关的自定义指标、日志和链路追踪可能不是Prometheus的强项，但有时会结合其他工具。 接下来，用户可能想知道具体的监控项，比如HTTP请求量、延迟、错误率这些。然后，业务逻辑相关的指标，比如订单数、用户活跃度这些自定义指标。这时候要提到Prometheus的客户端库，比如Java的SimpleClient，可以让开发者在代码里埋点，暴露指标。 然后需要考虑基础设施部分，虽然用户问的是业务应用，但业务应用依赖的数据库、缓存、消息队列的状态也会影响业务，所以可能需要提到这些关联监控。不过要区分清楚，Prometheus主要负责应用层面的，基础设施可能需要其他exporter。 然后告警部分，Prometheus的Alertmanager怎么配置规则，比如当错误率超过阈值时触发告警。这里要举一些例子，比如请求错误率超过5%就告警，或者延迟过高。 另外，用户可能对如何开始实施不太清楚，所以需要给出步骤，比如确定需求、埋点、暴露指标、配置采集、配置告警、可视化。可能还需要提到和Grafana结合做图表。 还需要注意一些常见问题，比如指标设计要合理，避免高基数标签，以及Prometheus的拉取模式可能需要服务支持/metrics端点。如果是短生命周期的任务，可能需要Pushgateway。 最后，确保回答结构清晰，分点列出，让用户容易理解。同时要检查有没有遗漏，比如业务连续性、SLO管理这些高阶内容，可能用户不一定需要，但可以简要提及。总之，要把Prometheus在业务监控中的核心部分讲清楚，给出实际例子和步骤，帮助用户落地。</think>Prometheus 针对业务应用的监控可分为以下核心维度，结合场景和最佳实践逐步实施： --- ### 一、基础存活监控 1. **服务存活状态** - 通过 `up{job="your_service"}` 监控实例是否存活 - 配置告警规则：`up == 0` 2. **健康检查端点** - 暴露 `/health` 端点，返回 HTTP 200 和状态数据 - 使用 `probe_success{job="health_check"}` 监控健康状态 --- ### 二、业务性能指标 1. **HTTP 请求指标** - 使用客户端库（如 `prometheus/client_java`）自动收集： ```java Counter requests = Counter.build() .name("http_requests_total") .help("Total HTTP requests") .labelNames("method", "path", "status") .register(); ``` - 关键指标： - 请求速率：`rate(http_requests_total[5m])` - 错误率：`sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))` - 延迟分布：`histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))` 2. **自定义业务指标** - 订单场景示例： ```python from prometheus_client import Gauge active_orders = Gauge('business_orders_active', 'Current active orders') ``` --- ### 三、资源与依赖监控 1. **应用资源消耗** - 容器化环境监控： - CPU：`rate(container_cpu_usage_seconds_total[5m])` - 内存：`container_memory_working_set_bytes` 2. **中间件依赖** - 数据库连接池： ```go db_connections = prometheus.NewGauge(prometheus.GaugeOpts{ Name: "db_connections_active", Help: "Current active DB connections", }) ``` --- ### 四、告警配置示例 ```yaml # alert_rules.yml groups: - name: business-alerts rules: - alert: HighErrorRate expr: | sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05 for: 10m labels: severity: critical annotations: summary: "High error rate ({{ $value }}) on {{ $labels.instance }}" ``` --- ### 五、实施路径 1. **指标埋点** - 选择关键业务路径埋点（注册、支付等核心流程） - 使用 `Counter/Gauge/Histogram` 三种基础类型 2. **暴露端点** - 确保应用暴露 `/metrics` 端点 3. **Prometheus 配置** ```yaml scrape_configs: - job_name: 'business-service' scrape_interval: 15s static_configs: - targets: ['app-server:8080'] ``` 4. **可视化集成** - 通过 Grafana 构建业务看板 - 关键模板：`179`（JVM 监控）、`315`（Redis 看板） --- ### 六、避坑指南 1. **标签设计** - 避免高基数标签（如用户ID），优先使用枚举值 - 错误示例：`path="/user/1234/profile"` - 正确做法：`path="/user/:id/profile"` 2. **采样频率** - 业务指标建议 `15-30s` 采集间隔 3. **长期存储** - 超过 15 天数据需接入 Thanos 或 VictoriaMetrics --- 通过以上分层监控，可构建覆盖业务健康度、性能表现、资源消耗的完整可观测体系，结合 SLO（服务等级目标）管理实现精准告警。