服务器监控与日志管理

Web开发专题 · 掌握服务器监控与日志管理

专题：Python Web开发系统学习

关键词：Python, Web开发, 服务器监控, 日志管理, Sentry, Prometheus, Grafana, ELK, APM, 告警

一、服务器监控概述

在生产环境中运行Web应用，服务器监控和日志管理是保障系统稳定性和可靠性的基石。没有有效的监控手段，开发者就如同在黑暗中航行，无法及时发现和解决问题。随着微服务架构和分布式系统的普及，监控体系已经从单一的"看服务器是否活着"演变为一个覆盖多维度、多层次的复杂体系。

1.1 监控的三要素

现代监控体系通常包含三大核心要素，被称为"可观测性"的三大支柱：指标、日志和链路追踪。指标是系统状态的数据化描述，如CPU使用率、请求延迟、错误率等，其特点是数值化、可聚合、适合长期存储。日志是系统运行过程中产生的事件记录，提供了最详细的问题诊断信息，对于排查复杂错误至关重要。链路追踪则记录了一个请求在分布式系统中的完整调用路径，帮助我们理解服务之间的依赖关系和性能瓶颈。三者相辅相成，缺一不可。

1.2 监控的目标

服务器监控的核心目标可以归纳为四个维度：可用性监控确保服务处于正常运行状态，能够在用户访问时正常响应。性能监控关注系统的响应速度和处理能力，包括请求延迟、吞吐量等关键指标。容量监控帮助我们了解系统的资源使用趋势，及时预测和应对增长需求，避免因资源耗尽导致的服务中断。安全监控则关注异常访问模式、潜在的攻击行为和数据泄露风险，是保障系统安全防线的重要组成部分。

1.3 监控体系分层

一个成熟的监控体系应当是分层构建的。最底层是基础设施监控，涵盖服务器硬件资源、网络设备、数据库、中间件等基础组件的运行状态。中间层是应用监控，关注业务应用本身的健康状况，包括接口响应时间、错误率、JVM/GC状态等。最上层是业务监控，直接与业务指标挂钩，如用户注册量、订单转化率、支付成功率等。每一层监控都有其独特的工具和关注点，从底层到上层，抽象程度逐渐提高，与业务的关联性越来越强。

监控层次	监控内容	常用工具
基础设施层	CPU、内存、磁盘、网络、硬件	Prometheus + Node Exporter
应用层	响应时间、错误率、慢查询	Sentry, Datadog, SkyWalking
业务层	用户行为、交易数据、转化率	自定义埋点 + Grafana

二、应用性能监控

应用性能监控（APM）是监控体系中最贴近开发者的部分，它关注的是应用程序本身的运行表现和性能特征。通过APM，开发者可以精确地了解每个请求的处理时间、数据库查询性能、外部API调用耗时等关键信息。

2.1 响应时间监控

响应时间是衡量应用性能最直观的指标。通常我们会关注P50、P90、P99三个百分位值。P50代表中位数响应时间，反映了大多数用户的体验；P90代表90%请求的响应时间上限，是评估系统整体表现的重要参考；P99则代表了最慢的1%请求的表现，这些往往是异常请求或极端负载下的表现。例如，一个电商网站的API如果P99响应时间超过3秒，说明在高峰时段部分用户的体验会受到明显影响。在监控中，通常将响应时间按区间划分采集，而不是简单地计算平均值，因为平均值会掩盖部分慢请求的问题。

2.2 请求吞吐量

吞吐量是指系统在单位时间内能够处理的请求数量，通常以RPS（Requests Per Second）或QPS（Queries Per Second）为单位。吞吐量监控可以帮助我们判断系统是否达到了容量上限，以及需要进行水平扩展的时机。在实际生产中，吞吐量通常会与响应时间呈反向关系——当吞吐量超过某个阈值后，响应时间会急剧上升，这个临界点就是系统的"拐点"。通过压力测试找到这个拐点，并设置合理的告警阈值，是容量规划的关键工作。

2.3 错误率监控

