From b496e684233bbdd65b9e70abeb2fc77af221a3fb Mon Sep 17 00:00:00 2001 From: Brian Cunnie Date: Thu, 20 Jan 2022 09:29:06 -0800 Subject: [PATCH] Website explains what each metric means Drive-by: updated publishing docs. --- docs/DEVELOPER.md | 1 + k8s/document_root/index.html | 43 ++++++++++++++++++++++++++++++++++++ 2 files changed, 44 insertions(+) diff --git a/docs/DEVELOPER.md b/docs/DEVELOPER.md index 508cfd9..6fc2e47 100644 --- a/docs/DEVELOPER.md +++ b/docs/DEVELOPER.md @@ -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 ``` diff --git a/k8s/document_root/index.html b/k8s/document_root/index.html index 17a9549..d2aacf6 100644 --- a/k8s/document_root/index.html +++ b/k8s/document_root/index.html @@ -289,6 +289,49 @@ dig @ns-azure.sslip.io txt version.status.sslip.io +short "- version TXT: 2" "- DNS-01 challenge: 2" +
Explanation of Metrics
+
+
uptime
+
The time since the DNS server has been started, in seconds
+
key-value store
+
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".
+
uptime
+
The time since the DNS server has been started, in seconds
+
queries
+
The raw number of DNS queries that the server has responded to since starting operation
+
queries/second
+
The raw number of DNS queries that the server has responded to since starting operation divided by the + number of seconds
+
successful
+
"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")
+
A
+
The number of responses which included an IPv4 record since starting operation (e.g. "dig + 127.0.0.1.sslip.io")
+
AAAA
+
The number of responses which included an IPv6 record since starting operation (e.g. "dig --1.sslip.io + aaaa")
+
source IP TXT
+
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")
+
version TXT
+
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")
+
DNS-01 Challenge
+
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")
+