[naemon-dev] metrics enhancement
Daniel Wittenberg
dwittenberg2008 at gmail.com
Thu Jan 9 21:54:57 CET 2014
So I was just thinking about this more generically, and was thinking, how about a new attribute to the object called something like “display” and could have it default to 1 (on) but you could set it to off in the config file to basically “hide” any objects that you just didn’t want to be displayed but still scheduled, checked, etc? I know this would change the struct so maybe someone has a better idea how to accomplish same thing ?
Dan
On Jan 9, 2014, at 1:46 PM, Daniel Wittenberg <dwittenberg2008 at gmail.com> wrote:
> Well, sort of. One example that I have used a lot over the years is CPU stats, so tracking Idle/IO/User/System. I want the metrics collected, but I’m not going to ever generate an alert. Another thing that I’m seeing is a trend to anomaly detection, so in that case we wouldn’t be doing the alerting but just collecting the stats and sending it off for something else to determine if it’s an alert. That make more sense?
>
> Dan
>
>
> On Jan 8, 2014, at 3:48 AM, Robin Sonefors <ozamosi at flukkost.nu> wrote:
>
>> On 2014-01-07 06:44, Daniel Wittenberg wrote:
>>> Another nifty feature I think would be nice to have is a “performance” resource, so one that
>>> just collects metrics and nothing more. So I know you can do that now by just making it show
>>> ‘OK’ but sometimes I just want it to quietly collect perf data and nothing more. I’m guessing
>>> I’m probably the only weird one who wants something like that though…
>>
>> How should that relate to other services and/or hosts? As in, is there a context where you want the performance available?
>>
>> It might be useful to be able to map extra performance checks for a host/service, and in a UI merge that information with the information retrieved from the regular host/service check - for example, you want your RAM to be used, goshdarnit, but you'd still like it to be graphed with the other services on the host. Do I understand you correctly?
>
More information about the Naemon-dev
mailing list