错误率是指返回状态码为5xx或业务错误码的请求占总请求量的比例。在理想情况下，生产环境的错误率应该接近于零。在实际运维中，通常将1%作为警告阈值，5%作为严重告警阈值。错误率监控不能只看全局平均值，还需要按接口、按错误类型、按用户群体进行细分。有时一个小众接口的错误率飙升并不会显著影响全局错误率，但对于使用该接口的用户来说，问题却非常严重。

2.4 慢查询追踪

数据库慢查询是Web应用性能问题的头号元凶。慢查询追踪需要记录执行时间超过阈值的SQL语句，并分析其执行计划。在Python的ORM框架（如SQLAlchemy、Django ORM）中，可以通过配置慢查询日志或使用第三方工具（如django-debug-toolbar、silk）进行采集。定位到慢查询后，常见的优化手段包括：添加合适的数据库索引、优化查询语句（避免SELECT *、合理使用JOIN）、引入缓存层、对大数据量表进行分区分表等。

APM工具的核心价值不在于告诉你系统现在"病了"，而在于帮助你找到"病因在哪里"。一个好的APM系统应该能够从成千上万的请求中，自动识别出那些异常的、有性能问题的请求，并展示完整的调用栈和上下文信息。

2.5 APM工具对比

市场上主流的APM工具各有特点。Sentry专注于错误追踪和性能监控，开源且对Python生态环境支持极好。Datadog是功能最为全面的商业APM平台，提供从基础设施到应用层的全栈监控，但成本较高。SkyWalking是Apache基金会的开源分布式APM系统，对微服务和云原生场景支持优秀，但配置相对复杂。对于中小型Python项目，推荐从Sentry入手，配合Prometheus+Grafana构建基础监控体系。

三、系统资源监控

系统资源监控是监控体系的底层基础，直接关注服务器硬件和操作系统的运行状态。即使应用代码完全正确，资源耗尽也会导致服务不可用。系统资源监控的主要目标是确保服务器有足够的资源来处理应用负载，并在资源紧张时及时发出预警。

3.1 CPU使用率监控

CPU使用率是衡量服务器繁忙程度的核心指标。我们不仅关注用户态CPU使用率，还应该关注系统态CPU（内核操作）、I/O等待和软中断的占比。当CPU使用率持续超过80%时，通常意味着服务器正处于高负载状态，需要排查是否存在死循环、大量计算任务或资源竞争等问题。特别需要注意的是，CPU使用率过高有时并不是应用代码本身导致的，可能是内存不足触发了频繁的交换操作（Swap），或者是磁盘I/O性能瓶颈导致大量进程处于D状态（不可中断睡眠）。

3.2 内存使用监控

内存监控关注已用内存、可用内存、缓存和交换分区的使用情况。在Python应用中，内存泄漏是一个常见问题——由于循环引用、全局缓存不当管理或第三方库的bug，内存占用可能会随时间缓慢增长，最终导致OOM（Out of Memory）被系统kill。内存监控应提供趋势视图，重点关注内存使用量随时间的变化曲线。如果发现内存使用呈现持续上升趋势而从不回落，就需要引起警惕了。除了系统级别的内存监控，还应该关注Python进程本身的内存使用情况，可以使用tracemalloc或memory_profiler等工具进行诊断。

3.3 磁盘I/O监控

磁盘I/O性能对数据库密集型应用的性能影响巨大。监控指标包括磁盘读写速率（IOPS）、读写延迟、磁盘使用率和队列长度。当磁盘利用率接近100%或I/O等待时间持续偏高时，数据库查询会变得异常缓慢。对于使用机械硬盘（HDD）的服务器，随机读写性能是主要瓶颈；而SSD虽然性能更好，但也有写入寿命限制。在线服务类应用应尽可能使用SSD，并对日志写入、数据备份等I/O密集型操作进行错峰调度。

3.4 网络流量监控

网络监控包括流入/流出流量、连接数、丢包率等指标。对于Web服务器来说，TCP连接状态分布是一个重要的诊断依据——TIME_WAIT连接过多说明短连接使用频繁，可以启用连接复用；ESTABLISHED连接数异常增多可能意味着DDoS攻击或连接泄漏。带宽利用率也需要关注，特别是对于提供文件下载或视频流服务的应用，带宽耗尽会直接影响用户体验。此外，网络延迟（Latency）监控对于跨地域部署的服务尤为关键。

