Update readme files for metrics (#2000)

README.md

@@ -105,8 +105,69 @@ On CentOS check `/etc/sysconfig/iptables` for IPTables rules. For other distribu
 
 ZeroTier One peers will automatically locate each other and communicate directly over a local wired LAN *if UDP port 9993 inbound is open*. If that port is filtered, they won't be able to see each others' LAN announcement packets. If you're experiencing poor performance between devices on the same physical network, check their firewall settings. Without LAN auto-location peers must attempt "loopback" NAT traversal, which sometimes fails and in any case requires that every packet traverse your external router twice.
 
-Users behind certain types of firewalls and "symmetric" NAT devices may not able able to connect to external peers directly at all. ZeroTier has limited support for port prediction and will *attempt* to traverse symmetric NATs, but this doesn't always work. If P2P connectivity fails you'll be bouncing UDP packets off our relay servers resulting in slower performance. Some NAT router(s) have a configurable NAT mode, and setting this to "full cone" will eliminate this problem. If you do this you may also see a magical improvement for things like VoIP phones, Skype, BitTorrent, WebRTC, certain games, etc., since all of these use NAT traversal techniques similar to ours.
+Users behind certain types of firewalls and "symmetric" NAT devices may not be able to connect to external peers directly at all. ZeroTier has limited support for port prediction and will *attempt* to traverse symmetric NATs, but this doesn't always work. If P2P connectivity fails you'll be bouncing UDP packets off our relay servers resulting in slower performance. Some NAT router(s) have a configurable NAT mode, and setting this to "full cone" will eliminate this problem. If you do this you may also see a magical improvement for things like VoIP phones, Skype, BitTorrent, WebRTC, certain games, etc., since all of these use NAT traversal techniques similar to ours.
 
 If a firewall between you and the Internet blocks ZeroTier's UDP traffic, you will fall back to last-resort TCP tunneling to rootservers over port 443 (https impersonation). This will work almost anywhere but is *very slow* compared to UDP or direct peer to peer connectivity.
 
 Additional help can be found in our [knowledge base](https://zerotier.atlassian.net/wiki/spaces/SD/overview).
+
+### Prometheus Metrics
+
+Prometheus Metrics are available at the `/metrics` API endpoint.  This endpoint is protected by an API key stored in `authtoken.secret` because of the possibility of information leakage.  Information that could be gleaned from the metrics include joined networks and peers your instance is talking to. 
+
+Access control is via the ZeroTier control interface itself and `authtoken.secret`. This can be sent as the `X-ZT1-Auth` HTTP header field or appended to the URL as `?auth=<token>`. You can see the current metrics via `cURL` with the following command:
+
+    // Linux
+    curl -H "X-ZT1-Auth: $(sudo cat /var/lib/zerotier-one/authtoken.secret)" http://localhost:9993/metrics
+
+    // macOS
+    curl -H "X-XT1-Auth: $(sudo cat /Library/Application\ Support/ZeroTier/One/authtoken.secret)" http://localhost:9993/metrics
+
+    // Windows PowerShell (Admin)
+    Invoke-RestMethod -Headers @{'X-ZT1-Auth' = "$(Get-Content C:\ProgramData\ZeroTier\One\authtoken.secret)"; } -Uri http://localhost:9993/metrics
+
+To configure a scrape job in Prometheus on the machine ZeroTier is running on, add this to your Prometheus `scrape_config`:
+
+    - job_name: zerotier-one
+      honor_labels: true
+      scrape_interval: 15s
+      metrics_path: /metrics
+      static_configs:
+      - targets:
+        - 127.0.0.1:9993
+        labels:
+          group: zerotier-one
+      params:
+        auth:
+        - $YOUR_AUTHTOKEN_SECRET
+
+If your Prometheus instance is remote from the machine ZeroTier instance, you'll have to edit your `local.conf` file to allow remote access to the API control port.  If your local lan is `10.0.0.0/24`, edit your `local.conf` as follows:
+
+    {
+      "settings": {
+        "allowManagementFrom:" ["10.0.0.0/24"]
+      }
+    }
+
+Substitute your actual network IP ranges as necessary.
+
+It's also possible to access the metrics & control port over the ZeroTier network itself via the same method shown above.  Just add the address range of your ZeroTier network to the list. NOTE: Using this method means that anyone with your auth token can control your ZeroTier instance, including leaving & joining other networks.
+
+If neither of these methods are desirable, it is probably possible to distribute metrics via [Prometheus Proxy](https://github.com/pambrose/prometheus-proxy) or some other tool.  Note: We have not tested this internally, but will probably work with the correct configuration.
+
+#### Available Metrics
+
+| Metric Name | Labels | Metric Type | Description |
+| ---         | ---    | ---         | ---         |
+| zt_packet | packet_type, direction | Counter | ZeroTier packet type counts |
+| zt_packet_error | error_type, direction | Counter | ZeroTier packet errors|
+| zt_data | protocol, direction | Counter | number of bytes ZeroTier has transmitted or received |
+| zt_num_networks | | Gauge | number of networks this instance is joined to |
+| zt_network_multicast_groups_subscribed | network_id | Gauge | number of multicast groups networks are subscribed to |
+| zt_network_packets | network_id, direction | Counter | number of incoming/outgoing packets per network |
+| zt_peer_latency | node_id | Histogram | peer latency (ms) |
+| zt_peer_path_count | node_id, status | Gauge | number of paths to peer |
+| zt_peer_packets | node_id, direction | Counter | number of packets to/from a peer |
+| zt_peer_packet_errors | node_id | Counter | number of incoming packet errors from a peer |
+
+If there are other metrics you'd like to see tracked, ask us in an Issue or send us a Pull Request!