I have few debugs with info in the java class configured in Idempiere plugin. But after execution of that class on that server, I am getting warning log, but not info log, inside idempiere logs.
I tried google but couldn't find anything related to it. Could some one help in "How to change logger level (warning, info, debug) for Idempiere logs"
You could use the iDempiere Monitor
http://127.0.0.0:8080/idempiereMonitor
You can access with your System User credentials. Then go to the line:
Trace Log Level
And select one of these:
OFF
SEVERE
WARNING
INFO
CONFIG
FINE
FINER
FINEST
ALL
This will regenerate the last log file and build the new ones with this parameter.
Related
I want to generate trace for performance log but I don't find where enable the trace.
Checking this documentation page https://help.hcltechsw.com/commerce/9.1.0/admin/refs/rlsperflog_dup.html it's mention that we need to use the following string: com.ibm.commerce.performance=fine.
In Logging and Tracing settings we don't have this class path to enable finest log.
I tried to perform some run command in ts-app like:
run set-dynamic-trace-specification com.ibm.commerce.performance=fine
run set-server-property com.ibm.commerce.performance fine
Keep not seeing the trace file in: WAS_profiledir/logs/performanceTrace.json.
Some tip ?
Best Regards
Document found:
https://help.hcltechsw.com/commerce/9.1.0/admin/tasks/tlslogging_txn.html
Basically, it's activated by PMT logs.
when I want to see the logs of a datastage job it gave me only the logs with the info level logs
I want to define a new level to see the logs please
Any help
Thanks in advance
Datastage knows three level of log entries - as you mentioned already:
Info
Warning
Error
They will be shown if they appear - so you do not have to do anything for it (as your question asumes)
You can "demote" a warning to an informational message or promote one i.e. from an information to a warning.
EDIT:
To do this you can define so called Messgae Handlers
his can be done on Job level or Project level (or Runtime handler)
In DataStage Director you eed to follow these steps: Menu - Tools - Message Handler Management
There are lots of descriptions out there - just search for DataStage Message Handler
The documentation at https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/rwlp_logging.html lists the following config snippet for configuring logs to go to the console in JSON format (a useful configuration when Liberty is running inside a Linux container like in a kubernetes pod):
com.ibm.ws.logging.console.format=json
com.ibm.ws.logging.console.log.level=info
com.ibm.ws.logging.console.source=message,trace,accessLog,ffdc,audit
However, I noticed that when I increase the log level inside my server.xml (say to FINER to enable tracing), the trace messages are also emitted to the console. I assume its because the source is configured to pick up messages from the trace, but what I don't understand is whether/how that interacts with the consoleLogLevel setting.
Why specify a com.ibm.ws.logging.console.log.level if its just going to include everything from message and trace log files anyway?
The com.ibm.ws.logging.console.source bootstrap property controls which sources the console handler will subscribe to. This means, if there is any trace (typically levels FINE / FINER / FINEST) enabled by the traceSpecification, that content will be consumed by the console handler and output as JSON to console.
So, setting...
com.ibm.ws.logging.console.source=message,trace,accessLog,ffdc,audit
means that the console handler will receive any log, trace, access log, ffdc, and audit events that are generated by the system.
If com.ibm.ws.logging.console.log.level is specified, it controls which log events are filtered out by the console handler. By setting com.ibm.ws.logging.console.log.level=WARNING you won't see INFO level messages in the console output unless you also explicitly set consoleLogLevel=info in the server.xml.
Note that logging settings explicitly set in the <logging> element in the server.xml (which is processed when the config manager is ready) override any configuration set using environment variables or the bootstrap.properties file (which are processed very early in the server startup process). In practice this means you should use bootstrap.properties or environment variables for logging configuration, and just use the logging element in the server.xml file to specify things you want to override while the server is running.
I have a clarion application running in Win Server 2016 talking to a sybase DB, over the past few weeks we find the application gets frozen for different users at a given time. However the user can leave the session as such and start a new one and that works good. The users are known to use multiple instances of the same application in one remote server or on multiple servers. Having said that, I wanted to get more information on the freezeup and looked through the application event logs in the system where I see explorer.exe crashes but these correlate to the time of occurrence of the issue at certain times but not always, checked the DB transaction logs from Sybase and I do not find any crashes, errors or stuck connections. Having said that, since I have exhausted all possible options I am reaching out to you guys to know if there are any other places that i can look for to gather more information.
I would love to know of any application / tools that we could use to gather logs of a frozen clarion application on windows. Also good to know if anyone has faced such a situation and where and how have you guys looked into the issue.
Thanks in advance for your help in this.
Clarion's runtime library and database drivers expect a persistent connection. Disconnects that are normal with remote ODBC can cause a problem (including app hangs) unless you test for them at the ABC file mgr level and reconnect, or use similar steps to test and recover.
If you're looking for specifics about what's going on between the driver and the SQL backend, I suggest using Clarion's database driver trace facilities. From the help topic: "Logging Driver I/O for debugging":
To view the trace details in debugview, name the target trace file "DEBUG:"
Logging opens the named logfile for exclusive access. If the file exists, the new log data is appended to the file.
On Demand Logging
For on-demand logging you can use property syntax within your program to conditionally turn various levels of logging on and off. The logging is effective for the target table and any view for which the target table is the primary table.
file{PROP:Profile}=Pathname !Turns Clarion I/O logging on
file{PROP:Profile}="DEBUG:" !Turns Clarion I/O logging on and
!sends output via OutputDebugString()
!(viewable via debugview, etc)
file{PROP:Profile}='' !Turns Clarion I/O logging off
PathName = file{PROP:Profile} !Queries the name of the log file
file{PROP:Log}=string !Writes the string to the log file
file{PROP:Log}="DEBUG:" !Writes the string to the log file
file{PROP:Details}=1 !Turns Record Buffer logging on
fFile{PROP:Details}=0 !Turns Record Buffer logging off
where Pathname is the full pathname or the filename of the log file to create. If you do not specify a path, the driver writes the log file to the current directory.
You can also accomplish on demand logging with a SEND() command and the LOGFILE driver string. See LOGFILE for more information.
Example I use frequently, which was based on the help above:
SYSTEM{PROP:DriverTracing} = '1'
CRMNotes{PROP:TraceFile} = 'DEBUG:'
CRMNotes{PROP:Details}=1
CRMNotes{PROP:Profile}= 'DEBUG:'
CRMNotes{PROP:LogSQL} = 1
Can anyone explain how to enable debug logging in Eucalyptus 4.0.0 properly?
I set LOGLEVEL="DEBUG" in /etc/eucalyptus/eucalyptus.conf
Then I restarted everything but logs still only show INFO, WARN and ERROR.
You're on the right track. Setting LOGLEVEL="DEBUG" in eucalyptus.conf is valid for C-based components, and Java-based components which have not yet fully bootstrapped. When you set DEBUG in eucalyptus.conf, you'll need to restart the affected components on just that machine. So for example, on the NC, you would need to issue a restart, eg, "service eucalyptus-nc restart" in order to pick up the new value.
For the Java components, in particular after they've bootstrapped, you set the cloud-wide PROPERTY thusly:
euca-modify-property -p cloud.euca_log_level=DEBUG
and the output will tell you what the property was, and what is has become, if done correctly.
For example:
# euca-modify-property -p cloud.euca_log_level=DEBUG
PROPERTY cloud.euca_log_level DEBUG was INFO
Once you've set that, you're good to go. No need to restart any of the Java components, anywhere in the cloud.