Nginx 错误日志（error_log）无法配置为 JSON 格式，因其由核心模块硬编码生成，不支持 log_format 或变量机制；可行方案是将业务异常响应通过 access_log 记录为 JSON，或借助 systemd/journald 二次结构化采集。
Nginx 本身不支持直接在 server 块中定义全局错误日志的 JSON 格式——错误日志（error_log）格式是固定的，无法自定义为 JSON，也不受 log_format 指令影响。这是 Nginx 的设计限制：错误日志只输出固定结构的文本（时间、级别、PID、TID、消息等），且不可通过配置改为结构化格式。
为什么 error_log 不能设为 JSON？
Nginx 错误日志由核心模块硬编码生成，用于记录启动失败、配置错误、worker 异常、系统调用失败等底层事件。这些日志强调可读性与调试性，而非采集友好性。它和访问日志（access_log）完全不同：
- access_log 支持 log_format + 变量，可自由定义 JSON 输出；
- error_log 没有变量机制，也没有格式模板语法，仅支持指定日志级别和文件路径。
可行的替代方案：把关键错误“升格”到 access_log 中
若你真正关心的是“可被 ELK / Loki / Datadog 等收集的结构化错误信息”，推荐将**业务层可识别的错误响应**（如 4xx/5xx）通过 access_log 记录为 JSON，同时保留原始 error_log 用于底层排障：
- 用
map指令提取状态码、上游响应时间、后端地址等字段 - 用
log_format构建 JSON 字符串（注意转义双引号和特殊字符） - 在
server或location中启用该 access_log，并配合if或log_not_found off等控制写入条件
示例配置片段：
wechat-article-extraction-mp-weixin-qq-com news-webpage-cleaning blog-post-parsing metadata-extraction-title-author-date multiple-output-formats-markdown-json-plain-text batch-processing-support
下载
基于三引擎设计，从微信文章、新闻和博客网页提取干净内容，支持标题作者日期元数据，多格式和批量处理。
map $status $is_error { default 0; ~^[45] 1; }
log_format json_combined escape=json '{'
'"time_local":"$time_local",'
'"remote_addr":"$remote_addr",'
'"status":$status,'
'"body_bytes_sent":$body_bytes_sent,'
'"request_time":$request_time,'
'"upstream_addr":"$upstream_addr",'
'"upstream_status":"$upstream_status",'
'"http_user_agent":"$http_user_agent"'
'}';
server {
error_log /var/log/nginx/example.error.log warn;
access_log /var/log/nginx/example.access.log json_combined if=$is_error;
}
进阶：用 systemd 或 rsyslog 做二次处理（Linux 系统适用）
如果必须让原始 error_log 进入结构化管道，可借助系统日志设施：
- 将 Nginx error_log 输出到
stderr（启动时加-e stderr或配置error_log stderr warn;） - 用 systemd 启动 Nginx，其 journal 自动捕获 stderr 并打上 _PID、_HOSTNAME、UNIT 等字段
- 再用
journalctl -u nginx --output=json或 Fluent Bit / Vector 直接消费 journald，实现准结构化采集
不推荐但存在的“伪 JSON error_log”技巧
有人尝试用 Lua（OpenResty）或第三方模块（如 nginx-json-log-module）在 log_by_lua* 阶段拼接 JSON 写入文件，但这不是真正的 error_log，而是额外日志流，无法捕获 Nginx 自身崩溃、配置加载失败等关键错误，仅适合记录请求生命周期内的逻辑异常。
