zishuo/nip
1
0
Fork 0
mirror of https://github.com/cunnie/sslip.io.git synced 2025-10-16 12:40:37 +08:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Website explains what each metric means

Browse Source 
Drive-by: updated publishing docs.
This commit is contained in:
Brian Cunnie
2022-01-20 09:29:06 -08:00
parent bbf1925be4
commit b496e68423
2 changed files with 44 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
docs/DEVELOPER.md
View File

@@ -90,6 +90,7 @@ ssh ns-aws sudo shutdown -r now
- Drag and drop `~/Downloads/sslip.io-release-${VERSION}.tgz` to the _Attach
binaries..._ section
- Drag and drop the executables in `bin/` to the _Attach binaries..._ section.
- Click "Publish release"
```bash
fly -t nono trigger-job -j dockerfiles/build-and-push-sslip.io-dns-server
```

43
k8s/document_root/index.html
View File

@@ -289,6 +289,49 @@ dig @ns-azure.sslip.io txt version.status.sslip.io +short
"- version TXT: 2"
"- DNS-01 challenge: 2"
</pre>
<h5>Explanation of Metrics</h5>
<dl>
<dt>uptime</dt>
<dd>The time since the DNS server has been started, in seconds</dd>
<dt>key-value store</dt>
<dd>This can be one of two values: "builtin" and "etcd". "builtin" means any changes to key/value are limited
to that specific DNS server. "etcd" means changes are propagated to all servers whose key-value store is
"etcd".</dd>
<dt>uptime</dt>
<dd>The time since the DNS server has been started, in seconds</dd>
<dt>queries</dt>
<dd>The raw number of DNS queries that the server has responded to since starting operation</dd>
<dt>queries/second</dt>
<dd>The raw number of DNS queries that the server has responded to since starting operation divided by the
number of seconds</dd>
<dt>successful</dt>
<dd>"successful" means the number of queries for which at least one record was returned as an answer (at least
one record in the ANSWER section). Note that the number of successful queries is typically a third or fourth
the size of the overall queries. This is normal. One reason for this disparity is that often both the IPv4 (A)
and IPv6 (AAAA) records will be checked, but only one record is returned (successful). For example, browsing to
"127.0.0.1.sslip.io" generates two lookups, one successful (IPv4), and one not (IPv6). Another reason is that
lookups follow a chain, e.g. looking up "127.0.0.1.sslip.io" may generate up to four queries for A records
("1.sslip.io", "0.1.sslip.io", "0.0.1.sslip.io" and "127.0.0.1.sslip.io"), only the last of which is
successful. Pro-tip: if you want to shave milliseconds off name resolution, use dashes not dots in your
hostname (e.g. "10-9-9-30.sslip.io" instead of "10.9.9.30.sslip.io")</dd>
<dt>A</dt>
<dd>The number of responses which included an IPv4 record since starting operation (e.g. "dig
127.0.0.1.sslip.io")</dd>
<dt>AAAA</dt>
<dd>The number of responses which included an IPv6 record since starting operation (e.g. "dig --1.sslip.io
aaaa")</dd>
<dt>source IP TXT</dt>
<dd>The number of responses which included a TXT record of the querier's IP address since starting operation
(e.g. "dig @ns.sslip.io ip.sslip.io txt")</dd>
<dt>version TXT</dt>
<dd>The number of responses which included a TXT record of the DNS's servers version since starting operation
(e.g. "dig @ns-azure.sslip.io version.status.sslip.io txt")</dd>
<dt>DNS-01 Challenge</dt>
<dd>The number of responses which included a delegation of the NS (nameserver). This lookup is used for
generating wildcard certificates from Let's Encrypt. Technically this is not a "successful" query in that we
don't return a record in the ANSWER section, but we do return an NS record in the AUTHORITY section. (e.g. "dig
@ns-gce.sslip.io _acme-challenge.192.168.0.1.sslip.io. soa")</dd>
</dl>
<h3 id="related">Related Services</h3>
<ul>
<li>