模型推理服务AI 应用后端【免费下载链接】serverThe Triton Inference Server provides an optimized cloud and edge inferencing solution.项目地址https://gitcode.com/gh_mirrors/server117/server点击查看免费下载Triton Inference Server 的 Logging 扩展Logging Extension允许客户端在服务器运行期间动态读取与修改日志设置覆盖日志文件输出位置、INFO/WARNING/ERROR 三个日志级别开关、verbose 详细日志等级以及日志时间戳格式。本文以 docs/protocol/extension_logging.md 为骨架结合本仓库的 HTTP/gRPC 服务端实现src/http_server.cc、src/grpc/grpc_server.cc与命令行参数解析src/command_line_parser.cc完整讲解该扩展的协议格式、源码级实现原理、日志格式规范与 QA 测试验证方式帮助读者掌握通过curl与 gRPC 客户端动态调优 Triton 日志输出的完整方案。扩展概览与 Server Metadata 声明Logging 扩展是 Triton 在 KServe 标准推理协议之上实现的若干扩展之一完整清单见 docs/protocol/README.md。它的核心能力是客户端通过 HTTP/REST 或 gRPC 在服务器运行期间读取当前日志设置客户端可以动态修改日志设置而无需重启tritonserver进程设置修改成功后立即生效且服务端会返回更新后的完整设置快照。与 Trace 扩展 类似Triton 在Server Metadata响应的extensions字段中报告logging用于声明服务器已启用该扩展能力。客户端可以通过查询 Server MetadataHTTPGET v2gRPCServerMetadata来确认目标服务器是否支持动态日志配置。需要特别说明的是该扩展受编译开关TRITON_ENABLE_LOGGING控制。若服务器在构建时未启用日志支持调用日志设置端点会返回TRITONSERVER_ERROR_UNAVAILABLEHTTP 503 语义与错误信息the server does not support dynamic logging见 src/http_server.cc 与 src/grpc/grpc_server.cc。此外Logging 端点属于可被限制的 API 类别之一。服务端可在启动时通过--allow-http/--allow-grpc配合--http-restricted-api/--grpc-restricted-api等参数RestrictedCategory::LOGGING定义于 src/restricted_features.h来限制对/v2/logging的访问具体限制策略可参考 docs/customization_guide/inference_protocols.md。日志设置项一览无论通过哪种协议访问Logging 扩展都围绕以下日志设置项工作。下表汇总了各设置项的名称、JSON 类型、含义与默认值设置项名称类型说明默认值log_file$string日志输出文件路径。为空字符串时日志输出流式打印到控制台stderrlog_info$boolean是否记录 INFO 级别日志truelog_warning$boolean是否记录 WARNING 级别日志truelog_error$boolean是否记录 ERROR 级别日志truelog_verbose_level$numberverbose 详细日志等级取任意 0的整数0log_format$string日志格式目前支持default与ISO8601两种default其中log_verbose_level的语义是阈值式的为0时verbose 日志被禁用服务器不输出任何 verbose 消息为1时输出等级 1 的 verbose 消息为2时输出所有等级 2的 verbose 消息依此类推尝试将log_verbose_level设置为 0的数值会返回错误。而log_format决定每条日志时间戳的呈现方式default采用 Triton 传统的I0520 20:03:25.829575格式ISO8601采用2024-05-20T20:03:26Z标准格式便于与日志采集/时序分析工具如 ELK、Loki对接。HTTP/REST 协议Triton 将 Logging 端点暴露在如下 URL默认 HTTP 服务监听localhost:8000GET v2/logging POST v2/loggingGET请求用于读取当前日志设置POST请求用于修改日志设置成功后返回更新后的完整设置失败则返回错误。在 HTTP 层/v2/logging由 src/http_server.cc 的路由分发给HandleLogging处理见 src/http_server.cc。Log Setting Response JSON Object成功响应成功的日志设置请求以 HTTP 200 状态码标识响应体为$log_setting_response对象$log_setting_response { $log_setting, ... } $log_setting $string : $string | $boolean | $number每个$log_setting是一个名称/值对名称为设置项名称的$string表示值为$string、$bool或$number。响应中始终包含上文列出的全部六个设置项——即使客户端只修改了其中一项响应也会返回所有设置项的当前值。以源码为准实际响应中的键名与类型为src/http_server.cc{ log_file: , log_info: true, log_warning: true, log_error: true, log_verbose_level: 0, log_format: default }注意原协议文档示例中曾出现log_warnings/log_errors的拼写但本仓库服务端实现与 QA 测试qa/L0_logging/logging_endpoint_test.py均采用单数形式键名log_warning/log_error实际对接时应以log_warning/log_error为准。Log Setting Response JSON Error Object失败响应请求失败时以 HTTP 错误状态码标识典型为 400响应体为$log_setting_error_response对象$log_setting_error_response { error: $string }其中error为描述性的错误消息。例如尝试通过网络协议修改log_file位置时服务端会返回错误见 src/http_server.cc{ error: log file location can not be updated through network protocol }Log Setting Request JSON Object修改请求修改日志设置通过POST v2/logging发起请求体为$log_setting_request对象$log_setting_request { $log_setting, ... }请求中可以只携带需要修改的设置项未被指定的设置项保持原值不变。当前可通过网络协议更新的设置项为log_infolog_warninglog_errorlog_verbose_levellog_format注意log_file不在可更新列表内——日志文件输出位置只能在服务器启动时通过命令行--log-file指定运行期间不可通过网络修改否则返回上述 UNSUPPORTED 错误。使用 curl 调用示例假设 Triton 服务器运行在localhost:8000可用 curl 发起修改请求同时打印 HTTP 状态码curl -s -w \n%{http_code}\n -d {log_verbose_level:1} -X POST localhost:8000/v2/logging该命令返回$log_setting_responseJSON 对象与状态码{log_file:,log_info:true,log_warning:true,log_error:true,log_verbose_level:1,log_format:default} 200可以看到虽然请求只修改了log_verbose_level但响应返回了全部六个设置项的当前值。这便于客户端在每次修改后同步本地状态无需额外发起一次GET。读取当前设置则直接使用 GETcurl -s localhost:8000/v2/logginggRPC 协议对于 Logging 扩展Triton 在GRPCInferenceService中实现了LogSettingsRPC默认 gRPC 服务监听localhost:8001service GRPCInferenceService { … // Update and get the log setting of the Triton server. rpc LogSettings(LogSettingsRequest) returns (LogSettingsResponse) {} }该 API 返回最新日志设置。错误通过google.rpc.Status指示OK表示成功其他状态码表示失败。请求与响应消息定义message LogSettingsRequest { message SettingValue { oneof parameter_choice { // bool param option bool bool_param 1; // uint32 param option uint32 uint32_param 2; // string param option string string_param 3; } } // The new setting values to be updated. // Unspecified settings will remain unchanged. mapstring, SettingValue settings 1; } message LogSettingsResponse { message SettingValue { oneof parameter_choice { // bool param option bool bool_param 1; // uint32 param option uint32 uint32_param 2; // string param option string string_param 3; } } // The latest log settings values. mapstring, SettingValue settings 1; }请求与响应都使用mapstring, SettingValue承载设置项SettingValue通过oneof提供三种取值类型布尔、无符号 32 位整数与字符串。请求中未指定的设置项保持不变响应则返回全部最新设置。各设置项的参数类型约束源码级gRPC 服务端在 src/grpc/grpc_server.cc 的OnExecuteLogging回调中对每个设置项做了严格的类型校验参数类型不匹配会返回TRITONSERVER_ERROR_INVALID_ARG设置项要求的parameter_choice类型不匹配时的错误信息log_file不允许出现在请求中log file location can not be updated through network protocolUNSUPPORTEDlog_infobool_paramexpect boolean for log_infolog_warningbool_paramexpect boolean for log_warninglog_errorbool_paramexpect boolean for log_errorlog_verbose_leveluint32_paramexpect int32 for log_verbose_levellog_formatstring_paramexpect string for log_format取值既非ISO8601也非default时返回invalid argument for log_format, got: valuegRPC 客户端调用Python 示例使用tritonclient的 gRPC 客户端可以这样读取与更新设置与 qa/L0_logging/logging_endpoint_test.py 中的测试用法一致import tritonclient.grpc as grpcclient client grpcclient.InferenceServerClient(localhost:8001) # 读取当前日志设置 settings client.get_log_settings() print(settings) # 更新 verbose 等级与日志格式 client.update_log_settings(settings{log_verbose_level: 2, log_format: ISO8601})日志格式规范default 与 ISO8601Logging 扩展支持两种日志格式二者字段集合相同仅日志条目时间戳的表示方式不同。日志消息默认按 JSON 编码规则序列化消息内容中的特殊字符会被转义该行为可在启动服务器时通过环境变量TRITON_SERVER_ESCAPE_LOG_MESSAGES设置为0来禁用但不能通过 Logging 扩展在运行期修改。日志条目分为单行single-line与多行multi-line两种形态。多行条目由一个可选的行首标题heading加一个结构化对象的文本表示如表格或 protobuf 消息组成多行条目以下一条日志条目开始时结束。1.TRITONSERVER_LOG_DEFAULTdefault 格式单行条目格式levelmonthdayhour:min:sec.usec pid file:line] message示例I0520 20:03:25.829575 3355 model_lifecycle.cc:441] AsyncLoad() simple多行条目格式levelmonthdayhour:min:sec.usec pid file:line] heading object示例I0520 20:03:25.912303 3355 server.cc:676] ------------------------- | Model | Version | Status | ------------------------- | simple | 1 | READY | -------------------------在 default 格式中level为单字符日志级别如I/W/E/V时间戳由月份、日期与本地时区时分秒微秒组成例如I0520 20:03:25.829575。2.TRITONSERVER_LOG_ISO8601ISO8601 格式单行条目格式year-month-dayThour:min:secZ level pid file:line] message示例2024-05-20T20:03:26Z I 3415 model_lifecycle.cc:441] AsyncLoad() simple多行条目格式year-month-dayThour:min:secZ level pid file:line] heading object示例2024-05-20T20:03:26Z I 3415 server.cc:676] ------------------------- | Model | Version | Status | ------------------------- | simple | 1 | READY | -------------------------ISO8601 格式采用 UTC 时间的YYYY-MM-DDThh:mm:ssZ时间戳末尾Z表示 UTC级别字段独立成列I前有空格适合被按时间排序的日志聚合系统直接解析。关于两种格式的完整输出与 JSON 转义行为的自动化校验可参考 qa/L0_logging/log_format_test.py。与启动期命令行参数的关系Logging 扩展所管理的设置项与tritonserver启动时的命令行参数一一对应定义与帮助文本见 src/command_line_parser.cc命令行参数对应设置项说明--log-verbose intlog_verbose_level设置 verbose 日志等级0禁用 1启用--log-info boollog_info启用/禁用 INFO 级日志--log-warning boollog_warning启用/禁用 WARNING 级日志--log-error boollog_error启用/禁用 ERROR 级日志--log-format stringlog_format取值default或ISO8601默认default--log-file stringlog_file日志输出文件名不指定则输出到控制台这些命令行参数的解析在 src/command_line_parser.cc 完成--log-format仅接受default与ISO8601两个取值其余值抛出ParseException--log-file直接记录文件路径。两者关系可概括为命令行参数决定服务器启动时的初始日志状态Logging 扩展负责运行期动态调整。其中唯一的例外是log_file——它只能在启动时通过--log-file指定运行期不可修改。从源码注释可以看到无论 HTTP 还是 gRPC 路径每次更新都必须同时作用到 server 仓库与 core 仓库两份 Logger 对象上Server and Core repos do not have the same Logger object. Each update must be applied to both server and core repo versions见 src/http_server.cc 与 src/grpc/grpc_server.cc即通过LOG_ENABLE_INFO/LOG_SET_VERBOSE/LOG_SET_FORMAT等宏更新本仓库日志器同时通过TRITONSERVER_ServerOptionsSetLogInfo/TRITONSERVER_ServerOptionsSetLogWarn/TRITONSERVER_ServerOptionsSetLogError/TRITONSERVER_ServerOptionsSetLogVerbose/TRITONSERVER_ServerOptionsSetLogFormat等 API 同步 core 仓库的日志配置。服务端实现路径剖析HTTP 处理流程路由分发HTTPAPIServer::Handle在 src/http_server.cc 中匹配请求路径/v2/logging调用HandleLogging权限与方法校验HandleLogging首先检查RestrictedCategory::LOGGING是否被限制src/http_server.cc随后校验请求方法必须为GET或POST否则返回405 Method Not Allowedsrc/http_server.ccPOST 处理将请求体解析为 JSON逐项检查log_file/log_info/log_warning/log_error/log_verbose_level/log_format仅更新请求中显式给出的设置项并同时同步 server 与 core 两份 Loggersrc/http_server.cc响应构造无论 GET 还是 POST最终都会构造包含全部六个设置项的 JSON 对象并返回200 OKsrc/http_server.cc。值得注意的是HandleLogging在解析请求时使用了EVRequestToJsonAllowsEmpty允许空请求体的 JSON 解析因此POST v2/logging传空请求体也不会报错——只是不更新任何设置项仅返回当前快照。gRPC 处理流程CommonHandler::RegisterLoggingsrc/grpc/grpc_server.cc完成LogSettingsRPC 的注册注册回调通过service_-RequestLogSettings注册异步请求处理经CommonCallData模板实例化为名为Logging的通用调用false /* async */表示非流式单次调用更新逻辑在OnExecuteLogging回调中若请求的settingsmap 非空则依次处理各设置项每个设置项都先校验parameter_choice类型再应用错误处理任何校验失败都会通过GOTO_IF_ERR(err, earlyexit)提前退出并由GrpcStatusUtil::Create(status, err)转换为google.rpc.Status返回给客户端src/grpc/grpc_server.cc响应构造成功时在响应 map 中写入全部六个设置项的当前值src/grpc/grpc_server.cc。QA 测试验证仓库的 QA 测试套件对 Logging 扩展做了完整的端到端验证可作为理解行为细节与复现实验的参考qa/L0_logging/logging_endpoint_test.py覆盖 HTTP 与 gRPC 两种协议的读取、更新、错误场景。测试用例验证了初始状态log_file、三个级别均为true、log_verbose_level0、log_formatdefault、修改log_info/log_warning/log_error后服务器状态的实时变化以及尝试通过网络修改log_file时返回log file location can not be updated through network protocol的错误见 qa/L0_logging/logging_endpoint_test.py。测试的tearDown还会将全部设置恢复到初始状态保证用例间互不影响qa/L0_logging/log_format_test.py以参数化方式验证default/ISO8601含_unescaped变体两种格式下日志行的时间戳正则匹配以及 JSON 转义/不转义场景下的日志注入防护行为qa/L0_logging/test.sh启动tritonserver并运行上述测试的入口脚本包含verify_correct_settings辅助函数用于断言服务器当前日志设置是否符合预期。典型实战场景场景一生产排障时动态开启 verbose 日志模型推理出现异常、需要深入排查请求调度细节时无需重启服务器即可提升 verbose 等级curl -s -d {log_verbose_level:3} -X POST localhost:8000/v2/logging排障完成后恢复默认curl -s -d {log_verbose_level:0} -X POST localhost:8000/v2/logging场景二临时关闭冗余日志以降低 IO在高吞吐压测时可通过关闭 INFO 日志降低日志 IO 开销curl -s -d {log_info:false} -X POST localhost:8000/v2/logging注意 WARNING 与 ERROR 级别默认保持开启关键错误信息不会丢失。场景三切换 ISO8601 格式对接日志平台日志采集系统要求标准时间戳时动态切换格式curl -s -d {log_format:ISO8601} -X POST localhost:8000/v2/logging切换后日志条目的时间戳立即变为2024-05-20T20:03:26Z形式。场景四运行期确认服务器日志能力调用GET v2查看 Server Metadata 中extensions字段是否包含logging可判断服务器是否支持本扩展curl -s localhost:8000/v2总结Triton Inference Server 的 Logging 扩展以极低的接入成本一个 HTTP 端点或一个 gRPC RPC为运维与开发提供了运行期动态调节日志的能力六个设置项覆盖了日志输出位置、三个日志级别开关、verbose 阈值等级与两种时间戳格式。结合本仓库源码可以确认其 HTTP 与 gRPC 实现共享同一套语义与校验规则并始终将 server 与 core 两份 Logger 的配置保持同步而 qa/L0_logging 下的端到端测试则为这些行为提供了可复现的验证依据。在实际部署中建议将 Logging 扩展与 docs/customization_guide/inference_protocols.md 描述的受限 API 机制配合使用在开放动态调试能力的同时守住安全边界。赞分享模型推理服务AI 应用后端【免费下载链接】serverThe Triton Inference Server provides an optimized cloud and edge inferencing solution.项目地址https://gitcode.com/gh_mirrors/server117/server点击查看免费下载相关推荐Triton Inference Server Trace 扩展协议解析通过 HTTP/REST 与 gRPC 在运行时配置追踪Triton Inference Server Trace 扩展协议解析通过 HTTP/REST 与 gRPC 在运行时配置追踪 导读 本文围绕 Triton模型推理服务AI 应用后端Triton Inference Server 的 KServe 协议扩展全景从 HTTP/REST 到 gRPC 的 11 个扩展机制详解Triton Inference Server 的 KServe 协议扩展全景从 HTTP/REST 到 gRPC 的 11 个扩展机制详解 导读 Trito模型推理服务AI 应用后端Triton Inference Server 统计扩展Statistics Extension协议深度解析HTTP/REST 与 gRPC 接口全解Triton Inference Server 统计扩展Statistics Extension协议深度解析HTTP/REST 与 gRPC 接口全解 T模型推理服务AI 应用后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
