📅 Original date posted:2014-05-07
📝 Original message:I'm going to install this now on my full node, looks really cool!
This is my node page: http://199.58.210.124/
Thanks,
Charlie
CharlieShrem.com | *Please **encrypt messages with my PGP key
<http://charlieshrem.com/contact/>;*
On Wed, May 7, 2014 at 4:25 PM, Mike Hearn <mike at plan99.net> wrote:
> 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 at gmail.com> wrote:
>
>> On Wed, May 7, 2014 at 9:57 PM, Jameson Lopp <jameson.lopp at 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140507/8915977a/attachment.html>;
Charlie 'Charles' Shrem [ARCHIVE] /
npub10v…v9kta
2023-06-07 15:21:05
in reply to nevent1q…lwp4
Author Public Key
npub10vhrk4v0t6r25eq3f6lf9ds7yrzmy4ahqahu6mj8dv27wshep53qhv9ktaPublished at
2023-06-07 15:21:05Event JSON
{
"id": "daa72fdf4d87e4c553891d5e1a293e792206e777c880f5bfc8e818a02b87d826",
"pubkey": "7b2e3b558f5e86aa64114ebe92b61e20c5b257b7076fcd6e476b15e742f90d22",
"created_at": 1686151265,
"kind": 1,
"tags": [
[
"e",
"eee9f45331490750cb4b2457486fbbd67822220193953d499fd36e4811e321a2",
"",
"root"
],
[
"e",
"7ab43e43392c92aba867c48dd3ab9799158f3c05b3100e27397e7f46f3ea1807",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-05-07\n📝 Original message:I'm going to install this now on my full node, looks really cool!\n\nThis is my node page: http://199.58.210.124/\n\n\n\nThanks,\n\nCharlie\n\nCharlieShrem.com | *Please **encrypt messages with my PGP key\n\u003chttp://charlieshrem.com/contact/\u003e*\n\n\nOn Wed, May 7, 2014 at 4:25 PM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\n\u003e I think there a few different possible ways to go here.\n\u003e\n\u003e One is to try and simplify the setup of all the components so it all gets\n\u003e installed together. That might be feasible in some quite restricted setups\n\u003e but the installation instructions for Graphite look kind of terrifying.\n\u003e\n\u003e Another is to export stats over regular TCP and make them public so\n\u003e literally anyone can listen to the stats feed for any node. Then people who\n\u003e dig stats and graphs could work on stats aggregators that give global\n\u003e network visibility independently, effectively crawling the p2p network for\n\u003e data. It'd have the advantage of having zero setup for the node operators\n\u003e and not require much in the way of resources.\n\u003e\n\u003e For what it's worth, although the environment is a bit different inside\n\u003e Google the latter approach is used. Monitoring servers locate servers of\n\u003e interest via a discovery service, connect to them and start streaming stats\n\u003e data into a database service that can then be queried later to get graphs.\n\u003e\n\u003e The stats are also run through various rules to obtain alerts about\n\u003e problematic conditions. For example, if a subset of the network splits it\n\u003e might be hard to notice that if the node operators aren't paying attention\n\u003e and Matt's fork alert/emailing code isn't set up. But if there was a site\n\u003e crawling nodes and aggregating chain heights by version, that could trigger\n\u003e an alert to people who *are* paying attention.\n\u003e\n\u003e I know from practical experience that monitoring and analysis tends to\n\u003e appeal more to certain types of people than others. So I quite like the\n\u003e \"let anyone monitor\" approach. However, it may not be appropriate in a P2P\n\u003e network, I did not think about it much.\n\u003e\n\u003e Obviously I'm assuming none of the stats expose privacy sensitive data.\n\u003e\n\u003e\n\u003e\n\u003e On Wed, May 7, 2014 at 10:18 PM, Wladimir \u003claanwj at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e On Wed, May 7, 2014 at 9:57 PM, Jameson Lopp \u003cjameson.lopp at gmail.com\u003e\n\u003e\u003e wrote:\n\u003e\u003e \u003e -----BEGIN PGP SIGNED MESSAGE-----\n\u003e\u003e \u003e Hash: SHA1\n\u003e\u003e \u003e\n\u003e\u003e \u003e I agree that it would be awesome to offer these types of stats with the\n\u003e\u003e installer; unfortunately the route I've taken has dependencies on several\n\u003e\u003e other other pieces of software to do all the heavy lifting of stats\n\u003e\u003e aggregation and chart rendering. I'm assuming that you would not want to\n\u003e\u003e build any of that processing into Bitcoin Core itself; would you be opposed\n\u003e\u003e to packaging other software along with the installer?\n\u003e\u003e\n\u003e\u003e Depends on just how much stuff it is. The idea is primarily to have an\n\u003e\u003e installer for running a (wallet-less) node as an OS background\n\u003e\u003e service.\n\u003e\u003e\n\u003e\u003e Having some statistics available would be worth some extra download\n\u003e\u003e size, otherwise it would be pretty much invisible.\n\u003e\u003e\n\u003e\u003e We'd already decided that we would need something like Python for the\n\u003e\u003e stats service. Implementing things like web services in C++ is just\n\u003e\u003e not realistic given the time constraints and the great already-written\n\u003e\u003e code that is out there. As an optional tool it should be external, not\n\u003e\u003e part of bitcoind itself.\n\u003e\u003e\n\u003e\u003e I suppose the chart rendering happens client-side? In that case the\n\u003e\u003e web service just has to collect and provide the data, and serve static\n\u003e\u003e html/js files.\n\u003e\u003e\n\u003e\u003e Wladimir\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e Is your legacy SCM system holding you back? Join Perforce May 7 to find\n\u003e\u003e out:\n\u003e\u003e \u0026#149; 3 signs your SCM is hindering your productivity\n\u003e\u003e \u0026#149; Requirements for releasing software faster\n\u003e\u003e \u0026#149; Expert tips and advice for migrating your SCM now\n\u003e\u003e http://p.sf.net/sfu/perforce\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Is your legacy SCM system holding you back? Join Perforce May 7 to find\n\u003e out:\n\u003e \u0026#149; 3 signs your SCM is hindering your productivity\n\u003e \u0026#149; Requirements for releasing software faster\n\u003e \u0026#149; Expert tips and advice for migrating your SCM now\n\u003e http://p.sf.net/sfu/perforce\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140507/8915977a/attachment.html\u003e",
"sig": "5eab9e9e03e7acbdded85ea9f9f8b40085dd42ec411798d901b3906cc617b989378420dc4728ad92cce3948fdc30b3cc971668b62782af3551227241becdcf69"
}