[metrics-team] Bringing back Tor Weather - volunteering developer

[Damian Johnson]

>>> Lets not replicate checks that can already be done with available services like uptimerobot.com or
>>> are already done by dir auths.
>>
>> Hi nusenu. Sorry, I might be missing something but I'm unsure how
>> uptimerobot.com would check tor relays. Unlike stem, it doesn't speak
>> the ORPort protocol.
>
> sorry for being unclear. I was not trying to say that uptimerobot covers
> everything that your stem script does. uptimerobot just checks if it can
> establish a TCP connection to the ORPort listener - so it detects if
> tor died or if it is not reachable.
>
> Do you see any error condition that is detected by your stem script
> that is not detectable by using consensus or onionoo data?
> (and that error condition happened already once to your relay)
>
> I assume such error conditions are rare?

That cron establishing a 1-hop circuit to my relay to download its
descriptor as tor clients would. This is deeper than a simple tcp
probe (hell, you could host a website at a relay's endpoint to get
that to pass). That said, in practice this might be overkill. Simply
checking the consensus would catch 99% of of issues.

I brought this up because if we're using stem to download the
consensus then it's just a couple more lines of code to do such a
check.

On a side note what are the benefits of using Onionoo rather than
merely downloading the hourly consensus? Unless I'm missing something
Onionoo is an unhelpful dependency to take here.

Cheers! -Damian