3.5 进程监控

进程监控确保关键的应用程序进程保持运行状态。在Linux系统中，常用的进程管理方案包括：使用systemd的service单元进行进程守护和自动重启；使用Supervisor管理多个Python进程，提供进程状态监控和自动重启功能；使用Docker的restart策略进行容器级别的进程管理。进程监控不仅要检查进程是否存在，还应该关注进程的健康状态，比如通过发送SIGQUIT信号获取线程堆栈信息，或者通过进程的HTTP健康检查端点确认应用是否正常响应。

四、Python日志配置

日志是问题诊断最重要的信息来源之一。Python标准库的logging模块提供了强大的日志框架，但在实际生产中，许多开发者只使用了其最基本的功能。下面我们来深入探讨如何在生产环境中正确地配置Python日志系统。

4.1 logging模块高级配置

Python的logging模块采用模块化设计，包含Logger、Handler、Formatter和Filter四个核心组件。生产环境的日志配置通常通过dictConfig进行集中管理，而不是在代码中分散调用basicConfig。通过dictConfig，我们可以为不同的模块配置不同的日志级别和输出目标，例如：将第三方库的日志级别设置为WARNING以减少噪音，而将自己的应用日志设置为DEBUG级别以获取详细信息。

import logging.config
import os

LOGGING_CONFIG = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'standard': {
            'format': '%(asctime)s [%(levelname)s] %(name)s: %(message)s'
        },
        'detailed': {
            'format': '%(asctime)s [%(levelname)s] %(name)s '
                      '(%(filename)s:%(lineno)d): %(message)s'
        },
    },
    'handlers': {
        'console': {
            'class': 'logging.StreamHandler',
            'level': 'DEBUG',
            'formatter': 'standard',
            'stream': 'ext://sys.stdout',
        },
        'file': {
            'class': 'logging.handlers.RotatingFileHandler',
            'level': 'INFO',
            'formatter': 'detailed',
            'filename': 'logs/app.log',
            'maxBytes': 10485760,  # 10MB
            'backupCount': 5,
        },
    },
    'loggers': {
        '': {  # root logger
            'handlers': ['console', 'file'],
            'level': 'INFO',
        },
        'django': {
            'handlers': ['console', 'file'],
            'level': 'WARNING',
            'propagate': False,
        },
    },
}

logging.config.dictConfig(LOGGING_CONFIG)

4.2 日志轮转

在生产环境中，日志文件如果不加控制会持续增长，最终占满磁盘空间。Python logging模块提供了两种日志轮转策略。RotatingFileHandler基于文件大小进行轮转，当日志文件达到指定大小后自动重命名并创建新文件。TimedRotatingFileHandler基于时间间隔进行轮转，支持按秒、分、时、天、周和月为单位进行切分。实际部署时建议将两者结合使用，既设置文件大小上限也设置时间间隔，以'when': 'midnight'配合'interval': 1实现每日轮转，同时设置'maxBytes'防止单日内日志量过大。轮转后的旧日志文件可以设置压缩策略，或者配置定期清理任务。

4.3 JSON日志格式

传统的文本格式日志对人类阅读友好，但不适合被日志收集系统（如ELK、Loki）解析。在生产环境的集中式日志系统中，推荐使用JSON格式输出日志，这样每个结构化字段（如请求ID、用户ID、响应时间等）都可以被独立索引和搜索。实现JSON日志格式的方法是自定义一个Formatter类，在format方法中将日志记录转换为JSON字符串。

import json
import logging


class JsonFormatter(logging.Formatter):
    def format(self, record):
        log_data = {
            'timestamp': self.formatTime(record),
            'level': record.levelname,
            'logger': record.name,
            'message': record.getMessage(),
            'module': record.module,
            'function': record.funcName,
            'line': record.lineno,
        }
        # 包含异常信息
        if record.exc_info and record.exc_info[0]:
            log_data['exception'] = self.formatException(record.exc_info)
        # 包含额外字段（如request_id）
        if hasattr(record, 'request_id'):
            log_data['request_id'] = record.request_id
        return json.dumps(log_data, ensure_ascii=False)

