The stats from LuaFunctionCallTracker are perhaps a bit too deep and integrated into the global namespace of stats messages. For example:
enwiki.wikibase.client.scribunto.wikibase.getEntityStatements.cache_miss:100|c enwiki.wikibase.client.scribunto.wikibase.getEntityStatements.call:100|c wikipedia.wikibase.client.scribunto.wikibase.getEntity.call:100|c wikipedia.wikibase.client.scribunto.wikibase.getEntityStatements.call:100|c
Compared to:
resourceloader_build.all:0.12707710266113|ms resourceloader_build.user_options:0.12707710266113|ms wanobjectcache.resourceloader_titleinfo.hit.volatile:0.41294097900391|ms wanobjectcache.filerepo_file.hit.good:0.50878524780273|ms
In particular:
- The fragments (sitegroup, wikiid) are top-level metrics whereas these should go to the end to avoid conflicts with other metrics.
- There is no containing metric for LuaFunctionCallTracker which makes these difficult to discover and organize.
Source code:
- Wikibase: LuaFunctionCallTracker.php
- Wikibase: mw.wikibase.lua (call example)
I suggest the following metric pattern instead:
wikibase_client_lua_tracker_by_wiki . <key> . <wiki> wikibase_client_lua_tracker_by_sitegroup . <key> . <sitegroup>
Where key would be a single segment, eg. dots converted to underscores using strtr( $key, '.', '_' ) . The Grafana dashboard can continue to query and plot multiple of these using wildcards, which are supported on segments as well. We can even copy over the existing data if preferred, using ad-hoc scripting on the Graphite which I can help with (and we've done this few times before).
This is also in preparation for Prometheus, to make the metric ready for the conversion. From a 5 minute capture in production, this was the only metric source I found that was not grouping its metrics or that was using many more subsegments than seem to logically expected from the underlyng source code.