(1)の続き。

どこまで書いたんだ、えーと、ログを.parquetにするところまでか。まあそれでいいや。そこまででも、duckdbのmcpサーバを定義した上でAIにスキーマとかファイル名を調べてスキルを作ってよ、と言うだけで作ってくれる。それを呼び出せば何があったか概要を答えてくれるだけの力は、AIにはある。かなり余裕で。スキルを使ってみて、改善点を出してもらってパターンを追加してクエリを出しやすい.parquetに作り替えしながら、少しずつ育てていけばいい。

ログに関してはこれでいい。次はメトリクス情報だ。

このサーバは2002年からのものだから、骨格自体は骨董品だ。代替わりはあったし途中から自宅サーバではなくVPSになったりしたが、基本は変わってない。まあ今はコンテナ化されているしstatic site generatorを使うようにしたり、static site専門のWebサーバ(AI以前の時代に書いたやつ)なんかも自作して作り込まれている。まあ古参の自宅サーバ勢は自作のWebサーバを自分でメンテしながら使ってる人も多いんだよ。そういう四半世紀の歴史を持つのがこのサーバというわけだ。

それだけあって、メトリクス情報は最近のprometheusとかクラウドネイティブ系のものではなくて、muninでrrdtoolのファイルとstatic HTMLを作る、ということを続けている。systemdのtimerですらなくcronだよ。muninのプラグインとか工夫したなあむかし…しかしそのせいで、rrdtoolへのクエリをかけるmcpサーバを作る流れになった。意外といいのがないんですよね、rrdtoolにアクセスするmcpサーバって。logidxみたいなものよりも希少な気が。これは作るしかない。AIならサクッとできることは容易に予想できた。

余談だがmuninはrrdtool-1.10以降は壊れていて、なんやかやしないとグラフが表示できない。修正は割と面倒だった。開発はしてるのにリリースしてないので、普通にバージョン番号を指定してインストールすると壊れている状態になる。ちゃんとリリースして欲しいなあ。本件とは全くの別件。

途中で「そういやsysstat(sar)もあったな…」と思い出してsarのファイルにクエリをかけられるようにもした。あとwtmpとかも。意外に豊富な材料があるんだね。他にもあるのかもな。思いついたら作るよ。claude codeとremote-controlで、今はもう、出先でもスマッフォーアプリでおざなりに指示してるだけで、コードが書ける時代なんだ。

ここまでの成果物: https://github.com/wtnb75/rrdmcp