What Create a Grafana Dashboard to show self defence check metrics Why So metrics captured about self defence checks can be visualised and used to decision making about future work on that App. How Sample self defence metric in postgres
clientid | event_time | client_time | data |
9796fb69-a566-43fb-b932-03951d82437f | 2018-03-05 11:13:37.208798+00 | 50136-07-24 05:22:22+00 | |
{ |
"security": [ |
{ |
"name": "Developer Mode Check", |
"type": "org.aerogear.mobile.security.checks.DeveloperModeCheck", |
"passed": true |
}, |
{ |
"name": "Emulator Check", |
"type": "org.aerogear.mobile.security.checks.EmulatorCheck", |
"passed": false |
}, |
{ |
"name": "Debugger Check", |
"type": "org.aerogear.mobile.security.checks.DebuggerCheck", |
"passed": false |
}, |
{ |
"name": "Rooted Check", |
"type": "org.aerogear.mobile.security.checks.RootedCheck", |
"passed": false |
}, |
{ |
"name": "Screen Lock Check", |
"type": "org.aerogear.mobile.security.checks.ScreenLockCheck", |
"passed": false |
} |
] |
}
|
- the metrics could be visualised on an existing dashboard (App Metrics) or on a separate dashboard just for security checks.
- As the only identifying factor is the 'clientid', the variation of visualisations will be limited (compared to the app init visualisations). A simple table visualisation showing the total number & percentage of failed checks may be sufficient.
- It should be technically possible to link the client id to app init information (and thus show more variations of metrics visualisations), however, that is outside the scope of this task.
Verification
- Some level of verification should happen for this (which may involve manually adding the dashboard json to Grafana).
- The majority of verification will happen as part of AEROGEAR-2242
|