i wish i had the time to work on this...
like florian mentioned earlier in this thread, the most important thing here is
coming up with a fast table design (the perfparse guys did a pretty good job
with theirs). once the perfdata table gets into the gigabytes, queries start to
get really slow...
a new ndo table trimming option would also be useful to keep this table from
getting out of control (eg: max_perfdata_age).
Mike Conigliaro
ProActive Technologies
conigliaro@getproactivenow.com
203.239.0440 ext:317
www.getproactivenow.com
Ethan Galstad wrote:
> I'd be happy to incorporate a patch to provide parsed perfdata in the
> ndoutils db if someone wants to take a stab at it. I think the raw
> perfdata field should remain and data that can be parsed should be
> stored elsewhere. That way data doesn't disappear just because it
> doesn't conform to the official perfdata standards.
>
> mike conigliaro wrote:
>> hey flo,
>>
>> i dont agree that mysql storage is not needed. i chose perfparse specifically
>> for this feature, so it would be nice if this was still an option. at my
>> company, its important that our customers have access to performance data so
>> they can generate their own reports and see the current status of their servers.
>> since we dont want our customers accessing our nagios server directly, we
>> created our own read-only nagios web interface (on a different, publicly
>> accessible server) using the ndoutils and perfparse databases as a data source.
>>
>> i dont have a lot of experience with rrdtool, but if performance data was only
>> stored in rrd files on the nagios box, it seems like there would be no easy way
>> to retrieve the data from elsewhere on the network. my first thought is that id
>> have to implement a clustered filesystem or some sort of rsync process in order
>> to share the rrd files, and thats a bit more complicated than writing a few sql
>> queries. =)
>>
>> it seems to me that if ndoutils took care of the parsing/storage on its own, the
>> only thing needed from the perfparse project would be the report generation
>> framework. and then id begin to wonder if perfparse was even appropriate as a
>> separate project, since this is something that should be (and could very easily
>> be) incorporated into the new nagios web interface. imho, graphs are
>> important/useful enough that they should be a core feature in any a monitoring
>> application.
>>
>> just my 2 cents.
>>
>> Mike Conigliaro
>> ProActive Technologies
>> conigliaro@getproactivenow.com
>> 203.239.0440 ext:317
>> www.getproactivenow.com
>>
>>
>> Florian Gleixner wrote:
>>> Christoph Maser wrote:
>>>>> http://nagiosplug.sourceforge.net/devel ... tml#AEN202
>>>>>
>>>> Yes i know i was refereing to that. But since there is no mechanism in
>>>> place to ensure the policy you will always find plugins wich will not
>>>> follow the policy
>>> Data that do not follow this guide can safely be discarded.
>>>
>>>>> im also not sure why code would be needed from the perfparse project.
>>>> I thought the parser might be not so simple and therefore reusing
>>>> working code would be useful.
>>> The parser is not the problem. A efficient and fast storage (database
>>> design) and usable report generation (web interface) is more work. And
>>> many people happy with rrd graphs, so no mysql storage would be needed.
>>>
>>> Flo
>>>
>
>
> Ethan Galstad,
> Nagios Developer
> ---
> Email: nagios@nagios.org
> Website: http://www.nagios.org
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/lis ... gios-devel
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: conigliaro@getproactivenow.com