I am looking at replacing our existing performance test suite with Gatling and have successfully migrated most of our test scripts over, the only hurdle now is the timestamp format in simulation.log.
At present the timestamp is in epoch which while makes for easy elapsed calculations, is not supported by our standard reporting tool used to provide metrics for the runs.
Is there any way I can provide a custom format to Gatling (none source) to represent the date in something workable?
Thanks.
You could write a perl script to convert the simulation log from the default format to the desired format. Should take you only a few minutes if you are fluent in Perl. Or you could do it in ruby, or node.js, or who knows, you might even be able to coax bash into doing it for you…
There’s no built in feature for this. And honestly, a timestamp is the most universal format and can be post processed like John said.
While post processing is possible, we process the logs in real time. This means post processing is not viable. In order to run the file through conversion, I would have to wait until the end just to see any problems. OK for reporting but not monitoring. As I said we have an existing reporting tool that does not deal well with epoch.
Epoch is a Unix concept and means nothing to Windows and many applications, it is far from a universal format, datetime is a universal format.
We have an existing monitoring and reporting mechanism that does not deal in epoch and unless we can read the logs in real time, it really makes that tool useless for it’s function.
All other performance tools provide the ability to use a defined timestamp, what is even more frustrating is in logback.xml you can specify a timestamp for the console log just not the simulation log.
%d{HH:mm:ss.SSS} [%-5level] %logger{15} - %msg%n%rEx
false
Is there not a similar capability for simulation.log? If so, what is the correct appender name and class?
I need to do this because of other system requirements not because I do not know how to process epoch.
Hi Stuart,
simulation.log writing is not handled by Logback, sorry.
If you really can’t process epoch, your best option is to fork https://github.com/gatling/gatling/blob/2.1.X/gatling-core/src/main/scala/io/gatling/core/result/writer/FileDataWriter.scala, put in a JAR, and get that JAR to Gatling’s classpath.
You can then in gatling.conf specify that you want to use that DataWriter by passing it fully qualified class name.
But know that this completely breaks Gatling own reporting engine. Gatling simply expects timestamps there.
Cheers,
Pierre
Sounds like something to try. Not sure what I would lose out of Gatling though as as the only reporting I see in the native tool is the console log which does not provide times.
Gatling is being requested by the developers for easy scripting (scala) compared to our existing tool which has much better reporting and a functioning UI, however this can be overlooked if the process can be more automated. But if reporting using existing methods is a no go, then so is Gatling. It is easier for me to change Gatling than corporate IT and security policy so I am still disappointed to see this restriction exists in such a tool.
Sounds like something to try. Not sure what I would lose out of Gatling
though as as the only reporting I see in the native tool is the console log
which does not provide times.
Well, you'll lose HTML reports with that modification, or you'll need to
fork it to handle datetimes.
Gatling is being requested by the developers for easy scripting (scala)
compared to our existing tool which has much better reporting and a
functioning UI, however this can be overlooked if the process can be more
automated. But if reporting using existing methods is a no go, then so is
Gatling. It is easier for me to change Gatling than corporate IT and
security policy so I am still disappointed to see this restriction exists
in such a tool.
You have to understand that Gatling has been maintained by 2 people
(Stéphane and me) for the last 3 years, mostly in our spare time.
Also, simulation.log is currently an implementation detail, since it's
meant to be read by Gatling's HTML reporting engine alone.
We do the best we can, but we cannot handle every single use case users may
need, this one being requested by you alone for as long as I can remember.
If you can contribute a solution to allow alternative date formats in
simulation.log, we'll gladly have a look at it.
Cheers,
Pierre
Willing to pitch in if possible as long as these kind of requirements can be addressed rather than argued about.