要实现nginx业务层可观测，需将业务逻辑翻译为prometheus指标：用lua模块在access_by_lua_block/log_by_lua_block中埋点并更新shared dict；用textfile collector聚合离线指标；或由上游服务主动暴露/metrics端点，nginx透传增强。
要让 Prometheus 监控到 Nginx 业务层的特定状态（比如某个接口的调用成功数、某类请求的耗时分布、灰度流量比例、自定义业务错误码计数等），不能只依赖 stub_status 或默认的 vts 模块——它们提供的是基础设施层指标。真正实现业务层可观测，关键在于把业务逻辑“翻译”成 Prometheus 可识别的指标，并稳定暴露出去。
在 Nginx 配置中嵌入业务逻辑埋点
利用 Nginx 的 lua-nginx-module（OpenResty 推荐）或 perl 模块，在请求处理的关键路径上执行轻量脚本，实时更新共享字典（shared dict）或计数器：
- 例如，在
access_by_lua_block中判断 URI 是否命中 /pay/callback，且响应状态为 200，则对custom_payment_success_total{env="prod",region="sh"}执行原子递增 - 用
log_by_lua_block提取 $upstream_response_time，按区间（如 0–100ms、100–500ms）分类打点，写入custom_api_latency_bucketHistogram 类型指标 - 所有 Lua 脚本需避免阻塞、不调外部服务、不写磁盘；指标值存在内存共享字典里，由单独的定时 exporter 拉取汇总
用 textfile collector 做离线/准实时业务指标聚合
适合变化不频繁但需多维标签的场景（如每日订单总量、各渠道转化率、配置热加载生效状态）：
- 写一个 Python 或 Shell 脚本，从数据库、Redis 或本地日志中提取业务数据（如
SELECT COUNT(*) FROM orders WHERE created_at > NOW() - INTERVAL 1 DAY） - 格式化为标准 Prometheus 文本格式，带完整 HELP/TYPE 和标签，例如：
# HELP custom_daily_order_count Total orders placed in last 24h
# TYPE custom_daily_order_count counter
custom_daily_order_count{channel="wechat",env="prod"} 14285 - 输出到 Node Exporter 的
textfile_collector目录（如/var/lib/node_exporter/textfile_collector/business.prom），由 Prometheus 自动抓取
通过上游服务主动上报 + sidecar 暴露指标
当业务逻辑主要在后端服务（如 Java/Go API）中，Nginx 仅作反向代理时，更推荐让服务自身暴露指标，Nginx 只做透传和增强：
- 后端服务集成 Micrometer（Java）或 Prometheus client（Go/Python），暴露
/metrics端点 - Nginx 配置
proxy_pass到该端点，并用proxy_set_header注入标识（如X-Service-Name "order-api"），方便后续按服务维度过滤 - 可额外用
auth_request模块对接一个轻量认证服务，将认证成功率、延迟等作为业务健康信号统一采集
注意事项：命名、类型与稳定性
业务指标一旦上线就很难重构，务必在初期定好规范：
- 命名统一加前缀，如
business_或app_，避免和系统指标混淆；子系统用下划线分隔，如business_user_login_failure_total - 计数类（累计值）必须用
Counter，状态类（开关、当前值）用Gauge，耗时类优先用Histogram（不是 Summary） - 所有指标必须有明确的业务含义和文档注释（# HELP 行不能写“自定义指标”这种空话）
- 避免在 Nginx 配置中直接执行耗时操作（如 curl 外部 API、读大文件），会导致 worker 阻塞；高频指标走 Lua 共享字典，低频指标走 textfile 定时聚合
