#376 - Add logging standards from MBTP #377
Open
Conversation
This file contains 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
…g logging patterns.
jeff-horton-ho-sas
added
content
Observability
Comment on lines
+41
to
+46
| Information | Description | ||
| ------------| ----------- | ||
| Date / Time | Each log message must include date and time (millisecond accuracy) (UTC). The time source for all service logs must be consistent so that messages can be viewed & sorted easily. | ||
| Service | Each log message must be attributed to an service (i.e. hostname). | ||
| Log level | Each log message must have an appropriate log level (INFO, WARN, ERROR, etc.) | ||
| Log Message | Each log message must have a log message. Log messages must follow a consistent log messaging format for all log types to allow for easy processing and translation of logs to other formats. |
There was a problem hiding this comment.
We have found tables can cause flow issues. Could consider using summary lists as in the docs-as-code pattern
|
|
||
| Examples of combined PII include: | ||
| * Passport number, Issuing Country, Expiry Dates | ||
| * BRP/C number, Date of Birth |
There was a problem hiding this comment.
Suggested change
| * BRP/C number, Date of Birth | |
| * Biometric residence permit or card (BRP/C) number, Date of Birth |
| * Passport number, Issuing Country, Expiry Dates | ||
| * BRP/C number, Date of Birth | ||
|
|
||
| With the examples above, the information by themselves do not mean very much. After all, a BRP/C number is just a "random" sequence of characters; but in combination with the date of birth it can be used to uniquely identify an individual. |
There was a problem hiding this comment.
Suggested change
| With the examples above, the information by themselves do not mean very much. After all, a BRP/C number is just a "random" sequence of characters; but in combination with the date of birth it can be used to uniquely identify an individual. | |
| With the examples above, the information by themselves do not mean very much. After all, a BRP/C number is a random sequence of characters; but in combination with the date of birth it can be used to uniquely identify an individual. |
| href: /patterns/securing-application-logging/ | ||
| --- | ||
|
|
||
| Logging tools are one of the primary tools to debug application problems and identifying the root cause of incidents. However, logs need to be formatted in a standard way so that they are not only useful for the application's original developers, but also those supporting the application later in its life-cycle. |
There was a problem hiding this comment.
Suggested change
| Logging tools are one of the primary tools to debug application problems and identifying the root cause of incidents. However, logs need to be formatted in a standard way so that they are not only useful for the application's original developers, but also those supporting the application later in its life-cycle. | |
| Logging tools are one of the primary tools to debug application problems and identifying the root cause of incidents. Logs need to be formatted in a standard way so that they are useful for the both application's developers and those supporting the application later in its life-cycle. |
Comment on lines
+22
to
+24
| However, logs are sometimes relied on too heavily for problem detection, when this role would be better suited to purpose chosen monitoring tooling. | ||
|
|
||
| Therefore these standards provide guidance on both the proper format of application logs, as well as their proper usage. |
There was a problem hiding this comment.
Suggested change
| However, logs are sometimes relied on too heavily for problem detection, when this role would be better suited to purpose chosen monitoring tooling. | |
| Therefore these standards provide guidance on both the proper format of application logs, as well as their proper usage. | |
| Logs are not a replacement for dedicated monitoring tooling. They should be used as part of a broader observabilty toolset. This standard provides guidance on a standard format for application logs, and suitable uses. |
|
|
||
| However, logs are sometimes relied on too heavily for problem detection, when this role would be better suited to purpose chosen monitoring tooling. | ||
|
|
||
| Therefore these standards provide guidance on both the proper format of application logs, as well as their proper usage. |
There was a problem hiding this comment.
Suggested change
| Therefore these standards provide guidance on both the proper format of application logs, as well as their proper usage. | |
| This standard provides guidance on the proper format and usage of logs. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
A PR to create a new set of Standards for application logging, based on those that exist in MBTP already.
Content change
I can confirm:
e.g. Writing a principle and Writing a standard