<html><head></head><body><div class="ydp15553396yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div>
        <div>I have to agree with Bleedangel on both points that they make: 1. Attempting to troubleshoot a relay every 3 days takes some serious patience and 2. Guidance in setting up PortMetrics is as important as understanding is output.</div><div><br></div><div>Excellent Suggestions!</div><div><br></div><div>Respectfully,</div><div><br></div><div><br></div><div>Gary</div><div><br></div><div><br></div>
        
        <div id="ydp15553396yahoo_quoted_4426221149" class="ydp15553396yahoo_quoted">
            <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
                
                <div>
                    On Wednesday, October 6, 2021, 12:48:31 AM PDT, Bleedangel Tor Admin <tor@bleedangel.com> wrote:
                </div>
                <div><br></div>
                <div><br></div>
                <div><div dir="ltr">-----BEGIN PGP SIGNED MESSAGE-----<br clear="none">Hash: SHA512<br clear="none"><br clear="none">This is much more informational. Great job!<br clear="none"><br clear="none">As someone with mystery "overloaded" problems, i'd recommend / request / beg for the following:<br clear="none"><br clear="none">1) When the relay is overloaded, a yellow indicator appears on the web page. This indicator remains for 72 hours after the overloaded state is remedied.<br clear="none">- This is not helpful in diagnosing anything, because even if the problem is solved, it is not evident that the relay is no longer overloaded for 72 hours.<br clear="none">-- once the relay is no longer overloaded, it should have a purple (or any other color) "recovery" indicator for 72 hours. At least the relay operator would know that the overloaded state has been repaired.<br clear="none"><br clear="none">2) metricsport<br clear="none">- This is such an enigma to someone who is not familiar with prometheus, or torrc beyond the basics. As a matter of fact, when installing the tor-git package on Arch Linux, the man pages dont install automatically, so 'man torrc' gives a very helpful:<br clear="none"><br clear="none">$ man torrc<br clear="none">No manual entry for torrc<br clear="none"><br clear="none">The official tor website, under manuals section, -alpha: <a shape="rect" href="https://2019.www.torproject.org/docs/tor-manual-dev.html.en" rel="nofollow" target="_blank">https://2019.www.torproject.org/docs/tor-manual-dev.html.en</a><br clear="none">does not include the documentation for metricsport.<br clear="none"><br clear="none">i think the troubleshooting guide should contain directions to enable metricsport, and how to view the results:<br clear="none"><br clear="none">...<br clear="none"><br clear="none">To enable metricsport for advanced diagnosis:<br clear="none"><br clear="none">In torrc set MetricsPort and MetricsPortPolicy flags as follows:<br clear="none"><br clear="none">MetricsPort <server ip address>:<port><br clear="none">MetricsPortPolicy accept <ip address to accept metricsport queries from><br clear="none"><br clear="none">it is good policy to only allow connections to the metricsport port from localhost as follows:<br clear="none"><br clear="none">MetricsPort 127.0.0.1:9035               #This will open the metricsport server on port 9035, listening on localhost (127.0.0.1).<br clear="none">MetricsPortPolicy accept 127.0.0.1       #This will allow only localhost (127.0.0.0) to query the metricsport server.<br clear="none"><br clear="none">Once these are set and the configuration reloaded (via SIGHUP or tor restart), the data can be queried as follows:<br clear="none"><br clear="none">wget <a shape="rect" href="http://127.0.0.1:9035/metrics " rel="nofollow" target="_blank">http://127.0.0.1:9035/metrics </a>-O metricsport.txt<br clear="none"><br clear="none">This will place a file in the current directory called 'metricsport.txt' that can be used to troubleshoot the overloaded relay issues via the information in this document<br clear="none"><br clear="none">...<br clear="none"><br clear="none"><br clear="none"><br clear="none">‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br clear="none"><div class="ydp15553396yqt9285135662" id="ydp15553396yqtfd31462"><br clear="none">On Tuesday, October 5th, 2021 at 4:33 PM, Silvia/Hiro <<a shape="rect" href="mailto:hiro@torproject.org" rel="nofollow" target="_blank">hiro@torproject.org</a>> wrote:<br clear="none"><br clear="none">> On 10/4/21 1:36 PM, David Goulet wrote:<br clear="none">><br clear="none">> > On 02 Oct (01:29:56), torix via tor-relays wrote:<br clear="none">> ><br clear="none">> > > My relays (Aramis) marked overloaded don't make any sense either. Two of<br clear="none">> > ><br clear="none">> > > the ones marked with orange are the two with the lowest traffic I have (2-5<br clear="none">> > ><br clear="none">> > > MiB/s and 4-9 MiB/s - not pushing any limits here); the third one with that<br clear="none">> > ><br clear="none">> > > host has more traffic and is fine.<br clear="none">> > ><br clear="none">> > > So far this indicator seems to be no help to me.<br clear="none">> ><br clear="none">> > Keep in mind that the overload state might not be only about traffic capacity.<br clear="none">> ><br clear="none">> > Like this page states, there other factors including CPU and memory pressure.<br clear="none">> ><br clear="none">> > <a shape="rect" href="https://support.torproject.org/relay-operators/relay-bridge-overloaded/" rel="nofollow" target="_blank">https://support.torproject.org/relay-operators/relay-bridge-overloaded/</a><br clear="none">> ><br clear="none">> > We are in a continuous process of making it better with feedback from the<br clear="none">> ><br clear="none">> > relay community. It is a hard problem because so many things can change or<br clear="none">> ><br clear="none">> > influence things. And different OSes also makes it challenging.<br clear="none">> ><br clear="none">> > Another thing here to remember, the overload state will be set for 72 hours<br clear="none">> ><br clear="none">> > even if a SINGLE overload event occurred.<br clear="none">> ><br clear="none">> > For more details:<br clear="none">> ><br clear="none">> > <a shape="rect" href="https://lists.torproject.org/pipermail/tor-relays/2021-September/019844.html" rel="nofollow" target="_blank">https://lists.torproject.org/pipermail/tor-relays/2021-September/019844.html</a><br clear="none">> ><br clear="none">> > (FYI, we are in the process of adding this information in the support page ^).<br clear="none">><br clear="none">> We have now updated the support article at:<br clear="none">><br clear="none">> <a shape="rect" href="https://support.torproject.org/relay-operators/relay-bridge-overloaded/" rel="nofollow" target="_blank">https://support.torproject.org/relay-operators/relay-bridge-overloaded/</a><br clear="none">><br clear="none">> We have tried to clarify how and why the overloaded state is triggered.<br clear="none">><br clear="none">> I hope this can help operators understand better why their relays can be<br clear="none">><br clear="none">> found in this state and how a normal state can be recovered.<br clear="none">><br clear="none">> Please do let us know what you think.<br clear="none">><br clear="none">> Cheers,<br clear="none">><br clear="none">> -hiro<br clear="none">><br clear="none">> > If you can't find sticking out, that is OK, you can move on and see if it<br clear="none">> ><br clear="none">> > continues to stick. If so, maybe its worth digging more and when 0.4.7 will be<br clear="none">> ><br clear="none">> > stable, you'll be able to enable the MetricsPort (man tor) to get into the<br clear="none">> ><br clear="none">> > rabbit hole a bit deeper.<br clear="none">> ><br clear="none">> > Cheers!<br clear="none">> ><br clear="none">> > David<br clear="none">> ><br clear="none">> > tor-relays mailing list<br clear="none">> ><br clear="none">> > <a shape="rect" href="mailto:tor-relays@lists.torproject.org" rel="nofollow" target="_blank">tor-relays@lists.torproject.org</a><br clear="none">> ><br clear="none">> > <a shape="rect" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays" rel="nofollow" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br clear="none">><br clear="none">> tor-relays mailing list<br clear="none">><br clear="none">> <a shape="rect" href="mailto:tor-relays@lists.torproject.org" rel="nofollow" target="_blank">tor-relays@lists.torproject.org</a><br clear="none">><br clear="none">> <a shape="rect" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays" rel="nofollow" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a></div><br clear="none">-----BEGIN PGP SIGNATURE-----<br clear="none">Version: ProtonMail<br clear="none"><br clear="none">wnUEARYKAAYFAmFcv8UAIQkQ07hp34FMyg4WIQSgEMifmnN5ohFWvfnTuGnf<br clear="none">gUzKDudLAP9iwogPbk+q1zBA+90BmT0dSnvq4vR0o8Jpr1H7NmWHQQEAizx8<br clear="none">9zAgec3xOKEM+f4cqgcGDwKUK3OT2P8sFrW0xwE=<br clear="none">=Dp/H<br clear="none">-----END PGP SIGNATURE-----<div class="ydp15553396yqt9285135662" id="ydp15553396yqtfd60185"><br clear="none"></div></div><div class="ydp15553396yqt9285135662" id="ydp15553396yqtfd06656">_______________________________________________<br clear="none">tor-relays mailing list<br clear="none"><a shape="rect" href="mailto:tor-relays@lists.torproject.org" rel="nofollow" target="_blank">tor-relays@lists.torproject.org</a><br clear="none"><a shape="rect" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays" rel="nofollow" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br clear="none"></div></div>
            </div>
        </div></div></body></html>