設定で問題を回避する例 ～ARM系計算機＋リソース監視Ganglia～

Diary
設定で問題を回避する例 ～ARM系計算機＋リソース監視Ganglia～
Page content

CPUがARM系 (AArch64アーキテクチャ) である計算機に対し、Ganglia Monitoring Systemによるリソースモニタリングを導入する作業をした。

この場合、Gangliaノードとなる計算機側にgmondというデーモンを導入する必要があるのだが、gmondとaarch64の組み合わせによる一つの問題に遭遇し、それを回避するworkaroundがわかったので、珍しい情報かもしれないと思いメモしておきます。

対象のGanglia環境

項目内容
バージョン3.7.2
サーバのCPU (gmetad,gmond)x86_64アーキテクチャのなにか
ノードのCPU (gmond)aarch64アーキテクチャのなにか

※上記のGangliaバージョン3.7.2は2015年7月リリースで、記事執筆時点の最新版

遭遇した問題の内容

Gangliaノードのaarch64計算機のgmondから得られる情報を、Gangliaサーバのgmetadが読み込む際に、次の「XML_ParseBuffer() error at line 9999:#012not well-formed (invalid token)#012」というエラーが発生した。Ganglia Web Frontendでは、当該計算機のいくつかのリソース情報のグラフが描画されない状態になる。

May 21 00:00:00 user.info server /usr/sbin/gmetad[99999]: Process XML (hoge-System): XML_ParseBuffer() error at line 9999:#012not well-formed (invalid token)#012

gmetadにエラーを発生させるXMLの実際のデータや、XMLとしての妥当性検証の結果は、次のコマンドで確認できる。

$ telnet <Gangliaサーバ> <Gangliaの待受ポート> | tail -n +4 > hoge.xml
$ cat hoge.xml

$ xmllint --valid --noout hoge.xml
hoge.xml:9999: parser error : CharRef: invalid decimal value
<METRIC NAME="machine_type" VAL="P&#Å0;s&#É4;&#É5;&#É5;" TYPE="string" UNITS
                                    ^
hoge.xml:9999: parser error : xmlParseCharRef: invalid xmlChar value 0
<METRIC NAME="machine_type" VAL="P&#Å0;s&#É4;&#É5;&#É5;" TYPE="string" UNITS
                                    ^

この確認によって、問題の要因はXML内の「METRIC NAME=“machine_type”」の行にある可能性が高く、何やら非ASCIIらしい、不可解な内容のVALが代入されていることがわかる。ちなみに、x86_64計算機は「VAL=“x86_64”」を返してくれる。

aarch64計算機が返すこの妙な内容は、一体どのような意味の文字列なのか、いくつかの文字コードとして解釈を試みても判明しなかった。

問題の原因と背景

「この計算機は machine_type = aarch64 と当然名乗るんじゃないの？ パッケージはaarch64対応版 (～.aarch64.rpm) をちゃんと選んだし、計算機側のgmondはエラーなく動いているし」と、私は思ったが、状況を調べたところ、Gangliaのリリースに関わる事情があるようだ。

まず、ソースコードに関しては、2016年9月にmachine_typeの選択肢としてaarch64を加えるパッチが出て、Ganglia monitor-coreの libmetrics/linux/metrics.c にマージされている。

しかし、Gangliaの正式版リリースは2015年7月の「3.7.2」を最後に、それ以降はまだ行われていない。つまり、上記のmachine_typeのaarch64対応がされている正式版は、2020年5月現在“リリース待ち”状態なのであろう。

未知のバグではなく既知の問題で、根本的な解決策は用意されているということになる。

問題の回避策 (workaround)

今回の導入作業では (正式版のバイナリパッケージのみを導入したい思いがあり)、Gangliaの次の正式版がリリースされるまでは、この問題を極力、いわゆる設定で回避したい。そこで安直に、「aarch64計算機からはmachine_typeの情報を送信しなければよいのでは？」と考えた。

この作戦が許される環境に限るが、aarch64計算機のgmondの設定で問題を回避する具体的な方法は次の通り。

  1. aarch64計算機側のgmond設定ファイル /etc/ganglia/gmond.conf にて、次のmachine_typeのmetric部分全体を「/* ～ */」でコメントアウトする
/*  metric {
	name = "machine_type"
	title = "Machine Type"
} */
  1. 当該環境のgmond.confには次の但し書きがあったので、計算機を再起動する
/* This collection group will send general info about this host every
1200 secs.
This information doesn't change between reboots and is only collected
once. */
collection_group {
  1. aarch64計算機が起動した後、次のコマンドにてXMLを検証し、問題がないことを確認する
$ telnet <gmetadのサーバ> <gmetadの待受ポート> | tail -n +4 > hoge.xml
$ xmllint --valid --noout hoge.xml
  1. aarch64計算機のリソース情報が、Ganglia Web Frontendに欠損なく反映されるのを待つ

以上。もし実際に上記のworkaroundをやってみる方がいらっしゃれば、どうかその環境でもうまく行きますように。

P.S. 最近の一枚

記事の内容とは関係ありませんが、昔からの計算機のイメージとして。