CoinbaseのソフトウェアエンジニアであるLuke Demi氏は、2018年半ばからCoinbaseで実施されてきたモニタリングとロギングの変更に関する記事を書いている。Coinbaseは、ログ分析とメトリクス視覚化という2つの目的を果たすセルフマネージドのElasticsearchクラスタから、メトリクスコレクション用のDatadogとログアグリゲーション用のAWSのマネージドElasticsearchへと移行した。
Coinbaseは、AWS上にホストしたセルフマネージドのElasticsearchクラスタを、エンジニアリングや他の機能チームで使っていた。カスタムのアプリケーションメトリクスは、アプリケーションの標準出力をパースすることで収集されていた。AWS CloudwatchはOSメトリクスを公開しているが、これらはカスタムメトリクスとは別のダッシュボードで使われていた。
2017年の暗号通貨ブームでCoinbaseのトラフィックは増加し、彼らのアプリが生成するログデータの量も増大した。彼らのElasticsearchクラスタは、こうした新たな負荷に対してスケールできなかった。負荷に伴う機能障害はクラスタの再起動を必要とし、負荷の高いクエリに対して弱かった。また、クラスタを再起動しない限り、診断データを収集することもできなかった。
チームは、最大のアプリケーションが大半のElasticsearchキャパシティを消費していることに気づいた。彼らはデータ量の増大に対処するため、ログ保存期間の短縮を余儀なくされた。Demi氏によると、Elasticsearchを回避するElastAlertやWatcherといったアラートのソリューションは、エンジニアが「インタラクティブにアラートを構築することができず」、サードパーティ製のツールとの統合は困難だったという。
Coinbaseのエンジニアリングチームは、様々な同時使用のユースケースに対応可能なスケーラブルなElasticsearchクラスタという課題を解決し、メトリクスコレクション、モニタリング、アラートシステムを用意する必要があった。彼らはAWSのマネージドElasticsearchサービスを使うことにした。これはフロントにnginxプロキシを用いるユースケースにより、論理的にシャーディングされる。これまでのCoinbaseのクラスタは、認証と認可のためにElasticの製品であるX-Packに依存しており、AWSのソリューションでは利用できない。プロキシを使うことで、やってくるリクエストに基づいてリクエストを適切なKibanaダッシュボードにルーティングし、Coinbaseの内部SSO（シングルサインオン）サービスに対して認証を実行する。
メトリクスに関して、チームはメトリクスコレクションとアラート用にDatadogをデプロイした。彼らは、提供されているものの代わりに独自のDockerコンテナを構築する、Datadogが必要かプロジェクトに選ばせる、そのホスト上の他のコンテナとは別のネットワークブリッジで実行する、といったセキュリティバリアを追加した。また、プロキシを用いて標準のDockerソケットをラップし、エージェントが環境変数にアクセスできないようにした。
Coinbaseチームは、新しいメトリクスに関するサービスレベル指標と、関連する時系列グラフを定義した。新しいツールセットによって、信頼性は高まり、ロギングパイプラインの保守オーバーヘッドは削減されたとDemi氏はいう。しかしながら、ログとメトリクスは別のサードパーティサービスにより収集されるため、それらの相関がどうなるかははっきりしない。