starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #2032] Prometheus metrics #855

New issue

Closed

opened 2026-03-16 00:35:58 +03:00 by kerem · 9 comments

kerem commented

2026-03-16 00:35:58 +03:00

Owner

Originally created by @jpds on GitHub (Sep 21, 2023).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2032

Is your feature request related to a problem? Please describe.

I currently use Unbound with https://github.com/letsencrypt/unbound_exporter/ (previously https://github.com/svartalf/unbound-telemetry) and am considering migrating my deployments to trust-dns.

However, I need the observability to keep an eye on things like query counts and latencies before users themselves start noticing them.

It'd be neat if trust-dns could integrate with https://crates.io/crates/prometheus-client to simply have native Prometheus metrics built into the server.

Originally created by @jpds on GitHub (Sep 21, 2023). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2032 **Is your feature request related to a problem? Please describe.** I currently use Unbound with https://github.com/letsencrypt/unbound_exporter/ (previously https://github.com/svartalf/unbound-telemetry) and am considering migrating my deployments to trust-dns. However, I need the observability to keep an eye on things like query counts and latencies before users themselves start noticing them. It'd be neat if trust-dns could integrate with https://crates.io/crates/prometheus-client to simply have native Prometheus metrics built into the server.

kerem

2026-03-16 00:35:58 +03:00

closed this issue
added the
enhance

ops
labels

kerem commented

2026-03-16 00:36:14 +03:00

Author

Owner

@djc commented on GitHub (Sep 22, 2023):

This is for a server? Is there anything blocking you from implementing this outside the core trust-dns code?

It's not clear to me that a Prometheus integration should be delivered as part of this project.

@djc commented on GitHub (Sep 22, 2023): This is for a server? Is there anything blocking you from implementing this outside the core trust-dns code? It's not clear to me that a Prometheus integration should be delivered as part of this project.

kerem commented

2026-03-16 00:36:19 +03:00

Author

Owner

@jpds commented on GitHub (Sep 22, 2023):

Yes, this is for the server. There does not appear to be an internal mechanism to gather metrics within the trust-dns codebase and present those to an external exporter/service (Unbound has an internal statistics feature). Once that's in place, the majority of the work is done and all that's missing is an HTTP endpoint to present the metrics (+ an optional crate feature to enable them).

For C based projects (such as unbound), there's hesitation to natively integrate Prometheus as it requires a web endpoint for the metrics (which of course is a small security nightmare in C). Which is both why unbound has a number of different external exporter projects (in various stages of maintenance) and Go/Rust projects typically just natively integrate (for example: Quickwit).

