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

[xavier r. <lis...@na...>]

|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.


|easy to install, and

well, you need a client AND a server.
nagios has only a server.


|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...

| And best of all:  It's much more fun than nagios! 

yup, that's why we all run it ! :-D

|But more on that later ....
|
|So in terms of who should we be looking to as potential adopters, I
|think it is more the recreational home user or sysadmin with a small
|number of servers.

agreed, until we find a ultimate usage.

|In terms of the core intent of the project, I see Peep as much as an art
|project than a monitoring tool.  So I would like to see, for example, a
|corresponding visual component, perhaps modeled on eXtace, and dockable
|panel applet.  I would like to promote themes and see what kind of
|things that folks come up with.  I would like to expand the sound
|library.  All these things are higher priority for me than writing more
|monitoring tools.  That's part of the reason I designed the client side
|to make it so easy to create custom clients.

that's good.

|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 ! ;-)

|
|In addition to the ease of installation, I think folks have likely been
|dissuaded from it recently because the project stalled.  Typically one

yeah. agreed.

|I think if we got a smooth packaging system organized, released 0.5.0,
|and started posting themes and doing other things to signal continued
|interest in the project, we would see folks adopt it quite a bit more
|readily.

agreed.

|
|> 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....
|
|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 ?


|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 ?)

|> - 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 ;-)
|> 
|> 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  !!)
|
|I agree that tying into esd or alsa would be nice.  I listen to XMMS all
|the time and have to turn off my monitoring when I do.
|
|> may be a visual output plugin might be a hooker for people ?
|
|Take a look at 
|
|  http://www.collinstarkweather.com/local/...
|
|I put together a quickie prototype of a visual output plugin using
|eXtace.  I think I'd like to revive that.

is the code on cvs ?
may be it should be...

it would be nice to put thoses images on the auralizer web pages
to "appeal" users. "see, we're working on it !!"


|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 ?


bye


-- 
xavier