前回は何を使って可視化しようかなと悩んでいろいろと試して比較したが、そのあと実際に形にしたので、今はこういったダッシュボードがいつでも眺められる。

System metrics dashboard

DigitalOceanの上でサーバーを4台立てて、一台はnginxの逆プロキシだけおいてる。一台はAPIサーバーで、一台PostgresのDBサーバー、そして一台はログ集計に使うElasticsearch/Grafanaのサーバー。もちろん開発中のサービスにこんなにはいらないところではあるが、DigitalOceanのレフェラルで期限付きの$100もらったので豪華にやってる。

API dashboard

通常のサイトやAPIならリクエストがリクエストで、あまり「リクエストって何」考える必要がない。一方分散連合だと、普通のAPIリクエストの他に、連合の他サーバーからきたリクエストと、こっちから他サーバーに向けて発信するリクエストもある。後者の2つはキツネの場合完全非同期で処理している。ログも「普通のAPIリクエスト」と「連合処理」で別ファイルに吐いてる。

APIはClojureで動いてて、ログはLogbackで直でJSONとしてファイルに出力している。最初はstdoutにもうちょっと読みやすい形で(も)吐こうと思ったけど、JSONでも意外とごちゃごちゃしないので、苦労して2種類の出力を作るの断念した。普通のアクセスログと連合ログはファイル分かれてる。ファイルからのログ収集はFilebeatでやって、そのままでElasticsearchに流してる。

- type: log
  enabled: true
  paths:
    - /usr/local/kitsune/log/federation*.log
  fields._class: federation
  json.keys_under_root: true
  processors:
  - decode_json_fields:
      fields: ["message"]
      target: ""

設定は必要最小限だけいじってる。inputのところで種類をカスタム値として定義して、それでElasticsearch上のインデックスも分けている。インデックスの準備やマッピングの定義などはFilebeatがよしなにやってくれるので、何も設定する必要なし。これでもうFilebeatの方でログのJSONを解読して、フィールドとしてElasticsearchに流してくれるし、もしログの項目増やしたら自動でインデックスも更新する。

Filebeatでログの流し先にいろいろな条件分岐とか、もっと複雑なことをやると、pipelines使った方がきれいに収まると思うけど、まだそこまで必要としてない。

Postgres台で遅いクエリのログを同じくFilebeatで収集しているが、Postgres用のmoduleがあって、それを有効にするだけで、設定が一切必要なし。Postgresの設定で log_min_duration_statementだけ適切な値に設定すればあとは自動。(ちなみに最初からクエリの最適化を頑張りたいので今は5msにしてる。これでも全然でないけど。)

収集する側で残るのはシステム監視。ClojureはJVMでリソースをけっこう食ってしまう傾向があるので、手は抜きたくない。ログ収集はFilebeatでやってるし、これはMetricbeatを使ってる。設定はモジュールの有効化と、流す先のElasticsearchの情報を入れるだけ。手軽で最高。

Grafana login

いよいよ見る側。Grafana入れてログインすると、最初はもちろんまっさら。Elasticsearchのそれぞれのインデックスを情報源として追加すると、オプションがどんどん広がる。ただ最初はゼロから自分でダッシュボード作るのはちょっと難易度高いので、システム監視用のはテンプレを使った。すごい数があるので見たい情報と趣味にも合うものがおそらく見つかる。APIの統計のダッシュボードはもう自分で作った(だから棒グラフとテーブルしかない。苦笑)

以降は一切触れる必要なく、眺めるだけの幸せな監視体制になった。グラフを見るだけでElasticsearchのGCの頻度や負荷とかも分かるし、連合のどのサーバーからどういうリクエストが飛んでくるか、その時間帯の傾向とかも見えるようになった。開発の合間に癒しによく見ている。「へーマストドンはこの時間帯でバッチ処理走らせてるだろうね、いっぱいユーザー削除の通知が飛んでくる」とか。

もっとグラフの動きを楽しみたいので、いち早くキツネを連合での我が巣にできるように頑張る。