1
============================
2
OOPS Repository design notes
3
============================
8
OOPS Repository is intended to scale up to 1 million OOPS reports a day (and
9
possibly further). This is based on a 1% soft failre rate needing collection.
11
It needs to supports an extensible model, aggregation, automated garbage
12
collection, emitting messages for trend and fault detection systems and finally
13
realtime insertion and display of individual OOPSes.
21
Cassandra was chosen because of the drop-dead simple method for increasing
22
write and read bandwidth available in the system.
27
OOPS : Individual OOPSes are in this column family.
28
row key : the oops ID supplied by the inserter
30
'date': LONG Used to build a secondary index for garbage collection.
31
optional known columns (all strings):
32
'bug.*': Maps to bugs.
33
'HTTP.*': HTTP variables. e.g. HTTP.method is PUT/POST/GET etc.
34
'REQUEST.*': arbitrary request variables.
35
'context': The context for the fault report. E.g. a page template,
36
particular API call - that sort of thing.
37
'exception': The exception causing the fault.
38
'URL': The URL of the request.
39
'username': the username.
40
'userid': A database id for the user.
41
'branch': Source code branch for the server
42
'revision': Revision of the server
43
'duration': The duration of the request
44
'timeline': A json sequence describing the actions taken during the
45
request. This may be split out to a separate CF in future. For now
46
an example would be [{"start":"0", "length": "34", "database": "main",
47
"statment":"SELECT ...", "callstack": "...."}, {....} ]
added
removed
DESIGN.txt
