Feature - Request Log#2306
Closed
VultureZZ wants to merge 17 commits into
Closed
Conversation
This commit introduces a new feature for optional HTTP request logging to PostgreSQL. The following changes were made: - Added new environment variables for configuring request logging in `lemond.service.in` and `secrets.conf`. - Updated `AGENTS.md` to document new request log endpoints and configuration options. - Modified `CMakeLists.txt` to include PostgreSQL support and conditionally compile the request logging service. - Implemented request log handling in the server, including new API endpoints for retrieving recent logs, searching logs, and statistics. - Added tests for the request log parser to ensure functionality. This feature enhances the observability of the server by allowing users to log and review HTTP requests, improving debugging and monitoring capabilities.
This commit modifies the PostgreSQL request logging configuration to use a dynamic port assignment instead of a hardcoded port. Changes include: - Updated `secrets.conf` to reflect the new `<PORT>` placeholder for the database URL. - Revised documentation in `request-log.md` to clarify the use of a random host port assigned by Docker. - Adjusted the `docker-compose.request-log.yml` to expose the PostgreSQL service on the default port without a specific host port mapping. - Enhanced the `start-request-log-db.sh` script to determine and display the assigned host port dynamically. These updates improve flexibility and usability for users setting up the request logging feature.
This commit introduces a new request log panel and enhances the center panel with tabs for switching between server logs and request logs. Key changes include: - Added `CenterPanelTabs` component to manage tab navigation. - Integrated `RequestLogPanel` for displaying request logs. - Updated state management to handle the active tab and visibility of logs. - Modified `ModelManager` and `TitleBar` components to include functionality for opening the request logs. - Enhanced layout settings to persist the selected center panel tab. These updates improve the user interface for viewing logs, providing better organization and accessibility for users monitoring server activity.
This commit improves the user experience for the request log feature by adding detailed error messages and hints in the UI when logging is unavailable or the database connection fails. Key changes include: - Updated `RequestLogPanel` to display specific guidance based on the error type, including setup instructions for enabling request logging and ensuring the database is running. - Enhanced error handling in `requestLogApi.ts` to provide more informative messages when API requests fail. - Added new CSS styles for better presentation of error hints in the request log panel. These updates aim to assist users in troubleshooting issues related to request logging, making the setup process clearer and more user-friendly.
… new row_to_json_from_result function This commit removes the obsolete `row_to_json` method from the `RequestLogService` class and introduces a new `row_to_json_from_result` function. The new function is designed to convert PostgreSQL query results into JSON format, enhancing the handling of request log entries. This change streamlines the codebase and improves the clarity of the logging functionality.
This commit introduces a new function, `sanitize_utf8_for_db`, to ensure that strings stored in the database are valid UTF-8. The function replaces invalid bytes with a replacement character. Additionally, the `extract_response_error` function has been updated to utilize this sanitization method for error messages, enhancing the robustness of error handling. The `RequestLogService` class has also been modified to reset the schema initialization flag upon closing connections, ensuring proper state management. Unit tests have been added to verify the functionality of the new sanitization feature.
…tracking This commit introduces a new endpoint for clearing request logs, allowing users to delete all HTTP request log entries from the database. Additionally, the request log schema has been updated to include `prompt_tokens` and `completion_tokens`, enabling better tracking of token usage in requests. The UI has been enhanced to support the new clear log functionality, including a confirmation dialog and feedback on the operation's success. Unit tests have been added to ensure the correct behavior of the new clear endpoint and token tracking features.
…st logging This commit introduces a new function, `sanitize_json_utf8`, to recursively sanitize JSON objects for valid UTF-8 encoding, ensuring that all strings are properly formatted before logging. The existing `sanitize_utf8_for_db` function has been integrated into the request logging process, enhancing the robustness of error handling during serialization. Additionally, error handling has been improved in the `insert_entries` method of `RequestLogService`, with try-catch blocks added to manage serialization errors gracefully. Unit tests have been added to verify the functionality of the new sanitization features and ensure safe handling of invalid UTF-8 data.
This commit adds a new function, `safe_json_dump`, to safely serialize JSON objects while handling potential errors gracefully. The function is integrated into various parts of the request logging process, replacing direct calls to `dump()` to ensure robust error handling. Additionally, the request log service has been updated to utilize this new function for logging redacted request and response bodies. Unit tests have been added to verify the functionality of the new dumping method and to ensure proper handling of invalid UTF-8 data and float token counts.
This commit introduces the `safe_json_dump_for_db` function, which sanitizes JSON data for safe storage in the database by stripping null escapes and ensuring valid UTF-8 encoding. The `sanitize_utf8_for_db` function has been updated to utilize this new method, improving the handling of redacted request and response bodies in the `RequestLogService`. Additionally, unit tests have been added to verify the functionality of the new JSON dumping method and ensure proper handling of binary responses and null byte stripping.
This commit introduces functionality to handle compressed response bodies in the request logging process. It adds methods to check for various content encodings (gzip, deflate, br, zstd) and decompress the response body accordingly before logging. The `prepare_response_body_for_logging` function has been implemented to ensure that the logged response body is in its decompressed form, improving the clarity and usability of logged data. Additionally, the logging setup has been updated to capture uncompressed response bodies prior to compression, ensuring accurate logging of the original content.
This commit updates the `request_log_service.cpp` file to utilize the `httplib_detail` namespace for decompressor types, enhancing code clarity and consistency. The changes include modifying the declarations of various decompressor instances to ensure they reference the correct namespace, which improves maintainability and aligns with recent refactoring efforts in the logging functionality.
This commit removes the `handleOpenRequestLogs` function and its associated references from the `App`, `ModelManager`, `TitleBar`, and related components. Additionally, the label "Server Logs" has been updated to "System Logs" in the `CenterPanelTabs` and `LogsWindow` components for consistency. These changes streamline the logging interface and improve clarity in the application.
This commit introduces new functions to improve the handling of JSON data in the request logging process. The `normalizeJsonForDisplay` function recursively expands JSON-encoded strings for better readability, while `tryParseJsonString` safely attempts to parse JSON strings. Additionally, the `prepare_response_body_for_logging` function has been updated to incorporate decompression for various content encodings, ensuring that logged response bodies are accurately represented. These enhancements improve the clarity and usability of logged data, particularly for complex JSON structures.
This commit refactors the request log payload display by replacing the JSON formatting logic with a new `RequestLogPayloadView` component for improved readability. Additionally, new CSS styles are introduced to enhance the layout and presentation of request and response payloads, including metadata handling and text formatting. These changes aim to provide a clearer and more user-friendly interface for viewing logged data.
Remove fork-specific deploy/diagnostic helpers and secrets template before upstream PR review. Co-authored-by: Cursor <cursoragent@cursor.com>
github-actions
Bot
added
enhancement
Member
|
I really like this idea! So sorry in advance for what I'm about to say - this falls under the category of "please contact the maintainers before implementing large features". GUI working group is replacing the entire existing GUI with a new one, called GUI3. Please join the discord and visit the gui3-beta channel to learn more. @kpoineal for awareness. This feature is a top request and it would be lovely to have it included in the app eventually. One last note: this kind of logging needs to be opt-in, otherwise it is a privacy violation. Thanks for the PR @VultureZZ and I hope to see you contributing to gui3! |
Contributor
|
Drive by comment: this is a very handy feature imho. Part of the motivation why I proposed #2330. @VultureZZ if the broader telemetry feature gets accepted, do you think the plumbing is better reused? I would also ask if its better to keep things modular, ie. allow users to bring an otel collector like Phoenix/Langfuse/Jaeger if they need this. That said, there might be value in enabling a real-time log view for admins without persistence, this could tap into the telemetry pipeline as well. @jeremyfowers regarding "this kind of logging needs to be opt-in" - do you have thoughts on how should this work? Is this something you expect to be opt-in by the per client/user or the by admin? For the telemetry proposal, my approach has been "admin managed server config" + transparency via health endpoint. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a big one for debugging purposes when building local projects. This implements a request log where users can have all API requests logged into a Postgres database for review and analysis. See example below.