You are browsing a read-only backup copy of Wikitech. The live site can be found at


From Wikitech-static
< Analytics‎ | Systems‎ | EventLogging
Revision as of 04:25, 12 September 2018 by imported>Nuria (→‎Eventlogging is not Well suited to do error logging)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Eventlogging is not Well suited to do error logging

There had been many talks in the past (and present, see: task T203814) about using eventlogging to do client side errorlogging. While eventlogging is well suited to handle events and ingesting client side traces shares similarities with ingesting events, Eventlogging is really not suited to be a client side error logging for several reasons:

1) Eventlogging is designed around handling data that validates to a schema, while error messages might be json there is really no value on validating them against a schema. The error happened and it should be ingested by backend regardless of whether it validates, it is not "curated data".

2) Any system we use to handle error logging should be tier-1, EventLogging is tier-2.

3) Any system to handle errors needs to be able to group by stacktraces and be good at handling free text, EventLogging is not for reasons in 1). It is made to deal with data that abides to a schema. It does not group by stack trace and an error that appears for a million pageviews in 1 hour will appear in the database a million times rather than appearing once with a count of 1 million. Because, again, EventLogging is made for distinct events, and errors are not distinct events. All users of Chrome 68 might be running on the same error for the same reasons. This is a big deal and why a solution customized to the error space is needed. See 4).

4) There is no need to reinvent the wheel, [Sentry] is a well-stablished software to do this very thing: client side error logging. See attempts to install Sentry at the foundation: