README

Secretary Log Module

The exported function is a factory for factories, this way you can provide a config that is used by all the individual loggers.

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

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

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

LogType

idsourcedataTypetype

0productstringfilters-loading 1productstringstartup-state 2frameworkboolcloud-online-state 3frameworkboolproduct-is-active

4roonstringsync-state

LogItem

idlogTypeIdlevelvalue

00errorcould not load store 10debugstarting 21infotrue 32noticefalse

44error{ "msg": "lost", "time": 90654 } 44error"found"

LogItem (large)

idsourcedataTypetypeleveldata 0productstringfilters-loadingerrorcould not load store

const logger= source -> type -> ( level, msg )

frmLogger( 'filter-state' )( 'mijn harde bericht' )

<5> sdfghjkl

constfilterLogger = frmLogger.createType( 'filter-state' )

filterLogger.error( 'could not load' )

logger.syncTypes() ==> [ "delay" ]

logger.createType( 'delay', 'integer' )