Re: [Peep-develop] peep's popularity problems

[Michael G. <mg...@ee...>]

  Sorry for the delay guys. I gotta change my mail sorter :)

On Sun, Jul 20 @ 19:48, xavier renaut wrote:
> |There are several ways I think about this discussion.  The first is Peep
> |into usage.  The second is the core intent of the project.  Finally,
> |there are barriers to adoption.
> |
> |In terms of usage, I see Peep as filling a much different niche than
> |nagios.  Nagios is the end-all-be-all of open source monitoring tools. 
> |It's got everything including the kitchen sink.  It is meant for the
> |data center.  If I were monitoring a facility with 1000 boxen and
> |downtime on the oracle cluster would cost the business $10,000/hour, I
> |would recommend nagios in a heartbeat.
> |
> |Peep, on the other hand, I see targeted at folks with smaller
> |installations that are not necessarily mission-critical.  I have a
> |server on campus, another in a local colocation facility, and one at
> |home.  Peep is the perfect "size" for me:  Small, 
> 
> well, yes, you need a "couple" of perl modules, and you're in business.

  I think this is part of the design. Peep's design was definitely
targeted at the smaller-medium sized network. There are some growing
pains that have surfaced and should be addressed once we get 0.5.x out
the door now that Collin has finished his dissertation.

> |easily configurable. 
> 
> well... i don't know. you need a client config, a server config...
> (damn class identifier...)
> 
> would it be interesting to get the config from the server ?
> that way, you only have to include the peep server ip on the 
> command line, for every client... no more check every where to
> set the config correctly... just an idea...

  I agree. I don't think relying on external tools to sync the
config is best solution as the configuration file has definitely
grown in complexity since. It would be nice to have each client
just point to a server or find one on the local subnet and
retrieve its config from the server. Definitely a good feature
to include in the future.

> |Finally, there are barriers to practical adoption.  I would love to
> |compile binaries of the clients (there's a new CPAN module to do that)
> |get apt-get packages and RPMs put out, get something into a Gentoo (my
> |latest fixation) portage tree, etc.  In other words, make it drop-dead
> |simple to install Peep for the average Linux or *BSD user.
> 
> this is something to be done for better adoption, yes. packages.
> with a good and working config. one day we'll make it to 
> the debian weekly news (where new packages are announced), 
> and bang ! 1 millions users more ! ;-)

  Packaging is always a time and evolution issue. I agree we should work
on this. We need some people with the bandwith to assemble the packaging
though. The gentoo folks I think had tackled this for their dist if
I remember correctly...

> |
> |> 2 problems (maybe?) with peep :
> |> 
> |> - setting up the communication channels between hosts
> |> part of the hassle is that for peep to work,
> |> we need a peep client on each machine. 
> |> means managing multiple peep configs, maybe it implies cvs....

  This is a problem with the model. If a client were to retrieve its
configuration from the server, that problem would be solved.

> |I see that as a common problem.  Even in the monitoring tools I have
> |worked with professionally, monitoring large-scale deployments for
> |clients such as the IRS and Qwest, pushing out configuration changes was
> |a huge pain.  
> |
> |If you had the individual monitors "pull" a configuration, then there
> |were possible security risks.  If configuration "pushes" were automated,
> |that is a security risk.
> 
> 
> hum. i see your point.
> the pull method seems fine though, it could be a choice to the user.
> currently peep has only one way to do it : a config on both side.
> i use the same file for both the client and the server.
> would it be hard to tell the client to pull the config of
> the server ?

  Again, this is definitely a feature to include.

> 
> |With Peep, since I see it as a tool for smaller installations, I don't
> |see the configuration issue as high on my list.  I would invite
> |suggestions / code from anyone for whom this would be a major issue, but
> |I doubt I'll get to it myself within the next few cycles.
> 
> 
> ok. does the server has the config in memory ?
> i think i could get the perl client to fetch it.
> after all, it's perl.
> would it be easy to code a little blurb on the server
> to give the config if the client connects and sends 
> a request for his config ?
> (Michael ?)

  Right now it parses the configuration into internal data structures
and only looks at the sections it likes. I think we can get this
feature into the next major release. Collin and I have had much
discussion about that.

> |> - using sound 
> |> we need to ease the processing. not many sound cards
> |> thoses days accept multiple locks on /dev/dsp,
> |> so we need to make it work with alsa and/or esd.
> |> fyi, i'm using esd on my machines thoses days.
> |> ppl don't want their /dev/dsp clogged all day by a program.
> |> ppl want their im/irc alert working. (talking to much about
> |> my self maybe ;-)

  .. Yeah, I meant to get around to this but somehow never did.

> |> and i don't know, maybe our culture is to much sight-centric,
> |> not really audiophile... audio is for entertainement (think
> |> music) when i explain peep to people, they're smiling
> |> when they learn that peep is sound based. 
> |> "realtime monitoring tool" sounds cool. this is peep.
> |> maybe ppl don't believe in sound. they believe in 
> |> popups. blinking. visual. another power of peep
> |> is that it's investigating another field yet
> |> unutilized professionaly speaking : the ear.
> |> (sound like i'm selling the lastest nonexistant dot com product.)
> |> (our product is based on a totally unexploited technology,
> |> multiply your productivity  !!)

  This really gets me to one of the things that I think we need to
revisit in Peep's architecture. We need to be able to embed the server
within other apps. Peep is an enchancement that can greatly ease
monitoring, not a make or break tool. The full power of the tool is
only unleashed when combined with other tools. Hence the importance
of embeddability.

  Of course, I think that perhaps the server should be ported to an
OO language, either C++ or Java or maybe Mono C#. Collin and I had
been playing around with the idea. It would be easier then to enforce
component separation (although the 0.5.0 server does a great job at
this even though it's all enforced in the loose C way). We could then
expand the input interfaces to include a variety of communications
methods much more easily then the current implementation. What do you
guys think of this?  It would also make it easier to embed in other
systems...

> |I would disagree.  For the home user or a sysadmin of a small shop, it's
> |much less intrusive than other monitoring systems which are sending out
> |pages all the time or with which you have to take some action such as
> |looking at a web page to figure out when something is down.  
> 
> 
> for that, we need esd/alsa working, ppl want to hear the music...
> is there a way to set the peep volume without changing the 
> music volume ?


  The current audio interface is nice modularized. Alsa works with 0.5.0,
as some people have told me. Esd doesn't yet. Just compile with alsa
support. I don't quite understand the last part of this comment though.

  Good to hear from all of you. I think now that Collin and I have
sync'd up, things should pick up a little more.

            Regards,

                 -- Mike

-- 
Michael Gilfix
mg...@ee...

For my gpg public key:
http://www.eecs.tufts.edu/~mgilfix/contact.html