- network-health - lists.torproject.org

The format of snowflake-stats descriptors and collector-rs
by David Fifield 08 Jul '26

08 Jul '26

For the past 3 months, collector-rs has been making snowflake-stats tarballs in an incorrect format. The recently committed fix for this problem implies that the incorrect format was the result of the Snowflake broker changing the format of its metrics. But this is not the case: Snowflake broker metrics have always (since 2019) contained multiple days of metrics. This was by design, and Java Collector was always able to parse that format. Since the recent fix, collector-rs treats snowflake-stats as a special case ("skip_seed_for_archive"), but Java Collector didn't treat snowflake-stats as exceptional—it parsed snowflake-stats in the same way as other types that have multiple days of data in one file, like bridgedb-metrics and bridgestrap-stats, using a method called parseOneOrMoreDescriptors. In summary, the problem was with collector-rs not parsing the metrics files in the same way as Java Collector did, not because of any change in the output of the Snowflake broker. snowflake-stats is not really a special case, but the collector-rs code now treats it as a special case, which makes me wonder if it could be handled in a more uniform way. This is the issue for collector-rs serving an incorrect format for snowflake-stats tarballs: "Snowflake stats format is broken for April" https://gitlab.torproject.org/tpo/network-health/metrics/collector-rs/-/wor… This is the merge request that closes #48 along with many other things: "Rework archive/publish/sync pipeline; add bridge import; vote & dirauth fixes" https://gitlab.torproject.org/tpo/network-health/metrics/collector-rs/-/mer… I understand that the fix has two parts: 1. Changing the collector-rs to ignore all but the last "snowflake-stats-end": https://gitlab.torproject.org/tpo/network-health/metrics/collector-rs/-/mer… 2. Running a one-time fix_snowflake script that rewrites past downloaded files so that they contain only the last "snowflake-stats-end": https://gitlab.torproject.org/juga/collector-fixes/-/commit/7b0aa3170313cb4… I'll quote from fix_snowflake.rs, because I think it reveals the misunderstanding on the collector-rs side: //! `fix-snowflake` - trim bloated snowflake-stats files down to a single //! reporting period, both in `out/recent/snowflakes/` and in the monthly //! `out/archive/snowflakes/snowflake-stats-*.tar.xz` tarballs. //! //! ## Background //! //! The snowflake broker's `/metrics` endpoint is meant to return a single //! `snowflake-stats-end <date> <time> (86400 s)` reporting block per fetch. //! Starting around collector-rs's deployment in 2026, the broker began //! returning the **entire cumulative history** since 2024-09-19 on every //! fetch instead: every previous day's block concatenated, with the new //! day's block appended at the end. Every file collector-rs wrote during //! that window inherited that bloat verbatim - both the daily files in //! `out/recent/snowflakes/` and the entries written into the monthly //! archive tarballs. The format emitted by the broker /metrics endpoint is not "bloat" and it is not "incorrect". Nor did the format change at any point. Here's a Wayback capture that shows it worked like that in 2020: https://web.archive.org/web/20200619131042/https://snowflake-broker.torproj… The format was intentionally designed this way. Here is part of a conversation with Karsten when the metrics feature was originally designed: https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/work_i… To answer your earlier question above: having just the last 24 hours of data might be problematic if the metrics host goes down for, say, a weekend. Ideally, there would be at least a week of statistics available. Or maybe just accumulate new statistics forever, given the tiny amount of statistics per day. This is the way it is intended to work and the way it worked before. collector-rs should not treat the format as anomalous or unexpected. The old metrics/library had a test case with 2 descriptors in it, since 2019: https://gitlab.torproject.org/tpo/network-health/metrics/library/-/blob/2b6… This is how the old metrics/library handled snowflake-stats descriptors: https://gitlab.torproject.org/tpo/network-health/metrics/library/-/blob/2b6… } else if (firstLines.startsWith("@type snowflake-stats 1.") || firstLines.startsWith(Key.SNOWFLAKE_STATS_END.keyword + SP) || firstLines.contains(NL + Key.SNOWFLAKE_STATS_END.keyword + SP)) { return this.parseOneOrMoreDescriptors(rawDescriptorBytes, sourceFile, Key.SNOWFLAKE_STATS_END, SnowflakeStatsImpl.class); } It called parseOneOrMoreDescriptors with "snowflake-stats-end" as a delimiter. Then it iterated over parsed descriptor and handled each one individually: https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/blob/0… DescriptorParser descriptorParser = DescriptorSourceFactory.createDescriptorParser(); SortedSet<LocalDateTime> snowflakeStatsEnds = new TreeSet<>(); this.outputPathName = config.getPath(Key.OutputPath).toString(); for (Descriptor descriptor : descriptorParser.parseDescriptors( downloadedBytes, null, null)) { ... The important thing to note is that Snowflake is not at all a special case; the detectTypeAndParseDescriptors method calls parseOneOrMoreDescriptors for many different descriptor types (with different delimiters): https://gitlab.torproject.org/tpo/network-health/metrics/library/-/blob/2b6…

