I think I just need to put in whatever I want in the string area where I have message, and the logger is that simple?
When this script fires, I will have a debug level entry on the gateway logs?
I never had to troubleshoot something this way before, but it was requested.
So I am probably not aware of different configuration options.
I put the name of the project and the name of the script the logger is in for both the logger name and string, might be overkill. Just hate when I have a logger I can't find.
Note that loggers do not process debug level message by default. You must deliberate set the level for that logger to DEBUG in the gateway web interface.
Also note that there are methods like.debugf(), .tracef(), .infof(), et cetera, that perform printf-style string formatting for you. This is especially helpful when the string you wish to log is complex, and would consume a lot of CPU time unnecessarily when the log level would skip it. Use them wherever they can save CPU time.
Consider also moving your event code to a project library script function, and defining your logger variable outside any function. The one instance can safely and efficiently be shared by all of the functions in the library script.
Do you mean that my script would be in a project library, and have my scheduled event call a function in a project library script?
I am not sure I understand.
The manual says:
"To change the logging level for a Logger in a Gateway script, go to Status > Diagnostics > Logs > Click the Settings settings button icon icon."
How does the logger I setup get populated to the settings?
I named my logger like: logger = system.util.getLogger("projectNameGatewayScriptPurpose")
My string is the same.
Can you help me understand or point me to where to read to understand how the loggers are instanced and how they populate in settings?
I did not find this logger in there to set to debug.
I thought that by choosing logger.debug.... this would set the level.
Yes. Making all events delegate to project library script functions with a one-liner provides opportunities to optimize performance with share imports and long-lived variables, makes it easy to group related functionality, and places the content in the gateway filesystem as plain text for source code control friendliness. For certain kinds of gateway events, it also avoids some legacy scope gotchas. At least until v8.3 arrives.
You won't see anything there from your own loggers. Look in the main status logs page. Log messages sent at DEBUG level while the logger level was INFO were discarded, so of course there's nothing to see yet.
The "Min Level" setting is not sufficient--you also need to click the gear icon, find your logger, and set the specific logger level to DEBUG.
Let's break things down to try and make it clearer:
When you use a logger in a script, you call one of its methods that will log a message at a certain level. Here you called .debug(), so a debug message was sent to the logging engine
For each logger, the logging engine as a configured level. When it receives a message for a logger, it compares the message's level to the configured level on the logger. If the message's level is equal or above the configured minimum level, it logs it. Otherwise, it is discarded.
In your case, the logger was configured to register messages of level info or higher, so your debug message was discarded.
When displaying logs, you can filter on levels. But if the message was discarded because its level was too low when it was emitted, it is lost. It will not show up there however you configure or filter anything now.
This is why you can't find your message in the logs.
So we have several layers of configuration to take into account.
Configure your logger on the gateway page, then log a message with a level that's at least as high as the configuration, and go back to check if it's there. It should be.
