Logging
Archon provides advanced logging capabilities in accordance with federal regulations. Leveraging our logging solution will ensure you have compliant, auditable logs.
What's in a log
Archon logs can include many different details. All details are required unless otherwise indicated.
note
You should always provide as many details as are relevant when you submit a log. Government customers love detailed logs.
- context: A message about the log. What you would typically put into a log function in other frameworks
- sensitiveContext: Any part of the message that may contain sensitive or protected information.
- For instance, if your log may contain personally identifiable or contract-protected information, you should place that info in the sensitiveContext field
- eventType: The user-defined type of the log. Useful for categorizing logs after the fact
- To simplify sorting and aggregation, you can define event types for groups of related logs. For instance, if you log every time a user visits a page, you may define a
PAGE_VISITevent type.
- To simplify sorting and aggregation, you can define event types for groups of related logs. For instance, if you log every time a user visits a page, you may define a
- source: The component that the log came from. Typically set by the name you define when initializing your SDK
- For instance, in the NodeJS SDK:
Archon.setComponentName('my-app')sets the source tomy-app
- For instance, in the NodeJS SDK:
- outcome: The outcome of the event that you're describing in the log. Recommended by federal regulations
- Valid outcomes are:
IN_PROGRESS,SUCCESS,FAILURE, andCOMPLETED - Logs without a distinct "outcome" should use
COMPLETED
- Valid outcomes are:
- severity: The level of importance of the event you're logging about, on a scale of 0-5. When in production, this determines whether or not a human is pinged to take action on a log.
| Severity Level | Description |
|---|---|
| Debug (0) | Only notable to developers. Causes no disruption and represents no deviation. |
| Info (1) | Informational messages that highlight the progress of the application at a coarse-grained level. |
| Notice (2) | Normal but significant events (e.g., user accesses a privileged location). |
| Warning (3) | Exceptional occurrences that are not errors (e.g., user attempts to access a privileged location but is denied). |
| Error (4) | Occurrences that do not require immediate action but should be logged and monitored. Flagged for human review if needed. |
| Critical (5) | Critical conditions (e.g., an application component is unavailable or compromised). Triggers immediate human intervention. |
- associatedResources: A list of ARIDs of resources that are involved in this log
- associatedUsers: A list of users that are involved in this log
- session: The session of the user that triggered this log
- submittingUser: The user account that submits the log. Typically the service user for your application.
Logging in practice
Your language's SDK provides logging functions that you should use where appropriate. Refer to your language's specific documentation for more information.