Subject: Re: Infrastructure monitoring

From: "Dave Page" <[email-masked]>
Date: Sat, 14 Jan 2006 19:25:02 -0000

-----Original Message-----
From: [email-masked] on behalf of Marc G. Fournier
Sent: Sat 1/14/2006 2:16 AM
To: Josh Berkus
Cc: John Hansen; [email-masked]; Jim C. Nasby
Subject: Re: [pgsql-www] Infrastructure monitoring
 
> As I've said above ... physical servers are being monitored, so if anyone 
> has some ideas on how we can improve "content monitoring", for lack of a 
> better word, I know I'm all ears ...
> 
> Again, if Hyperic can offer something for this, let me know ...

We also monitor a bunch of services using a nagios installation here. With the search though it's not always so easy because the search engine is tucked away behind a firewall with only the web frontend poking through.

Regards, Dave

---

From: Guido Barosio <[email-masked]>
Date: Sat, 14 Jan 2006 20:43:58 +0000

I insist cause I find it easy (even for a standard nagios)

The search failure was due to a 503 error being dispatched from the server.

GET http://search.postgresql.org and expect to recive an array of codes for
a succesfull lookup, or drop an alert.

G.-

On 1/14/06, Dave Page <[email-masked]> wrote:
> We also monitor a bunch of services using a nagios installation here. With
> the search though it's not always so easy because the search engine is
> tucked away behind a firewall with only the web frontend poking through.
>
> Regards, Dave
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to [email-masked] so that your
>       message can get through to the mailing list cleanly
>

--
/"\   ASCII Ribbon Campaign  .
\ / - NO HTML/RTF in e-mail  .
X  - NO Word docs in e-mail .
/ \ -----------------------------------------------------------------

---

From: "Joshua D. Drake" <[email-masked]>
Date: Sat, 14 Jan 2006 12:59:34 -0800

Hello,

I believe the biggest issue is not the monitoring but the fact
that these machines are not managed.

All due respect to John (I believe he does the search) but if he
is often on the road for 12 hours then someone else needs
to be hosting those machines.

The machines need to be hosted by companies that manage
servers. There are several in the PostgreSQL community and
yes CMD is one of them.

I am not trying to take any kudos from anyone or suggest that
they are not doing a bang up job. I am saying that all of the
communities machines should be managed.

Outside of a hardware failure there is zero reason for these
machines to have extended outages unless scheduled.

Sincerely,

Joshua D. Drake

-- 
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: PLphp, PLperl - http://www.commandprompt.com/

---

From: Dave Page <[email-masked]>
Date: Sat, 14 Jan 2006 21:01:23 +0000

> I insist cause I find it easy (even for a standard nagios)
With all due respect, insist all you want but the search engine backend does
not run HTTP and is behind a firewall where we cannot monitor it from the
outside without punching a hole first. From what John has said though, it is
monitored from elsewhere on his private network.

The frontend server is monitored by nagios, but as I knew search was being
moved, I was not paying any attention to it.

Regards, Dave.

---

From: Dave Page <[email-masked]>
Date: Sat, 14 Jan 2006 21:11:19 +0000

> machines to have extended outages unless scheduled.

Well john has told me in the past he'd be happy to move the search to more
suitable servers. It's a big database handling a high volume of queries
though so a shared or old machine simply won't do.

I don't know how ASPseek will run on modern hardware, but the
far-less-efficient Mnogosearch became a gibbering wreck on a dual 3GHz Xeon
with 4GB RAM and what iirc was a 147GB RAID1 array.

Do you think Command Prompt might be able to help in this case? John can
give a better idea of the actual requirements of course - the only other
oddity that I can recall is that ASPSeek must be compiled with gcc 2.95 due
to some changes in the hashing functions in the STL in later versions which
cause index bloat.

Regards, Dave.

---

From: "Joshua D. Drake" <[email-masked]>
Date: Sat, 14 Jan 2006 13:24:48 -0800

> to some changes in the hashing functions in the STL in later versions which
Sure we could help and we are happy to. John what types of machines
are we talking about here?

Also if ASPSeek actually is an issue we can look into OpenFTS which I have
used successfully in the past, I also believe it is what pgsql.ru uses.

Sincerely,

Joshua D. Drake

---

From: Dave Page <[email-masked]>
Date: Sat, 14 Jan 2006 21:39:50 +0000

> used successfully in the past, I also believe it is what pgsql.ru uses.

ASPSeek is only an issue with the STL problem I mentioned, if used with GCC
3.something or above (2.95 should definitely work). Other than that, John's
PG port works like a charm.

The problem with OpenFTS et al, is that there's a lot more to do than simply
install, configure and run. There's a whole heap of packages used on
pgsql.ru, including one for which the website and documentation is entirely
in Russian iirc. From what I remember that major parts that don't exist are
the indexer (to spider the sites and get them into the website), and a
frontend to actually render the output in HTML.

The ASPSeek code requires only PostgreSQL and a couple of templates.

Regards, Dave.