Hello Robin, I totally agree that the overhead of kresctl is way too high, especially on some of the weaker hardware that we are using. The HTTP responses are available instantaneously which is much nicer as it almost uses zero resources.
It seems that kresctl is only returning the plain output of the HTTP API anyways. However, I am not sure if we should make this available over the network because of the following problems: * Port Number Congestion - Port 5000 is a very round number and might already be used by other services like OpenVPN or even the proxy where people can choose a port number freely. As the number is easy to remember chances are high. * Security - Securing access to localhost is hard. So I have a counter-proposal which does not require any configuration changes on behalf of the Knot Resolver configuration. Kresctl already as a socket to communicate with the daemon using a Unix domain socket using the HTTP API - although it feels a bit weird sending HTTP over the socket. But it does work: [root@fw01 ~]# curl --unix-socket /var/run/knot-resolver/kres-api.sock http://localhost/metrics/json {"kresd:kresd0": {"answer": {"total": 0, "noerror": 0, "nxdomain": 0, "nodata": 0, "1ms": 0, "10ms": 0, "50ms": 0, "100ms": 0, "250ms": 0, "500ms": 0, "1000ms": 0,… Is this an option for Zabbix? I suppose you are using curl as a replacement to kresctl as it is much more lightweight. Or are you using an internal HTTP client of the zabbix agent? And if so, does it support the Unix socket? Best, -Michael > On 16 Jun 2026, at 21:15, Robin Roevens <[email protected]> wrote: > > Hi all > > For Zabbix to be able to get knot-resolver metrics, I would like to have > the HTTP API enabled > (https://www.knot-resolver.cz/documentation/latest/manager-api.html). > Receving the same metrics is currently already possible using kresctl > however this is very slow and seems to use quite some resources > (especially on my mini appliance v1: one cpu goes to 100% for 2s) while > when using curl to get the metrics from the HTTP API, they are returned > instantly without noticable cpu usage: > Timings for kresctl: > real 0m1.979s > user 0m1.825s > sys 0m0.126s > Timings for curl using the http api: > real 0m0.051s > user 0m0.015s > sys 0m0.018s > > And secondly, if I would use kresctl, I would need an additional config to > zabbix_agent and sudoers to support calling that binary, while > using the HTTP API is natively built in into the zabbix_agent and much > more performant. > > I have added a patch that will enable the HTTP API in the knot resolver > config. If possible, I would like this to be applied already to CU 203 > so that I can release a Zabbix template to monitor knot without the need > for additional changes to the zabbix_agent pak that would then probably > have to wait for at least CU 204. > > Regards > Robin > > -- > Dit bericht is gescanned op virussen en andere gevaarlijke > inhoud door MailScanner en lijkt schoon te zijn. > >
