----- Original Message ----- > From: "Romain F." <romain.fi...@gmail.com> > To: "puppet-dev" <puppet-dev@googlegroups.com> > Sent: Friday, May 22, 2015 2:17:47 PM > Subject: Re: [Puppet-dev] Adding metrics in agent report - PUP-4634
> Le vendredi 22 mai 2015 14:53:10 UTC+2, R.I. Pienaar a écrit : >> >> these would be good to add to both last_run_summary.yaml and the reports >> indeed, >> I mentioned this in the ticket but the report already contains a wealth of >> perf >> data, I have a report parser you can use on the CLI that produce output >> like this: >> >> https://github.com/ripienaar/puppet-reportprint/blob/master/SAMPLE.txt >> >> So already there you have config retrieval for example, adding more >> metrics around >> the saving and re-loading of the catalog would be handy. As well as >> firming up >> the docs around these and explain exactly what they are - this might exist >> now but >> last time I checked it didnt and it was a bit of guess work what they all >> do and >> mean esp some in last_run_summary.yaml. >> >> > It sounds like it shows metrics of the catalog application, not really > about catalog manipulation, facter or Indirection caching. And those steps > can take a while. > This is what we wanted to monitor originally.\ yes it's not complete at the moment, I am just saying more in the same way would be good >> > Notice: Send report in 11.17 seconds >> >> obv this could not be in the report but be handy in last_run_summary.yaml >> >> It would be ideal if like the existing agent perf data this is always >> collected >> and always stored in reports but optionally shown to the console. >> >> > Adding a bunch of report.add_times(:step_to_report, thinmark > {block_of_something}) would do the job right ? > > >> I can't right now think of specific additions but whoever implements it >> should just >> go through every major life cycle event and make sure its reported. One >> thing that >> might be handy is some details around the number of HTTP requests that are >> being made >> to measure and observe the impact of things like the HTTP connection pool. >> > > +1 > Too much handshakes can put heavy pressure on masters, this would implement > a way to monitor this. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email > to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/d0283a1c-6681-4475-a644-caba3f61542c%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/2125104489.48180.1432300805899.JavaMail.zimbra%40devco.net. For more options, visit https://groups.google.com/d/optout.
