When developing an exhibit there are 3 different types of logs in 2 locations available for use. Each are controlled independently so it is up to the exhibit developer to decide which is appropriate, though we layout some opinions at the bottom of this discussion. Each logger can use the same severity levels but they end up in different places.
Your logs
gumbandLocalLogger
gumbandCloudLogger
Your Console Log Statements
This one is the easiest. When you are writing your own code and you use console
statements you can see those in the node process that is running your exhibit. In the example of The Digital Signage and Game Tutorial I have thrown in some logging statements before and after the socket handlers so I know that all of these were mounted in the addSDKListeners
.
// gumband-sdk-tutorial/gumband/gumband-service.js class GumbandService { ... instance variables, constructor /** * Add listeners to the Gumband SDK to handle messages from the Gumband Cloud. */ addSDKListeners() { console.log('Adding SDK listeners...') // đ I added this to my exhibit code to know the function is running. this.gumbandSDK.on(Sockets.OP_MODE_RECEIVED, (payload) => { //Body Ommitted }) this.gumbandSDK.on(Sockets.READY, async (manifest) => { //Body Ommitted }) this.gumbandSDK.on(Sockets.SETTING_RECEIVED, (payload) => { //Body Ommitted }) this.gumbandSDK.on(Sockets.FILE_UPLOADED, async (manifest) => { //Body Ommitted }) //listen for the CONTROL_RECEIVED event this.gumbandSDK.on(Sockets.CONTROL_RECEIVED, async (payload) => { * //Body Ommitted }); // đ I added this to make sure all of the `.on` methods completed. console.log('SDK listeners added.') } }
You can see those logs as I start up the exhibit.
Gumband Local Logger
When you install the Gumband SDK there is a component of that package called localLogger
. This package is what the Gumband team uses to log information to you (the exhibit developer) regarding the operation of your exhibit. As an exhibit developer you will NOT make calls to the local logger, but you can control how noisy itâs output is depending on your personal preference.
const { Gumband } = require("@deeplocal/gumband-node-sdk"); this.gumbandSDK = new Gumband( process.env.EXHIBIT_TOKEN, process.env.EXHIBIT_ID, `./manifest.json`, { // Additional Configuration Options localLoggingLevel: 'debug' } );
The acceptable values for localLoggingLevel
:
debug
- the ânoisiestâ of the logs, it includes all levels of severity listed below in addition toconsole.debug
statements. You probably donât need this log level unless youâre curious as to how the SDK works âunder the hoodâ.info
- the second noisiest of the logs, includes all levels of severity below in addition toconsole.info
statements. You may find this useful, even though it increases the volume of logs in your terminal.warn
- this log level includes the severity below in addition toconsole.warn
statements. It is helpful because this is where we will post notices of future deprecation, tips/tricks or potential âgotchya momentsâ to keep you aware. This is the default log level if you donât set anything in thenew Gumband()
constructor options object.error
- this level is reserved for the most alarming use cases. We try to use it as little as possible, but when it arrives you should probably double check your code/connections etc to ensure the exhibit is functioning as intended as itâs likely that something is awry.
Gumband Cloud Logs
These log messages can be triggered by the exhibit developer during runtime and, assuming a healthy internet connection, those logs will appear in the Logging Tab of the Gumband Cloud UI.
You can trigger these logs by calling commands like:
this.gumbandSDK.logger.debug('This is a debug log'); this.gumbandSDK.logger.info('This is an info log'); this.gumbandSDK.logger.warn('This is a warn log'); this.gumbandSDK.logger.error('This is an error log');
You may have seen this if you followed the Digital Signage and Game Tutorial