4.4 日志级别动态调整

在生产环境中，有时我们需要临时提高某个模块的日志级别以排查问题，但又不想重启服务（重启可能会让问题消失）。通过实现一个HTTP端点或使用信号处理机制，可以在运行时动态调整日志级别。例如，可以提供一个/debug/log-level的端点，传入logger名称和目标级别，程序内部调用logger.setLevel()即可即时生效。这种做法在线上排查问题时极为有用——将级别从INFO临时调整为DEBUG，获取到所需信息后再恢复为正常级别。

4.5 请求ID追踪

在Web应用中，一个用户请求可能涉及多个服务调用、数据库查询和异步任务。如果没有请求ID，很难将分散的日志条目关联到同一个请求上。请求ID追踪的实现思路是：在每个请求进入时生成一个唯一的UUID，通过日志的extra参数或ContextVar（Python 3.7+）将其注入到日志记录中。在Flask中可以通过before_request钩子实现，在Django中则可以通过中间件实现。请求ID不仅用于日志关联，还可以传递给下游服务，实现跨服务的请求追踪。

import uuid
from contextvars import ContextVar
import logging

request_id_var: ContextVar[str] = ContextVar('request_id', default='')


class RequestIdFilter(logging.Filter):
    def filter(self, record):
        record.request_id = request_id_var.get()
        return True


# 在Web框架中间件中设置请求ID
async def middleware(request, call_next):
    request_id = str(uuid.uuid4())
    request_id_var.set(request_id)
    response = await call_next(request)
    response.headers['X-Request-ID'] = request_id
    return response

五、集中式日志管理

在单服务器时代，直接登录服务器查看日志文件是一种常见做法。但在微服务和分布式部署场景下，日志分散在成百上千个服务器上，必须要有一个集中式的日志管理平台来统一采集、存储、搜索和分析日志数据。

5.1 ELK Stack

ELK是Elasticsearch、Logstash和Kibana三个开源项目的首字母缩写，是业界最经典的日志管理解决方案。Elasticsearch是一个分布式搜索和分析引擎，负责日志数据的存储、索引和搜索。Logstash是一个服务器端数据处理管道，负责从多种来源采集日志数据，进行转换和 enrichment，然后发送到Elasticsearch。Kibana是可视化层，提供数据探索、图表展示和仪表盘功能。在实际部署中，通常会加入Filebeat作为轻量级的日志采集代理，形成ELK Filebeat的架构。Filebeat消耗资源极低，部署在每个业务服务器上，负责读取日志文件并发送到Logstash或直接发送到Elasticsearch。

5.2 Loki + Grafana

Loki是Grafana Labs推出的日志聚合系统，其设计理念与Prometheus一脉相承——使用标签作为索引的主要方式，而不是对日志全文建立索引。这种设计的优势在于：对于Kubernetes环境，可以直接复用Pod的标签来组织日志，配置简单且存储成本远低于ELK。Loki的日志采集通常通过Promtail代理完成，Promtail从日志文件中读取内容，自动附加Kubernetes标签后发送到Loki。查询使用LogQL语法，它与PromQL高度相似，开发者可以在Grafana中无缝切换指标查询和日志查询。

ELK vs Loki 选型建议：如果你的团队已经使用Elasticsearch，且需要进行复杂的全文搜索和分析，ELK是成熟的选择。如果预算有限、运维人力不足且环境以Kubernetes为主，Loki+Grafana方案更加轻量和经济。对于大型企业，ELK的功能更为全面；对于中小团队，Loki的简洁性和与Prometheus的原生集成更具吸引力。

5.3 日志采集工具

