New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 667545 link

Starred by 1 user

Issue metadata

Status: Archived
Owner: ----
Closed: Aug 20
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Alert on chromium source commit rate being too low

Project Member Reported by martiniss@chromium.org, Nov 22 2016

Issue description

We should scope this to only be working hours MTV, since we aren't really supporting other times. Or maybe only weekdays, since that's when troopers are on call.

I don't think we have a graph for this right now, but we could get one fairly easily I think, right?

dsansome@, is this a good idea at all? I was thinking we could do this to have another way to detect if CQ is down, if CQ gets confused or something. Maybe redundancy here is not useful.
 
Cc: benhenry@chromium.org
Owner: dsansome@chromium.org
Status: Assigned (was: Available)
Assigning to dave to get your thoughts.
We have metrics for CQ's commit rate (http://shortn/_NnXrmURCWX) but that won't include people bypassing CQ and landing CLs directly.

I don't think the base rate is high enough for you to get a meaningful signal out of the noise.

What's the context here - what are you trying to detect?

Comment 4 by benhenry@google.com, Nov 23 2016

Labels: cit-pm-6

Comment 5 by benhenry@google.com, Nov 23 2016

Owner: martiniss@chromium.org
Assigning back to Stephen as Dave shared his thoughts.
Oh right, the context is https://docs.google.com/document/d/1norVOQ0vMp5dW7PE0m0gKlu2uwSZ_htUYQ7oamsoY0s/edit# of course.

I'd say the failed/successful commit ratio would make a better metric.  You could threshold it on the total queue length so it doesn't fire when volume is low.
So, I wanted to have two separate ways to track success. I don't know how often CQ monitoring would fail, I was just thinking that we could have two redundant things.

So, I agree the failed successful commit ratio is good to track, but we should also track commit rate. But if no one else thinks it's worth tracking, we can close this.
We do have this alert: https://cs.corp.google.com/piper///depot/google3/configs/monitoring/chrome_infra/buildbot_alerts.py?q=buildbot_alerts&dr=C&l=257 

It might be worth checking to see if it's threshold is effective.
Owner: ----
Status: Available (was: Assigned)
I haven't worked on this in a while.

Should we do this?

Katie, you did something similar to this, right? Did we make an alert for CQ commit failure rate?

Comment 10 by efoo@chromium.org, Mar 29 2017

Components: -Infra>Git -Infra>Monitoring Infra>CQ
Labels: Ops-AddMonitoring
Removing Infra>Monitoring since this is a CQ related alert modification. Please reserve Infra>Monitoring for monitoring (ts_mon and event_mon) bugs. Added Ops-AddMonitoring label to track monitoring related tasks.
Components: -Infra>CQ Infra>Client>Chrome
Project Member

Comment 12 by sheriffbot@chromium.org, Aug 20

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: -dsansome@chromium.org
Status: Archived (was: Untriaged)
This is a very old bug for a postmortem that is no longer relevant (CQ no longer needs a local checkout). On top of all, IMHO alerting on low commit rate may be suboptimal (e.g. it might trigger on holidays or on a valid tree closure). I think it's better to have a proper CQ service monitoring, which Foundation most likely has now.

Sign in to add a comment