Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wi8PK-0000WS-7o for bitcoin-development@lists.sourceforge.net; Wed, 07 May 2014 20:25:38 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.50 as permitted sender) client-ip=209.85.219.50; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f50.google.com; Received: from mail-oa0-f50.google.com ([209.85.219.50]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wi8PI-0007cs-SE for bitcoin-development@lists.sourceforge.net; Wed, 07 May 2014 20:25:38 +0000 Received: by mail-oa0-f50.google.com with SMTP id i7so1909182oag.37 for ; Wed, 07 May 2014 13:25:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.16.103 with SMTP id f7mr49087836oed.8.1399494331304; Wed, 07 May 2014 13:25:31 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.71.162 with HTTP; Wed, 7 May 2014 13:25:31 -0700 (PDT) In-Reply-To: References: <536A8592.8010009@gmail.com> <536A902C.6080602@gmail.com> Date: Wed, 7 May 2014 22:25:31 +0200 X-Google-Sender-Auth: usJQzzB8yebuvuaDvBeFh9iEeiY Message-ID: From: Mike Hearn To: Wladimir Content-Type: multipart/alternative; boundary=089e0149c04e7b92e504f8d52ad1 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Wi8PI-0007cs-SE Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] Announcing the Statoshi fork X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 20:25:38 -0000 --089e0149c04e7b92e504f8d52ad1 Content-Type: text/plain; charset=UTF-8 I think there a few different possible ways to go here. One is to try and simplify the setup of all the components so it all gets installed together. That might be feasible in some quite restricted setups but the installation instructions for Graphite look kind of terrifying. Another is to export stats over regular TCP and make them public so literally anyone can listen to the stats feed for any node. Then people who dig stats and graphs could work on stats aggregators that give global network visibility independently, effectively crawling the p2p network for data. It'd have the advantage of having zero setup for the node operators and not require much in the way of resources. For what it's worth, although the environment is a bit different inside Google the latter approach is used. Monitoring servers locate servers of interest via a discovery service, connect to them and start streaming stats data into a database service that can then be queried later to get graphs. The stats are also run through various rules to obtain alerts about problematic conditions. For example, if a subset of the network splits it might be hard to notice that if the node operators aren't paying attention and Matt's fork alert/emailing code isn't set up. But if there was a site crawling nodes and aggregating chain heights by version, that could trigger an alert to people who *are* paying attention. I know from practical experience that monitoring and analysis tends to appeal more to certain types of people than others. So I quite like the "let anyone monitor" approach. However, it may not be appropriate in a P2P network, I did not think about it much. Obviously I'm assuming none of the stats expose privacy sensitive data. On Wed, May 7, 2014 at 10:18 PM, Wladimir wrote: > On Wed, May 7, 2014 at 9:57 PM, Jameson Lopp > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > I agree that it would be awesome to offer these types of stats with the > installer; unfortunately the route I've taken has dependencies on several > other other pieces of software to do all the heavy lifting of stats > aggregation and chart rendering. I'm assuming that you would not want to > build any of that processing into Bitcoin Core itself; would you be opposed > to packaging other software along with the installer? > > Depends on just how much stuff it is. The idea is primarily to have an > installer for running a (wallet-less) node as an OS background > service. > > Having some statistics available would be worth some extra download > size, otherwise it would be pretty much invisible. > > We'd already decided that we would need something like Python for the > stats service. Implementing things like web services in C++ is just > not realistic given the time constraints and the great already-written > code that is out there. As an optional tool it should be external, not > part of bitcoind itself. > > I suppose the chart rendering happens client-side? In that case the > web service just has to collect and provide the data, and serve static > html/js files. > > Wladimir > > > ------------------------------------------------------------------------------ > Is your legacy SCM system holding you back? Join Perforce May 7 to find > out: > • 3 signs your SCM is hindering your productivity > • Requirements for releasing software faster > • Expert tips and advice for migrating your SCM now > http://p.sf.net/sfu/perforce > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --089e0149c04e7b92e504f8d52ad1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think there a few different possible ways to go here.
One is to try and simplify the setup of all the components= so it all gets installed together. That might be feasible in some quite re= stricted setups but the installation instructions for Graphite look kind of= terrifying.

Another is to export stats over regular TCP and make th= em public so literally anyone can listen to the stats feed for any node. Th= en people who dig stats and graphs could work on stats aggregators that giv= e global network visibility independently, effectively crawling the p2p net= work for data. It'd have the advantage of having zero setup for the nod= e operators and not require much in the way of resources.

For what it's worth, although the environment is a = bit different inside Google the latter approach is used. Monitoring servers= locate servers of interest via a discovery service, connect to them and st= art streaming stats data into a database service that can then be queried l= ater to get graphs.=C2=A0

The stats are also run through various rules to obtain = alerts about problematic conditions. For example, if a subset of the networ= k splits it might be hard to notice that if the node operators aren't p= aying attention and Matt's fork alert/emailing code isn't set up. B= ut if there was a site crawling nodes and aggregating chain heights by vers= ion, that could trigger an alert to people who are=C2=A0paying atten= tion.

I know from practical experience that monitoring and an= alysis tends to appeal more to certain types of people than others. So I qu= ite like the "let anyone monitor" approach. However, it may not b= e appropriate in a P2P network, I did not think about it much.

Obviously I'm assuming none of the stats expose pri= vacy sensitive data.

<= br>
On Wed, May 7, 2014 at 10:18 PM, Wladimir= <laanwj@gmail.com> wrote:
On Wed, May 7, 2014 at 9:57 = PM, Jameson Lopp <jameson.lopp= @gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I agree that it would be awesome to offer these = types of stats with the installer; unfortunately the route I've taken h= as dependencies on several other other pieces of software to do all the hea= vy lifting of stats aggregation and chart rendering. I'm assuming that = you would not want to build any of that processing into Bitcoin Core itself= ; would you be opposed to packaging other software along with the installer= ?

Depends on just how much stuff it is. The idea is primarily to have a= n
installer for running a (wallet-less) node as an OS background
service.

Having some statistics available would be worth some extra download
size, otherwise it would be pretty much invisible.

We'd already decided that we would need something like Python for the stats service. Implementing things like web services in C++ is just
not realistic given the time constraints and the great already-written
code that is out there. As an optional tool it should be external, not
part of bitcoind itself.

I suppose the chart rendering happens client-side? In that case the
web service just has to collect and provide the data, and serve static
html/js files.

Wladimir

---------------------------------------------------------------------------= ---
Is your legacy SCM system holding you back? Join Perforce May 7 to find out= :
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/= sfu/perforce
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--089e0149c04e7b92e504f8d52ad1--