Michael Gillespie

Members
  • Content Count

    2
  • Joined

  • Last visited

  • Days Won

    2

Community Reputation

6 Neutral

About Michael Gillespie

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. When there is a legitimate reason for disabling alerts for a device, it would be very useful to be able to leave a note as to why (and by whom). This would prevent confusion with teams, where the case of "why would this be disabled" would come up frequently. For example, there is a known bug with a certain version combination of ESXi and HPE servers that triggers a false-positive hardware alert internally, so we disable alerts for that instance on servers that meet the criteria as we encounter them. Or, some QNAPs will give false-positive alerts that their disk is full when in fact it is "full" due to a RAIN configured as a LUN (we thus rely on the server alerting when the iSCSI volume is actually full). However, another technician may log in and flip alerting for these instances back on, assuming it was a mistake or something, and then we would get flooded with these false-positive alerts, prompting technicians to look into them; as you can see, this causes a loop of wasted time. Simply putting a note associated with the "Alerting Off / On" switch and tagging it with the user invoking it would easily solve issues like this. Something like what is shown for Acknowledgements would be adequate. Perhaps even an admin option to require a note or not?
  2. Has anyone come up with a work-around or anything for this? I have a situation where it would be super useful for alerts regarding a firmware update to provide more information. The API I'm using returns a boolean "upgradable" key that I alert on, but would love to be able to put in the alert message something like "Update available (from ##current_version## -> ##new_version##)", where those are tokens for other datapoints already defined.