2 2

Mid-month descriptors from collector-rs?
by David Fifield 05 Jul '26

05 Jul '26

It used to be that the "archive" directory of collector.torproject.org would serve unchanging descriptor tarballs from past months, along with a more or less continuously updated tarball for the current month. But now it seems that there is no tarball for the current month. See here: https://collector.torproject.org/archive/bridge-descriptors/extra-infos/ https://web.archive.org/web/20260504132617/https://collector.torproject.org… The date is currently 2026-05-04, but the latest tarball is extra-infos-2026-04.tar.xz 2026-05-02 03:42 218M Is there a way to get, for example, descriptors from May 3, without waiting until the end of the month? There is the "recent" directory which might work, but it only goes back a few days. At this moment, "recent" covers from 2026-04-30 to 2026-05-04, but if I were to check on 2026-05-20, say, I might not be able to get descriptors from 2026-05-10. https://collector.torproject.org/recent/bridge-descriptors/extra-infos/ https://web.archive.org/web/20260504132701/https://collector.torproject.org… The reason I'm asking: When I make monthly graphs of snowflake bridges, I usually wait a few days into the next month and download the next month's descriptor to include it with the data. The reason is that the tarball for May, for example, contains descriptors that cover the end of April. Without including the beginning of the next month's data, I found, the last 1–2 days of the previous month's data can be incomplete. For example, I just used https://gitlab.torproject.org/dcf/snowflake-graphs to compute statistics using tarballs up to extra-infos-2026-04.tar.xz. This is showing just one bridge (which consists of 12 tor instances). Notice the last few days of April 2026, the "coverage" drops from from 12.0/12.0 to 9.95/12.0: date, fingerprint, transport, users, num_instances,coverage 2026-04-24,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14592.87,12.00,12.00 2026-04-25,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14615.31,12.00,12.00 2026-04-26,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14992.47,12.00,12.00 2026-04-27,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,15056.68,12.00,12.00 2026-04-28,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,15250.09,12.00,12.00 2026-04-29,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,15034.07,12.00,11.92 2026-04-30,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,12877.20,12.00,9.95 If I regenerate the statistics, manually including also the "recent" descriptors, the coverage gets "filled in" (and the users count correspondingly goes up): date, fingerprint, transport, users, num_instances,coverage 2026-04-24,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14592.87,12.00,12.00 2026-04-25,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14615.31,12.00,12.00 2026-04-26,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14992.47,12.00,12.00 2026-04-27,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,15056.68,12.00,12.00 2026-04-28,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,15250.09,12.00,12.00 2026-04-29,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,15099.58,12.00,12.00 2026-04-30,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14834.64,12.00,12.00 2026-05-01,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14781.53,12.00,12.00

2 3

April and May Microdescriptor Consensuses?
by Ellis Fenske 02 Jun '26

02 Jun '26

Hello, I am an academic working on some Tor research and am trying to download the microdescriptor consensuses and microdescriptors for May and April, and it seems on the CollecTor website that these consensuses are missing from the archive (along with many microdescriptors for April). The regular descriptors seem to be there for May, and recent microdescriptors consensuses are available (though the router status entries in them have future-dated timestamps), but I don't see a way to access the microdescriptor information for this time window. I was hoping you could let me know whether to expect this data to be filled in later, whether I'm misunderstanding something about the way the data is stored, or whether it's just missing. Thanks so much! -- -Ellis

2 2

Why are some recent relay extra-infos so much larger than others?
by David Fifield 18 May '26

18 May '26

The sizes of recent relay extra-info files are really non-uniform. Some are ≈2 MB, while a few are around 100 MB. Why is that? https://collector.torproject.org/recent/relay-descriptors/extra-infos/ https://web.archive.org/web/20260504124134/https://collector.torproject.org… The timestamps of the larger files are around 02:15. collector.torproject.org/recent/relay-descriptors/extra-infos$ du -b * | awk '{printf "%s %9d\n", $2, $1}' 2026-04-30-14-11-19-extra-infos 1276042 2026-04-30-15-14-46-extra-infos 1247336 2026-04-30-16-10-53-extra-infos 2855275 2026-04-30-17-15-35-extra-infos 1753035 2026-04-30-18-15-14-extra-infos 2060495 2026-04-30-19-12-44-extra-infos 2660025 2026-04-30-20-14-53-extra-infos 1568362 2026-04-30-21-13-22-extra-infos 1761678 2026-04-30-22-12-10-extra-infos 1413393 2026-04-30-23-12-17-extra-infos 1905710 2026-05-01-00-11-08-extra-infos 1752284 2026-05-01-01-11-37-extra-infos 1534231 2026-05-01-02-15-15-extra-infos 111364852 2026-05-01-02-16-14-extra-infos 1901771 2026-05-01-03-10-54-extra-infos 2386246 2026-05-01-04-13-07-extra-infos 2167008 2026-05-01-05-13-50-extra-infos 1885811 2026-05-01-06-11-28-extra-infos 1963598 2026-05-01-07-14-22-extra-infos 2573871 2026-05-01-08-12-47-extra-infos 1420773 2026-05-01-09-14-42-extra-infos 1172538 2026-05-01-10-11-11-extra-infos 2023018 2026-05-01-11-14-24-extra-infos 2755937 2026-05-01-12-14-47-extra-infos 2134339 2026-05-01-13-10-51-extra-infos 2432106 2026-05-01-14-12-04-extra-infos 1463049 2026-05-01-15-13-41-extra-infos 1408304 2026-05-01-16-11-20-extra-infos 1214815 2026-05-01-17-14-52-extra-infos 1760421 2026-05-01-18-13-18-extra-infos 1674648 2026-05-01-19-14-23-extra-infos 1702962 2026-05-01-20-13-36-extra-infos 1737346 2026-05-01-21-10-54-extra-infos 1926319 2026-05-01-22-12-52-extra-infos 1667868 2026-05-01-23-10-44-extra-infos 1555635 2026-05-02-00-13-03-extra-infos 1999089 2026-05-02-01-11-28-extra-infos 2173352 2026-05-02-02-15-32-extra-infos 100456075 2026-05-02-02-15-58-extra-infos 1528017 2026-05-02-03-16-55-extra-infos 1789647 2026-05-02-04-14-34-extra-infos 2824311 2026-05-02-05-13-56-extra-infos 2511073 2026-05-02-06-15-40-extra-infos 1742844 2026-05-02-07-11-59-extra-infos 2570830 2026-05-02-08-12-55-extra-infos 1371061 2026-05-02-09-14-25-extra-infos 1628251 2026-05-02-10-13-19-extra-infos 1571755 2026-05-02-11-11-02-extra-infos 1821608 2026-05-02-12-12-16-extra-infos 1371271 2026-05-02-13-11-58-extra-infos 1661234 2026-05-02-14-11-01-extra-infos 1574868 2026-05-02-15-11-16-extra-infos 1242763 2026-05-02-16-10-51-extra-infos 1342396 2026-05-02-17-12-29-extra-infos 1888936 2026-05-02-18-13-52-extra-infos 2304888 2026-05-02-19-12-30-extra-infos 2062860 2026-05-02-20-10-59-extra-infos 1352409 2026-05-02-21-14-36-extra-infos 1781758 2026-05-02-22-14-43-extra-infos 2905690 2026-05-02-23-11-41-extra-infos 1102832 2026-05-03-00-14-02-extra-infos 2498869 2026-05-03-01-13-17-extra-infos 2065183 2026-05-03-02-11-55-extra-infos 1270464 2026-05-03-02-15-15-extra-infos 95955891 2026-05-03-03-12-59-extra-infos 1642662 2026-05-03-04-12-22-extra-infos 1666690 2026-05-03-05-14-40-extra-infos 1917854 2026-05-03-06-11-22-extra-infos 1521837 2026-05-03-07-14-49-extra-infos 2303808 2026-05-03-08-12-57-extra-infos 1712003 2026-05-03-09-13-51-extra-infos 1186784 2026-05-03-10-12-13-extra-infos 1366221 2026-05-03-11-15-02-extra-infos 2046367 2026-05-03-12-15-20-extra-infos 1850313 2026-05-03-13-12-08-extra-infos 1817772 2026-05-03-14-11-49-extra-infos 1906482 2026-05-03-15-10-58-extra-infos 1995252 2026-05-03-16-11-14-extra-infos 2764421 2026-05-03-17-14-16-extra-infos 2263420 2026-05-03-18-11-22-extra-infos 1383370 2026-05-03-19-15-02-extra-infos 2885490 2026-05-03-20-13-33-extra-infos 1640791 2026-05-03-21-13-50-extra-infos 1704498 2026-05-03-22-15-00-extra-infos 1998454 2026-05-03-23-12-27-extra-infos 1963243 2026-05-04-00-11-32-extra-infos 1576046 2026-05-04-01-11-25-extra-infos 2282145 2026-05-04-02-15-22-extra-infos 97728439 2026-05-04-02-16-07-extra-infos 1823340 2026-05-04-03-11-09-extra-infos 1136708 2026-05-04-04-13-17-extra-infos 733055 2026-05-04-05-12-45-extra-infos 2051394 2026-05-04-06-12-31-extra-infos 1921639 2026-05-04-07-14-56-extra-infos 540867 2026-05-04-08-14-21-extra-infos 1347267 2026-05-04-09-12-37-extra-infos 757562 2026-05-04-10-17-40-extra-infos 5263330 2026-05-04-11-14-42-extra-infos 1783890 2026-05-04-12-14-28-extra-infos 1537615 2026-05-04-13-13-04-extra-infos 2080428