Filebeat是Elastic公司推出的轻量级日志采集器，使用Go语言编写，资源占用极小（通常只需10-20MB内存）。它支持自动多行合并（如将Java异常堆栈跟踪合并为一条日志）、加载均衡和背压感知等功能。Fluentd是另一个流行的开源数据采集器，由CNCF托管，使用Ruby编写，拥有丰富的插件生态系统。Fluent Bit是Fluentd的轻量级C语言版本，内存占用仅为几百KB，适合在资源受限的环境中运行。在选型时，如果日志系统使用ELK，优先考虑Filebeat；如果使用其他后端（如MongoDB、S3），Fluentd的灵活性更高。

5.4 日志索引与搜索

无论是ELK还是Loki，日志搜索的效率都依赖于合理的索引策略。在Elasticsearch中，建议按照时间（如按天创建索引）和业务类型进行索引拆分。使用Index Lifecycle Management（ILM）自动管理索引的生命周期：热阶段存放最新日志并提供快速写入和搜索，暖阶段存放近期的历史日志，冷阶段将旧日志转移到廉价存储。搜索时尽量缩小时间范围和指定明确的字段过滤条件，避免对整个索引进行全文搜索。对于Loki，合理的标签设计是查询性能的关键——标签的基数不宜过高（避免使用user_id等高基数字段作为标签），常用的标签包括namespace、app、level、cluster等。

5.5 日志告警

从日志中检测异常并触发告警是集中式日志管理的高级应用。Elasticsearch提供了Watcher功能（X-Pack的一部分），可以定期执行查询并基于条件触发告警，支持Slack、钉钉、邮件等多种通知渠道。在开源方案中，ElastAlert是广泛使用的Elasticsearch告警工具，支持频率告警、变化率告警、缺失告警等多种规则类型。对于Loki，可以直接使用Grafana的告警功能，基于LogQL查询结果设置告警规则。日志告警的典型场景包括：在最近5分钟内ERROR级别日志超过阈值、连续N分钟没有日志产生（服务可能挂了）、特定关键字（如OutOfMemoryError）出现等。

六、Sentry错误追踪

Sentry是目前最流行的开源错误追踪平台之一，专注于帮助开发者实时发现、诊断和修复生产环境中的错误。与其他监控工具不同，Sentry提供的是代码级别的错误上下文，包括完整的堆栈跟踪、局部变量值、HTTP请求参数、用户信息等，大大加快了问题定位的速度。

6.1 Sentry集成

Sentry对Python Web框架提供了原生支持，集成过程非常简单。对于Flask应用，安装sentry-sdk后只需在应用初始化时调用sentry_sdk.init()并传入DSN。对于Django应用，sentry-sdk会自动集成Django的信号机制，捕获视图函数中的异常。对于FastAPI，使用sentry_sdk.init()后还需要配置asgi_handler=True以正确捕获ASGI异常。需要注意的是，Sentry默认不会捕获日志记录中的error和warning级别消息，需要通过配置将logging模块与Sentry集成，实现日志级别的错误上报。

import sentry_sdk
from sentry_sdk.integrations.flask import FlaskIntegration
from sentry_sdk.integrations.logging import LoggingIntegration

sentry_logging = LoggingIntegration(
    level=logging.INFO,       # 捕获INFO及以上级别日志
    event_level=logging.ERROR # ERROR及以上级别生成Sentry事件
)

sentry_sdk.init(
    dsn="https://your-dsn@sentry.io/project-id",
    integrations=[
        FlaskIntegration(),
        sentry_logging,
    ],
    traces_sample_rate=1.0,   # 性能追踪采样率
    environment="production",
    release="v1.0.0",
)

6.2 错误分组与过滤

Sentry默认根据堆栈跟踪和错误消息对错误事件进行分组。但在实际应用中，相同的底层错误可能因为请求参数不同而产生看似不同的错误消息，导致分组不合理。可以通过实现before_send回调函数来修改或过滤错误事件：对错误消息进行归一化处理（如替换URL中的动态参数和ID），或者屏蔽包含敏感信息的错误事件（如密码、信用卡号）。另外，对于已知的、无需关注的低优先级错误，可以在Sentry的Ingestion规则中配置过滤条件，避免这些"噪音"淹没真正需要关注的关键错误。

