Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
T
Tor
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,064
    • Issues 1,064
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 17
    • Merge Requests 17
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • The Tor Project
  • Core
  • Tor
  • Issues
  • #40063

Closed
Open
Opened Jul 24, 2020 by David Goulet@dgoulet😈Owner

stats: Create a stat exporter port for monitoring purposes

The Control Port does basically export a lot of data that tor holds but this new Stat Port (we'll call that for now) differs in a couple of ways.

The idea is that it would be a pull mechanism so tools connect to the port, request a series of stats, tor sends it and then disconnects. This follows the Prometheus model which is to expose your stats through an HTTP interface and the monitoring server just comes in regularly and get the data.

Tor has already everything to support that that is listener port and HTTP interface we can hook on (with a bit of work :).

We can export all sorts of stats useful for monitoring relays and onion services. For example, for onion service monitoring, exporting these would be game changer for service operators:

  1. Amount of traffic the .onion is getting
  2. Amount of introduction requests
  3. Amount of rendezvous requests and how many succeeds vs fails.
  4. Descriptor status with HSDir ...

The reason it differs from the Control Port is that most public relays or onion services would prefer not having that port open especially on a public address. But also, this follows the concept of providing a REST interface which would be very little amount of work for the tor daemon where with the control port, is often a mixed of poking at our internal state instead of a pre-populated memory with stats.

There is of course the question of data safety here. If we build nice interface that in couple clicks allows operators to have beautiful Grafana graphs, then some says it is an incentive to export it and sometimes publicly.

However, this is really not different from the Control Port or Nyx monitoring interface. The problem shows up when the third part tool gathering the data actually archives. That today, is doable. This would yes be lowering the bar for this to happen but I think the ability to properly monitor a relay or an onion service outweigh the cons.

We could see that at first it is only for onion services and on a non public port. We could think of security checks like this but in the end, this is would just be another tool in the service operator belt to properly monitor tor if they choose to with of course risks associated with it like anything tor opens.

This is one example that @ahf worked on but with a push model: https://github.com/ahf/tor/tree/ahf/feature/stats_reporter

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Tor: 0.4.5.x-stable
Milestone
Tor: 0.4.5.x-stable (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: tpo/core/tor#40063