Lycolog

検索条件

タグで絞り込み OS(1) OS::Linux(1) OS::Linux::Ubuntu(1) ジャンル::インターネット(2) ジャンル::サイト運営(6) ソフトウェア(6) ソフトウェア::CMS(2) ソフトウェア::CMS::adiary(2) ソフトウェア::Forgejo(3) ソフトウェア::Git(1) ソフトウェア::HTTPD(1) ソフトウェア::HTTPD::nginx(1) ネットワーク(1) ネットワーク::IPv4(1) ネットワーク::IPv6(1) 技術(2) 技術::監視(2)

全14件 (2/3ページ) 記事本文を表示

2026/06/08(月)FluentBitでSystemdのログをLokiに送ってGrafanaで見れるようにし、ついでに設定をYAMLにした

更新日：2026/06/10
投稿日：2026/06/08

技術::監視ジャンル::自宅サーバー

本記事は自宅サーバーに雑に監視を入れた時にやったこと、先日の自宅サーバー移転に対し追加対応をしたの続きである。

今回はSystemdのログをFluentBitで拾ってLokiに送ってGrafanaで見れるようにしたログ。

AWSやDockerなどを使った情報は散見したが、バイナリをネイティブ環境で動かしている情報や、複数のデーモンのログを収集する方法が見当たらなかったのでちょっと苦労した。GPT-5.5も正確なことを言わないので真面目にリファレンスを読んだりググったりして何とかした。LLM頼みも限度があるね。

確認環境

Env	Ver
OS	Ubuntu 24.04.4 LTS
Fluent Bit	5.0.6
Loki	3.5.9
Grafana	12.1.1

設定内容

今回は前回までのconfig設定をYAML設定に全面移行した。基本的にはデフォルトのconfigファイル＋私が使っているI/Oの移植である。Lokiの待ち受けポートが9100であると仮定して進める。

各設定については公式マニュアルを参照のこと。

service → Service | Fluent Bit: Official Manual
storage → Storage configuration | Service | Fluent Bit: Official Manual
- serviceに元々あったが別キーに分離している。但しドキュメントのページは同じ。わかりづらい
systemd → Systemd | Fluent Bit: Official Manual
- systemd_filterを複数設定する方法は記載がないが、配列にすればよい

service:
  flush: 1
  log_level: 'info'
  parsers_file: 'parsers.conf'
  plugins_file: 'plugins.conf'
storage:
  metrics: 'on'
pipeline:
  inputs:
    - name: 'systemd'
      tag: 'systemd'
      db: '/var/lib/fluent-bit/systemd.db'
      systemd_filter:
        - '_SYSTEMD_UNIT=adiary.service'
        - '_SYSTEMD_UNIT=mastodon-web.service'
        - '_SYSTEMD_UNIT=mastodon-sidekiq.service'
        - '_SYSTEMD_UNIT=mastodon-streaming@5001.service'
    - name: 'tail'
      tag: 'nginx.access'
      path: '/var/log/nginx/access.log'
      parser: 'json'
      db: '/var/lib/fluent-bit/nginx-access.db'
      refresh_interval: 5
    - name: 'tail'
      tag: 'nginx.error'
      path: '/var/log/nginx/error.log'
      db: '/var/lib/fluent-bit/nginx-error.db'
      refresh_interval: 5
    - name: 'tail'
      tag: 'apache.access'
      path: '/var/log/apache2/access.log'
      parser: 'apache2_vhost'
      db: '/var/lib/fluent-bit/apache_access.db'
      refresh_interval: 5
    - name: 'tail'
      tag: 'apache.error'
      path: '/var/log/apache2/error.log'
      db: '/var/lib/fluent-bit/apache_error.db'
      refresh_interval: 5
  outputs:
    - name: 'loki'
      match: 'systemd'
      host: '::1'
      port: 9100
      labels: 'job=systemd'
    - name: 'loki'
      match: 'nginx.*'
      host: '::1'
      port: 9100
      labels: 'job=nginx, log_type=$TAG[1]'
    - name: 'loki'
      match: 'apache.*'
      host: '::1'
      port: 9100
      labels: 'job=apache, log_type=$TAG[1]'

PARSER: apache2_vhost

前回の記事で作った以下のパーサーを利用している。