6.3 源映射

如果你的前端使用TypeScript编译为JavaScript，并且部署时对代码进行了混淆和压缩，那么Sentry上报的错误堆栈将难以阅读。Source Maps（源映射）文件可以将压缩后的代码映射回原始源代码，帮助开发者直接看到TypeScript源码中的错误位置。Sentry提供了两种处理方式：在构建过程中使用@sentry/webpack-plugin自动上传源映射文件，或者将源映射文件部署到公开的服务器URL上。注意：为了安全，通常建议将源映射文件仅在内部访问，或者通过Sentry的Relay代理进行上传而非公开发布。

6.4 性能追踪

除了错误追踪，Sentry还提供了性能监控功能。通过配置traces_sample_rate参数，可以控制采样率对事务进行追踪。每个事务包含多个Span（操作单元），例如：一个HTTP请求事务可能包含数据库查询、外部API调用、模板渲染等Span。在代码中通过手动创建Span来追踪关键业务操作的耗时。Sentry的性能追踪视图会展示所有事务的耗时分布、每个Span的详细时间消耗，并自动标记出最慢的Span，帮助开发者快速定位性能瓶颈。

from sentry_sdk import start_transaction, start_span

with start_transaction(op="task", name="process_order"):
    with start_span(op="db.query", description="查询用户信息"):
        user = get_user(order.user_id)

    with start_span(op="http.post", description="调用支付网关"):
        payment_result = payment_gateway.charge(order)

    with start_span(op="db.save", description="保存订单"):
        order.save()

6.5 Release追踪

Sentry的Release追踪功能可以将错误事件与特定的发版版本关联起来，帮助判断某个错误是新增的还是在某次发版后引入的。在sentry_sdk.init()中配置release参数（如release="v1.0.0"），Sentry会自动将每次发版后的错误与之前的版本进行对比。使用Sentry的Release Health仪表盘，可以直观地看到每个版本的用户影响范围、崩溃率变化趋势。结合CI/CD流水线，可以在发现新版本引入严重错误时自动触发回滚流程。

七、Prometheus + Grafana

Prometheus是一个开源的系统监控和告警工具包，由CNCF托管，是云原生监控领域的事实标准。Grafana则是业界最流行的指标可视化平台。两者的结合构成了目前最流行的开源监控方案。

7.1 应用指标暴露

Prometheus通过HTTP端点定期拉取（Pull）指标数据，因此应用需要暴露一个/metrics端点来提供指标数据。在Python中，prometheus_client库提供了完整的指标采集和暴露功能。对于Flask应用，可以使用prometheus_flask_exporter自动暴露指标。对于Django应用，django-prometheus提供了类似的集成。手动实现时，只需要在应用的路由中注册一个/metrics端点，调用generate_latest()函数返回Prometheus格式的指标文本即可。Prometheus默认每15秒拉取一次指标数据，这个频率可以通过scrape_interval配置项调整。

from prometheus_client import Counter, Histogram, generate_latest
from flask import Flask, Response, request
import time

app = Flask(__name__)

REQUEST_COUNT = Counter(
    'http_requests_total',
    'Total HTTP requests',
    ['method', 'endpoint', 'status']
)

REQUEST_DURATION = Histogram(
    'http_request_duration_seconds',
    'HTTP request duration in seconds',
    ['method', 'endpoint'],
    buckets=(0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10)
)

@app.before_request
def before_request():
    request.start_time = time.time()

@app.after_request
def after_request(response):
    duration = time.time() - request.start_time
    REQUEST_COUNT.labels(
        method=request.method,
        endpoint=request.path,
        status=response.status_code
    ).inc()
    REQUEST_DURATION.labels(
        method=request.method,
        endpoint=request.path
    ).observe(duration)
    return response

@app.route('/metrics')
def metrics():
    return Response(generate_latest(), mimetype='text/plain')

7.2 自定义指标类型

