From: Mike Hearn <mike@plan99•net>
To: Wladimir <laanwj@gmail•com>
Cc: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Announcing the Statoshi fork
Date: Wed, 7 May 2014 22:25:31 +0200 [thread overview]
Message-ID: <CANEZrP2aUBFkwx0s_xcS_e4gv1Ao1240NVNNFR3bFUBf9hHqsA@mail.gmail.com> (raw)
In-Reply-To: <CA+s+GJCaUX3ErgVean0e91CBorPc6RNKgYs08fOOsqNYtbd6RA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3705 bytes --]
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 <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 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
>
[-- Attachment #2: Type: text/html, Size: 4756 bytes --]
next prev parent reply other threads:[~2014-05-07 20:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-07 19:12 Jameson Lopp
2014-05-07 19:46 ` Wladimir
2014-05-07 19:57 ` Jameson Lopp
2014-05-07 20:18 ` Wladimir
2014-05-07 20:25 ` Mike Hearn [this message]
2014-05-07 20:31 ` Charlie 'Charles' Shrem
2014-05-07 21:07 ` Wladimir
2014-05-08 0:47 ` Gregory Maxwell
2014-05-08 7:45 ` Wladimir
2014-05-08 10:08 ` Mike Hearn
2014-05-08 10:32 ` Wladimir
2014-05-07 20:28 ` Nelson Castillo
2014-05-08 11:22 ` Wladimir
2014-05-07 20:35 ` Jameson Lopp
2014-05-07 21:04 ` Charlie 'Charles' Shrem
2014-05-07 19:50 ` Mike Hearn
2014-05-07 20:00 ` Jameson Lopp
2014-05-07 20:12 ` Mike Hearn
2014-05-07 19:55 ` Pavol Rusnak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANEZrP2aUBFkwx0s_xcS_e4gv1Ao1240NVNNFR3bFUBf9hHqsA@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=laanwj@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox