Web Application向け(?)エラートラッキングツール Faultline の紹介

セキュリティ製品特集

#AWS

#監視

#監視サービス

夏目祐樹

2018.03.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは、夏目です。

今日は個人的に使っているエラートラッキングツールを紹介します。

エラートラッキングツール faultline

簡単に言うと、AWS上に構築して使う、エラー情報を収集するためのソフトウェアです。
付け加えると、当時Fusic (現GMO ペパボ)の小山さんが開発したサーバーレスなエラートラッキングツールです。

faultline本体はREST APIでエラー情報を登録/取得することしかできないので、エラーを収集したいアプリケーション側でfaultlineの各種言語用ライブラリを使うなり、自力でAPIにエラー情報を投げるなりしてあげる必要があります。
なのでWeb Application向けと題うったものの実際は何にでも使えます。現状ライブラリがある言語を見るとWeb Application向けかなぁって感じです。

機能

できることは、以下の5つです。

プロジェクトというくくりでエラーを集約
エラーの詳細記録
エラーの通知 (Slack, GitHub Issue, GitLab Issue)
エラーの集約通知 (30イベント以上発生したら通知/5回に1回通知)
エラーの時系列集計/グラフ (faultline-webui)

エラーの詳細を記録していることと、通知の頻度などを設定できることが自分は非常に気に入ってます。

使い方

$ git clone https://github.com/faultline/faultline  
$ cd faultline/  
$ npm install  
$ cp config.default.yml config.yml  
$ [Edit config.yml] # Api Keyとかここで決める
$ AWS_PROFILE=XXXXXX npm run deploy

Node.jsがインストールされていることやAWSのクレデンシャルの設定がすでにされていることが必要ですが、ざっと6コマンド程度でfaultline本体は構築できます。
構築に成功するとStackOutputs に ServiceEndpointが出力されるので、どこかわかるところに保存しておいてください。
(Endpointがわからないとエラーを登録できないので)

あとは、Faultlineのライブラリ使うなりREST API叩くなりでエラーを登録します。
とりあえずここではREST APIを叩いて登録してみます。エラーの内容はFaultlineリポジトリに同封されているエラーサンプル(sample-errors.json)を使います。

$ curl -X POST -H "x-api-key: [ここにconfig.ymlのclientApiKeyかapiKeyが入ります]" -H "Content-Type: application/json" -d @sample-errors.json [ここにServiceEndpointが入ります]/projects/sample-project/errors

エラーを登録したのでその内容を見てみます。

$ cd ..
$ git clone https://github.com/k1LoW/faultline-webui
$ cd faultline-webui
$ [Edit ./config.js] # EndpointとかApi Keyとかを記入する
$ open index.html # Macを使っていればopenで見ることができる
$ # Mac以外の方はローカルのindex.htmlをブラウザで開けばOK

sample-projectという名前のプロジェクトにいくつかエラーが登録されているのがわかります。

以下Web UIのサンプル画像(HTMLを開いた直後のプロジェクト一覧ではなく、エラーの詳細画面)

対応言語

公式で対応している言語は以下の4つです。

対応していない言語でも、サンプルエラーの登録でやったように、APIにエラー内容を送るように書いてしまえば使えます。
さらに言えば、faultlineのライブラリはairbrakeというエラートラッキングサービスのライブラリを参考にして作られているので、とりあえず使える程度のものは比較的作りやすいと思っています。

現に自分は、AWS Lambdaでfaultline-jsがうまく動かなかったため、node-airbrakeをベースにnode-faultline-protoというライブラリを作りました。

faultlineのコンセプト

faultlineのコンセプトとしては以下の4つがあるそうです。

Simple Deploy
Manageless
POST (errors) with config
Between "Only mail notify" and "Error tracking Service"

1. Simple Deploy

使い方で示したようにfaultlineの構築は非常に簡単です。

2. Manageless

OSSでありながらSaaSに近い感覚で運用できている
(※注意: 決して運用ゼロにはなりませんよ！！)

AWSのマネージド・サービスを使用しているため運用のほとんどをAWSにまかせることができます。
ついでに言うと、使ってるサービスも比較的安価です。

3. POST (errors) with config

設定値をツール側で保持するだけでステートの管理対象が増えてしまうので、できるだけ値を保持しないのが鉄則
APIベースのツールなのであれば、リクエストに必要な設定を毎回付与してしまえばいいというアイデア
秘匿が必要な設定値でさえもKMSを利用して暗号化してリクエストに付与する

設定値を毎回送り込むという発想には本当に脱帽する。
AWS LambdaがCallされたタイミングで情報がほとんど揃っていることになるので、どこかから設定値を引っ張ってくる必要もほぼ無くなるだろうし、このテクニックは使っていきたい。

4. Between "Only mail notify" and "Error tracking Service"

あくまで、「エラーメール通知のみの開発の世界」と「有償のエラートラッキングサービスに任せているの開発の世界」の間を狙っています。

本当の「管理レス」は金の弾丸を使った有償サービスなので。

エラー通知をメールでやっていたときのツラみとエラートラッキングサービスを導入するのが難しいという事情から生まれたのがfaultline。

ここまでしっかり考えてからプロダクトを作る必要があるんだなぁと自分は感銘を受けました。

自分はどう使ったか

このfaultlineをどう使ったかというと、大きく分けると２つのことに使ってました。

自作Serverless Web Applicationのエラー監視
AWS Lambdaの開発中のエラーの取得

使った感触でいくと後者が思った以上に大きかったです。
具体的に何をしていたかというと、Lambda関数の開発において最初にfaultlineにエラーを飛ばすように設定しておいてから開発していただけです。
開発中って予期しないエラーがよく起きるのですが、その詳細をすぐ見れるのと見れないのとでは大きな違いでした。