@jpds commented on GitHub (Sep 22, 2023): Yes, this is for the server. There does not appear to be an internal mechanism to gather metrics within the trust-dns codebase and present those to an external exporter/service (Unbound has an [internal statistics](https://unbound.docs.nlnetlabs.nl/en/latest/topics/core/monitoring.html) feature). Once that's in place, the majority of the work is done and all that's missing is an HTTP endpoint to present the metrics (+ an optional crate feature to enable them). For C based projects (such as unbound), there's hesitation to natively integrate Prometheus as it requires a web endpoint for the metrics (which of course is a small security nightmare in C). Which is both why unbound has a number of different external exporter projects (in various stages of maintenance) and Go/Rust projects typically just natively integrate (for example: [Quickwit](https://quickwit.io/docs/reference/metrics/)).

kerem commented

2026-03-16 00:36:25 +03:00

Author

Owner

@djc commented on GitHub (Sep 22, 2023):

I think we currently don't have a lot of the infrastructure for this in place, but if you want to contribute, say, something to track statistics in a server, I'd be happy to provide guidance for that.

To me it feels like the server binary that trust-dns delivers is more of a prototype or tech preview and the project is mostly focused on libraries, so for now that's what I'd want to focus on.

@djc commented on GitHub (Sep 22, 2023): I think we currently don't have a lot of the infrastructure for this in place, but if you want to contribute, say, something to track statistics in a server, I'd be happy to provide guidance for that. To me it feels like the server binary that trust-dns delivers is more of a prototype or tech preview and the project is mostly focused on libraries, so for now that's what I'd want to focus on.

kerem commented

2026-03-16 00:36:30 +03:00

Author

Owner

@bluejekyll commented on GitHub (Sep 22, 2023):

Just for reference, I think the way that we should consider integrating this is in two parts. We should probably look at embracing tracing more deeply and then that has its own metrics collectors implemented for promethius.

So, use https://docs.rs/tracing/0.1.37/tracing/ in the libraries and then we could add a configuration to the server binary with a prometheus exporter https://docs.rs/metrics-exporter-prometheus/latest/metrics_exporter_prometheus/, I think those are all the correct things...

@bluejekyll commented on GitHub (Sep 22, 2023): Just for reference, I think the way that we should consider integrating this is in two parts. We should probably look at embracing `tracing` more deeply and then that has its own metrics collectors implemented for promethius. So, use https://docs.rs/tracing/0.1.37/tracing/ in the libraries and then we could add a configuration to the server binary with a prometheus exporter https://docs.rs/metrics-exporter-prometheus/latest/metrics_exporter_prometheus/, I think those are all the correct things...

kerem commented

2026-03-16 00:36:35 +03:00

Author

Owner

@scabala commented on GitHub (Feb 21, 2025):

Hello,
I feel like this is going to be implemented because it was mentioned on #2725 (correct me if I'm wrong) but I would like to kindly, very gently ask: is there any time estimation when that might be done?

I'm currently comparing my options for self-hosted DNS server and lack of metrics is the only weak point of HickoryDNS.

I do not know Rust (yet) so cannot help with implementation but I can offer testing such feature.

@scabala commented on GitHub (Feb 21, 2025): Hello, I feel like this is going to be implemented because it was mentioned on #2725 (correct me if I'm wrong) but I would like to kindly, very gently ask: is there any time estimation when that might be done? I'm currently comparing my options for self-hosted DNS server and lack of metrics is the _only_ weak point of HickoryDNS. I do not know Rust (yet) so cannot help with implementation but I can offer testing such feature.

kerem commented

2026-03-16 00:36:40 +03:00

Author

Owner

@djc commented on GitHub (Feb 21, 2025):

Likely in the next 6 months-ish. Sooner if you can sponsor it.

@djc commented on GitHub (Feb 21, 2025): Likely in the next 6 months-ish. Sooner if you can sponsor it.

kerem commented

2026-03-16 00:36:45 +03:00

Author

Owner

@hargut commented on GitHub (Mar 31, 2025):

Thank you for your collaboration on setting up the initial pieces for the metrics. 👍

I'll try to add more metrics within the next days.

One of the areas will likely be to integrate metrics_process for more metrics around the server process (cpu, memory, threads, fds, ...).
Another area intended to be added is query/cache hit metrics and dynamic update metrics add/delete for zone record updates.

Please let me know if you have any other priorities and/or ideas.

Have a nice week. 😃

@hargut commented on GitHub (Mar 31, 2025): Thank you for your collaboration on setting up the initial pieces for the metrics. 👍 I'll try to add more metrics within the next days. One of the areas will likely be to integrate [metrics_process](https://docs.rs/metrics-process/latest/metrics_process/) for more metrics around the server process (cpu, memory, threads, fds, ...). Another area intended to be added is query/cache hit metrics and dynamic update metrics add/delete for zone record updates. Please let me know if you have any other priorities and/or ideas. Have a nice week. 😃

kerem commented

2026-03-16 00:36:50 +03:00

Author

Owner

@divergentdave commented on GitHub (Apr 29, 2025):

This was implemented in #2886 and #2900. Thanks again to @hargut!

@divergentdave commented on GitHub (Apr 29, 2025): This was implemented in #2886 and #2900. Thanks again to @hargut!

kerem commented

2026-03-16 00:36:55 +03:00

Author

Owner

@hargut commented on GitHub (Apr 29, 2025):

Hi @divergentdave, @djc, @bluejekyll,

thank you as well for your support and collaboration! 👍

@hargut commented on GitHub (Apr 29, 2025): Hi @divergentdave, @djc, @bluejekyll, thank you as well for your support and collaboration! 👍

kerem referenced this issue

2026-03-16 02:23:02 +03:00

[PR #855] [CLOSED] Disable the backtrace feature from failure when possible #1743