Prefect 服务器性能探究实战基于 OpenTelemetry 的本地遥测与数据库压测方案【免费下载链接】prefectPrefect is a workflow orchestration framework for building resilient data pipelines in Python.项目地址: https://gitcode.com/GitHub_Trending/pr/prefect导读本文围绕 Prefect 官方仓库load_testing/目录入口文档为 load_testing/README.md展开讲解一套面向 Prefect Server 的**本地性能探究investigating server performance**方法论通过 Docker 拉起 OpenTelemetry 采集栈Jaeger Prometheus Collector用opentelemetry-instrument对 Prefect Server 进程注入自动插桩再配合 SQLite / PostgreSQL 两种数据库形态运行服务器、填充工作池与部署、启动 Worker 制造真实负载最终在 Jaeger 与 Prometheus 中观察 trace 与指标。读完本文你将掌握如何在本地复现这套可观测性压测环境并理解每个脚本、配置与源码调用点的底层原理。一、前置条件与依赖安装原文档明确列出两项硬性要求Docker与OpenTelemetry 相关 Python 库。前者用于运行本地遥测栈Collector / Jaeger / Prometheus 三个容器后者用于对 Prefect Server 进程做自动插桩。依赖安装直接使用uv pip install一次性安装五个包uv pip install opentelemetry-api \ opentelemetry-sdk \ opentelemetry-exporter-otlp \ opentelemetry-instrumentation-sqlalchemy \ opentelemetry-instrumentation-fastapi各包职责如下包作用opentelemetry-api/opentelemetry-sdkOpenTelemetry 的 API 抽象与 SDK 实现负责 span/metric/log 的创建与导出opentelemetry-exporter-otlpOTLP 导出器将遥测数据以 gRPC 协议发送到 Collector 的4317端口opentelemetry-instrumentation-sqlalchemy自动插桩 SQLAlchemy 数据库访问产生数据库调用 spanopentelemetry-instrumentation-fastapi自动插桩 FastAPI 请求处理产生 HTTP 请求 span注意仓库中的脚本都以 bash 脚本形式存放首次运行前需要赋予执行权限原文档要求执行chmod x load_testing/local-telemetry/start chmod x load_testing/run-server.sh chmod x load_testing/populate-server.sh说明chmod属于本地开发环境的一次性授权操作是官方文档为运行仓库脚本给出的标准步骤。二、启动本地遥测栈Collector、Jaeger 与 Prometheus2.1 一条命令拉起整个栈./load_testing/local-telemetry/start该脚本load_testing/local-telemetry/start的逻辑非常简单先检查名为telemetry的 Docker 网络是否存在不存在则创建然后以脚本所在目录为项目目录后台拉起 Compose#!/bin/bash if ! docker network inspect telemetry /dev/null 21; then docker network create telemetry fi docker compose --project-directory $(dirname $0) up -d独立的telemetry网络保证了三个容器之间可以通过服务名互访例如 Collector 以jaeger:4317转发 trace同时不影响其他 Docker 项目。2.2 三个容器的分工与端口load_testing/local-telemetry/docker-compose.yml 定义了三个服务Prometheusprom/prometheus:v3.14.0监听端口9090即指标查询前端挂载prometheus.yml作为抓取配置Jaegerjaegertracing/all-in-one:1.76.016686Jaeger UI 前端用于浏览 trace4317接收 Collector 转发过来的 OTLP gRPC trace其余5775/6831/6832/5778/14250/14268/14269/9411为 Jaeger 兼容的各类采集协议与健康检查端口depends_on: prometheus保证启动顺序OpenTelemetry Collectorotel/opentelemetry-collector-contrib:0.159.04317接收来自 Prefect Server 的 OTLP gRPC 遥测数据这是OTEL_EXPORTER_OTLP_ENDPOINT指向的入口8888Collector 自身的指标供 Prometheus 抓取8889Collector 作为 Prometheus exporter 暴露处理后的指标挂载 load_testing/local-telemetry/otelcol-config.yaml 作为配置依赖关系为collector - jaeger, prometheus即先有存储端再有采集端。2.3 Collector 管道配置解读load_testing/local-telemetry/otelcol-config.yaml 是理解数据流向的关键receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 processors: batch: exporters: otlp_grpc/jaeger: endpoint: jaeger:4317 tls: insecure: true debug: prometheus: endpoint: 0.0.0.0:8889 send_timestamps: true metric_expiration: 180m resource_to_telemetry_conversion: enabled: true service: telemetry: metrics: readers: - pull: exporter: prometheus: host: 0.0.0.0 port: 8888 pipelines: traces: receivers: [otlp] processors: [batch] exporters: [otlp_grpc/jaeger, debug] metrics: receivers: [otlp] processors: [batch] exporters: [prometheus, debug] logs: receivers: [otlp] processors: [batch] exporters: [debug]关键设计点**三条管道traces / metrics / logs**共用同一个 OTLP gRPC receiver入口均为0.0.0.0:4317trace 管道batch 合并后转发给 Jaegerjaeger:4317内部网络tls.insecure: true同时输出到debugexporter 便于终端排查metrics 管道batch 后由内置 Prometheus exporter 在8889暴露同时通过 pull reader 在8888上以拉取方式提供服务metric_expiration: 180m控制指标在 3 小时无更新后被清理logs 管道仅输出到debug用于排查日志链路。Prometheus 的抓取目标定义在 load_testing/local-telemetry/prometheus.yml每 15 秒抓取 Collector 的8888自身指标与8889处理后指标global: scrape_interval: 15s scrape_configs: - job_name: opentelemetry static_configs: - targets: - collector:8888 - collector:88892.4 验证栈是否就绪启动完成后Jaeger UIhttp://localhost:16686选择服务名prefect-server即可查看 tracePrometheushttp://localhost:9090可对prefect_*、http_*等指标做查询与绘图。正如 load_testing/local-telemetry/README.md 所述对本地服务器发起请求后trace 会实时出现在 Jaeger 前端中这是判断链路是否打通的最直观信号。三、带追踪运行 Prefect ServerSQLite 与 PostgreSQL3.1 一键脚本run-server.sh原文档给出的运行方式# Run with SQLite (default) ./load_testing/run-server.sh # Run with PostgreSQL 15 ./load_testing/run-server.sh postgres:15阅读 load_testing/run-server.sh 源码可以确认脚本实际支持三个位置参数并带有默认值参数默认值说明$1DB_TYPEsqlite数据库类型支持sqlite或postgres:version$2NO_SERVICESFalse是否仅启动 Web 服务关闭后台调度等服务$3SERVER_LOGGING_LEVELwarningUvicorn 日志级别3.2 SQLite 模式当$1为sqlite时脚本直接沿用 Prefect 的默认 SQLite 配置不做任何数据库初始化动作: # Use default SQLite configuration分支仅作占位。适合快速验证遥测链路是否打通。3.3 PostgreSQL 模式与容器生命周期管理当$1形如postgres:version例如postgres:15时脚本调用start_postgres函数其生命周期策略非常值得借鉴复用优先若存在名为prefect-postgres的容器先docker exec读取其实际 PostgreSQL 版本号版本不匹配则清理重建若现有版本与请求版本不一致docker rm -f容器并docker volume rm prefectdb清空数据卷保证从干净状态启动启动失败则重建复用场景下若docker start失败同样删除容器与卷重新创建无容器则新建docker run -d --name prefect-postgres \ -v prefectdb:/var/lib/postgresql/data \ -p 5432:5432 \ -e POSTGRES_USERpostgres \ -e POSTGRES_PASSWORDyourTopSecretPassword \ -e POSTGRES_DBprefect \ postgres:${version}就绪探活最多重试 30 次、每秒一次执行pg_isready -U postgres超时则打印容器日志并退出防止后续服务在数据库未就绪时启动。容器就绪后脚本写入连接配置prefect config set PREFECT_API_DATABASE_CONNECTION_URLpostgresqlasyncpg://postgres:yourTopSecretPasswordlocalhost:5432/prefect注意这里使用的是postgresqlasyncpg异步驱动与 Prefect Server 的 async 架构一致。3.4 进程内启动 Serveropentelemetry-instrument create_app无论哪种数据库最终都以同一段 Python 逻辑启动服务器关键环境变量与启动命令如下截取自脚本省略默认值分支PREFECT_API_URLhttp://localhost:4200/api \ OTEL_SERVICE_NAMEprefect-server \ OTEL_TRACES_EXPORTERotlp \ OTEL_EXPORTER_OTLP_ENDPOINThttp://localhost:4317 \ OTEL_EXPORTER_OTLP_PROTOCOLgrpc \ OTEL_LOG_LEVELdebug \ PREFECT_SERVER_ANALYTICS_ENABLEDfalse \ PREFECT_API_SERVICES_SCHEDULER_ENABLEDtrue \ PREFECT_API_SERVICES_LATE_RUNS_ENABLEDtrue \ PREFECT_UI_ENABLEDtrue \ PYTHONPATHsrc \ opentelemetry-instrument \ python -c import uvicorn from prefect.server.api.server import create_app app create_app(finalTrue, webserver_onlyeval(${NO_SERVICES}.title())) uvicorn.run( appapp, app_dirsrc, host127.0.0.1, port4200, timeout_keep_alive5, log_level${SERVER_LOGGING_LEVEL} ) 对这段启动逻辑可以从源码层面印证几个关键点create_app来自 src/prefect/server/api/server.py其签名包含webserver_only与final两个参数webserver_onlyTrue时只提供 Web 服务与 UI、禁用全部后台服务finalTrue表示这是进程内最后一个 App 实例允许应用额外优化opentelemetry-instrument是 OpenTelemetry 的自动插桩入口通过opentelemetry-instrumentation-fastapi与opentelemetry-instrumentation-sqlalchemy自动为 FastAPI 请求与数据库调用创建 span无需改动业务代码timeout_keep_alive5设置 keep-alive 超时为 5 秒避免压测时连接长期占用后台服务开关Scheduler、Late Runs由PREFECT_API_SERVICES_SCHEDULER_ENABLED、PREFECT_API_SERVICES_LATE_RUNS_ENABLED显式打开模拟真实生产服务行为。3.5 手动运行服务器的等价环境变量如果你不想使用脚本原文档给出了等价的“手工配方”这些变量与脚本内置值完全一致prefect config set PREFECT_API_URLhttp://localhost:4200/api unset $(env | grep OTEL_ | cut -d -f1) export OTEL_SERVICE_NAMEprefect-server export OTEL_TRACES_EXPORTERotlp export OTEL_EXPORTER_OTLP_ENDPOINThttp://localhost:4317 export OTEL_EXPORTER_OTLP_PROTOCOLgrpc export OTEL_LOG_LEVELdebug export PYTHONPATHsrc各变量含义变量值说明PREFECT_API_URLhttp://localhost:4200/api客户端访问的 API 地址与 Server 监听端口一致unset $(env \| grep OTEL_ ...)—清除环境中可能残留的其他 OTEL 配置保证压测环境干净OTEL_SERVICE_NAMEprefect-servertrace 中标识的服务名Jaeger 中按此名检索OTEL_TRACES_EXPORTERotlp导出器类型OTEL_EXPORTER_OTLP_ENDPOINThttp://localhost:4317Collector 的 OTLP gRPC 入口OTEL_EXPORTER_OTLP_PROTOCOLgrpc传输协议与 Collector 配置的grpcreceiver 对应OTEL_LOG_LEVELdebugOpenTelemetry 自身日志级别便于排障PYTHONPATHsrc让import prefect命中仓库源码目录src/四、填充数据创建工作池与部署./load_testing/populate-server.shload_testing/populate-server.sh 只有两条命令却承担了“制造真实负载前置条件”的任务prefect --no-prompt work-pool create local --type process --overwrite prefect --no-prompt deploy --all --prefect-file load_testing/prefect.yaml第一条创建名为local、类型为process的工作池work pool--overwrite允许重复执行时覆盖重建第二条基于load_testing/prefect.yaml批量部署--all部署deployments。需要特别说明的是脚本引用了一个由使用者自行准备的部署清单文件load_testing/prefect.yaml它不在当前仓库的load_testing/目录内该目录仅包含 README、local-telemetry/、run-server.sh、populate-server.sh、track_cnx.py。要生成它可参考仓库内提供的部署模板例如 src/prefect/deployments/recipes/local/prefect.yaml结合自己的 flow 文件按prefect.yaml规范编写后放置到load_testing/下。也就是说populate-server.sh的可复现性取决于使用者是否已准备好这个文件。五、启动 Worker 制造真实负载prefect worker start --pool local该命令启动一个进程型 Worker从local工作池中拉取并执行部署的 flow run。当上面的 deployments 配置了调度或你手动触发 flow run 时Worker 会在本地子进程中执行 flow从而向 Server 产生真实的 API 请求、数据库查询与调度活动——这正是压测阶段 trace 与指标的数据来源。六、进阶工具实时监控 PostgreSQL 连接状态在 PostgreSQL 模式下做压测时一个高频排查点是数据库连接池是否被打满、是否存在长事务与锁等待。仓库为此提供了一个专门的监控工具 load_testing/track_cnx.py它以 1 秒刷新频率实时展示pg_stat_activity视图以asyncpg连接postgresql://postgres:yourTopSecretPasswordlocalhost:5432/prefect注意用户名、密码与run-server.sh启动的容器保持一致查询pg_stat_activity按state_duration倒序展示 PID、状态、持续时间、等待事件与当前查询用rich渲染表格并自动标红三类异常处于Client.ClientRead等待且超过 5 秒的连接疑似卡死的读操作处于事务中且超过 10 秒的连接长事务等待Lock事件的连接锁阻塞。顶部状态行汇总Total / active / idle / waiting连接数。运行方式python load_testing/track_cnx.py它需要asyncpg与rich依赖仓库未在脚本内做依赖声明可按需pip install asyncpg rich且仅在 PostgreSQL 模式下有意义——这也再次说明深度的 Server 性能探究场景PostgreSQL 是更贴近生产的目标环境。七、完整压测流程串联与排障提示将以上步骤串联一套完整的“Prefect Server 性能探究”工作流如下安装 Docker 与五个 OpenTelemetry Python 包见第一节授权并启动本地遥测栈./load_testing/local-telemetry/start确认16686Jaeger与9090Prometheus可访问按需选择数据库启动 Server./load_testing/run-server.shSQLite或./load_testing/run-server.sh postgres:15PostgreSQL填充数据准备好load_testing/prefect.yaml后执行./load_testing/populate-server.sh启动 Workerprefect worker start --pool local触发或等待 flow run然后在 Jaeger 中按服务名prefect-server检索 trace在 Prometheus 中查询指标PostgreSQL 场景下另开终端运行python load_testing/track_cnx.py观察连接与锁情况。常见排障提示均由上述配置与源码可推导Jaeger 无 trace优先检查OTEL_EXPORTER_OTLP_ENDPOINT是否指向localhost:4317、协议是否为grpc并确认 Collector 容器已就绪连接串不匹配track_cnx.py中的连接信息必须与run-server.sh启动的 PostgreSQL 容器一致用户名postgres、密码yourTopSecretPassword、库名prefect、端口5432部署失败确认load_testing/prefect.yaml已按仓库部署模板编写并放在正确位置prefect --no-prompt deploy --all依赖它枚举待部署对象后台服务缺失若仅需纯 API 压测可将run-server.sh第二参数设为Truewebserver_onlyTrue关闭 Scheduler / Late Runs 等后台服务降低干扰变量。八、小结本文基于 load_testing/README.md 完整还原了 Prefect 官方仓库的本地性能探究方案并逐层深入local-telemetry栈、run-server.sh、populate-server.sh与track_cnx.py的实现细节同时以 src/prefect/server/api/server.py 的create_app源码印证了 Server 启动参数的真实语义。整套方案的工程价值在于在本地以最小成本复刻生产形态FastAPI SQLAlchemy PostgreSQL的可观测环境用 trace、指标与连接状态三条证据链定位 Server 性能瓶颈为后续针对具体接口或数据库查询的优化提供数据支撑。【免费下载链接】prefectPrefect is a workflow orchestration framework for building resilient data pipelines in Python.项目地址: https://gitcode.com/GitHub_Trending/pr/prefect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Prefect 服务器性能探究实战：基于 OpenTelemetry 的本地遥测与数据库压测方案
Prefect 服务器性能探究实战基于 OpenTelemetry 的本地遥测与数据库压测方案【免费下载链接】prefectPrefect is a workflow orchestration framework for building resilient data pipelines in Python.项目地址: https://gitcode.com/GitHub_Trending/pr/prefect导读本文围绕 Prefect 官方仓库load_testing/目录入口文档为 load_testing/README.md展开讲解一套面向 Prefect Server 的**本地性能探究investigating server performance**方法论通过 Docker 拉起 OpenTelemetry 采集栈Jaeger Prometheus Collector用opentelemetry-instrument对 Prefect Server 进程注入自动插桩再配合 SQLite / PostgreSQL 两种数据库形态运行服务器、填充工作池与部署、启动 Worker 制造真实负载最终在 Jaeger 与 Prometheus 中观察 trace 与指标。读完本文你将掌握如何在本地复现这套可观测性压测环境并理解每个脚本、配置与源码调用点的底层原理。一、前置条件与依赖安装原文档明确列出两项硬性要求Docker与OpenTelemetry 相关 Python 库。前者用于运行本地遥测栈Collector / Jaeger / Prometheus 三个容器后者用于对 Prefect Server 进程做自动插桩。依赖安装直接使用uv pip install一次性安装五个包uv pip install opentelemetry-api \ opentelemetry-sdk \ opentelemetry-exporter-otlp \ opentelemetry-instrumentation-sqlalchemy \ opentelemetry-instrumentation-fastapi各包职责如下包作用opentelemetry-api/opentelemetry-sdkOpenTelemetry 的 API 抽象与 SDK 实现负责 span/metric/log 的创建与导出opentelemetry-exporter-otlpOTLP 导出器将遥测数据以 gRPC 协议发送到 Collector 的4317端口opentelemetry-instrumentation-sqlalchemy自动插桩 SQLAlchemy 数据库访问产生数据库调用 spanopentelemetry-instrumentation-fastapi自动插桩 FastAPI 请求处理产生 HTTP 请求 span注意仓库中的脚本都以 bash 脚本形式存放首次运行前需要赋予执行权限原文档要求执行chmod x load_testing/local-telemetry/start chmod x load_testing/run-server.sh chmod x load_testing/populate-server.sh说明chmod属于本地开发环境的一次性授权操作是官方文档为运行仓库脚本给出的标准步骤。二、启动本地遥测栈Collector、Jaeger 与 Prometheus2.1 一条命令拉起整个栈./load_testing/local-telemetry/start该脚本load_testing/local-telemetry/start的逻辑非常简单先检查名为telemetry的 Docker 网络是否存在不存在则创建然后以脚本所在目录为项目目录后台拉起 Compose#!/bin/bash if ! docker network inspect telemetry /dev/null 21; then docker network create telemetry fi docker compose --project-directory $(dirname $0) up -d独立的telemetry网络保证了三个容器之间可以通过服务名互访例如 Collector 以jaeger:4317转发 trace同时不影响其他 Docker 项目。2.2 三个容器的分工与端口load_testing/local-telemetry/docker-compose.yml 定义了三个服务Prometheusprom/prometheus:v3.14.0监听端口9090即指标查询前端挂载prometheus.yml作为抓取配置Jaegerjaegertracing/all-in-one:1.76.016686Jaeger UI 前端用于浏览 trace4317接收 Collector 转发过来的 OTLP gRPC trace其余5775/6831/6832/5778/14250/14268/14269/9411为 Jaeger 兼容的各类采集协议与健康检查端口depends_on: prometheus保证启动顺序OpenTelemetry Collectorotel/opentelemetry-collector-contrib:0.159.04317接收来自 Prefect Server 的 OTLP gRPC 遥测数据这是OTEL_EXPORTER_OTLP_ENDPOINT指向的入口8888Collector 自身的指标供 Prometheus 抓取8889Collector 作为 Prometheus exporter 暴露处理后的指标挂载 load_testing/local-telemetry/otelcol-config.yaml 作为配置依赖关系为collector - jaeger, prometheus即先有存储端再有采集端。2.3 Collector 管道配置解读load_testing/local-telemetry/otelcol-config.yaml 是理解数据流向的关键receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 processors: batch: exporters: otlp_grpc/jaeger: endpoint: jaeger:4317 tls: insecure: true debug: prometheus: endpoint: 0.0.0.0:8889 send_timestamps: true metric_expiration: 180m resource_to_telemetry_conversion: enabled: true service: telemetry: metrics: readers: - pull: exporter: prometheus: host: 0.0.0.0 port: 8888 pipelines: traces: receivers: [otlp] processors: [batch] exporters: [otlp_grpc/jaeger, debug] metrics: receivers: [otlp] processors: [batch] exporters: [prometheus, debug] logs: receivers: [otlp] processors: [batch] exporters: [debug]关键设计点**三条管道traces / metrics / logs**共用同一个 OTLP gRPC receiver入口均为0.0.0.0:4317trace 管道batch 合并后转发给 Jaegerjaeger:4317内部网络tls.insecure: true同时输出到debugexporter 便于终端排查metrics 管道batch 后由内置 Prometheus exporter 在8889暴露同时通过 pull reader 在8888上以拉取方式提供服务metric_expiration: 180m控制指标在 3 小时无更新后被清理logs 管道仅输出到debug用于排查日志链路。Prometheus 的抓取目标定义在 load_testing/local-telemetry/prometheus.yml每 15 秒抓取 Collector 的8888自身指标与8889处理后指标global: scrape_interval: 15s scrape_configs: - job_name: opentelemetry static_configs: - targets: - collector:8888 - collector:88892.4 验证栈是否就绪启动完成后Jaeger UIhttp://localhost:16686选择服务名prefect-server即可查看 tracePrometheushttp://localhost:9090可对prefect_*、http_*等指标做查询与绘图。正如 load_testing/local-telemetry/README.md 所述对本地服务器发起请求后trace 会实时出现在 Jaeger 前端中这是判断链路是否打通的最直观信号。三、带追踪运行 Prefect ServerSQLite 与 PostgreSQL3.1 一键脚本run-server.sh原文档给出的运行方式# Run with SQLite (default) ./load_testing/run-server.sh # Run with PostgreSQL 15 ./load_testing/run-server.sh postgres:15阅读 load_testing/run-server.sh 源码可以确认脚本实际支持三个位置参数并带有默认值参数默认值说明$1DB_TYPEsqlite数据库类型支持sqlite或postgres:version$2NO_SERVICESFalse是否仅启动 Web 服务关闭后台调度等服务$3SERVER_LOGGING_LEVELwarningUvicorn 日志级别3.2 SQLite 模式当$1为sqlite时脚本直接沿用 Prefect 的默认 SQLite 配置不做任何数据库初始化动作: # Use default SQLite configuration分支仅作占位。适合快速验证遥测链路是否打通。3.3 PostgreSQL 模式与容器生命周期管理当$1形如postgres:version例如postgres:15时脚本调用start_postgres函数其生命周期策略非常值得借鉴复用优先若存在名为prefect-postgres的容器先docker exec读取其实际 PostgreSQL 版本号版本不匹配则清理重建若现有版本与请求版本不一致docker rm -f容器并docker volume rm prefectdb清空数据卷保证从干净状态启动启动失败则重建复用场景下若docker start失败同样删除容器与卷重新创建无容器则新建docker run -d --name prefect-postgres \ -v prefectdb:/var/lib/postgresql/data \ -p 5432:5432 \ -e POSTGRES_USERpostgres \ -e POSTGRES_PASSWORDyourTopSecretPassword \ -e POSTGRES_DBprefect \ postgres:${version}就绪探活最多重试 30 次、每秒一次执行pg_isready -U postgres超时则打印容器日志并退出防止后续服务在数据库未就绪时启动。容器就绪后脚本写入连接配置prefect config set PREFECT_API_DATABASE_CONNECTION_URLpostgresqlasyncpg://postgres:yourTopSecretPasswordlocalhost:5432/prefect注意这里使用的是postgresqlasyncpg异步驱动与 Prefect Server 的 async 架构一致。3.4 进程内启动 Serveropentelemetry-instrument create_app无论哪种数据库最终都以同一段 Python 逻辑启动服务器关键环境变量与启动命令如下截取自脚本省略默认值分支PREFECT_API_URLhttp://localhost:4200/api \ OTEL_SERVICE_NAMEprefect-server \ OTEL_TRACES_EXPORTERotlp \ OTEL_EXPORTER_OTLP_ENDPOINThttp://localhost:4317 \ OTEL_EXPORTER_OTLP_PROTOCOLgrpc \ OTEL_LOG_LEVELdebug \ PREFECT_SERVER_ANALYTICS_ENABLEDfalse \ PREFECT_API_SERVICES_SCHEDULER_ENABLEDtrue \ PREFECT_API_SERVICES_LATE_RUNS_ENABLEDtrue \ PREFECT_UI_ENABLEDtrue \ PYTHONPATHsrc \ opentelemetry-instrument \ python -c import uvicorn from prefect.server.api.server import create_app app create_app(finalTrue, webserver_onlyeval(${NO_SERVICES}.title())) uvicorn.run( appapp, app_dirsrc, host127.0.0.1, port4200, timeout_keep_alive5, log_level${SERVER_LOGGING_LEVEL} ) 对这段启动逻辑可以从源码层面印证几个关键点create_app来自 src/prefect/server/api/server.py其签名包含webserver_only与final两个参数webserver_onlyTrue时只提供 Web 服务与 UI、禁用全部后台服务finalTrue表示这是进程内最后一个 App 实例允许应用额外优化opentelemetry-instrument是 OpenTelemetry 的自动插桩入口通过opentelemetry-instrumentation-fastapi与opentelemetry-instrumentation-sqlalchemy自动为 FastAPI 请求与数据库调用创建 span无需改动业务代码timeout_keep_alive5设置 keep-alive 超时为 5 秒避免压测时连接长期占用后台服务开关Scheduler、Late Runs由PREFECT_API_SERVICES_SCHEDULER_ENABLED、PREFECT_API_SERVICES_LATE_RUNS_ENABLED显式打开模拟真实生产服务行为。3.5 手动运行服务器的等价环境变量如果你不想使用脚本原文档给出了等价的“手工配方”这些变量与脚本内置值完全一致prefect config set PREFECT_API_URLhttp://localhost:4200/api unset $(env | grep OTEL_ | cut -d -f1) export OTEL_SERVICE_NAMEprefect-server export OTEL_TRACES_EXPORTERotlp export OTEL_EXPORTER_OTLP_ENDPOINThttp://localhost:4317 export OTEL_EXPORTER_OTLP_PROTOCOLgrpc export OTEL_LOG_LEVELdebug export PYTHONPATHsrc各变量含义变量值说明PREFECT_API_URLhttp://localhost:4200/api客户端访问的 API 地址与 Server 监听端口一致unset $(env \| grep OTEL_ ...)—清除环境中可能残留的其他 OTEL 配置保证压测环境干净OTEL_SERVICE_NAMEprefect-servertrace 中标识的服务名Jaeger 中按此名检索OTEL_TRACES_EXPORTERotlp导出器类型OTEL_EXPORTER_OTLP_ENDPOINThttp://localhost:4317Collector 的 OTLP gRPC 入口OTEL_EXPORTER_OTLP_PROTOCOLgrpc传输协议与 Collector 配置的grpcreceiver 对应OTEL_LOG_LEVELdebugOpenTelemetry 自身日志级别便于排障PYTHONPATHsrc让import prefect命中仓库源码目录src/四、填充数据创建工作池与部署./load_testing/populate-server.shload_testing/populate-server.sh 只有两条命令却承担了“制造真实负载前置条件”的任务prefect --no-prompt work-pool create local --type process --overwrite prefect --no-prompt deploy --all --prefect-file load_testing/prefect.yaml第一条创建名为local、类型为process的工作池work pool--overwrite允许重复执行时覆盖重建第二条基于load_testing/prefect.yaml批量部署--all部署deployments。需要特别说明的是脚本引用了一个由使用者自行准备的部署清单文件load_testing/prefect.yaml它不在当前仓库的load_testing/目录内该目录仅包含 README、local-telemetry/、run-server.sh、populate-server.sh、track_cnx.py。要生成它可参考仓库内提供的部署模板例如 src/prefect/deployments/recipes/local/prefect.yaml结合自己的 flow 文件按prefect.yaml规范编写后放置到load_testing/下。也就是说populate-server.sh的可复现性取决于使用者是否已准备好这个文件。五、启动 Worker 制造真实负载prefect worker start --pool local该命令启动一个进程型 Worker从local工作池中拉取并执行部署的 flow run。当上面的 deployments 配置了调度或你手动触发 flow run 时Worker 会在本地子进程中执行 flow从而向 Server 产生真实的 API 请求、数据库查询与调度活动——这正是压测阶段 trace 与指标的数据来源。六、进阶工具实时监控 PostgreSQL 连接状态在 PostgreSQL 模式下做压测时一个高频排查点是数据库连接池是否被打满、是否存在长事务与锁等待。仓库为此提供了一个专门的监控工具 load_testing/track_cnx.py它以 1 秒刷新频率实时展示pg_stat_activity视图以asyncpg连接postgresql://postgres:yourTopSecretPasswordlocalhost:5432/prefect注意用户名、密码与run-server.sh启动的容器保持一致查询pg_stat_activity按state_duration倒序展示 PID、状态、持续时间、等待事件与当前查询用rich渲染表格并自动标红三类异常处于Client.ClientRead等待且超过 5 秒的连接疑似卡死的读操作处于事务中且超过 10 秒的连接长事务等待Lock事件的连接锁阻塞。顶部状态行汇总Total / active / idle / waiting连接数。运行方式python load_testing/track_cnx.py它需要asyncpg与rich依赖仓库未在脚本内做依赖声明可按需pip install asyncpg rich且仅在 PostgreSQL 模式下有意义——这也再次说明深度的 Server 性能探究场景PostgreSQL 是更贴近生产的目标环境。七、完整压测流程串联与排障提示将以上步骤串联一套完整的“Prefect Server 性能探究”工作流如下安装 Docker 与五个 OpenTelemetry Python 包见第一节授权并启动本地遥测栈./load_testing/local-telemetry/start确认16686Jaeger与9090Prometheus可访问按需选择数据库启动 Server./load_testing/run-server.shSQLite或./load_testing/run-server.sh postgres:15PostgreSQL填充数据准备好load_testing/prefect.yaml后执行./load_testing/populate-server.sh启动 Workerprefect worker start --pool local触发或等待 flow run然后在 Jaeger 中按服务名prefect-server检索 trace在 Prometheus 中查询指标PostgreSQL 场景下另开终端运行python load_testing/track_cnx.py观察连接与锁情况。常见排障提示均由上述配置与源码可推导Jaeger 无 trace优先检查OTEL_EXPORTER_OTLP_ENDPOINT是否指向localhost:4317、协议是否为grpc并确认 Collector 容器已就绪连接串不匹配track_cnx.py中的连接信息必须与run-server.sh启动的 PostgreSQL 容器一致用户名postgres、密码yourTopSecretPassword、库名prefect、端口5432部署失败确认load_testing/prefect.yaml已按仓库部署模板编写并放在正确位置prefect --no-prompt deploy --all依赖它枚举待部署对象后台服务缺失若仅需纯 API 压测可将run-server.sh第二参数设为Truewebserver_onlyTrue关闭 Scheduler / Late Runs 等后台服务降低干扰变量。八、小结本文基于 load_testing/README.md 完整还原了 Prefect 官方仓库的本地性能探究方案并逐层深入local-telemetry栈、run-server.sh、populate-server.sh与track_cnx.py的实现细节同时以 src/prefect/server/api/server.py 的create_app源码印证了 Server 启动参数的真实语义。整套方案的工程价值在于在本地以最小成本复刻生产形态FastAPI SQLAlchemy PostgreSQL的可观测环境用 trace、指标与连接状态三条证据链定位 Server 性能瓶颈为后续针对具体接口或数据库查询的优化提供数据支撑。【免费下载链接】prefectPrefect is a workflow orchestration framework for building resilient data pipelines in Python.项目地址: https://gitcode.com/GitHub_Trending/pr/prefect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考