Sanitize strings from /sys/class/power_supply

[SuperQ]

Avoid panic on invalid UTF-8 from /sys/class/power_supply by
sanitizing strings parsed from the kernel.

Fixes: #1979

Signed-off-by: Ben Kochie superq@gmail.com

[SuperQ]

CC @hhoffstaette, could you give this patch a try?

[SuperQ]

Ok, so I am not liking the simple sanitize by dropping invalid runes. I'm going to figure out a better string sanitizer.

[hhoffstaette]

Ok, so I am not liking the simple sanitize by dropping invalid runes. I'm going to figure out a better string sanitizer.

Why not? There is IMHO no other good way to handle this. Replacing them with other characters ('X' or '?') is bound to be misleading, and they are not likely to appear in the middle of the name.
Thanks for your effort. ❤️

[SuperQ]

What I would like is to replace the letters with something like \xc0, exactly how the panic prints it out. Finding the right way to convert a rune to an escaped ascii is not being obvious to me.

[hhoffstaette]

What I would like is to replace the letters with something like \xc0, exactly how the panic prints it out.

🤔 having escaped characters in the string is IMHO not helpful. I'd rather just have the value reduced to ASCII (printable characters) and be done, I don't see why this needs to be more complicated than necessary; remember that this will almost never trigger anyway.

[hhoffstaette]

When I fix the patch to use ToValidUTF8(value, "") everything seems fine:

$curl -s http://localhost:9100/metrics | grep \^node_power
node_power_supply_capacity{power_supply="BAT0"} 96
node_power_supply_current_ampere{power_supply="ucsi-source-psy-USBC000:001"} 3
node_power_supply_current_ampere{power_supply="ucsi-source-psy-USBC000:002"} 0
node_power_supply_current_max{power_supply="ucsi-source-psy-USBC000:001"} 3.25
node_power_supply_current_max{power_supply="ucsi-source-psy-USBC000:002"} 0
node_power_supply_cyclecount{power_supply="BAT0"} 3
node_power_supply_energy_full{power_supply="BAT0"} 44.48
node_power_supply_energy_full_design{power_supply="BAT0"} 45
node_power_supply_energy_watthour{power_supply="BAT0"} 42.72
node_power_supply_info{power_supply="AC",type="Mains"} 1
node_power_supply_info{power_supply="ucsi-source-psy-USBC000:001",type="USB",usb_type="C [PD] PD_PPS"} 1
node_power_supply_info{power_supply="ucsi-source-psy-USBC000:002",type="USB",usb_type="[C] PD PD_PPS"} 1
node_power_supply_info{capacity_level="Normal",manufacturer="LGC",model_name="LNV-5B10W13894",power_supply="BAT0",serial_number="3482",status="Unknown",technology="Li-poly",type="Battery"} 1
node_power_supply_online{power_supply="AC"} 1
node_power_supply_online{power_supply="ucsi-source-psy-USBC000:001"} 1
node_power_supply_online{power_supply="ucsi-source-psy-USBC000:002"} 0
node_power_supply_power_watt{power_supply="BAT0"} 0
node_power_supply_present{power_supply="BAT0"} 1
node_power_supply_voltage_max{power_supply="ucsi-source-psy-USBC000:001"} 20
node_power_supply_voltage_max{power_supply="ucsi-source-psy-USBC000:002"} 0
node_power_supply_voltage_min{power_supply="ucsi-source-psy-USBC000:001"} 5
node_power_supply_voltage_min{power_supply="ucsi-source-psy-USBC000:002"} 0
node_power_supply_voltage_min_design{power_supply="BAT0"} 11.1
node_power_supply_voltage_volt{power_supply="BAT0"} 12.197
node_power_supply_voltage_volt{power_supply="ucsi-source-psy-USBC000:001"} 5
node_power_supply_voltage_volt{power_supply="ucsi-source-psy-USBC000:002"} 0

..works for me? ¯\_(ツ)_/¯

[SuperQ]

Yea, I suppose. My usual preference is to preserve as much data as possible. I dislike silently eating data.

[SuperQ]

That's weird, this shouldn't impact the scrape duration that much. Is that for node_scrape_collector_duration_seconds{collector="powersupplyclass"}?

[hhoffstaette]

That's weird, this shouldn't impact the scrape duration that much. Is that for
node_scrape_collector_duration_seconds{collector="powersupplyclass"}?

I deleted my comment. The picture showed the complete scrape time (up by ~50ms), but then I realized that the additional time was caused by the powersupply class collector (regardless of sanitizing). procfs/sysfs values are pulled on-demand and talking to the HW (in this case reading voltages etc. from the battery/sensors via ACPI and whatnot) is just slow.

[discordianfish]

LGTM