Skip to content

feat: added logging standard#551

Open
PaulGregoryBaker wants to merge 1 commit into
masterfrom
logging_std
Open

feat: added logging standard#551
PaulGregoryBaker wants to merge 1 commit into
masterfrom
logging_std

Conversation

@PaulGregoryBaker
Copy link
Copy Markdown
Contributor

Added logging standard for community review


### Log to Stdout

Write all logs to stdout. Do **not** use `console.log` or write to files directly. Delegate collection, rotation, and shipping to external tools (Fluentd, Vector, OTel Collector). In containerized environments, a sidecar or daemonset picks up stdout, enriches it with pod/host metadata, and ships it to a centralized store.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this possible in all cases? Is there an acceptable window for console logging during container startup before connectivity to the sidecar can be assured? For example: if the log is about connectivity to the side-car failing?

| FATAL | 21-24 | ✅ Always | Service outage | DB unreachable, panic |
| ERROR | 17-20 | ✅ Always | Operation failures | Transaction failed |
| WARN | 13-16 | ✅ Always | Recoverable issues | Validation failure, retry |
| INFO | 9-12 | ✅ Always | Business events | Transfer completed |
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Always" for INFO here seems like it could be a risk for performance if the frequency of logging is unexpetedly high. If you're logging "business events" at a high level of granularity, you could easily log at 10x or higher compared to your actual event volume.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants