Closed Bug 956230 Opened 11 years ago Closed 11 years ago

improve instrumentation of bugzilla's internals

Categories

(bugzilla.mozilla.org :: General, defect, P1)

Production
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: glob, Assigned: glob)

References

Details

(Keywords: bmo-goal)

Attachments

(3 files, 3 obsolete files)

we need to improve the instrumentation of bugzilla's internals with a mind to new-relic integration once their perl sdk is available. bugzilla instrumentation - determine instrumentation points - provide an abstraction class so we can swap different reporting systems in/out - start_web_transaction and end_web_transaction - call at the start and end of the script - simplest option is in mod_perl.pl - for mod_cgi support BEGIN and END blocks in Bugzilla.pm - name_web_transaction - default to cgi's filename (eg. show_bug) - break down each api call (by transport and method) from webservice base class ? identify bzapi calls (from ua) - start_datastore_statement and end_datastore_statement - wrap each dbi call which hits the database - simplest option is to add wrapper methods to Bugzilla::DBI for - do - selectrow_hashref - selectall_arrayref - ... - prepare + execute requires more work - subclass DBI::st - prepare --> grab sql - execute
Priority: -- → P1
Attached file sample wip data (obsolete) —
here's a sample of the data i've gathered after hooking up templates and database calls (show_bug for id 35).
Status: NEW → ASSIGNED
Attached patch 956230_1.patch (obsolete) — Splinter Review
here's an "all dressed up with nowhere to go" patch. this removes the current instrumentation class, replacing it with collectors for template-toolkit and mysql. the data collection can be considered complete at this point. i have two mock-up reporters, one which dumps to STDERR and another which dumps into a data/metrics.json file. once we've figured out where to send this data so it can be reported upon, i'll add a reporter for that.
Attachment #8370776 - Flags: feedback?(dkl)
Attached file sample json data
Attachment #8362847 - Attachment is obsolete: true
Attached patch 956230_2.patch (obsolete) — Splinter Review
looks like elasticsearch is a go for receiving this data, with some modifications to the json structure. here's an updated patch which includes the start of an ES reporter, which flattens the json structure after building a path array for each node.
Attachment #8370776 - Attachment is obsolete: true
Attachment #8370776 - Flags: feedback?(dkl)
Attachment #8371300 - Flags: feedback?(dkl)
Attached file sample flat json data
Attachment #8371301 - Attachment description: sample flag json data → sample flat json data
Attached patch 956230_3.patchSplinter Review
new since the last revision: - configurable via parameters - reports on memcached hit rates - reporting restricted to show_bug.cgi and list of specified users - log stacktrace instead of raw sql for database queries - add this_duration to elasticsearch json - removes confidential/personal data - actually sends to elasticsearch
Attachment #8371300 - Attachment is obsolete: true
Attachment #8371300 - Flags: feedback?(dkl)
Attachment #8377551 - Flags: review?(dkl)
Comment on attachment 8377551 [details] [diff] [review] 956230_3.patch Review of attachment 8377551 [details] [diff] [review]: ----------------------------------------------------------------- All very nice. Code looks good and also works properly when using the STDERR reporter. I did not test the ElasticSearch submission pieces but look good from inspection. Few non-critical comments included. r=dkl ::: Bugzilla.pm @@ +131,5 @@ > > my $script = basename($0); > > + # BMO - init metrics collection if required > + if (i_am_cgi() && $script eq 'show_bug.cgi') { Should we also be looking for process_bug.cgi, page.cgi, xmlrpc.cgi, jsonrpc.cgi, and rest.cgi as well as you have altered those to include metrics data? Maybe add a METRICS_SCRIPT_WHITELIST constant to keep the list of scripts to enable for. I realize you want to just do show_bug.cgi I would personally like to see metrics on the API services. ::: Bugzilla/Metrics/Reporter/STDERR.pm @@ +61,5 @@ > + $timer->{start_time} = $timer->{start_time} - $start_time; > + delete $timer->{end_time}; > + > + # show times in ms instead of fractional seconds > + foreach my $field (qw( start_time duration duration_this )) { Use of uninitialized value in multiplication (*) at /home/bugzilla/devel/htdocs/956230/Bugzilla/Metrics/Reporter/STDERR.pm line 66 This is happening when backgrounding Reporter/STDERR.pm when accessing some timing data that does not have a duration_this key. From looking at the code duration_this is not set for memcache timing which I have enabled. ::: metrics.pl @@ +9,5 @@ > + > +# > +# report errors to sentry > +# expects a filename with a Data::Dumper serialised parameters > +# called by Bugzilla::Sentry remove this section ::: template/en/default/admin/params/advanced.html.tmpl @@ +90,5 @@ > + metrics_enabled => > + "Collect metrics for reporting to ElasticSearch", > + metrics_user_ids => > + "Comma separated list of user_id's which trigger data collection and reporting." > + _ " eg <code>3881,5038,5898,13647,20209,251051,373476,409787</code>.", nit: <kbd></kbd> and others as it is not actually code.
Attachment #8377551 - Flags: review?(dkl) → review+
(In reply to David Lawrence [:dkl] from comment #7) > Should we also be looking for process_bug.cgi, page.cgi, xmlrpc.cgi, > jsonrpc.cgi, and rest.cgi as well as you have altered those to include > metrics data? right now we're only interested in show_bug for specific users. the other files were altered to make it easier to add those endpoints at a later date (this filtering code should be the only place we need to touch). > Maybe add a METRICS_SCRIPT_WHITELIST constant to keep the list of scripts to > enable for. I realize you want to just do show_bug.cgi I would personally > like to see metrics on the API services. as do i! we can easily generate a volume of data that will swamp elasticsearch, so we'll probably require more complicated filtering rules than just the script name when we enable that.
Committing to: bzr+ssh://bjones%40mozilla.com@bzr.mozilla.org/bmo/4.2/ modified Bugzilla.pm added metrics.pl modified page.cgi modified process_bug.cgi modified sentry.pl modified show_bug.cgi modified Bugzilla/DB.pm missing Bugzilla/Instrument.pm deleted Bugzilla/Instrument.pm added Bugzilla/Metrics modified Bugzilla/Template.pm modified Bugzilla/Config/Advanced.pm modified Bugzilla/Install/Filesystem.pm modified Bugzilla/Install/Requirements.pm added Bugzilla/Metrics/Collector.pm added Bugzilla/Metrics/Memcached.pm added Bugzilla/Metrics/Mysql.pm added Bugzilla/Metrics/Reporter added Bugzilla/Metrics/Reporter.pm added Bugzilla/Metrics/Template added Bugzilla/Metrics/Template.pm added Bugzilla/Metrics/Reporter/ElasticSearch.pm added Bugzilla/Metrics/Reporter/STDERR.pm added Bugzilla/Metrics/Template/Context.pm modified Bugzilla/WebService/Server.pm modified template/en/default/admin/params/advanced.html.tmpl Committed revision 9263.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Depends on: 980188
unfortunately i overlooked the new module requirement for elasticsearch (bug 980188). as there isn't a standard rpm for this module, it wasn't able to get installed in time for today's push. this instrumentation code has been pushed to production, however i'll leave it disabled until the module has been installed and tested on our staging environment.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: