<unnamed>

Public Key

npub10vhrk4v0t6r25eq3f6lf9ds7yrzmy4ahqahu6mj8dv27wshep53qhv9kta

Profile Code

nprofile1qqs8kt3m2k84ap42vsg5a05jkc0zp3dj27mswm7dderkk908gtus6gsprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqyxhwumn8ghj7mn0wvhxcmmvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hssssvpy

Publishing to

relay.snort.social

nos.lol

relay.damus.io

Last Notes

2023-06-07 15:21:05 UTC

- reply

📅 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>