何を監視するのか？
サービスを提供する際にはSLO（Service Level Objective）を設けることが一般的です。
KARTEではサービス利用者に向けたSLO（外部SLO）の他に、よりシビアに設定した内部向けのSLO（内部SLO）も定義しており、後者の内部SLOを基準に監視を行っています。
監視は以下の情報などを利用して、さまざまな角度から行っています。
-
OSから見えるサーバのメトリクス
- CPU使用率、ディスク使用率、メモリ使用率など
-
DBのメトリクス
- クエリのレスポンスタイム、クエリ数、コネクション数など
-
エンドポイントからのレスポンスメトリクス
- ステータスコード、レスポンスタイムなど
-
GCPやAWSなどのクラウドサービスのメトリクス
- CloudLoadBalancingへのリクエスト数、Cloud Pub/Subのメッセージサイズなど
-
アプリケーションのメトリクス
- 関数の実行時間、処理のタイムアウト率など
-
ログ
- システムログ、アプリケーションログなど
このようにさまざまな情報を使って監視をしているのですが、この中でも特に「アプリケーションのメトリクス」が監視の肝になります。このメトリクスを監視することで、アプリケーションの挙動に基づく詳細なアラート設定、問題の切り分けが可能になり、問題発生時に素早く対応できるからです。
以降では「アプリケーションのメトリクス」を含むこれらの情報を、何を使って、どのように集めているのか、またそれらを使ってどのようなポイントで監視しているかを紹介していきます。
監視に利用するサービス
メトリクス監視
GCPにはStackdriverという監視サービスが存在しますが、KARTEでは現時点でStackdriverはほとんど利用しておらず、Datadogという監視サービスを中心にさまざまなメトリクスを監視しています。
Datadogを利用する主な理由としては、以下が挙げられます。
-
連携できるサードパーティサービス／プロダクトが豊富である
- Stackdriverで監視できる多くの項目が、Datadogで監視可能である
-
とことんユーザ視点でサービスが設計されている
- 豊富なアラートトリガー（閾値、異常値、外れ値など）が存在する
- 直感的に理解しやすいインターフェースが用意されており、アラート／ダッシュボードなどが作りやすい
- メトリクスへのタグ付けによって問題の切り分けが効率的にできる
- 開発スピードが早く、かなり早いサイクルで新しい機能/連携先が出てくる
-
サポートの質が高い
- どのような質問を投げても真摯でスピーディに対応してくれる
- 問題解決に有効なのであれば、時に非公開の機能も利用させてくれる
- GCPやAWSなどの特定のクラウドプロバイダーが提供しているサービスではないので、ベンダーロックインされにくい
この中でも特に1と2が私たちにとってDatadogを利用し続ける大きなモチベーションとなっています。
豊富なサードパーティサービス／プロダクトの連携先が用意されていることは、Datadogという統一的なインターフェースでそれらを監視できることを意味します。
また、とことんユーザ視点でサービスが設計されていることで日々の運用を効率的に行うことができます。
ログの監視
魅力的なサービスであるDatadogですが、長らくログの監視機能が存在しませんでした。Logmatic.ioというログ監視のサービスの買収が発表されたので、近いうちに実装されそうだと思っていたところ、「Announcing log processing and analytics in Datadog」という発表があり、ついにDatadogでもログを扱えるようになったようです。かなり高機能みたいなのでこちらも要検討です。
現時点では、ログ監視をする場合は別の仕組みを使っています。KARTEではログ監視のためにLogDNAというサービスを利用しています。このサービスではサーバから送信されたログを、Webブラウザ上でリアルタイムに閲覧することができます。
リアルタイムのログ閲覧以外にも「特定のキーワードが一定時間に一定回数出る」などをトリガーにSlackなどに通知する機能が存在し、これを用いてログの監視を行っています。
