stork issueshttps://gitlab.isc.org/isc-projects/stork/-/issues2024-03-25T17:24:07Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/1335Not possible to run DHCPv6 only and collect stats with Prometheus2024-03-25T17:24:07ZRinse KloekNot possible to run DHCPv6 only and collect stats with Prometheus - Kea version: 2.4.1
- Stork: which version? 1.15.0
- OS: Debian 11
I have an issue with the prometheus exporter. I had enabled DHCPv4/DHCPv6/D2 in my kea-ctrl-agent as well as installed the KEA DHCPv4 server. However this server on... - Kea version: 2.4.1
- Stork: which version? 1.15.0
- OS: Debian 11
I have an issue with the prometheus exporter. I had enabled DHCPv4/DHCPv6/D2 in my kea-ctrl-agent as well as installed the KEA DHCPv4 server. However this server only serves DHCPv6 request. If I remove the DHCPv6/D2 entries in the Kea-ctrl-agent.conf and deinstall KEA DHCPv4 server, I am not able to see my DHCPv6 PD stats (kea_dhcp6_pd_assigned_total) anymore.
I get this error message in the log on the server
stork-agent[929757]: time="2024-03-19 11:54:23" level="error" msg="Problem parsing DHCPv4 labels from Kea: problem with content of DHCP labels response from Kea: forwarding socket is not configured for the server type dhcp4\nisc.org/stork/agent.(*SubnetList).UnmarshalJSON\n\t/builds/isc-projects/stork/backend/agent/promkeaexporter.go:82\nencoding/json.(*decodeState).array\n\t/builds/isc-projects/stork/tools/golang/go/src/encoding/json/decode.go:507\nencoding/json.(*decodeState).value\n\t/builds/isc-projects/stork/tools/golang/go/src/encoding/json/decode.go:364\nencoding/json.(*decodeState).unmarshal\n\t/builds/isc-projects/stork/tools/golang/go/src/encoding/json/decode.go:181\nencoding/json.Unmarshal\n\t/builds/isc-projects/stork/tools/golang/go/src/encoding/json/decode.go:108\nisc.org/stork/agent.(*lazySubnetNameLookup).fetchAndCacheNames\n\t/builds/isc-projects/stork/backend/agent/promkeaexporter.go:274\nisc.org/stork/agent.(*lazySubnetNameLookup).getName\n\t/builds/isc-projects/stork/backend/agent/promkeaexporter.go:291\nisc.org/stork/agent.(*lazySubnetNameLookup).getNameOrDefault\n\t/builds/isc-projects/stork/backend/agent/promkeaexporter.go:303\nisc.org/stork/agent.(*PromKeaExporter).setDaemonStats\n\t/builds/isc-projects/stork/backend/agent/promkeaexporter.go:772\nisc.org/stork/agent.(*PromKeaExporter).collectStats\n\t/builds/isc-projects/stork/backend/agent/promkeaexporter.go:877\nisc.org/stork/agent.(*PromKeaExporter).statsCollectorLoop\n\t/builds/isc-projects/stork/backend/agent/promkeaexporter.go:724\nruntime.goexit\n\t/builds/isc-projects/stork/tools/golang/go/src/runtime/asm_amd64.s:1650" file=" promkeaexporter.go:276 "
`
After installing the KEA DHCPv4 server again and reeneabling the KEA DHCPv4 server in kea-ctrl-agent these log message don't appear anymore and the Prometheus stats collection works again.
Is it possible to remove the DHCPv4 server and keep the stats working for DHCPv6
regads,
Rinsehttps://gitlab.isc.org/isc-projects/stork/-/issues/1322Upgrade Grafana and its dashboards2024-03-05T15:02:12ZSlawek FigielUpgrade Grafana and its dashboardsYou cannot import the example Grafana dashboards to a modern Grafana instance.
![image](/uploads/a95f33a1aa876ae18d92057fd933fc5f/image.png)
The Stork demo uses the `8.3.7` Grafana version. The latest version is `10.3.3`.
We should up...You cannot import the example Grafana dashboards to a modern Grafana instance.
![image](/uploads/a95f33a1aa876ae18d92057fd933fc5f/image.png)
The Stork demo uses the `8.3.7` Grafana version. The latest version is `10.3.3`.
We should upgrade the Grafana (and maybe Prometheus) used in the demo and migrate the example dashboards to a modern format.1.16https://gitlab.isc.org/isc-projects/stork/-/issues/1193CA returns number overflow on ipv6 stats2024-03-22T12:56:27ZSlawek FigielCA returns number overflow on ipv6 statsThe issue was found during [1.13 sanity checks](https://gitlab.isc.org/isc-projects/stork/-/issues/1187#note_408666) by @slawek.
I have observed a weird error in logs:
```
stork-1130-agent-kea6-1 | INFO COMMAND_RECEIVED R...The issue was found during [1.13 sanity checks](https://gitlab.isc.org/isc-projects/stork/-/issues/1187#note_408666) by @slawek.
I have observed a weird error in logs:
```
stork-1130-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'statistic-get-all'
stork-1130-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_RECEIVED command statistic-get-all received from remote address 127.0.0.1
stork-1130-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'statistic-get-all'
stork-1130-agent-kea6-1 | time="2023-10-10 12:40:51" level="error" msg="Failed to parse responses from Kea: response result from Kea != 0: 1, text: internal server error: unable to parse server's answer to the forwarded message: Number overflow: 36893488147419103232 in <wire>:0:8422" file=" promkeaexporter.go:850 "
stork-1130-agent-kea6-1 | time="2023-10-10 12:40:51" level="error" msg="Some errors were encountered while collecting stats from Kea: response result from Kea != 0: 1, text: internal server error: unable to parse server's answer to the forwarded message: Number overflow: 36893488147419103232 in <wire>:0:8422\nisc.org/stork/agent.(*GetAllStatisticsResponse).UnmarshalJSON\n\tisc.org/stork/agent/promkeaexporter.go:149\nencoding/json.(*decodeState).array\n\tencoding/json/decode.go:507\nencoding/json.(*decodeState).value\n\tencoding/json/decode.go:364\nencoding/json.(*decodeState).unmarshal\n\tencoding/json/decode.go:181\nencoding/json.Unmarshal\n\tencoding/json/decode.go:108\nisc.org/stork/agent.(*PromKeaExporter).collectStats\n\tisc.org/stork/agent/promkeaexporter.go:847\nisc.org/stork/agent.(*PromKeaExporter).statsCollectorLoop\n\tisc.org/stork/agent/promkeaexporter.go:710\nruntime.goexit\n\truntime/asm_amd64.s:1650" file=" promkeaexporter.go:712 "
```1.16Slawek FigielSlawek Figiel2024-05-29https://gitlab.isc.org/isc-projects/stork/-/issues/1153add pool statistics to prometheus2023-09-12T13:48:16ZRazvan Becheriuadd pool statistics to prometheusnew stats have been added in 2.4.0:
v4:
```
"subnet[1].pool[0].assigned-addresses": [
[
0,
"2023-06-13 20:42:46.836205"
]
],
"subnet[1...new stats have been added in 2.4.0:
v4:
```
"subnet[1].pool[0].assigned-addresses": [
[
0,
"2023-06-13 20:42:46.836205"
]
],
"subnet[1].pool[0].cumulative-assigned-addresses": [
[
0,
"2023-06-13 20:42:46.836137"
]
],
"subnet[1].pool[0].declined-addresses": [
[
0,
"2023-06-13 20:42:46.836213"
]
],
"subnet[1].pool[0].reclaimed-declined-addresses": [
[
0,
"2023-06-13 20:42:46.836225"
]
],
"subnet[1].pool[0].reclaimed-leases": [
[
0,
"2023-06-13 20:42:46.836236"
]
],
"subnet[1].pool[0].total-addresses": [
[
11010049,
"2023-06-13 20:42:46.836128"
]
],
```
v6:
```
"subnet[1].pd-pool[0].assigned-pds": [
[
0,
"2023-06-13 21:28:57.196785"
]
],
"subnet[1].pd-pool[0].cumulative-assigned-pds": [
[
0,
"2023-06-13 21:28:57.196744"
]
],
"subnet[1].pd-pool[0].reclaimed-leases": [
[
0,
"2023-06-13 21:28:57.196789"
]
],
"subnet[1].pd-pool[0].total-pds": [
[
256,
"2023-06-13 21:28:57.196741"
]
],
"subnet[1].pool[0].assigned-nas": [
[
0,
"2023-06-13 21:28:57.196773"
]
],
"subnet[1].pool[0].cumulative-assigned-nas": [
[
0,
"2023-06-13 21:28:57.196739"
]
],
"subnet[1].pool[0].declined-addresses": [
[
0,
"2023-06-13 21:28:57.196775"
]
],
"subnet[1].pool[0].reclaimed-declined-addresses": [
[
0,
"2023-06-13 21:28:57.196779"
]
],
"subnet[1].pool[0].reclaimed-leases": [
[
0,
"2023-06-13 21:28:57.196783"
]
],
"subnet[1].pool[0].total-nas": [
[
281474976710656,
"2023-06-13 21:28:57.196736"
]
],
```
```backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/341Self-documenting stats (--list-stats switch for agent)2021-06-01T08:44:42ZTomek MrugalskiSelf-documenting stats (--list-stats switch for agent)@matthijs and @tomek discussed the need to have a good statistics list for BIND 9. One way to achieve that would be to implement a `--list-stats` kind of command line switch. It would export the list of currently supported stats by the a...@matthijs and @tomek discussed the need to have a good statistics list for BIND 9. One way to achieve that would be to implement a `--list-stats` kind of command line switch. It would export the list of currently supported stats by the agent, along with some reasonably easy to understand, non-cryptic, non-overly abbreviated description.
For bonus points, that list could be in a format that could be integreated into Stork ARM.
This would address a real issue many BIND 9 users are having: BIND 9 has lots of stats, but nobody really knows what they mean. We won't solve the problem instantly. Incremental steps are the way to go.
We want to have something similar for Kea. However, Kea stats are well documented, so there is less pressing need for this (which also makes the issue easier to solve for Kea, by employing well proven copy-paste programming techniques) ;)backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/175Agent shouldn't open stats exporter port for Kea when Kea is not detected.2020-03-03T16:54:07ZTomek MrugalskiAgent shouldn't open stats exporter port for Kea when Kea is not detected.This is a follow-up to https://gitlab.isc.org/isc-projects/stork/merge_requests/77#note_112821.
The problem is that the agent starts Kea exporter even when there's no Kea detected at all.
This has couple problems:
- unnecessary CPU cyc...This is a follow-up to https://gitlab.isc.org/isc-projects/stork/merge_requests/77#note_112821.
The problem is that the agent starts Kea exporter even when there's no Kea detected at all.
This has couple problems:
- unnecessary CPU cycles (minor)
- opened port when it's not needed. This may be an attack vector.outstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/174Kea stats list should not be hardcoded in the agent2020-03-03T16:52:28ZTomek MrugalskiKea stats list should not be hardcoded in the agentThe !77 introduced a nice feature: the stork agent extracts Kea statistics and exposes them in Prometheus format.
However, the list of stats is hardcoded. This should be more flexible. My proposal is to store the list in a text file.
Up...The !77 introduced a nice feature: the stork agent extracts Kea statistics and exposes them in Prometheus format.
However, the list of stats is hardcoded. This should be more flexible. My proposal is to store the list in a text file.
Upon first start, the agent would look if there's a file for that. If the file isn't there, it would be created. That way agent deployment still would be easy (just copy one binary), but would be flexible at the same time.
This doesn't have to be implemented that way. The goal is to be able to modify the list of statistics to be exported without recompiling the code.outstanding