久しぶり VPS の top を眺めていたら systemd-journald が9%食っていることに気付いた。2GB のマシンなのに。

どうやら SystemMaxFileSize を小さくするとメモリ消費量も減るらしい。ので以下のように設定した。

[Journal]
SystemMaxFileSize=32M
SystemMaxFiles=100
systemctl restart systemd-journald

ディスクの消費

/var/log/journal はあり、こちらでディスクを 4GB ほど消費している。

$ ls -altrh /var/log/journal/*/
-rw-r-----+ 1 root systemd-journal 128M Apr 29 13:41 'system@...68e.journal'
...

1ファイルあたり128MBが32個ほどあった。SystemMaxUse のデフォルト値はややこしいので man 確認する必要がある。自分の環境の場合、ディスクが48GBで、デフォルトの最大は10%の4.8GB、ただし 4GB が上限。

ファイルの数 (SystemMaxFileSize) は SystemMaxUse の 1/8 らしいので過去ログは7件しかないはずだけど、なんかいっぱいあって謎。しらべてもよく挙動がわからんかった

ref

  1. トップ
  2. tech
  3. systemd-journald がメモリ食いすぎ

Text-Xatena というはてな記法に近い記法をパースしてフォーマットする Perl のモジュールがある (ややこしい言いかただが……)。この日記も Text-Xatena + 拡張インライン記法でフォーマットされている。

golang にも同様のものが欲しくなったので作ってみることにした。

一応もとの Text-Xatena 同様、HatenaCompatible モードというのをつけてある

GOOS=js GOARCH=wasm によるデモページ

https://cho45.github.io/xatena-go/

golang は wasm に直接出力できるので、これでデモページを作ってみた。.wasm ファイルが 6MB超あるけど……

実装

Text-Xatena のほぼ単純移植として実装する方針で、Copilot (GPT 4.1) と共にやってみたけどまぁまぁ面倒だった。

元実装があり、あまりデザインを変えずに言語を変更するという感じなので、AIでもできるだろと思ったけど、案外うまくいかず、結構いちいち指示やら手を入れることが必要になってしまった。とはいえ自分で書くよりは早くできたと思う。

ある程度できてくれば複数ファイルにまたがる変更もやってくれるけど、微妙に修正漏れがあったりして面倒。

テストの雛形をつくったあと、Perl のテストファイルをコピペして、それぞれ分けてテストファイルつくるように指示したけど、テストの中身を適当に書きかえられてひどかった。

コンテキストを小さくするために、先に全体の要約とか実装方針とかをまとめたほうがよかったのかも…… 自分は元コードを理解してるから、元コードの要約をさせる発想がなかったのが敗因かもしれない。

  1. トップ
  2. tech
  3. xatena-go (はてな記法のような記法フォーマットパーサー) を作った

IT技術者なのに情報処理系の試験はまったく受けずに生きてきてしまった。アマチュア無線技士第二種電気工事士とは違って法的に別にできることが増えるわけではなく特に受けるモチベがなかったからだけど、諸事情によりITパスポート試験は受けてみることにした。

毎週試験が受けれるみたい。過去問を1週間で1450問ほど解いた。

出題範囲が広い割に問題数は100しかないから、問題運で結構ブレそう。結果はテクノロジがストラテジより低くなってしまった。個別の正誤判定はないから何ミスったかはわからない。

なんかよく意図がわからない問題があった。あとは普通に知らない言葉の意味を聞かれる問題があった。ので、そのあたりを順当に間違えてそう……

定義が問題文に書いてある(ほぼ無知識で回答できる)やつと、聞かれてるものはわからないけど消去法で1択のものを落とさないように気をつけた。知ってないと答えようがない問題はあきらめた……

  1. トップ
  2. tech
  3. ITパスポート試験を受けてきた

自宅ラズパイのメトリクスとかセンサー類を VPS 上の prometheus に溜めているけど、1年分で12GBぐらいと、用途の割にかなり大きくて、容量が足りなくなったときに悩んでいた。

VictoriaMetrics だと圧縮効率がよいらしいので試しに移行してみた。クエリ (MetricsQL) は PromQL 互換らしい。事前に調べたけどあんまりデメリットがなさそうに思えた。クラッシュなどによる多少の損失を許容しているところぐらい? 自宅のあれこれでは問題ない要件

✅ 前提条件

  • OS: Ubuntu
  • Prometheus は systemd により `/var/lib/prometheus` にデータ保存中
  • 移行後は VictoriaMetrics(+vmagent)で運用する
  • Prometheus の停止は TSDB データ移行直前まで遅らせる
  • すべてのバイナリは `/usr/lib/victoriametrics/bin` 以下に配置
  • 設定ファイルは `/etc/victoriametrics/` 以下に配置

1. ディレクトリ構成の準備

sudo mkdir -p /usr/lib/victoriametrics/bin
sudo mkdir -p /etc/victoriametrics/vmagent
sudo mkdir -p /var/lib/victoriametrics

2. VictoriaMetrics のインストール

sudo useradd -s /usr/sbin/nologin victoriametrics
sudo chown -R victoriametrics:victoriametrics /var/lib/victoriametrics
wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.117.1/victoria-metrics-linux-amd64-v1.117.1.tar.gz
tar -xzf victoria-metrics-linux-amd64-*.tar.gz
sudo cp victoria-metrics-prod /usr/lib/victoriametrics/bin/

3. vmagent, vmctl のインストールと設定

wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.117.1/vmutils-linux-amd64-v1.117.1.tar.gz
tar xzvf vmutils-linux-amd64-*.tar.gz
sudo cp vmagent-prod /usr/lib/victoriametrics/bin/
sudo cp /etc/prometheus/prometheus.yml /etc/victoriametrics/vmagent/scrape.yml
sudo cp vmctl-prod /usr/lib/victoriametrics/bin/

`scrape.yml` は `scrape_configs` 部分と global の scrape_interval だけのこす

5. systemd ユニットファイルの作成

/etc/systemd/system/victoriametrics.service
[Unit]
Description=VictoriaMetrics service
After=network.target

[Service]
Type=simple
User=victoriametrics
Group=victoriametrics
ExecStart=/usr/lib/victoriametrics/bin/victoria-metrics-prod \
  -storageDataPath=/var/lib/victoriametrics \
  -retentionPeriod=365d -selfScrapeInterval=10s
SyslogIdentifier=victoriametrics
Restart=always

PrivateTmp=yes
ProtectHome=yes
NoNewPrivileges=yes

ProtectSystem=full

[Install]
WantedBy=multi-user.target
`/etc/systemd/system/vmagent.service`
[Unit]
Description=vmagent
After=network.target

[Service]
User=victoriametrics
Group=victoriametrics
ExecStart=/usr/lib/victoriametrics/bin/vmagent-prod \
  -promscrape.config=/etc/victoriametrics/vmagent/scrape.yml \
  -remoteWrite.tmpDataPath=/var/tmp/vmagent/tmp/ \
  -remoteWrite.url=http://localhost:8428/api/v1/write
  Restart=on-failure
  User=nobody
  Group=nogroup

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable victoriametrics
sudo systemctl enable vmagent

7. VictoriaMetrics と vmagent の起動

sudo systemctl start victoriametrics
sudo systemctl status victoriametrics

sudo systemctl start vmagent
sudo systemctl status vmagent

6. TSDB データ移行(vmctl)

Prometheus snapshot の作成
curl -XPOST http://127.0.0.1:9090/api/v1/admin/tsdb/snapshot
{"status":"success","data":{"name":"20250516T103320Z-3bf4745e0d76170b"}}%

(snapshot はハードリンクなだけなのでいらなくなったらディレクトリごと消せばよい)

vmctl を使ってデータを移行
sudo /usr/lib/victoriametrics/bin/vmctl-prod prometheus --prom-snapshot=/var/lib/prometheus/snapshots/20250516T103320Z-3bf4745e0d76170b
2025/05/16 19:33:50 ERROR: metrics: disable exposing PSI metrics because of failed init: open /sys/fs/cgroup/system.slice/ssh.service/cpu.pressure: no such file or directory
Prometheus import mode
Prometheus snapshot stats:
  blocks found: 27;
  blocks skipped by time filter: 0;
  min time: 1714608000341 (2024-05-02T09:00:00+09:00);
  max time: 1747391598321 (2025-05-16T19:33:18+09:00);
  samples: 11071261940;
  series: 135060.
Found 27 blocks to import. Continue? [Y/n]

結構時間がかかる。12GBで2時間弱ぐらい。インポート後は2.5GBになった。

8. Grafana の設定変更(任意)

  • Grafana にログイン
  • Data Sources > Add data source > Prometheus
  • URL を `http://localhost:8428` に設定
  • Save & Test

http://localhost:9090/

9. Prometheus の停止

sudo systemctl stop prometheus
sudo systemctl disable prometheus
  1. トップ
  2. tech
  3. Prometheus から VictoriaMetrics への移行(Ubuntu, systemd)