feat: Add log callback option to tritonserver C and Python APIs

[pskiran1]

Exposes the new common-layer callback through Triton's public APIs: a TRITONSERVER_ServerOptionsSetLogCallback C API and a log_callback field on the Python Options.

CI: triton-inference-server/server#8858

[whoisj]

Looking good. I have a quesion.

[yinggeh]

Need to add new stub to tritonserver_stub.cc. Did it build successfully without it?

[pskiran1]

Need to add new stub to tritonserver_stub.cc. Did it build successfully without it?

Good catch, added the TRITONSERVER_ServerOptionsSetLogCallback stub next to the other option setters. It built successfully without it. I think tritonserver_stub.cc is a separate target of empty placeholder symbols, and the real libtritonserver builds from tritonserver.cc.

[whoisj]

LGTM

[yinggeh]

Looks like some agent reviews were posted accidentally😅.

[greptile-apps]

Greptile Summary

This PR exposes the common-layer log callback through Triton's public C and Python APIs, allowing embedding applications to intercept structured log records instead of parsing formatted stderr/file output. The callback is staged on the options object and installed atomically in TRITONSERVER_ServerNew before any worker threads start.

• C API (tritonserver.h, tritonserver.cc): New TRITONSERVER_LogCallbackFn_t typedef and TRITONSERVER_ServerOptionsSetLogCallback; TRITONSERVER_ServerNew calls LOG_SET_CALLBACK unconditionally, clearing any previous callback when none is staged.
• Python binding (tritonserver_pybind.cc): A SetLogCallback trampoline wraps each Python callable in a heap-allocated py::object holder, acquires the GIL per invocation, and releases the holder permanently for process-global logger lifetime. The PyServer constructor now releases the GIL during TRITONSERVER_ServerNew to prevent deadlock.
• High-level Python API (_server.py): Adds Optional[Callable] log_callback to Options, wired to set_log_callback when non-None.

Confidence Score: 5/5

The change is safe to merge. GIL management is correct in both the trampoline and PyServer constructor, the callback lifetime design is intentional and commented, and the level mapping covers all known log levels.

The implementation is internally consistent: the GIL is released during TRITONSERVER_ServerNew to prevent deadlock, the trampoline properly acquires the GIL before calling into Python, exceptions are correctly caught at the C boundary, and callback installation is atomic with respect to worker-thread startup.

The level-mapping switch in src/tritonserver.cc is the one spot worth a second look — its default case will silently reclassify any log level added to the common library in the future as INFO.

Important Files Changed

Filename	Overview
src/tritonserver.cc	Adds TRITONSERVER_ServerOptionsSetLogCallback with level mapping and LOG_SET_CALLBACK in TRITONSERVER_ServerNew; default case maps unknown levels to INFO silently.
python/tritonserver/_c/tritonserver_pybind.cc	Adds SetLogCallback trampoline with correct GIL management; adds py::gil_scoped_release to PyServer constructor preventing deadlock.
include/triton/core/tritonserver.h	Adds TRITONSERVER_LogCallbackFn_t typedef and TRITONSERVER_ServerOptionsSetLogCallback declaration with thorough doc comments.
python/tritonserver/_api/_server.py	Adds log_callback: Optional[Callable] = None to Options; wires it to set_log_callback when non-None.
python/test/test_logging_callback.py	New test suite covering callback install, default-sink fallback, throwing-callback isolation, and the high-level Options.log_callback path.
src/tritonserver_stub.cc	Adds link-time stub for TRITONSERVER_ServerOptionsSetLogCallback consistent with existing stub pattern.

_{Reviews (4): Last reviewed commit: "Undo last commit" | Re-trigger Greptile}