Hi Thomas, On Friday, December 23, 2016 at 3:11:53 AM UTC-8, Thomas Müller wrote: > > Hi Jeremy > > Am Mittwoch, 21. Dezember 2016 22:31:34 UTC+1 schrieb Jeremy Barlow: >> >> I don't think there's any way to register the TeeFilter without making >> changes to the library, trapperkeeper-webserver-jetty9 >> <https://github.com/puppetlabs/trapperkeeper-webserver-jetty9>, that >> Puppet Server uses to integrate the Jetty web server. If you just wanted to >> get the response body but didn't need the full request body, you could turn >> on "trace" level logging for the "puppetlabs.ring-middleware.core" >> namespace in the */etc/puppetlabs/puppetserver/logback.xml *file: >> >> <logger name="puppetlabs.ring-middleware.core" level="trace"/> >> >> With that in place you'd see the response body appear in the >> */etc/puppetlabs/puppetserver/puppetserver.log* file, like this: >> >> 2016-12-21 13:21:08,327 TRACE [qtp993744537-38] [p.r.core] Computed >> response: {:status 200, :headers {Content-Type text/pson, X-Puppet- >> Version 4.8.1}, :body {"tags":["settings"... >> >> I think we could add some functionality to the >> trapperkeeper-webserver-jetty9 library to enable integration with the >> logback TeeFilter. If you are interested in pursuing this further, would >> you mind submitting a request for this in a SERVER or TK project ticket at >> https://tickets.puppetlabs.com? >> > > I would have been interested in the POST params the an agents catalog > request. > > I've found https://github.com/puppetlabs/gatling-puppet-load-test which > looks like it could help me. It would allow to run a more realistic test > than i thought about. But looks also like learning gatling/scala and co. > > - Thomas >
Ah, Gatling is a great tool to use not only for capturing request content but also for replaying the captured content under arbitrarily simulated load to a target server. As evidenced from what is in the gatling-puppet-load-test repo that you found, we use Gatling pretty heavily in our own internal load testing and have been very pleased with it. If you want to get into parameterizing the captured payload, e.g., to introduce some variation in playback of a captured recording to put more stress on the server, it does come with a bit of a learning curve with Scala, etc. as you mentioned. If you were interested in just doing a one-off capture of an agent run against a master so that you can grab the POST params in an agent’s catalog request, you could also try a puppet agent run with the --http_debug flag. For example, if you were to run the following… puppet agent -t --http_debug … then you should see something like the following in the console output: <- "POST /puppet/v3/catalog/localhost?environment=production HTTP/1.1\r\nAccept: pson, dot, binary\r\nX-Puppet-Version: 4.8.1\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nUser-Agent: Ruby\r\nHost: localhost:8140\r\nContent-Length: 20809\r\nContent-Type: application/x-www-form-urlencoded\r\n\r\n" <- "environment=production&facts_format=pson&facts=%257B%2522name%2522%253A%2522localhost%2522... I don't remember exactly what release of Puppet that the --http_debug flag was released in but if your agent versions are relatively recent, this should be available for you. --- Jeremy -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/f1f9eb02-2761-4818-9dae-ff874f03ac7f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
