1305616 - Stop storing memory_report in Elasticsearch

Status: RESOLVED FIXED

(Socorro :: Backend, task)

Description

[[DEACTIVATED] Adrian Gaudebert]

We are currently storing the memory_report key of the processed crash in our Elasticsearch database, but we never use in our search system, and will never use it as it is now, because its current form makes it basically unsearchable. 

We should thus stop storing it in Elasticsearch, and gain a considerable amount of storage space over time. 

To support this, here's a description of the size of 100 crash reports, downloaded from prod (sizes in mega bytes):

count    100.000000
mean       3.471716
std        2.478142
min        0.000004
25%        2.033601
50%        2.992229
75%        4.353797
max       16.534454

So on average, a memory_report key takes about 3MB. And according to [0], there have been 105,486 crash reports with a memory_report in the last 7 days. That's definitely not negligible. 

[0] https://crash-stats.mozilla.com/search/?contains_memory_report=%21__null__#crash-reports

Comment 1

[Peter Bengtsson [:peterbe]]

According to https://crash-stats.mozilla.com/search/?product=Firefox&_sort=-date&_facets=signature&_facets=contains_memory_report&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-contains_memory_report about 8% of crashes have a memory report (assuming that when ContainsMemoryReport=1).

Comment 2

[[DEACTIVATED] Adrian Gaudebert]

Attachment: Link to Github pull-request: https://github.com/mozilla/socorro/pull/3491

Comment 3

[[github robot]]

Commit pushed to master at https://github.com/mozilla/socorro

https://github.com/mozilla/socorro/commit/4808425f826b0e04546143c45a1dd617432e8482
Fixes bug 1305616 - Stop storing memory_report into Elasticsearch. (#3491)

Comment 4

[[DEACTIVATED] Adrian Gaudebert]

This is actually not resolved. A configuration change is needed, and whatever code change I made is simply not doing anything (see bug 1310903).

I applied this change to stage today: 

consulate kv set socorro/processor/destination.storage2.es_redactor.forbidden_keys 'memory_report, upload_file_minidump_browser.json_dump, upload_file_minidump_flash1.json_dump, upload_file_minidump_flash2.json_dump'

I have confirmed that the memory_report is not stored in our elasticsearch database as of this config change. 

Peter, r? for applying it to stage?

Comment 5

[Peter Bengtsson [:peterbe]]

I would strongly prefer that we don't depend on consulate at all and have the correct default in source code.

Comment 6

[[DEACTIVATED] Adrian Gaudebert]

We already have the right default in code. The fact that that default is not used will be treated in bug 1310903, but in the meantime, I think we should stop storing the memory_report in ES asap. 

We can delete those keys when we have solved the underlying issue.

Comment 7

[Peter Bengtsson [:peterbe]]

(In reply to Adrian Gaudebert [:adrian] from comment #6)
> We already have the right default in code. The fact that that default is not
> used will be treated in bug 1310903, but in the meantime, I think we should
> stop storing the memory_report in ES asap. 
> 
> We can delete those keys when we have solved the underlying issue.

Ah! Excellent. Then r+

Comment 8

[[DEACTIVATED] Adrian Gaudebert]

Done on prod and verified.