Change Details

We have wired up client side errors to EventLogging to give us an insight into how many client side errors we have in our code. We would like to turn this on to measure progress and code quality in our refactor process. We use the schema https://meta.wikimedia.org/wiki/Schema:WebClientError = Acceptance criteria [] Increase the sampling rate of MinervaErrorLogSamplingRate from 0 to 1. [] Given we have no idea about how many errors we expect to see here, we should aim to do this over multiple deploys, starting with something extremely small e.g. 0.05 = Sign off steps [] Rate of events should not exceed ~100 / sec or less at any given time. If it does roll back. It if gets close, stop increasing the value so we can talk to analytics.

We have wired up client side errors to EventLogging to give us an insight into how many client side errors we have in our code. We would like to turn this on to measure progress and code quality in our refactor process. We use the schema https://meta.wikimedia.org/wiki/Schema:WebClientError = Acceptance criteria [] Increase the sampling rate of MinervaErrorLogSamplingRate from 0 to 1 on the beta cluster. This will help us identify bugs before they hit production. Monitoring those is blocked on T204088 [] Make sure it's not turned on in production! = Sign off steps [] In the unlikely event that rate of events on the beta cluster should not exceed ~100 / sec or less at any given time. If it does roll back. It if gets close, stop increasing the value so we can talk to analytics. [] Setup a dashboard and add a monitoring step to https://www.mediawiki.org/wiki/Reading/Web/Chores

We have wired up client side errors to EventLogging to give us an insight into how many client side errors we have in our code. We would like to turn this on to measure progress and code quality in our refactor process. We use the schema https://meta.wikimedia.org/wiki/Schema:WebClientError = Acceptance criteria [] Increase the sampling rate of MinervaErrorLogSamplingRate from 0 to 1.1 on the beta cluster. This will help us identify bugs before they hit production. Monitoring those is blocked on T204088 [] Given we have no idea about how many errors we expect to see here, we should aim to do this over multiple deploys, starting with something extremely small e.g. 0.05Make sure it's not turned on in production! = Sign off steps [] RIn the unlikely event that rate of eventsnts on the beta cluster should not exceed ~100 / sec or less at any given time. If it does roll back. It if gets close, stop increasing the value so we can talk to analytics. [] Setup a dashboard and add a monitoring step to https://www.mediawiki.org/wiki/Reading/Web/Chores