bug: runtime error when exporter fetches disk info

[toddatmilford]

I am running:

Copyright (c) 2004-2018 Areca, Inc. All Rights Reserved.
Areca CLI, Version: 1.15.8, Arclib: 373, Date: May 29 2018( Linux ) 
ARC-1882   Raid Controller  PCI
Main Processor     : 800MHz
CPU ICache Size    : 32KB
CPU DCache Size    : 32KB
CPU SCache Size    : 1024KB
System Memory      : 4096MB/1333MHz
Firmware Version   : V1.52 2014-02-07
BOOT ROM Version   : V1.52 2014-02-07
Serial Number      : A228CADFAR300104
Controller Name    : ARC-1882
Current IP Address : 192.168.1.100

and I get this:

areca-prometheus-exporter
level=info ts=2024-12-07T14:23:25.647Z caller=areca_exporter.go:465 msg="Starting areca_exporter" version="(version=, branch=, revision=88d08d5250b588675da4c6c95d9ee7676089291b)"
level=info ts=2024-12-07T14:23:25.647Z caller=areca_exporter.go:466 msg="Build context" build_context="(go=go1.23.4, platform=linux/amd64, user=, date=, tags=unknown)"
level=info ts=2024-12-07T14:23:25.648Z caller=tls_config.go:313 msg="Listening on" address=[::]:9423
level=info ts=2024-12-07T14:23:25.648Z caller=tls_config.go:316 msg="TLS is disabled." http2=false address=[::]:9423
level=error ts=2024-12-07T14:23:29.148Z caller=areca_exporter.go:171 err="runtime error: index out of range [5] with length 5" msg="goroutine 23 [running]:\nruntime/debug.Stack()\n\t/usr/local/go/src/runtime/debug/stack.go:26 +0x5e\nmain.getDiskInfo.func1()\n\t/root/software/areca-prometheus-exporter/areca_exporter.go:171 +0xa5\npanic({0x992380?, 0xc00033a048?})\n\t/usr/local/go/src/runtime/panic.go:785 +0x132\nmain.getDiskInfo()\n\t/root/software/areca-prometheus-exporter/areca_exporter.go:216 +0x6e7\nmain.recordMetrics.func1()\n\t/root/software/areca-prometheus-exporter/areca_exporter.go:338 +0x77\ncreated by main.recordMetrics in goroutine 1\n\t/root/software/areca-prometheus-exporter/areca_exporter.go:332 +0x205\n"

Any ideas on what this is?

Thank you Todd

[vilhelmprytz]

@toddatmilford Thank you for reporting this bug! Can you run the command areca.cli64 disk info and post the information here?

I've been using the following version of Areca CLI when testing:

# areca.cli64
Copyright (c) 2004-2022 Areca, Inc. All Rights Reserved.
Areca CLI, Version: 1.15.23, Arclib: 384, Date: May 17 2022( Linux )
...

But I've used the exporter on much older versions of the CLI as well without this problem.

[toddatmilford]

Also I have three controllers so I use the curctrl parm

root@jack1:~# cli64 curctrl=2 disk info
  # Enc# Slot#   ModelName                        Capacity  Usage
===============================================================================
  1  01  Slot#1  N.A.                                0.0GB  N.A.
  2  01  Slot#2  N.A.                                0.0GB  N.A.
  3  01  Slot#3  N.A.                                0.0GB  N.A.
  4  01  Slot#4  N.A.                                0.0GB  N.A.
  5  01  Slot#5  N.A.                                0.0GB  N.A.
  6  01  Slot#6  N.A.                                0.0GB  N.A.
  7  01  Slot#7  N.A.                                0.0GB  N.A.
  8  01  Slot#8  N.A.                                0.0GB  N.A.
  9  02  SLOT 01 Hitachi HUA723030ALA640          3000.6GB  jr1c2
 10  02  SLOT 02 WDC  WUS721010ALE6L4            10000.8GB  HotSpare[Global]
 11  02  SLOT 03 Hitachi HUS724040ALE641          4000.8GB  jr1c2
 12  02  SLOT 04 ST4000DM004-2CV104               4000.8GB  jr1c2
 13  02  SLOT 05 Hitachi HUA723030ALA640          3000.6GB  jr1c2
 14  02  SLOT 06 Hitachi HUA723030ALA640          3000.6GB  jr1c2
 15  02  SLOT 07 Hitachi HUA723030ALA640          3000.6GB  jr1c2
 16  02  SLOT 08 Hitachi HUS724040ALE641          4000.8GB  jr1c2
 17  02  SLOT 09 Hitachi HUA723030ALA640          3000.6GB  jr1c2
 18  02  SLOT 10 WDC WD8004FRYZ-01VAEB0           8001.6GB  jr2c2
 19  02  SLOT 11 Hitachi HUA723030ALA640          3000.6GB  jr1c2
 20  02  SLOT 12 Hitachi HUA723030ALA640          3000.6GB  jr1c2
 21  02  SLOT 13 Hitachi HUA723030ALA640          3000.6GB  jr1c2
 22  02  SLOT 14 Hitachi HUA723030ALA640          3000.6GB  jr2c2
 23  02  SLOT 15 Hitachi HUA723030ALA640          3000.6GB  jr2c2
 24  02  SLOT 16 Hitachi HUA723030ALA640          3000.6GB  jr2c2
 25  02  SLOT 17 ST4000DM004-2CV104               4000.8GB  jr2c2
 26  02  SLOT 18 ST4000DM004-2CV104               4000.8GB  jr2c2
 27  02  SLOT 19 ST4000DM004-2CV104               4000.8GB  jr2c2
 28  02  SLOT 20 Hitachi HUA723030ALA640          3000.6GB  jr2c2
 29  02  SLOT 21 Hitachi HUA723030ALA640          3000.6GB  jr2c2
 30  02  SLOT 22 WDC  WUS721010ALE6L4            10000.8GB  Free
 31  02  SLOT 23 Hitachi HUA723030ALA640          3000.6GB  jr2c2
 32  02  SLOT 24 Hitachi HUA723030ALA640          3000.6GB  jr2c2
 33  02  EXTP 01 N.A.                                0.0GB  N.A.
 34  02  EXTP 02 N.A.                                0.0GB  N.A.
 35  02  EXTP 03 N.A.                                0.0GB  N.A.
 36  02  EXTP 04 N.A.                                0.0GB  N.A.
===============================================================================
GuiErrMsg<0x00>: Success.

[sebbov]

The issue is that the exporter is splitting disk info output lines by double-spaces, but the slot and modelname fields are separated by only a single space for drive 9 onwards in the provided output (sth similar happens for the default controller, 1).

I don't see a great solution to this - fundamentally the exporter is trying to generically parse key values out of table output where columns are not generically distinguishable. The formatting string in the code (see below) indeed only single-space separates these so there's no guarantee of a double-space separator in the formatted output. The slot field also doesn't use truncation, so fixed-width parsing won't work either. I don't think slot strings are controllable - not sure what defines them. The formatting string hasn't changed since 1.80A (2007) and I assume there's little chance it will see change moving forward (this stuff not EOL?). One option is to make the exporter more aware of disk info semantics and make some assumptions on what slot strings look like (e.g., everything up to and including a word containing a number). A better solution would be to avoid parsing cli output meant to be consumed by humans, and use SNMP, the arclib API, or sth similarly machine-readable instead. That seems out of scope.

If the solution is going to be incomplete and hacky anyhow ... a simple one handling the problem at hand is to patch the cli binary:

# diff <(strings /usr/local/bin/areca.cli64) <(strings /tmp/areca.cli64)
2284c2284
< %3s  %02d  %-7s %-30.30s %8.1lfGB  %-10s
---
> %3s  %02d  %-9s %-30.30s %8.1lfGB  %-10s

(and point your exporter to it using --cli-path.)

Also I have three controllers so I use the curctrl parm

unrelated to the problem at hand, but noting there's no multi-controller support in the exporter - it only exports data for the first controller. The controller count could be discovered at startup, data gathered for each of them, and the controller index added as a label to each metric.

[vilhelmprytz]

Thanks, @sebbov, for taking the time to investigate this! You’re absolutely right—a better solution would be to use a machine-readable format. However, when I initially wrote this exporter and explored the options, none seemed as straightforward as simply parsing the output. I originally had no intention of publishing this as a public repository—it was just for my own use case—but putting it on GitHub felt like something I could do.

Unfortunately, I don’t have much time to implement a solution for this issue. @sebbov, am I correct in assuming that your pull request (#27) does not address this issue?

[sebbov]

thanks @vilhelmprytz . Correct, #27 does not address it. I see no evidence for this issue to hit anyone but @toddatmilford at this point, and given how old these controllers are it seemed unlikely to me to hit new users in the future. The binary patch should be sufficient until (at the very least) we hear back from more folks here.