Prometheus客户端库提供四种核心指标类型。Counter（计数器）表示一个只增不减的数值，适用于记录请求总数、错误总数等。Gauge（仪表盘）表示一个可上下波动的数值，适用于记录当前内存使用量、并发连接数、队列长度等。Histogram（直方图）对观测值进行采样并分桶统计，适用于记录请求延迟、响应大小等，可以计算P50/P90/P99百分位数。Summary（摘要）类似于Histogram但计算的是流式百分位数（在客户端直接计算分位数）。在实际使用中，Histogram比Summary更常用，因为可以在服务端对多个实例的Histogram数据进行聚合计算。

指标类型	特点	适用场景	常用方法
Counter	只增不减	请求总数、错误总数、任务执行次数	inc()
Gauge	可增可减	内存使用、连接数、队列长度	set(), inc(), dec()
Histogram	分桶统计	请求延迟、响应大小	observe()
Summary	流式分位数	客户端计算的分位数指标	observe()

7.3 Grafana仪表盘配置

Grafana作为指标可视化平台，其核心功能是创建仪表盘（Dashboard）。一个典型的Web应用监控仪表盘应包含以下面板：RPS面板（展示每秒请求数的趋势变化，按状态码着色区分）、延迟面板（展示P50/P90/P99响应时间的叠加折线图）、错误率面板（展示各接口的5xx错误占比）、CPU和内存面板（展示应用实例的系统资源消耗）、慢请求面板（展示响应时间超过阈值的请求分布）。Grafana支持丰富的图表类型（折线图、柱状图、热力图、仪表盘等），也支持使用PromQL进行灵活的指标查询和聚合计算。仪表盘创建完成后可以导出为JSON文件进行版本管理和团队共享。

7.4 告警规则设置

Prometheus的告警功能通过Alertmanager组件实现。告警规则的配置分为三个步骤：首先在Prometheus配置文件中定义告警规则（如：当error_rate > 0.05持续5分钟时触发告警），然后配置Alertmanager负责告警的去重、分组、静默和路由，最后配置通知渠道将告警发送给相关人员。Alertmanager支持分组通知（将同一类别的告警合并为一条通知以减少信息轰炸）、抑制（某个告警触发后自动抑制相关的低级别告警以防止告警风暴）和静默（在维护窗口期内暂时屏蔽告警）等功能。

# Prometheus 告警规则示例
groups:
- name: web_app_alerts
  rules:
  - alert: HighErrorRate
    expr: |
      sum(rate(http_requests_total{status=~"5.."}[5m]))
      /
      sum(rate(http_requests_total[5m])) > 0.05
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "错误率超过5%，当前值: {{ $value | humanizePercentage }}"
      description: |
        服务 {{ $labels.job }} 在最近5分钟内错误率达到
        {{ $value | humanizePercentage }}，超过了5%的阈值。

  - alert: HighLatency
    expr: |
      histogram_quantile(0.99,
        rate(http_request_duration_seconds_bucket[5m])
      ) > 3
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "P99延迟超过3秒，当前值: {{ $value }}s"

7.5 常见监控指标

一个Python Web应用需要关注的核心指标包括：请求速率（rps，按接口和方法维度）、请求延迟分布（按百分位和接口维度）、错误率（按状态码和接口维度）、活跃用户数、数据库连接池使用率、缓存命中率、任务队列深度（Celery/RQ）、异步任务执行延迟、数据库查询耗时分布以及外部API调用耗时。通过这些指标，可以全面掌握应用的运行状态和性能表现。建议将指标按层次组织——黄金信号指标（延迟、流量、错误、饱和度）放在仪表盘顶部，详细指标放在下方供深入分析。

八、健康检查与告警

健康检查是确保服务可用性的最后一道防线，告警则是将问题信息传递给运维人员的关键桥梁。一个没有告警的监控系统是"聋子的耳朵"——即使收集了再多数据也无法起到实际作用。

8.1 健康检查端点

健康检查端点（通常为/health或/healthz）是负载均衡器和容器编排系统判断服务是否正常的标准接口。一个优秀的健康检查端点应该检查以下内容：应用进程是否存活并能正常响应HTTP请求、数据库连接是否正常、缓存服务能否正常读写、关键依赖服务（如消息队列、外部API）是否可用、以及磁盘空间是否充足。健康检查端点应该返回标准的状态码（200表示正常，503表示不健康），并建议使用JSON格式的响应体提供详细的检查结果，方便自动化运维系统进行分析和处理。

