Except not everyone uses Thruk or a gui for that matter. Using another tool also means another agent so more overhead. If you already have an agent deployed it seems to make sense to use it for all your monitoring, the KISS principle. Then it's also standard in the perf only data is handled the same way and same path as monitoring check with perf data. We have monitoring without perf data, monitoring with perf data, so why not perf data with monitoring? Dan <div class="gmail_quote">On Jan 9, 2014 5:57 PM, "Matthias Eble" <<a href="mailto:psychotrahe@gmail.com">psychotrahe@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Why not let thruk be more of an operations console? Naemon doesn't need to gather performance only metrics. There are other tools that can do it quite fine. Cacti, collectd,... with powerful backends like opentsdb or kairosdb. Naemon perfdata should actually go there first and then be shown in the UI. Same for log monitoring. Splunk or logstash or the like will be everywhere. What do you think? Matthias <div class="gmail_quote">Am 09.01.2014 21:55 schrieb "Daniel Wittenberg" <<a href="mailto:dwittenberg2008@gmail.com" target="_blank">dwittenberg2008@gmail.com</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 <<a href="mailto:dwittenberg2008@gmail.com" target="_blank">dwittenberg2008@gmail.com</a>> 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 <<a href="mailto:ozamosi@flukkost.nu" target="_blank">ozamosi@flukkost.nu</a>> 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? > </blockquote></div> </blockquote></div>