[PARSER]
    Name        apache2_vhost
    Format      regex
                ^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")?$
    Regex       ^(?<vhost>[^:]+):(?<port>\d+) (?<remote_host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>[^ ]*) (?<size>[^ ]*) "(?<referer>[^\"]*)" "(?<agent>[^\"]*)"$
    Time_Key    time
    Time_Format %d/%b/%Y:%H:%M:%S %z
    Time_Keep   On

また前回の記事で作成したapache_errorというパーサーについては役に立たなかったので使わなくなった。標準で付いてるapache_errorも使えないし、apache2もイマイチ使えないので公式のパーサーは当てにしないほうがいいのかもしれない。

なおパーサーは旧config形式で記述している。これはとてもじゃないが書き換えてられないボリュームだったのとYAMLに対応させようとするとエスケープがだるそうだったからだ。config形式は今年でサポート外になるようだが、既存の設定のプリセットはすべてconfig形式でしか存在しないため、何とも先行きが心配だ。

サービスの修正

設定を.confで読んでいるので、ここを.yamlに変えてやる。

 [Unit]
 Description=Fluent Bit
 Documentation=https://docs.fluentbit.io/manual/
 Requires=network.target
 After=network.target

 [Service]
 Type=simple
 EnvironmentFile=-/etc/sysconfig/fluent-bit
 EnvironmentFile=-/etc/default/fluent-bit
+ExecStart=/opt/fluent-bit/bin/fluent-bit -c /etc/fluent-bit/fluent-bit.yaml
-ExecStart=/opt/fluent-bit/bin/fluent-bit -c //etc/fluent-bit/fluent-bit.conf
 Restart=always

 [Install]
 WantedBy=multi-user.target

インストールした当時は何故YAMLで書いても読んでくれないのか悩んでいたが、こんなところで指定されていた。しかも何故かパスが二重スラッシュになっていたので、そこも直しておいた。

FluentBitが上手く動いてなさそうなときのデバッグ方法

以下のコマンドを流すと動いているかどうかが分かる。なんかログが取れてなさそうだったり、Lokiに届いてなさそうなときに使える。

/opt/fluent-bit/bin/fluent-bit -i systemd \
           -p systemd_filter=_SYSTEMD_UNIT=mastodon-web.service \
           -p tag='host.*' \
           -o stdout

あとがき

なんか最近のソフトウェアのマニュアルって論理的に書かれすぎてて具体的にどう設定したらいいのかよくわからなくて困る。もう少し具体的な設定例とか書いてくれてもいいと思うんだ。

YAML configuration files are the standard configuration format as of Fluent Bit v3.2. They use the .yaml file extension.

Classic configuration files will be deprecated at the end of 2026. They use the .conf file extension.

しかしconfigは今年末でサポート外になるという話があるのにGitHubのリポジトリの設定ファイルは全部configで、果たしてこんなので大丈夫なのか…とIssueを眺めていたら、そもそも開発側もYAMLの仕様を余り解ってないような空気を感じたので、これは今年中は厳しいのではないか？という感じがした。

ひとまず私はキー名がkebab-caseからcamelCaseになってもすぐ対応できるようにメインの設定だけYAMLにしておいたが、Parserを直すのはエスケープが面倒などもあると思うので、なかなか大変だと思う。

あと個人的に不思議に思った部分としてoutputsのlabelsが配列ではなく、文字列だというところだ。

pipeline:
  outputs:
    - name: loki
      match: '*'
      labels: job=fluentbit, mystream=$sub['stream']

何でここは配列にしなかったのだろうか？

実際に以下の記述でラベルが機能しているので、おそらくこの構文がFluentBitのDSLとして機能していて、真面目に配列すると改修が大変とか、そういうのがあるのかもしれないなとは思った。

    - name: loki
      match: 'apache.*'
      host: '::1'
      port: 9100
      labels: 'job=apache, log_type=$TAG[1]'

ちなみに一番ハマったのはブログ執筆用に作っていたLokiのポートを書き換えたメモを基に作業していて、未来永劫FluentBitがLokiに疎通しなかったことである。

コメント（0件）

2026/06/06(土)Anubisを雑に設置したが、結果微妙だったので撤去した話

投稿日：2026/06/06

ジャンル::自宅サーバージャンル::サイト運営