import flask
import psycopg2
import redis

app = flask.Flask(__name__)

def check_database():
    try:
        conn = psycopg2.connect(**DB_CONFIG)
        conn.close()
        return True, "database ok"
    except Exception as e:
        return False, f"database error: {str(e)}"

def check_redis():
    try:
        r = redis.Redis(**REDIS_CONFIG)
        r.ping()
        return True, "redis ok"
    except Exception as e:
        return False, f"redis error: {str(e)}"

@app.route('/health')
def health():
    checks = {
        'database': check_database(),
        'redis': check_redis(),
    }

    status = 200 if all(ok for ok, _ in checks.values()) else 503
    return flask.jsonify({
        'status': 'healthy' if status == 200 else 'unhealthy',
        'checks': {
            name: {'status': 'ok' if ok else 'error', 'message': msg}
            for name, (ok, msg) in checks.items()
        }
    }), status

8.2 存活与就绪探针

在Kubernetes环境中，健康检查被细分为存活探针（Liveness Probe）和就绪探针（Readiness Probe）。存活探针用于判断容器是否需要重启——如果应用死锁或进入了无法恢复的状态，存活探针失败后Kubernetes会自动重启容器。就绪探针用于判断容器是否已经准备好接收流量——如果应用启动中或过载，就绪探针失败后Kubernetes会暂时将容器从Service的负载均衡池中移除。两者的合理配置至关重要：将/healthz端点配置为存活探针，将/ready端点配置为就绪探针，可以避免因短暂阻塞导致容器被频繁重启的"CrashLoopBackOff"问题。

8.3 告警通知

告警通知渠道的选择直接影响响应效率。邮件通知适合低优先级的告警（如磁盘使用率超过70%），提供详细的信息和操作建议。即时通讯通知（钉钉、企业微信、Slack）适合中高优先级的告警，通过Webhook机器人发送格式化消息，支持@指定负责人。短信和电话通知仅用于最高优先级的告警（如服务完全不可用、P0级故障），确保在任何时间都能联系到值班人员。在实际配置中，推荐采用"分层告警"策略：不同严重等级的告警使用不同的通知渠道和响应时间要求，避免不重要的告警干扰到值班人员。

告警最佳实践：好的告警系统应该做到"该响的响，不该响的不响"。为每条告警规则设置清晰的操作指南（Runbook），明确责任人和处理步骤。定期审查告警规则，消除那些从未触发过或者总是触发却无人处理的"僵尸告警"。告警不是越多越好——每次告警都应该是一个需要人工干预的真实问题。

8.4 值班排班

值班排班是运维流程的重要环节。常用的值班方案包括：使用PagerDuty或Opsgenie等SaaS服务进行值班排班和告警路由，支持定时轮换、接力通知和升级策略（第一负责人未确认则自动升级到第二负责人）。对于国内团队，蓝鲸智云（BK-BCS）提供了类似的能力。对于中小团队，可以通过Grafana的OnCall插件或自建简单的轮班脚本实现值班管理。无论采用何种方案，都需要确保告警通知中有明确的当前值班人员联系方式，以及标准的故障升级流程。

8.5 完整的监控体系总结

建立一个完整的监控体系是一个持续迭代的过程，建议从最基础的可用性监控开始，逐步扩展和丰富。第一阶段实现基础设施监控（CPU、内存、磁盘）和应用存活检查。第二阶段引入APM工具追踪性能和错误。第三阶段建设集中式日志平台，实现日志的搜索和分析。第四阶段建立业务监控指标，将监控与业务目标对齐。最后持续优化告警规则和响应流程，让监控体系真正服务于系统稳定性和业务连续性。

"你能测量的，才能管理；你能监控的，才能保证。" —— 在Web开发中，监控不是可选项，而是生产环境的必备基础设施。投入精力建设好监控体系，会在未来的每一个故障排查时刻获得百倍的回报。