Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenIM Logging System: Design and Usage #841

Closed
cubxxw opened this issue Aug 10, 2023 — with Slack · 1 comment
Closed

OpenIM Logging System: Design and Usage #841

cubxxw opened this issue Aug 10, 2023 — with Slack · 1 comment
Assignees
Labels
documentation Categorizes issue or PR as related to documentation. feature Categorizes issue or PR as related to a new feature. RFC Project design proposal
Milestone

Comments

Copy link
Contributor

cubxxw commented Aug 10, 2023

OpenIM Logging System: Design and Usage

PATH: scripts/lib/logging.sh

Introduction

OpenIM, an intricate project, requires a robust logging mechanism to diagnose issues, maintain system health, and provide insights. A custom-built logging system embedded within OpenIM ensures consistent and structured logs. Let's delve into the design of this logging system and understand its various functions and their usage scenarios.

Design Overview

  1. Initialization: The system begins by determining the verbosity level through the OPENIM_VERBOSE variable. If it's not set, a default value of 5 is assigned. This verbosity level dictates the depth of the log details.
  2. Log File Setup: Logs are stored in the directory specified by OPENIM_OUTPUT. If this variable isn't explicitly set, it defaults to the _output directory relative to the script location. Each log file is named based on the date to facilitate easy identification.
  3. Logging Function: The echo_log() function plays a pivotal role by writing messages to both the console (stdout) and the log file.
  4. Logging to a file: The echo_log() function writes to the log file by appending the message to the file. It also adds a timestamp to the message. path: _output/logs/*, Enable logging by default. Set to false to disable. If you wish to turn off output to log files set ENABLE_LOGGING=flase.

Key Functions & Their Usages

  1. Error Handling:
    • openim::log::errexit(): Activated when a command exits with an error. It prints a call tree showing the sequence of functions leading to the error and then calls openim::log::error_exit() with relevant information.
    • openim::log::install_errexit(): Sets up the trap for catching errors and ensures that the error handler (errexit) gets propagated to various script constructs like functions, expansions, and subshells.
  2. Logging Levels:
    • openim::log::error(): Logs error messages with a timestamp. The log message starts with '!!!' to indicate its severity.
    • openim::log::info(): Provides informational messages. The display of these messages is governed by the verbosity level (OPENIM_VERBOSE).
    • openim::log::progress(): Designed for logging progress messages or creating progress bars.
    • openim::log::status(): Logs status messages with a timestamp, prefixing each entry with '+++' for easy identification.
    • openim::log::success(): Highlights successful operations with a bright green prefix. It's ideal for visually signifying operations that completed successfully.
  3. Exit and Stack Trace:
    • openim::log::error_exit(): Logs an error message, dumps the call stack, and exits the script with a specified exit code.
    • openim::log::stack(): Prints out a stack trace, showing the call hierarchy leading to the point where this function was invoked.
  4. Usage Information:
    • openim::log::usage() & openim::log::usage_from_stdin(): Both functions provide a mechanism to display usage instructions. The former accepts arguments directly, while the latter reads them from stdin.
  5. Test Function:
    • openim::log::test_log(): This function is a test suite to verify that all logging functions are operating as expected.

Usage Scenario

Imagine a situation where an OpenIM operation fails, and you need to ascertain the cause. With the logging system in place, you can:

  • Check the log file for the specific day to find error messages with the '!!!' prefix.
  • View the call tree and stack trace to trace back the sequence of operations leading to the failure.
  • Use the verbosity level to filter out unnecessary details and focus on the crux of the issue.

This systematic and structured approach greatly simplifies the debugging process, making system maintenance more efficient.

Conclusion

OpenIM's logging system is a testament to the importance of structured and detailed logging in complex projects. By using this logging mechanism, developers and system administrators can streamline troubleshooting and ensure the seamless operation of the OpenIM project.

@cubxxw cubxxw added documentation Categorizes issue or PR as related to documentation. feature Categorizes issue or PR as related to a new feature. sig/docs labels Aug 10, 2023 — with Slack
@cubxxw cubxxw added this to the v3.2 milestone Aug 10, 2023 — with Slack
@cubxxw cubxxw self-assigned this Aug 10, 2023
@cubxxw cubxxw added the RFC Project design proposal label Aug 10, 2023
@kubbot
Copy link
Contributor

kubbot commented Oct 10, 2023

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Categorizes issue or PR as related to documentation. feature Categorizes issue or PR as related to a new feature. RFC Project design proposal
Projects
Status: Done
Development

No branches or pull requests

2 participants