この記事の話は仮運用環境の構築なので、本番向きではない。また必要であろうDBのセットアップは今回していない。

Anubisとは？

端的に言うとBOTを弾くためのWAFのような奴だ。公式サイトはAnubis: Web AI Firewall Utility | Anubisだが、その名の通りLLMのクローラーを弾くことを重点にしている。

こういった感じのCloudflareにあるようなBOT認証画面が出てくるのだが、これが結構かわいい。公式サイトもかわいい。カナダのFF14プレイヤーの人が作ってるらしい。

実際の動作画面はList of known websites using Anubis | Anubis辺りから見れる。FOSSや、ザ・海外のオタクみたいなサイトが軒を連ねている。

最近BOTのアクセスが目立つし、こういう可愛いのいいなと思って導入を検討したのが事の発端だ。

ちなみにローディング画面はカスタマイズも可能なので、カスタマイズしている人もいるが、ちゃんとかわいい文化が継承されているのがいい。

またAnubisを導入しているサイトをClaude Opus 4.8に見させたところエラートラップに掛かって閲覧できなかったので機能的には問題なさそうだった。LLM越しにコンテンツを見られたくない場合には、かなりフィットしそうだ。

今回構築した構成

確認環境

adiaryはFastCGI + libfcgi-perl、PukiwikiはFastCGI + PHP-FPMで実行している。

Env	Ver
Ubuntu	24.04.4 LTS
Anubis	1.25.0
nginx	1.26.1
adiary	3.52dev / Extends 0.25.0
libfcgi-perl	0.82+ds-3build2
Pukiwiki	1.5.4
PHP-FPM	8.3.31-3+ubuntu24.04.1
Prometheus	3.5.0

導入方法

1. インストール

GitHubのリリース一覧から最新のバイナリのURLを控える
- 糞長いのでAMD64は項目を展開しないと出てこない
インストールする
```bash
curl -OL https://github.com/TecharoHQ/anubis/releases/download/v1.25.0/anubis_1.25.0_amd64.deb
sudo apt install ./anubis_1.25.0_amd64.deb
```

2. Anubisの設定

まずは/etc/anubis/default.envに設定があるので適当に書き換える。

以下は設定例。細かいのは公式の設定ドキュメントに書いてある。

BIND=[::]:10000
DIFFICULTY=4
METRICS_BIND=[::]:9110
SERVE_ROBOTS_TXT=0
REDIRECT_DOMAINS="example.com,*.example.com"
TARGET=http://[::1]:8081
OG_PASSTHROUGH=true

あとはサービスを有効化して開始すれば動く。

sudo systemctl enable anubis@default.service
sudo systemctl start anubis@default.service

今回設定した項目について

項目	役割
`BIND`	Anubis自体のListenポート
`DIFFICULTY`	チャレンジの難易度
`METRICS_BIND`	Prometheusがポーリングしに来る時のポート
`SERVE_ROBOTS_TXT`	Anubisに`robots.txt`を代理生成させるかどうか
`REDIRECT_DOMAINS`	Anubisの先にあるサイトのドメイン、無指定だと悪意のあるサイトに飛んでいく可能性がある
`TARGET`	Anubisがプロキシする先のサイト。Anubisから繋ぎこむ先を同じポート番号にしていれば一元的に飛ばせる
`OG_PASSTHROUGH`	OGをパススルーするかどうか。Anubis自身がOGを取り込んでSNSとかのOG取得BOTに渡してくれるのだと思う

3. TLS終端となるnginxの設定

example.com, blog.example.com, tool.example.comに対してAnubisを利かせたい場合、以下のように書く。

upstream anubis {
  server [::1]:10000;
}

