Service Virtualization

Hi,

how the events logging works on devtest server console for virtual services.

I have customized my default VSM with only the steps i needed in VSM and get rid off unused steps..

Also I have added script(groovy) step after image selection for response manipulation.. that script contains logger details so only those details gets logged into server console all time..

example script line is

_logger.error("the response is feteched {}" response);

so if see the above snap only it shows the events of what I logging in script..

1. default logging events are not shown here like it is logging for other service - I guess this is because of VSM customization , is that correct ?

2. other part is if I log it as _logger.error or warn .. those are only getting logged into console.. why if I log as _logger.info will not be shown ? is it something to do with logging.properties ?

apart from the above can you please suggest me how can I make this logging switch off and on at VS level not for entire VSE..can this be added through my same script step  ?

thanks for your time..

Did you check out the DevTest scripting guide at DevTest 8.0 - Scripting Guide - V1.1.pdf on Logging (pp. 19 ff.)? Does this work for you?

Ulrich_Vogt thanks for the response.. yes i have checked.. i have added log4j.logger.com.itko.lisa.script.logger=DEBUG to logging properties as well..

still i did not see the event details on server console > inspection view..

do I need to set log level in script also ?

if I want particular VS to log only info , can do this ?

Ulrich_Vogt

any suggestion please?

Sorry, but I am not sure, I understand all your questions.

1. First thing that I crosses my eyes is that your example script line does not seem to be correct: A comma is missing between the text output and the parameter to print. Correctly it should read: _logger.error("the response is feteched {}", response); where 'response' is an existing property in your VS. Therefore I assume that the typo prevents the log messages to show up in both the console and the log file. I recommend to use the Test button to execute the script after editing in order to avoid syntax errors.
2. I am not aware of a configuration parameter that allows to enable logging for a single VS only. In order to test your VS you may want to deploy a separate VSE for your test purposes only.
3. You set the log level of the script for both logging to the log file and to the server console by the same parameter in logging.properties. Please see the document for details. The default setting is INFO unless set differently. If you see _logger.warn() and _logger.error() output, but no output from _logger.info() calls, the setting has changed most likely to WARN.
4. _logger.error() and _logger.warn() occur as 'Step warning' messages in Server console and are highlighted with some yellow background color. The other _logger calls are diesplayed as 'Log message' with some brown/green background color.
5. If you want to raise events in the console only, but not in vse.log, please check out calls testExec.log(), testExec.warn and testExec.raiseEvent() as described in the DevTest Scripting Guide (p. 21 ff.) mentioned above.

With following setting in LISA_HOME/logging.properties

and following groovy script step added to a VS

I created following output in server console (DevTest 9.1):

Hope that helps.

Thanks Ulrich_Vogt

I am inline with what your mentioned above but still did not get through what is the issue..

my VSE server logging.properties details..

linux@DevTest803]$ cat logging.properties

# see http://logging.apache.org/log4j/docs/index.html and http://logging.apache.org/log4j/docs/manual.html

# This file is polled regularly by LISA applications at runtime so you can add new DEBUG loggers

# or change system-wide logging without restarting LISA apps.

log4j.rootCategory=INFO,A1

# For cloud runs, you probably want centralized logging so add the registry appender like this

#log4j.rootCategory=INFO,A1,registry

# and uncomment the registry appender properties at the end of this file.

# The following lines adjust the log levels of third-party libraries used by LISA so that

# they don't clutter the logs with messages unrelated to LISA.

log4j.logger.com.teamdev=WARN

log4j.logger.EventLogger=WARN

log4j.logger.org.apache=ERROR

log4j.logger.com.smardec=ERROR

log4j.logger.org.apache.http=ERROR

log4j.logger.org.apache.http.header=ERROR

log4j.logger.org.apache.http.wire=ERROR

log4j.logger.com.mchange.v2=ERROR

log4j.logger.org.hibernate=WARN

log4j.logger.org.jfree=ERROR

log4j.logger.com.jniwrapper=ERROR

log4j.logger.sun.rmi=INFO

log4j.logger.com.itko.util.ThreadDumper=INFO

# make this INFO if you want your profile events to be logged

log4j.logger.profiler=OFF

log4j.appender.A1=com.itko.util.log4j.TimedRollingFileAppender

log4j.appender.A1.File=${lisa.tmpdir}/${LISA_LOG}

log4j.appender.A1.MaxFileSize=10MB

log4j.appender.A1.MaxBackupIndex=5

log4j.appender.A1.layout=org.apache.log4j.EnhancedPatternLayout

log4j.appender.A1.layout.ConversionPattern=%d{ISO8601}{UTC}Z (%d{HH:mm}) [%t] %-5p %-30c - %m%n

# Keep a separate log for VSE transaction match/no-match events, this makes debugging much easier.

# Change INFO below to WARN for production systems, the logging is expensive and will slow down

# systems with high transaction rates. Do not simply comment out the following line; explicitly

# set the log level to OFF or WARN instead of INFO

log4j.logger.VSE=INFO, VSEAPP

# If you want to add VSE logging to other log destinations, comment out the next line

log4j.additivity.VSE=false

log4j.appender.VSEAPP=com.itko.util.log4j.TimedRollingFileAppender

log4j.appender.VSEAPP.File=${lisa.tmpdir}/vse_matches.log

