On Thu, 13 Jun 2019, Neha Ojha wrote: What if we start with something like: - a 'mute' targets a specific warning code (e.g., OSD_DOWN) e.g., 'ceph health mute OSD_DOWN' - the mute matches the alert code and the short description (e.g., "2 osds down") - this could be more specific, like matching the detail items too - or, it could be less specific, so that e.g., a OSD_DOWN going from 2 to 1 osd won't unmute - or, individual detail items could be the things that get muted -> we might need to make alerts include more structured fields (besides a summary string and vector<string> of details) in order to make this work perfectly... but we can start start simple (with just the summary string match?). - the mute goes away if - the description changes - the alert resolves - the TTL/expiration time is reached - the user unmutes (the specific mute 'ceph health unmute <code>' or all mutes with 'ceph health umute') - 'ceph -s' will say HEALTH_OK (if all alerts are muted), but *also* say how many muted alerts there are, e.g. cluster: id: 28f7427e-5558-4ffd-ae1a-51ec3042759a health: HEALTH_OK 2 muted alerts: OSD_DOWN, TOO_MANY_PGS services: ... - 'ceph health' will say HEALTH_OK (if all alerts are muted) - 'ceph health detail' will say HEALTH_OK (if all alerts are muted), but will *also* show all of the muted alerts in a separate section (along with the mute TTL/expiration) - the dashboard would show HEALTH_OK, plus some clear visual indication that there are one or more mutes, with an easy UI to mute/unmute sage