server {
  listen 443 ssl;
  listen [::]:443 ssl;
  server_name example.com blog.example.com tool.example.com;

  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

  client_max_body_size 100M;

  location / {
    proxy_pass http://anubis/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

4. virtual host側のnginxの設定

listenポートをAnubisから投げるポートに変更し、TLS終端でなくなるため証明書も消し去る。ここは受け口ではないため受けるIPも片方だけあればいい。

 server {
-  listen 443 ssl;
-  listen [::]:443 ssl;
+  listen [::]:8081;
   server_name blog.example.com;

-   ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
-   ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

   ...
 }

余談だが、以下のような記述がある場合、Anubisがいい感じにしてくれるので消せる、というか消さないとポート番号がむき出しになったり、無限リダイレクトし始めるので、そういうことが起きたら消したほうがいい。

location = /hoge {
  return 301 /hoge/;
}

5. Prometheus側の設定

scrape_configs:に以下をぶら下げれば取れる。メトリクス名はanubis始まり。

  - job_name: 'anubis'
    static_configs:
      - targets: ['[::1]:9110']

ハマったところ

Pukiwikiに対して流すとHTTP通信になり、nginx側のポート番号が露出した

https://eco.lycolia.info/wikiにアクセスするとhttp://eco.lycolia.info:8081/wikiとなり、HTTP通信になったうえ、ポート番号が露出する問題が発生した。この問題はケツにスラッシュをつけてると起きなかった。

これはnginxに次の設定をしていたため、これを消すことで解消した。削除してもAnubisがいい感じに繋いでくれるようでhttps://eco.lycolia.info/wikiで問題なくアクセスできた。

location = /hoge {
  return 301 /hoge/;
}

Matomoでリファラが取れなくなった

取れないなぁ…と思ってググったら、GitHubにIssueが出ていたので取れないっぽい。

この時点で導入を断念した。

撤去

nginxの設定を戻す

Anubisを消す

sudo systemctl stop anubis@default.service
sudo systemctl disable anubis@default.service
sudo apt remove anubis
sudo rm -Rf /etc/anubis
sudo systemctl restart nginx

PrometheusからAnubisの設定を消して再起動
各ドメインにアクセスできるか確認
おわり

あとがき

BOT弾きついでにAnubisの可愛い画面を出せるようにと導入を検討していたが、結果として断念した。Matomoでリファラが取れないのが深刻すぎたからだ。

リファラが取れるようになったら、また試すかもしれないし、試さないかもしれない。或いはそういう風に改造するか。でもこの手の奴はセキュリティリスクが高いので、あまり自分では触りたくない気持ちもある。

しかし個人サイトWebオンリーめぐる市の会期中にサーバーの上げ下げをしながらメンテを連発していたので、何ともアレである。まぁうちのサイトは管理人である私が好き放題やる実験場なので仕方がないね。

コメント（0件）

2026/06/05(金)先日の自宅サーバー移転に対し追加対応をした

更新日：2026/06/08
投稿日：2026/06/05

ジャンル::サイト運営ジャンル::自宅サーバー

昨日、さくらのレンタルサーバでホスティングしていたサイトの大部分を自宅サーバーに移行したが改善点が幾つか見えたので、その追加対応をしたログ。

adiaryをApacheからNginx * FastCGIへ移行

こちらについては構築記事をUbuntuのadiaryをlibfcgi-perlで動かす方法に、パフォーマンス計測記事をサイト環境を移転したのでadiaryのパフォーマンス計測をやってみたに書いている。

ECO-WikiをApacheからNginx * PHP-FPMへ移行

Pukiwiki本体はPHP-FPM、それ以外をApacheで動かすようにしている。キメラ構成。

将来的にドメイン直下に静的コンテンツを置いたり、サイトをレガシー技術で拡張することを念頭に置いて設計しているがKISSだし、意味があるかどうかは謎である。

server {
  ...前略...

  root /var/www/path/to/eco;

  location = /wiki {
    return 301 /wiki/;
  }

  location /wiki/ {
    try_files $uri /wiki/index.php$is_args$args;
  }

  location ~ ^/wiki/.+\.php$ {
    fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  }

  location / {
    proxy_pass http://apache/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

FluentBitにApacheのパーサーを追加

/etc/fluent-bit/parsers.confに以下のパーサーを追加した。(LLMの言った内容のコピペ)

[PARSER]
    Name        apache_vhost
    Format      regex
    Regex       ^(?<vhost>[^:]+):(?<port>\d+) (?<remote_host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>[^ ]*) (?<size>[^ ]*) "(?<referer>[^\"]*)" "(?<agent>[^\"]*)"$
    Time_Key    time
    Time_Format %d/%b/%Y:%H:%M:%S %z
    Time_Keep   On

[PARSER]
    Name        apache_error
    Format      regex
    Regex       ^\[(?<time>[^\]]*)\] \[(?<module>[^:]*):(?<level>[^\]]*)\] \[pid (?<pid>[^\]]*)\](?: \[client (?<client>[^\]]*)\])? (?<message>.*)$
    Time_Key    time
    Time_Format %a %b %d %H:%M:%S.%L %Y
    Time_Keep   On

