Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of kxepal@gmail.com designates
 74.125.83.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <B2D6873FFE52470EA4AECDCB23D4B86D@thenoi.se>
References: <B2D6873FFE52470EA4AECDCB23D4B86D@thenoi.se>
Date: Sun, 8 Jul 2012 18:05:36 +0400
Message-ID: 
 <CAHdjipK-W8_k2+2q94KHkQnyvXufwTruuzjVKkdhfFLEpPnk8g@mail.gmail.com>
Subject: Re: Best way to monitor availability of a CouchDB install
From: Alexander Shorin <kxepal@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Martin.

Your plan sounds good, but why not to use special tools such
monitoring tasks? Like monit[1], which could not only tell you that
CouchDB instance is not available by HTTP API, but also does his
process even alive, notify about any problems and restart service if
so.

[1] http://mmonit.com/monit/


--
,,,^..^,,,


On Sun, Jul 8, 2012 at 5:51 PM, Martin Hewitt <martin@thenoi.se> wrote:
> Hi all,
>
> I'm working up a monitoring system to track our database servers' statuse=
s and I was just wondering if anyone had any hints or tips of how best to d=
etect a server going down or becoming unreachable?
>
> My current plan is to subscribe to the _changes feed for a system databas=
e, say _users, with a heartbeat of a second or so, and mark the server "at =
risk" if the connection drops, or the heartbeat doesn't arrive, and mark it=
 as "down" if the _changes connection can't be re-established or if a secon=
d heartbeat in a row is missed.
>
> Martin