I’ve recently enabled Gitlab metric tracking in InfluxDB with Grafana and the Gitlab-provided reports. This is really nice, but I’m having trouble determine the root cause of one frequently-occurring event. On the ‘Event’ view ‘build_not_found’ is getting logged about 2400 times per hour but I have no idea what this is. Perhaps it is the web api ‘jobs’ or ‘builds’? How can I track this down if we have hundreds of projects?
Thanks,
-Rob
According to Jose from Gitlab support, "Runners poll the GitLab application server for pending builds when they find one the event build_found is added but when there isn’t any pending builds then a
build_not_found event is triggered. You can find a better context at https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/api/runner.rb#L100."
Also asked him about, “On the Daily Overview page, how do I debug performance of slow (red) transactions like ‘git-receive-pack’? According to the reports, our average time is 45s for this transaction with 95th percentile over 2.5 minutes! Unfortunately, I have no idea how to improve this. I see one git-receive-pack call that took 2.17 minutes from just over an hour ago. The transaction was started from a merge request, so local to the gitlab server. According to the breakdown, GitAccess#check took the most time at 10ms, everything else was sub-5ms. The git_receive_pack transactions immediately before and after this one took less than 1s each (on different repos).” His reply, "This event is git sending a package such as a git push. This would make it much more difficult to optimize as it depends on the code being pushed by a user or in the case of your email update it would be the size of the MR but it does explain the variety in timing for each of these events. More context at https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/controllers/projects/git_http_controller.rb#L24."