Usage no npm install needed!

<script type="module">
  import clerksystemsSecretary from 'https://cdn.skypack.dev/@clerksystems/secretary';


Secretary Log Module

Table of Content


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.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



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




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