FluentBitでApacheのログをとれるようにした

/etc/fluent-bit/fluent-bit.confに対し、以下のような設定を追加。(LLMの言った内容のコピペ)

[INPUT]
    Name         tail
    Path         /var/log/apache2/access.log
    Tag          apache.access
    Parser       apache_vhost
    DB           /var/log/flb_apache.db
    Mem_Buf_Limit 5MB

[INPUT]
    Name         tail
    Path         /var/log/apache2/error.log
    Tag          apache.error
    Parser       apache_error
    DB           /var/log/flb_apache_error.db

[OUTPUT]
    name        loki
    match       apache.*
    host        ::1
    port        9100
    labels      job=apache, log_type=$TAG[1]

上記の設定にあるポート番号は他の記事と整合するように書いているつもりだが、ひょっとしたらずれているかもしれない。ちなみにうちのサーバーでは上記と別のポートを使っている。

Apacheのバーチャルホスト設定からログ設定を削除し、グローバル設定に集約

こうすることでログファイルを統一でき、管理が楽になる。

/etc/apache2/sites-enabled/hoge.confからログ設定を削除

        #LogLevel info ssl:warn

-         ErrorLog ${APACHE_LOG_DIR}/eco-error.log
-         CustomLog ${APACHE_LOG_DIR}/eco-access.log combined
</VirtualHost>

/etc/apache2/apache2.confのファイル末尾に共通的なログ設定を追加。vhost_combinedを指定することでログにホスト名が出るようになっている

ErrorLog ${APACHE_LOG_DIR}/error.log
LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
CustomLog ${APACHE_LOG_DIR}/access.log vhost_combined

壊れていたカウンタを直した

今回のサイト移転に伴い、IPv6側が優先接続されるようになったのか、アクセスカウンタが回らなくなったため、アクセスカウンタにIPv6対応を施した。

具体的にはうちで使っているアクセスカウンタはリモホを見て日本のISPならカウントしているのだが、IPv6ではリモホが取れないためカウントできない問題があった。この問題そのものは去年の8月には気づいてIssueにしていたのだが、対応せず放置していたところ、ちょっとこれは困ると思って対応した。

変更差分としては、UAによるBOT判定を強化した上で、日本のISPかIPv6ならカウントするように変更した。また、条件分岐がmutableでイケてなかったので、Immutableになるように書き直した。

コメント（0件）

2026/06/05(金)Ubuntuのadiaryをlibfcgi-perlで動かす方法

投稿日：2026/06/05

ソフトウェア::CMS::adiaryジャンル::自宅サーバーOS::Linux::Ubuntu

サイト環境を移転したのでadiaryのパフォーマンス計測をやってみたの環境構築した時のログ。

確認環境

Env	Ver
Ubuntu	24.04.4 LTS
nginx	1.26.1
adiary	3.52dev / Extends 0.25.0
libfcgi-perl	0.82+ds-3build2

前提

nginxとperlがインストール済

手順

libfcgi-perlをインストールする
```
sudo apt install libfcgi-perl
```

/etc/systemd/system/adiary.serviceを次のように作成し、adiaryのFastCGIデーモンを作る

[Unit]
Description=adiary daemon
After=network.target

[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/var/www/path/to
ExecStart=/usr/bin/perl /var/www/path/to/adiary.fcgi /var/www/path/to/adiary.sock 10 100
Restart=always

[Install]
WantedBy=multi-user.target

サービスを有効化する

sudo systemctl enable adiary.service
sudo systemctl start adiary.service

nginxの設定を書く

server {
   listen 443 ssl;
   listen [::]:443 ssl;
   server_name  blog.example.com;

   client_max_body_size 100M;

   ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

   root /var/www/path/to/blog;

   location / {
      try_files $uri @adiary;
   }

   location /__cache   { deny all; }
   location /data      { deny all; }
   location ~ \.cgi$   { deny all; }

   location @adiary {
      include fastcgi_params;
      fastcgi_pass unix:/var/www/path/to/adiary.sock;
      fastcgi_param   Basepath        /;
   }
}