Secretary Log Module

Table of Content

• Description
  • Main factory options
  • Factory options
• Default log levels

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' )