2 1

Explanation on (negative) spikes in number of relays
by ttlns 19 Apr '26

19 Apr '26

Around 2 weeks ago, I posted the following concerns regarding "negative spikes" for the number of relays measured by metrics.torproject.org [1] in forum.torproject.org [2] (and earlier on r/TOR [3] ) : > Are there any good explanations on why these spikes occurred? > Might those outages imply some centralized infrastructure? If so, how is that not a major concern? So far, I have not received any definite explanations. If those spikes happen to be measurement errors, I imagine that there should be logs somewhere to support this explanation. 3. Does such evidence exist publicly? 4. If not (3), where would that evidence be stored? Sources: [1] http://metrics.torproject.org/networksize.html?start=2022-01-01&end=2026-03… [2] https://forum.torproject.org/t/explanation-on-negative-spikes-in-number-of-… [3] https://www.reddit.com/r/TOR/comments/1s8wx24/explanation_on_spikes_in_numb… I appreciate any clues, hints, or pointers on where to ask further. Best, ttlns

2 5

Less that two weeks old?
by Johannes Kingma 18 Apr '26

18 Apr '26

https://metrics.torproject.org/rs.html#details/DB16235B1337EEE3D0004F83EF29… I read "This relay appears to be less than 2 weeks old.This blog post <https://blog.torproject.org/lifecycle-new-relay>explains the lifecycle of a new relay, and why it will not be immediately fully used to capacity." But in fact it show history back to about 1.5 years. Has been rebooted less that 2 week ago would be better.

