Hi,
Couple of items for the wish list. These are based on feedback from my IT support Teams on both 3.x and 4.x of HM.
1)Is it possible to have an additional status “Warning”? There are many circumstances where a service can be exhibiting aberrant behaviour, but stops short of warranting a “Bad” status. For example a mail queue might gradually build up over time before tripping over, a “warning” status would forewarn of an impending problem.
2)Is it possible to build in a facility to acknowledge a monitor in the web interface – a date and time stamped note that can be attached to a monitor if the status registers as “Bad”. This would be a huge advantage and allow tracking of the fault diagnosis and resolution of a problem. The ability to add notes against a monitor would have a mass of other advantages – the ability to note and audit changes against a server for example.
3)Unique Ids. As a monitor name can change over time it can be correspondingly difficult to analyse data over time. A unique ID attached to each new instance of a monitor would resolve this potential problem.
I think the addition of alert acknowledgements would make this a truly awesome application...anyway a couple of ideas to keep you busy!
Many Thanks
Fergus
Status values and acknowledging alerts
FLynch,
could you please provide more detailed explanation?
>2) Is it possible to build in a facility to acknowledge a monitor in the web interface – a date and time stamped note that can be attached to a monitor if the status registers as “Bad”.
I do not understand what do you mean. What is "a date and time stamped note that can be attached to a monitor"? What monitor? HostMonitor? Or attached to a test? What date&time is should use?
>3)Unique Ids. As a monitor name can change over time it can be correspondingly difficult to analyse data over time. A unique ID attached to each new instance of a monitor would resolve this potential problem.
HostMonitor uses unique ID for each test. Are you talking about Log Analyzer when said "difficult to analyse data over time"? Or you are talking about your own application?
>1)Is it possible to have an additional status “Warning”?
I understand this item
This task requires changes in all test methods. Because for different tests you should be able to provide defferent conditions for the "warning" status. We have this task in our "to do" list but it will not be implemented soon.
Regards
Alex
could you please provide more detailed explanation?
>2) Is it possible to build in a facility to acknowledge a monitor in the web interface – a date and time stamped note that can be attached to a monitor if the status registers as “Bad”.
I do not understand what do you mean. What is "a date and time stamped note that can be attached to a monitor"? What monitor? HostMonitor? Or attached to a test? What date&time is should use?
>3)Unique Ids. As a monitor name can change over time it can be correspondingly difficult to analyse data over time. A unique ID attached to each new instance of a monitor would resolve this potential problem.
HostMonitor uses unique ID for each test. Are you talking about Log Analyzer when said "difficult to analyse data over time"? Or you are talking about your own application?
>1)Is it possible to have an additional status “Warning”?
I understand this item
This task requires changes in all test methods. Because for different tests you should be able to provide defferent conditions for the "warning" status. We have this task in our "to do" list but it will not be implemented soon.Regards
Alex
Hi,
More details below;
>2) Is it possible to build in a facility to acknowledge a monitor in the web interface – a date and time stamped note that can be attached to a monitor if the status registers as “Bad”.
I do not understand what do you mean. What is "a date and time stamped note that can be attached to a monitor"? What monitor? HostMonitor? Or attached to a test? What date&time is should use?
Reply >> The note would be attached to a specific test. The overall aim is to allow IT support staff to acknowledge a “bad” alert and make a note of the actions they are taking to rectify the problem (especially useful in multi-site environments with distributed or de-centralised IT support teams) The date & time would reflect when the note was actually entered into the system by the support technician. Ultimately this would build up to an invaluable historical audit trail of the server/services behaviour over time. I think that it would also increase use of HM within an organisation as this type of facility could be used for recording work, change management, a knowledge base etc etc.
>3)Unique Ids. As a monitor name can change over time it can be correspondingly difficult to analyse data over time. A unique ID attached to each new instance of a monitor would resolve this potential problem.
HostMonitor uses unique ID for each test. Are you talking about Log Analyzer when said "difficult to analyse data over time"? Or you are talking about your own application?
Reply >> Arrah! I didn’t know that (betraying my ignorance here) How do I view the (numeric?) id associated with a particular test ?
Many Thanks
Fergus
More details below;
>2) Is it possible to build in a facility to acknowledge a monitor in the web interface – a date and time stamped note that can be attached to a monitor if the status registers as “Bad”.
I do not understand what do you mean. What is "a date and time stamped note that can be attached to a monitor"? What monitor? HostMonitor? Or attached to a test? What date&time is should use?
Reply >> The note would be attached to a specific test. The overall aim is to allow IT support staff to acknowledge a “bad” alert and make a note of the actions they are taking to rectify the problem (especially useful in multi-site environments with distributed or de-centralised IT support teams) The date & time would reflect when the note was actually entered into the system by the support technician. Ultimately this would build up to an invaluable historical audit trail of the server/services behaviour over time. I think that it would also increase use of HM within an organisation as this type of facility could be used for recording work, change management, a knowledge base etc etc.
>3)Unique Ids. As a monitor name can change over time it can be correspondingly difficult to analyse data over time. A unique ID attached to each new instance of a monitor would resolve this potential problem.
HostMonitor uses unique ID for each test. Are you talking about Log Analyzer when said "difficult to analyse data over time"? Or you are talking about your own application?
Reply >> Arrah! I didn’t know that (betraying my ignorance here) How do I view the (numeric?) id associated with a particular test ?
Many Thanks
Fergus
>The note would be attached to a specific test. The overall aim is to allow IT support staff to acknowledge a “bad” alert and make a note of the actions they are taking to rectify the problem (especially useful in multi-site environments with distributed or de-centralised IT support teams) The date & time would reflect when the note was actually entered into the system by the support technician. Ultimately this would build up to an invaluable historical audit trail of the server/services behaviour over time. I think that it would also increase use of HM within an organisation as this type of facility could be used for recording work, change management, a knowledge base etc etc.
Now I understand. It has sense but will not be implemented in nearest versions. May be in version 4.50 or 5.0..
>I didn’t know that (betraying my ignorance here) How do I view the (numeric?) id associated with a particular test ?
You didn't know that because HostMonitor never displays this ID, its for internal use only. So, why do you need it? You want to create some application for data analyzing?
Regards
Alex
Now I understand. It has sense but will not be implemented in nearest versions. May be in version 4.50 or 5.0..
>I didn’t know that (betraying my ignorance here) How do I view the (numeric?) id associated with a particular test ?
You didn't know that because HostMonitor never displays this ID, its for internal use only. So, why do you need it? You want to create some application for data analyzing?
Regards
Alex
"You didn't know that because HostMonitor never displays this ID, its for internal use only. So, why do you need it? You want to create some application for data analyzing?"
Yes, we are thinking of developing a very simple supplementary reporting application that will be used to generate very specific management reports. Distinguishing tests by a unique id number would ease the data analysis.
Thanks
Fergus
<font size=-1>[ This Message was edited by: flynch on 2003-07-26 04:15 ]</font>
Yes, we are thinking of developing a very simple supplementary reporting application that will be used to generate very specific management reports. Distinguishing tests by a unique id number would ease the data analysis.
Thanks
Fergus
<font size=-1>[ This Message was edited by: flynch on 2003-07-26 04:15 ]</font>
