ntfy 如何配置 JSON 日志与临时 debug 日志级别辅助问题定位【免费下载链接】ntfySend push notifications to your phone or desktop using PUT/POST项目地址: https://gitcode.com/GitHub_Trending/nt/ntfy当你自托管 ntfy 服务器并且某个组件行为不符合预期时官方推荐的排查手段是先确认服务器日志格式便于收集再临时把日志级别提高到debug或trace观察服务器内部发生了什么。这篇文章基于 ntfy 的配置文档和故障排查文档给出这条排查路径的完整配置项、命令行写法、热重载方式和验证方法。适用对象是自己运行ntfy serve的服务器Android、Web 等客户端侧的日志不在这篇范围内。了解默认日志行为ntfy 的默认日志行为是输出到控制台stderr日志级别为info格式为人类可读的文本text。也就是说默认配置下日志没有写入任何文件也没有结构化格式。相关配置项及其对应环境变量如下均来自配置文档的选项表配置项环境变量默认值说明log-formatNTFY_LOG_FORMATtext输出格式可为text或jsonlog-fileNTFY_LOG_FILE未设置输出到 stderr日志写入的文件名log-levelNTFY_LOG_LEVELinfo默认日志级别可为trace、debug、info、warn、errorlog-level-overridesNTFY_LOG_LEVEL_OVERRIDES未设置按字段匹配覆盖日志级别配置有三种设置方式配置文件默认路径/etc/ntfy/server.yml、命令行选项如--log-format json、环境变量。配置文件里也可以把连字符写成下划线log_format与log-format等价。配置 JSON 格式日志官方给出的、适合生产使用的日志配置示例是log-level: info log-format: json log-file: /var/log/ntfy.log含义很直接保持info级别不变把输出格式改为json并写入/var/log/ntfy.log。/var/log/ntfy.log是文档示例路径你可以按自己的日志目录替换如果不设置log-file日志会一直输出到 stderr。如果不想改配置文件也可以用命令行选项临时指定例如在启动参数上加--log-format json对应环境变量NTFY_LOG_FORMAT。临时开启 debug / trace 日志定位问题当某项功能不正常时把日志级别临时调高是官方故障排查文档给出的通用做法。在server.yml中设置log-level: debug或者log-level: trace其他等价方式使用环境变量时NTFY_LOG_LEVELdebug或trace直接在启动命令上追加参数ntfy serve --debug或ntfy serve --trace。debug与trace的输出粒度不同debug会输出每条已发布消息的信息但不包含消息内容trace会连消息内容一起打印。文档示例debug 级别日志$ ntfy serve --debug 2023/03/20 14:45:38 INFO Listening on :2586[http] :1025[smtp], ntfy 2.1.2, log level is DEBUG (tagstartup) 2023/03/20 14:45:38 DEBUG Waiting until 2023-03-21 00:00:00 0000 UTC to reset visitor stats (tagresetter) 2023/03/20 14:45:39 DEBUG Rate limiters reset for visitor (visitor_auth_limiter_limit0.016666666666666666, visitor_auth_limiter_tokens10, visitor_emails0, visitor_emails_limit12, visitor_emails_remaining12, visitor_idip:127.0.0.1, visitor_ip127.0.0.1, visitor_messages0, visitor_messages_limit500, visitor_messages_remaining500, visitor_request_limiter_limit0.2, visitor_request_limiter_tokens60, visitor_seen2023-03-20T14:45:39.7-04:00) 2023/03/20 14:45:39 DEBUG HTTP request started (http_methodPOST, http_path/mytopic, taghttp, visitor_auth_limiter_limit..., visitor_ip127.0.0.1, ...) 2023/03/20 14:45:39 DEBUG Received message (http_methodPOST, http_path/mytopic, message_body_size2, message_delayedfalse, ..., message_idEZu6i2WZjH0v, message_sender127.0.0.1, ..., tagpublish, topicmytopic, topic_subscribers0, ...) 2023/03/20 14:45:39 DEBUG Adding message to cache (...) 2023/03/20 14:45:39 DEBUG HTTP request finished (http_methodPOST, http_path/mytopic, taghttp, time_taken_ms2, ...) 2023/03/20 14:45:39 DEBUG Wrote 1 message(s) in 8.285712ms (tagmessage_cache) ...文档示例trace 级别日志可以看到 trace 额外打印了完整 HTTP 请求头和消息体$ ntfy serve --trace 2023/03/20 14:40:42 INFO Listening on :2586[http] :1025[smtp], ntfy 2.1.2, log level is TRACE (tagstartup) ... 2023/03/20 14:40:59 TRACE HTTP request started (http_methodPOST, http_path/mytopic, http_requestPOST /mytopic HTTP/1.1 User-Agent: curl/7.81.0 Accept: */* Content-Length: 2 Content-Type: application/x-www-form-urlencoded hi, taghttp, ...) 2023/03/20 14:40:59 TRACE Received message (http_methodPOST, http_path/mytopic, message_body{ id: Khaup1RVclU3, time: 1679337659, expires: 1679380859, event: message, topic: mytopic, message: hi }, message_body_size2, message_delayedfalse, ...) 2023/03/20 14:40:59 TRACE No stream or WebSocket subscribers, not forwarding (...)上面两段都是文档中的示例日志实际输出的时间戳、消息 ID、数值会不同观察重点在于级别生效后出现DEBUG/TRACE行以及每类事件HTTP 请求开始/结束、消息接收、写入缓存是否齐全。只提高特定字段相关的日志级别log-level-overrides把全局级别提到debug或trace会产生大量日志。如果只想盯住系统的某一部分例如某个账号管理流程、某个访问者可以用log-level-overrides做细粒度覆盖。它是一组字符串数组格式为fieldvalue - level精确匹配某个值例如tagmanager - tracefield - level匹配任意值例如time_taken_ms - debug官方示例只输出info级别但当事件匹配到任一覆盖规则时提高级别log-level: info log-level-overrides: - tagmanager - trace - visitor_ip1.2.3.4 - debug - time_taken_ms - debug文档中明确提到的可用于匹配的字段包括访问者 IPvisitor_ip、用户名user_name、标签tag实际有几十个字段可用要弄清都有哪些可以把日志级别临时设为trace观察输出或查阅 ntfy 源码。验证配置是否生效修改server.yml后log-level和log-level-overrides支持热重载不需要重启服务。发送SIGHUP信号即可systemctl reload ntfy # ntfy 由 systemd 托管时 kill -HUP $(pidof ntfy) # 或者直接向进程发信号重载成功后日志中会出现类似下面的内容文档示例日期时间与日志级别以实际为准$ ntfy serve 2022/06/02 10:29:28 INFO Listening on :2586[http] :1025[smtp], log level is INFO 2022/06/02 10:29:34 INFO Partially hot reloading configuration ... 2022/06/02 10:29:34 INFO Log level is TRACE判断标准看到Partially hot reloading configuration和随后新的Log level is ...行说明热重载成功、新级别已生效。注意热重载只覆盖log-level和log-level-overrides这两项log-format、log-file不在可热重载范围内修改它们需要重启服务。如果 ntfy 是通过 systemd 运行的还可以直接用journalctl -u ntfy -f跟踪日志。限制与收尾配置文档明确警告debug尤其是trace输出非常冗余只应短暂开启用于调试使用log-level-overrides也存在性能开销同样只建议临时使用。排查结束后记得把log-level恢复为info改完配置后同样可以systemctl reload ntfy生效并移除临时的log-level-overrides条目。trace会把消息内容写入日志开启前需要考虑日志中出现的消息内容文档没有给出其他自动脱敏机制。完成一次JSON 格式 临时 debug 级别的定位后如果你的问题出在反向代理后的 WebSocket 行为例如客户端一直显示 Reconnecting故障排查文档中还列出了behind-proxy配置和主题访问权限两类需要核对的项可作为下一个排查方向。【免费下载链接】ntfySend push notifications to your phone or desktop using PUT/POST项目地址: https://gitcode.com/GitHub_Trending/nt/ntfy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ntfy 如何配置 JSON 日志与临时 debug 日志级别辅助问题定位
ntfy 如何配置 JSON 日志与临时 debug 日志级别辅助问题定位【免费下载链接】ntfySend push notifications to your phone or desktop using PUT/POST项目地址: https://gitcode.com/GitHub_Trending/nt/ntfy当你自托管 ntfy 服务器并且某个组件行为不符合预期时官方推荐的排查手段是先确认服务器日志格式便于收集再临时把日志级别提高到debug或trace观察服务器内部发生了什么。这篇文章基于 ntfy 的配置文档和故障排查文档给出这条排查路径的完整配置项、命令行写法、热重载方式和验证方法。适用对象是自己运行ntfy serve的服务器Android、Web 等客户端侧的日志不在这篇范围内。了解默认日志行为ntfy 的默认日志行为是输出到控制台stderr日志级别为info格式为人类可读的文本text。也就是说默认配置下日志没有写入任何文件也没有结构化格式。相关配置项及其对应环境变量如下均来自配置文档的选项表配置项环境变量默认值说明log-formatNTFY_LOG_FORMATtext输出格式可为text或jsonlog-fileNTFY_LOG_FILE未设置输出到 stderr日志写入的文件名log-levelNTFY_LOG_LEVELinfo默认日志级别可为trace、debug、info、warn、errorlog-level-overridesNTFY_LOG_LEVEL_OVERRIDES未设置按字段匹配覆盖日志级别配置有三种设置方式配置文件默认路径/etc/ntfy/server.yml、命令行选项如--log-format json、环境变量。配置文件里也可以把连字符写成下划线log_format与log-format等价。配置 JSON 格式日志官方给出的、适合生产使用的日志配置示例是log-level: info log-format: json log-file: /var/log/ntfy.log含义很直接保持info级别不变把输出格式改为json并写入/var/log/ntfy.log。/var/log/ntfy.log是文档示例路径你可以按自己的日志目录替换如果不设置log-file日志会一直输出到 stderr。如果不想改配置文件也可以用命令行选项临时指定例如在启动参数上加--log-format json对应环境变量NTFY_LOG_FORMAT。临时开启 debug / trace 日志定位问题当某项功能不正常时把日志级别临时调高是官方故障排查文档给出的通用做法。在server.yml中设置log-level: debug或者log-level: trace其他等价方式使用环境变量时NTFY_LOG_LEVELdebug或trace直接在启动命令上追加参数ntfy serve --debug或ntfy serve --trace。debug与trace的输出粒度不同debug会输出每条已发布消息的信息但不包含消息内容trace会连消息内容一起打印。文档示例debug 级别日志$ ntfy serve --debug 2023/03/20 14:45:38 INFO Listening on :2586[http] :1025[smtp], ntfy 2.1.2, log level is DEBUG (tagstartup) 2023/03/20 14:45:38 DEBUG Waiting until 2023-03-21 00:00:00 0000 UTC to reset visitor stats (tagresetter) 2023/03/20 14:45:39 DEBUG Rate limiters reset for visitor (visitor_auth_limiter_limit0.016666666666666666, visitor_auth_limiter_tokens10, visitor_emails0, visitor_emails_limit12, visitor_emails_remaining12, visitor_idip:127.0.0.1, visitor_ip127.0.0.1, visitor_messages0, visitor_messages_limit500, visitor_messages_remaining500, visitor_request_limiter_limit0.2, visitor_request_limiter_tokens60, visitor_seen2023-03-20T14:45:39.7-04:00) 2023/03/20 14:45:39 DEBUG HTTP request started (http_methodPOST, http_path/mytopic, taghttp, visitor_auth_limiter_limit..., visitor_ip127.0.0.1, ...) 2023/03/20 14:45:39 DEBUG Received message (http_methodPOST, http_path/mytopic, message_body_size2, message_delayedfalse, ..., message_idEZu6i2WZjH0v, message_sender127.0.0.1, ..., tagpublish, topicmytopic, topic_subscribers0, ...) 2023/03/20 14:45:39 DEBUG Adding message to cache (...) 2023/03/20 14:45:39 DEBUG HTTP request finished (http_methodPOST, http_path/mytopic, taghttp, time_taken_ms2, ...) 2023/03/20 14:45:39 DEBUG Wrote 1 message(s) in 8.285712ms (tagmessage_cache) ...文档示例trace 级别日志可以看到 trace 额外打印了完整 HTTP 请求头和消息体$ ntfy serve --trace 2023/03/20 14:40:42 INFO Listening on :2586[http] :1025[smtp], ntfy 2.1.2, log level is TRACE (tagstartup) ... 2023/03/20 14:40:59 TRACE HTTP request started (http_methodPOST, http_path/mytopic, http_requestPOST /mytopic HTTP/1.1 User-Agent: curl/7.81.0 Accept: */* Content-Length: 2 Content-Type: application/x-www-form-urlencoded hi, taghttp, ...) 2023/03/20 14:40:59 TRACE Received message (http_methodPOST, http_path/mytopic, message_body{ id: Khaup1RVclU3, time: 1679337659, expires: 1679380859, event: message, topic: mytopic, message: hi }, message_body_size2, message_delayedfalse, ...) 2023/03/20 14:40:59 TRACE No stream or WebSocket subscribers, not forwarding (...)上面两段都是文档中的示例日志实际输出的时间戳、消息 ID、数值会不同观察重点在于级别生效后出现DEBUG/TRACE行以及每类事件HTTP 请求开始/结束、消息接收、写入缓存是否齐全。只提高特定字段相关的日志级别log-level-overrides把全局级别提到debug或trace会产生大量日志。如果只想盯住系统的某一部分例如某个账号管理流程、某个访问者可以用log-level-overrides做细粒度覆盖。它是一组字符串数组格式为fieldvalue - level精确匹配某个值例如tagmanager - tracefield - level匹配任意值例如time_taken_ms - debug官方示例只输出info级别但当事件匹配到任一覆盖规则时提高级别log-level: info log-level-overrides: - tagmanager - trace - visitor_ip1.2.3.4 - debug - time_taken_ms - debug文档中明确提到的可用于匹配的字段包括访问者 IPvisitor_ip、用户名user_name、标签tag实际有几十个字段可用要弄清都有哪些可以把日志级别临时设为trace观察输出或查阅 ntfy 源码。验证配置是否生效修改server.yml后log-level和log-level-overrides支持热重载不需要重启服务。发送SIGHUP信号即可systemctl reload ntfy # ntfy 由 systemd 托管时 kill -HUP $(pidof ntfy) # 或者直接向进程发信号重载成功后日志中会出现类似下面的内容文档示例日期时间与日志级别以实际为准$ ntfy serve 2022/06/02 10:29:28 INFO Listening on :2586[http] :1025[smtp], log level is INFO 2022/06/02 10:29:34 INFO Partially hot reloading configuration ... 2022/06/02 10:29:34 INFO Log level is TRACE判断标准看到Partially hot reloading configuration和随后新的Log level is ...行说明热重载成功、新级别已生效。注意热重载只覆盖log-level和log-level-overrides这两项log-format、log-file不在可热重载范围内修改它们需要重启服务。如果 ntfy 是通过 systemd 运行的还可以直接用journalctl -u ntfy -f跟踪日志。限制与收尾配置文档明确警告debug尤其是trace输出非常冗余只应短暂开启用于调试使用log-level-overrides也存在性能开销同样只建议临时使用。排查结束后记得把log-level恢复为info改完配置后同样可以systemctl reload ntfy生效并移除临时的log-level-overrides条目。trace会把消息内容写入日志开启前需要考虑日志中出现的消息内容文档没有给出其他自动脱敏机制。完成一次JSON 格式 临时 debug 级别的定位后如果你的问题出在反向代理后的 WebSocket 行为例如客户端一直显示 Reconnecting故障排查文档中还列出了behind-proxy配置和主题访问权限两类需要核对的项可作为下一个排查方向。【免费下载链接】ntfySend push notifications to your phone or desktop using PUT/POST项目地址: https://gitcode.com/GitHub_Trending/nt/ntfy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考