From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4ggPPx182qz2yTD for ; Wed, 17 Jun 2026 13:11:33 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "YR2" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4ggPPs588lz2xYX for ; Wed, 17 Jun 2026 13:11:29 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4ggPPr5CPdzsm; Wed, 17 Jun 2026 13:11:28 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1781701888; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=45nzqsPwDB/d9G3slSEDVJfSRE9yhWaBreM5n3PZsFw=; b=0uzQaVsyA0IwPQ+pEfYCpZyK3HUVxN2RJm39QClt40JT0SKhSw6cAhJuGHbyBneBZvGXGh l7m5+lUQoP+zDkBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1781701888; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=45nzqsPwDB/d9G3slSEDVJfSRE9yhWaBreM5n3PZsFw=; b=PeNGQNj9n/jytuSXkobdE18WPhB0a4dEoafrl79BfyauthBuFE7QbERHEbV/LkE+edLNT5 OHOZqV/WJGlx7qPE91oMtTIKMM45xdn3pkDNh1+a1oE7miaU5755tzkjaHmmns0zTm3gWB 1STu/KnZUZP0BNKis9jOvMvuZGi8nIBzx8Hjz4gDn9vGJrQTGPUqdQKNWOoI2hZQI1Val7 zUOseaMLvQaV3NSkg8crnuUUex70qQ1s9g1thJyK84FQBPvyjacWdnGNP9/llZhD4DWFhA tV7qzYqc+WrBBARbsk15Iq2JRlkMX6arsgaVhcL2eNwlduLY4OK4QoqdhCkXQw== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: Knot resolver in CU 203: enable HTTP API From: Michael Tremer In-Reply-To: <20260616203719.1383402-1-robin.roevens@disroot.org> Date: Wed, 17 Jun 2026 14:11:28 +0100 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20260616203719.1383402-1-robin.roevens@disroot.org> To: Robin Roevens 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,=E2=80=A6 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 = wrote: >=20 > Hi all >=20 > 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=20 > 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 >=20 > 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. >=20 > 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. >=20 > Regards > Robin >=20 > --=20 > Dit bericht is gescanned op virussen en andere gevaarlijke > inhoud door MailScanner en lijkt schoon te zijn. >=20 >=20