1 0

incorrect data on metrics.torproject.org relay search
by txt.file 14 Apr '26

14 Apr '26

Please explain how a Tor relay can have graphs on https://metrics.torproject.org/rs.html#details/506C582367B6ABED6EEF3936DCEB… since 2023-02-17 but at the same time have "First Seen 2026-04-06 23:00:00 (7 days 9 hours 22 minutes and 50 seconds)" in the data. Why has the "first seen" of my 3 year old relay reset? regards txt.file PS: Am not subscribed to this list.

2 1

500 Internal Server Error on TorMetrics site
by mossy_road_523 17 Mar '26

17 Mar '26

Repeatdly getting a "500 Internal Server Error" on the Tor Metrics website. Happens when I visit the Users page and click either the "Top 10 Countries by Relay Users" or "Top 10 Countries by Bridge Users" links. All other links on that page (Tor Metrics --> Users) work. Sent with [Proton Mail](https://proton.me/mail/home) secure email.

2 1

Possibly invalid "First seen" metadata in metrics.torproject.org
by Eric Cheng 11 Mar '26

11 Mar '26

Hi all, I checked a few webtunnel bridges, and their "First seen" dates are all showing "1970-01-01 00:00:00". https://metrics.torproject.org/rs.html#details/7A78527DBDB7EFF85E5AA926A1B9… https://metrics.torproject.org/rs.html#details/6996BC2264025E9A87D51324CF56… https://metrics.torproject.org/rs.html#details/81895A2C4E22E861615DD9127543… For the top relays, I checked a few, and instead of showing the year 1970, they showed dates with times exactly at certain hours. I feel like this kind of coincidence is weird. 2024-08-25 00:00:00 https://metrics.torproject.org/rs.html#details/9AB93B5422149E5DFF4BE6A3814E… 2025-06-26 21:00:00 https://metrics.torproject.org/rs.html#details/5835631C79E55CDFDCF9E2D14CB9… 2019-02-18 00:00:00 https://metrics.torproject.org/rs.html#details/9AB93B5422149E5DFF4BE6A3814E… Is this correct behavior? Information for relays was published: 2026-02-27 05:00:00 UTC. Information for bridges was published: 2026-02-27 03:57:24 UTC. Thanks, Eric

4 3

Exit Relay DNS Health Module for Exitmap - Seeking Guidance Before Deployment
by Tor at 1AEO 22 Feb '26

22 Feb '26

Hi Network Health Team, A few large-scale exit relay operators have asked for better visibility into DNS health across their relays. We've built an exitmap module, dnshealth, to address this and want your input before we start running scans and publishing results. What It Does - Generates unique DNS queries per relay (wildcard subdomain → expected IP) to avoid caches - Classifies failures: timeout, NXDOMAIN, wrong IP, SOCKS errors - Outputs structured JSON with latency and error details All code is open source: https://github.com/1aeo/exitmap Initial testing: ~98% success rate across ~3k exits, 50-90 true failures per scan, 4-8 min runtime. Before We Proceed 1. Any concerns with us running regular scans and publishing results? 2. Recommendations on scan frequency or methodology? Happy to adjust our approach based on your guidance.

3 6