DEVELOPMENT TOOL: Logging system #14

New Issue

azpect · 2025-07-12T10:57:25-07:00

azpect commented

2025-07-12 10:57:25 -07:00

Currently, this application has no logging. This will be a problem at some point if errors ever take place and something needs to be reported.

At some point, this will need to be implemented.

Currently, this application has no logging. This will be a problem at some point if errors ever take place and something needs to be reported. At some point, this will need to be implemented.

azpect commented

2025-09-03 20:23:30 -07:00

There should exist an interface, Logger, which will have methods like Write and WriteAll. Implementations of the interface can be created to write to files, databases, etc. Simply calling a write method will handle the writing of a log statement to the implementation.

A list of loggers will be stored somewhere in the application that can be accessed anywhere. This list can be used to log to many places at the same time.

Maybe: WIP

A queue will exist which will accept a LogStatement struct (will all required details) and the queue will execute each statement in order and make a call to each logger provided. Making use of concurrency would be ideal; a routine for each logger for each log? Might create lots of routines, but they're cheap and the ops should be fast. This should also allow for pretty quick turn over. UNLESS we reach race conditions in the DB or in files.

When the queue gets too large, maybe we should use the WriteAll implementation to write a list of logs to the logger. This would be pretty easy to implement. However, the queue is not as simple.

There should exist an interface, `Logger`, which will have methods like `Write` and `WriteAll`. Implementations of the interface can be created to write to files, databases, etc. Simply calling a write method will handle the writing of a log statement to the implementation. A list of loggers will be stored somewhere in the application that can be accessed anywhere. This list can be used to log to many places at the same time. ### Maybe: WIP A queue will exist which will accept a `LogStatement` struct (will all required details) and the queue will execute each statement in order and make a call to each logger provided. Making use of concurrency would be ideal; a routine for each logger for each log? Might create lots of routines, but they're cheap and the ops should be fast. This should also allow for pretty quick turn over. UNLESS we reach race conditions in the DB or in files. When the queue gets too large, maybe we should use the `WriteAll` implementation to write a list of logs to the logger. This would be pretty easy to implement. However, the queue is not as simple.

azpect commented

2025-09-03 20:28:52 -07:00

`LogStatement` Data Requirements

Type: Enumerated type: DEBUG, INFO, WARN, ERROR

Date: Timestamp of the log (UTC)

Message: String content of the log, could be JSON stringified or textual content

Reference: Optional string content which can be used as a reference point, similar to a stack trace, if errors occur.

ID: Unique UUID for reference. As needed in DB as well.

## `LogStatement` Data Requirements **Type**: Enumerated type: `DEBUG`, `INFO`, `WARN`, `ERROR` **Date**: Timestamp of the log (UTC) **Message**: String content of the log, could be JSON stringified or textual content **Reference**: Optional string content which can be used as a reference point, similar to a stack trace, if errors occur. **ID**: Unique UUID for reference. As needed in DB as well.

azpect added the

Kind/Infrastructure

Priority

Critical

labels 2025-11-24 11:23:30 -07:00

azpect commented

2026-01-26 22:34:12 -07:00

Reference will be stored in the message, if needed.

**Reference** will be stored in the message, if needed.

azpect commented

2026-01-26 22:46:06 -07:00

All that is left is a way to load the loggers from the environment.