@clerksystems/secretary v1.0.16
Secretary Log Module
Table of Content
Description
The exported function is a factory for factories, this way you can provide a config that is used by all the individual loggers.
Main factory options
| Option | Description |
|---|---|
| options.db | Sequelize options |
| options.db.storage | Where to save the database |
| options.db.logging | Should Sequelize log its actions? |
| options.log | |
| options.log.verbose | Should secretary log its internal actions? |
| options.log.maxNrOfItems | How many items may be stored in the database |
| options.log.itemThreshold | How many items the database should be able to store safely without overflowing |
| options.log.maxCache | How many items the cache can hold |
| options.log.uploadBulkSize | How many logs are in a single batch for uploading |
| options.log.onOnline | This function takes a function which gets triggered when online status changes |
| options.log.upload | This function is used to upload data |
Factory options
| Option | Description |
|---|---|
| options.source | Logger source name |
| options.instructions | Object describing minimum levels and their log output |
| options.styles | Overwrite default styling, use an object with level as key and chalk color function as value |
| options.standardTrace | Startup logging function if its enabled in main options.log.verbose |
| options.debug | Boolean indicating if debug messages should be traced |
| options.dbLogger | Custom database logger |
Default log levels
| Option | Description |
|---|---|
| emergency | System unusable - exiting / shutting down |
| alert | Act now or the application shuts down |
| critical | Error on app level, but trying to continue |
| error | Error on operation level. Definitely a problem that should be investigated. SysAdmin should be notified automatically, but doesn't need to be dragged out of bed. By filtering a log to look at errors and above you get an overview of error frequency and can quickly identify the initiating failure that might have resulted in a cascade of additional errors. Tracking error rates as versus application usage can yield useful quality metrics such as MTBF which can be used to assess overall quality |
| warning | This MIGHT be problem, or might not. For example, expected transient environmental conditions such as short loss of network or database connectivity should be logged as Warnings, not Errors. Viewing a log filtered to show only warnings and errors may give quick insight into early hints at the root cause of a subsequent error. |
| notice | Normal but significant |
| info | Normal messages shouldn't be to many |
| debug | Everything else, also this level is turned off from the console in production |
Thoughts for future development
LogType
id source dataType type
0 product string filters-loading 1 product string startup-state 2 framework bool cloud-online-state 3 framework bool product-is-active
4 roon string sync-state
LogItem
id logTypeId level value
0 0 error could not load store 1 0 debug starting 2 1 info true 3 2 notice false
4 4 error { "msg": "lost", "time": 90654 } 4 4 error "found"
LogItem (large)
id source dataType type level data 0 product string filters-loading error could not load store
const logger = source -> type -> ( level, msg )
frmLogger( 'filter-state' )( 'mijn harde bericht' )
<5> sdfghjkl
const filterLogger = frmLogger.createType( 'filter-state' )
filterLogger.error( 'could not load' )
logger.syncTypes() ==> "delay"
logger.createType( 'delay', 'integer' )