742897 - Verify Telemetry data in elastic search database after processing job is run

Status: RESOLVED FIXED

(Mozilla Metrics :: Data/Backend Reports, defect)

Description

[Lawrence Mandel [:lmandel] (use needinfo)]

It would be beneficial to have an automated way to ensure that the data in the Telemetry elastic search database is correct. As we saw recently, a problem with the job to aggregate data from hbase caused invalid data in elastic search.

I think that this may be related to bug 736189. Can we use the JSON data to determine that the data has been aggregated correctly? Do we need an alternate automated verification system? Are there patterns in the data that we can detect?

Comment 1

[Annie Elliott]

Marking: in group of > 33 asks for Telemetry that need PM priority before triage/scheduling.

Comment 2

[Annie Elliott]

Specific JIRA: https://metrics.mozilla.com/projects/browse/METRICS-831

Comment 3

[Annie Elliott]

New JIRA migration identifier - 55 BZ issues being considered in current planning for Q3

Comment 4

[Paulo Pires]

We implemented several tests for telemetry data, namely for ES data such as:
- existence of data for yesterday;
- existence of aurora data for yesterday and variation d/d-7;
- existence of nightly data for yesterday and variation d/d-7;
- existence of beta data for yesterday and variation d/d-7;
- existence of release data for yesterday and variation d/d-7.

Also we have some more test for representative measures, such as:
- CYCLE_COLLECTOR;
- GC_REASON;
- FX_TAB_ANIM_OPEN_MS;
- CACHE_OFFLINE_SEARCH;
- FX_NEW_WINDOW_MS
where we test if there is any data in the last 3 days, but on this I think it's best if we had some feedback, namely what are the (most important) measures that you want to be tested.

Comment 5

[Pedro Alves]

This has been in place and working great for a while now. Closing it down! One caveat is that GC_REASON was replaced with GC_REASON2