log4j.appender.VSEAPP.MaxFileSize=10MB

log4j.appender.VSEAPP.MaxBackupIndex=20

log4j.appender.VSEAPP.layout=org.apache.log4j.EnhancedPatternLayout

log4j.appender.VSEAPP.layout.ConversionPattern=%d{ISO8601}{UTC}Z (%d{HH:mm})[%t] %-5p - %m%n

# Keep a separate log for advisory events. This logger warns of potential configuration issues, potential

# memory leaks, etc. It is deliberately kept separate to the application log to minimize noise.

log4j.logger.ADVICE=WARN, ADVICE_APP

log4j.additivity.ADVICE=false

log4j.appender.ADVICE_APP=org.apache.log4j.RollingFileAppender

log4j.appender.ADVICE_APP.File=${lisa.tmpdir}/advice.log

log4j.appender.ADVICE_APP.MaxFileSize=10MB

log4j.appender.ADVICE_APP.MaxBackupIndex=20

log4j.appender.ADVICE_APP.layout=org.apache.log4j.EnhancedPatternLayout

log4j.appender.ADVICE_APP.layout.ConversionPattern=%d{ISO8601}{UTC}Z (%d{HH:mm}) %-5p - %m%n

# If periodic thread dumps are enabled, this is where they will be sent. Note that we log at INFO level so

# to actually get the thread dumps just change WARN in the next line to INFO, even with LISA servers and/or

# workstation running and you should get a thread dump in the named file within 30 seconds.  Search for 'threadDump'

# in lisa.properties for more info. This makes it very simple to get thread dump to debug performance issues, simply

# change WARN in the next line to INFO, wait for a minute or two, then (maybe) change it back to WARN to prevent the

# thread dumps.

#

# You can also generate a point-in-time thread dump with the LISA_HOME/bin/ServiceManager application

# e.g. ServiceManager -threadDump tcp://hostname:2014/Simulator  or use standard java tools such as jstack

#

log4j.logger.threadDumpLogger=INFO, THREAD_DUMPS

log4j.additivity.threadDumpLogger=false

log4j.appender.THREAD_DUMPS=org.apache.log4j.RollingFileAppender

log4j.appender.THREAD_DUMPS.File=${lisa.tmpdir}/threadDumps/TD_${LISA_LOG}

log4j.appender.THREAD_DUMPS.MaxFileSize=10MB

log4j.appender.THREAD_DUMPS.MaxBackupIndex=20

log4j.appender.THREAD_DUMPS.layout=org.apache.log4j.EnhancedPatternLayout

log4j.appender.THREAD_DUMPS.layout.ConversionPattern=%d{ISO8601}{UTC}Z (%d{HH:mm}) [%t] %-5p - %m%n

## Mirror our logging to the (remote) registry.

#log4j.appender.registry=com.itko.lisa.net.LoggingToRegistryAppender

#log4j.appender.registry.layout=org.apache.log4j.EnhancedPatternLayout

#log4j.appender.registry.layout.ConversionPattern=%d{ISO8601}{UTC}Z [%t] %-5p - %m%n

#script logging

log4j.logger.com.itko.lisa.script.logger=INFO

I have added the above line to logging.properties as well.

script added in VSM is

String TrafficCheck = "log test";

_logger.info("test Info enable {}", TrafficCheck);

_logger.debug("test debug enable {}", TrafficCheck);

_logger.error("test error enable {}", TrafficCheck);

_logger.warn("test warn enable {}", TrafficCheck);

and above is the snapshot of it printed for errors and warning.

thanks for your time

Looks better now from my point of view. Your _logger calls now show up in the event list, and the content of the property is also resolved and displayed. Please correct me if I am mistaken, but the only remaining issue now appears to be that your _logger.info() call does not show up, although you have configured log4j.logger.com.itko.lisa.script.logger=INFO. In your other thread you mentioned that you use DevTest 8.3. Can you please provide further details on OS + Version and the DevTest deployment architecture you are running (distributed DevTest, separate VSE, etc.). I could not reproduce the problem on a standalone single DevTest server installation on Windows 7. All seems to work as I expect in this environment. 

_logger calls worked me initially as well.. I could able to print error and warn from beginning but not for info or debug.

when comes to devtest deployment infrastructure we use

devtest 8.3

server is configure on RHEL 6.7

and DevTest Workstation client is connected from win 2008 R2 - service pack1

Trying to reproduce your problem, I tested with DevTest 8.3 server (i.e. VSE) on RHEL 7, workstation on Windows 7, and it worked as expected. Depending on whether I configured log4j.logger.com.itko.lisa.script.logger in logging.properties on the DevTest(VSE) server to INFO or to WARN, _logger.info() output was visible or not visible in the event list. If you are sure that you have configured log4j.logger.com.itko.lisa.script.logger on your DevTest(VSE) server correctly, I recommend to open a ticket with support.

Ok . I will check with support team then...

other question I have got now is

If I set log4j.logger.com.itko.lisa.script.logger = Info   in logging.properties and set log level via script to

Logger log = Logger.getInstance(getClass());

log.level = Level.WARN;

can I control the logging events on server console? The reason is always I don't want to log in info mode.. when required i will log the info and I should be able to change that via script in VSM rather than vse logging.properties...

so will above code set/override the log level set in properties file.