On Sat, 2010-04-10 at 07:33 -0500, Chris Wopat wrote:
> On Sat, Apr 10, 2010 at 6:53 AM, Jim Mercer <[email protected]> wrote:
> > i find that so much "developed on Linux" code is highly un-portable, and
> > assumes way too much about the environment it is running in.
> >
> > i'll be happy to help with this portion, once you have some of the new
> > code on the go.
>
> Ditto, I'm more than willing to test builds on FreeBSD.
That does happen a lot but often its because people are writing it for
their system only and don't see the wider view. Pretty much everything
I write works on most POSIX unixes today. I'm pretty sure Debian now
ships FreeBSD "architecture" so if it doesn't work I've got a bunch of
infrastrcuture to check it on. As an aside, the reason why procps
(which I maintain but don't develop) doesn't work in FreeBSD is all
FreeBSD's procfs emulation fault.
> the original post- is the rewrite intended to get us to exactly the
> same functionality or is there a different goal in mind?
First thing is to get same functionality. So the first cut probably will
look much the same except how it does it.
> I've always wanted to see adjustable intervals (I'd like to keep 5
> minute data for a much longer time). Honestly I'd love to see a
> possibility to use the RTG poller or one of its forks (already written
> in c, fast, etc) that stores in a SQL db to keep 5 minute data
> forever. Here's some links for those that aren't familiar with it:
I'm not sure what you mean by 5 minute data. The huge delay in
processing large networks is something I want to work on. I'm not sure
if it is RRDTools fault or is it how it is called? The thing is having
it in C will give me a lot more of a handle about what is going on.
Actually is more the direct access to librrd that does that.
I've seen RTG. While I'm not 100% sure it will be the same, one of the
goals is to be more like it. That probably doesn't mean using that
projects code, we do things slight different, but it probably means
having a look at how they do it and learning from their lessons.
Another project is nagios. It has (or had) some of the best poller
scheduler I've seen anywhere, including in commercial software.
I'm working on the internal structures and configuration file handling.
libconfig will look after the files as its very flexible and will do
what I need.
An interface type definition would look something like the following.
It's still a very rough outline at the moment. The transforms basically
take an input and change the output and can be put pretty much anyhwere.
I'm missing the poller definition here but it will look an ordered list
of pollers and backends on one line.
interface_types {
{
description = "My Type";
fields = (
{ name = "bps"; type="rrd"; format="some-rrd-definition"; },
{ name = "state"; type="desc"; size=40 ; default="hello"; },
{ name = "maxbps"; type="text"; size=20; maximum=100; default=0; }
);
discovery:
{
enabled=1;
type = "snmptable";
tables = (
{ oid = "1.2.3.4"; field="state"; transform = "mytype_state" },
{ oid = "1.2.3.5"; field="maxbps"; }
);
}
};
};
transforms {
mytype_state = {
mapping = ( 0, "up", 1, "down", 2, "dunno" );
default = "down";
};
};
--
Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/ csmall at : enc.com.au
http://www.debian.org/ Debian GNU/Linux, software should be Free
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
jffnms-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jffnms-users
