Hi folks,
I'm happy to add my embeddedgmetric c/python/whatever into your repository
if there is any interest. http://code.google.com/p/embeddedgmetric/ (oh
by the way, it's now at version 1.1)
To answer the question on what is the difference between my python module
and the other one, it's "in process vs. out of process" FOR CASUAL USE IT
MAKES NO DIFFERENCE!
Mine directly creates the "packets" and sends them to gmond. It just "does
the work" inside your program with no external resources. The python code
_only_ can do multicast or point-to-point to _one_ gmond server.
The other one creates and calls the "gmetric process" -- this means creating
a process, reading the config file, all that. It can send metrics to
anything gmetric can (since it's the same thing).
As mentioned, it really makes no difference for if you are doing a few
metrics here and there. Once you start really pumping out a lot metrics, it
can have a noticable impact. The name escapes me, but someone timed this,
and the embedded version was like 3 or 4 times faster (this person was
sending 100s of metrics regularly).
The origins of gmetric is that I wrote one in C/C++ to directly inject
starts into gmond for a variety of reasons (and not using gmetric directly).
After 'reverse-engineering' the protocol, as an experiment I ported it to
many scripting languages "just because" At least one person is using the
python version in production.
side note: it would be "really great" to make gmetric take multiple metrics
and blast them all at once. That would probably require a new command line
flag. Maybe I'll write a patch for that later.
Comments, feedback welcome!
--nickg
On 7/12/07, Brad Nicholes <[EMAIL PROTECTED]> wrote:
>>> On 7/11/2007 at 6:05 PM, in message
<[EMAIL PROTECTED]>, "Bernard
Li"
<[EMAIL PROTECTED]> wrote:
> Hi Brad:
>
> So how did you do it? Are you using the distro provided apr-1 or did
> you install it from source with --prefix?
>
> With apr-1-config, I can get the include path into a variable -- I
> then have this include path added to the numerous Makefile.am that
> needs it.
>
> It's not especially clean and I'm not sure whether it's the correct
> way to do it, but so far it seems to work.
>
> However, I'm not sure why I need to do this for apr, but not for
> expat/libconfuse -- any ideas?
>
> BTW, Python.h is found in /usr/include/python<ver>/ on Red Hat
> distroes, so I am implementing a workaround so that things work
> cross-distroes.
>
> Cheers,
>
> Bernard
>
Actually I am doing both. On some machines I have the distro provided
apr-1 and on another I have built and installed APR from source with a
--prefix. The difference is that none of my machines have apr-0
installed. So the trick is getting around the apr-0 headers if they are
installed. The --with-libapr parameter could allow you to specify the
appropriate lib directory but in that case we would be missing an equivalent
--with-apr-include parameter. As it stands currently, the --with-libapr
parameter allows you to specify a parent directory. By default this is /usr
which has both /usr/include and /usr/lib as subdirectories so the configure
script does the right thing when setting up the CFLAGS and the LDFLAGS. If
you specify a different path with the --with-libapr parameter that points to
a from-source built and installed apr-1, the same is still true. Both the
include and lib directories are sub-directories of the path you specified so
CFLAGS and LDFLAGS are correct.
The problem is when apr0 is also installed under /usr. Then it's not
so clear on which headers get picked up. Bottomline is that if you build
trunk on a machine that does not have apr0 installed, everything will build
fine. We just may have to handle the case where apr0 is also installed.
The reason why you have the problem with apr and not expat or libconfuse,
is simply because you don't have multiple versions of expat-devel or
libconfuse-devel installed on your machine. The problem is that you have
both apr0-devel and apr1-devel installed. That is where the problem comes
in.
Brad
-------------------------------------------------------------------------
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/
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
-------------------------------------------------------------------------
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/
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
