Merge pull request #14770 from omoerbeek/rec-docs-metrics

rec: generate metrics docs when publishing

.github/workflows/documentation.yml

@@ -62,6 +62,8 @@ jobs:
         if: ${{github.ref_name == 'master' && steps.setup-ssh.outputs.have_ssh_key != ''}}
 
       # Rec
+      - run: inv ci-metrics-rec-generate
+        working-directory: ./pdns/recursordist
       - run: inv ci-docs-rec-generate
         working-directory: ./pdns/recursordist/settings
       - run: inv ci-docs-build

pdns/recursordist/docs/changelog/4.1.rst

@@ -933,7 +933,7 @@ See :doc:`EOL Statements <../appendices/EOL>`.
     :tags: Improvements
     :pullreq: 5774
 
-    Add :ref:`experimental metrics <stat-x-our-latency>` that track the time spent inside PowerDNS per query.
+    Add experimental :doc:`../metrics` ``x-our-latency`` that track the time spent inside PowerDNS per query.
     These metrics ignore time spent waiting for the network.
 
   .. change::

pdns/recursordist/docs/performance.rst

@@ -205,15 +205,15 @@ If you expect few clients, you can increase :ref:`setting-max-concurrent-request
 If you expect many clients and you have increased :ref:`setting-max-tcp-clients`, reduce :ref:`setting-max-concurrent-requests-per-tcp-connection` number to prevent mthread starvation or increase the maximum number of mthreads.
 
 To increase the maximum number of concurrent queries consider increasing  :ref:`setting-max-mthreads`, but be aware that each active mthread consumes more than 200k of memory.
-To see the current number of mthreads in use consult the :ref:`stat-concurrent-queries` metric.
-If a query could not be handled due to mthread shortage, the :ref:`stat-over-capacity-drops` metric is increased.
+To see the current number of mthreads in use consult the :doc:`metrics` ``concurrent-queries`` metric.
+If a query could not be handled due to mthread shortage, the ``over-capacity-drops`` metric is increased.
 
 As an example, if you have typically 200 TCP clients, and the default maximum number of mthreads of 2048, a good number of concurrent requests per TCP connection would be 5. Assuming a worst case packet cache hit ratio, if all 200 TCP clients fill their connections with queries, about half (5 * 200) of the mthreads would be used by incoming TCP queries, leaving the other half for incoming UDP queries.
 Note that starting with version 5.0.0, TCP queries are processed by dedicated TCP thread(s), so the sharing of mthreads between UDP and TCP queries no longer applies.
 
 The total number of incoming TCP connections is limited by :ref:`setting-max-tcp-clients`.
 There is also a per client address limit: :ref:`setting-max-tcp-per-client` to limit the impact of a single client.
-Consult the :ref:`stat-tcp-clients` metric for the current number of TCP connections and the :ref:`stat-tcp-client-overflow` metric to see if client connection attempts were rejected because there were too many existing connections from a single address.
+Consult the :doc:`metrics` ``tcp-clients`` metric for the current number of TCP connections and the ``tcp-client-overflow`` metric to see if client connection attempts were rejected because there were too many existing connections from a single address.
 
 .. _tcp-fast-open-support:
 

tasks.py

@@ -355,6 +355,10 @@ def ci_autoconf(c, meson=False):
 def ci_docs_rec_generate(c):
     c.run('python3 generate.py')
 
+@task
+def ci_metrics_rec_generate(c):
+    c.run('python3 metrics.py')
+
 @task
 def ci_docs_build(c):
     c.run('make -f Makefile.sphinx -C docs html')