Stack Exchange のアーキテクチャリードである Nick Craver 氏は最近、彼らの監視システムについて記事を書いた。彼はそのモニタリング戦略の背後にある哲学と動機について議論し、そのツール群、Bosun、Grafana、Opserver などについて語った。
Stack Overflow と Stack Exchange にある姉妹サイトは .NET と MS の SQL Server、 IIS ウェブサーバー、HAProxy (ロードバランサーとして)、 Redis が提供する追加サービス、そして Elasticsearch で構成されている。彼らのプライマリーデータセンターはニューヨークにあり、フェイルオーバー用としてオレゴンのものがある。 Stack Exchange のモニタリングは Craver 氏いわく、主にログ、メトリクス、ヘルスチェック、プロファイリングによって構成されており、彼らはツールとして Bosun、 Opserver、Grafana そして MiniProfiler を利用している。
Stack Exchange のモニタリングシステムのデータソースはログ、ヘルスチェック、そしてデータ系列のメトリクスだ。ロギングは標準的なメカニズムとデータベースに書き込むカスタムライブラリによって実現されている。また Logstash と、HAProxy ロードバランサーからの HTTP リクエストが要約されたログイベントも含まれる。ホームページなどが実際にエンドユーザーにどのように見えたかをテストする、価値あるヘルスチェックが行われる。 Bosun はアラートを送り Pagerduty はエスカレーション管理を司る。そして、モニタリングシステム全体のダッシュボードビューを表示する Opserver と呼ばれるツールが全体像を完成させる。
画像出典: https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/
すべての Stack Exchange アプリケーションは、ログを MSSQL Server に送信するStackExchange.Exceptionalと呼ばれるエラーロギングライブラリを使用している。これは ELMAH という .NET のロギングライブラリのフォークだ。 Redis、 Elasticsearch そして SQL Server は標準のロギングロケーションにログを書き込むが、そのログが集約と検索のための中央サーバーに送信されたかどうかは確かではない。ネットワーク機器からのログは Logstash に送信され Kibana のダッシュボードで確認することができる。ページロードタイムは MiniProfiler を用いて詳細を解析することができ、そこでは様々な層を通してメソッドコールのタイミングが表示される。
Bosun は Stach Exchange が開発し後にオープンソース化されたモニタリングツールだ。 Bosun の重要な機能は、過去のデータに対するテストアラート機能、時系列の評価へのクエリ言語、テンプレート化されたアラート、時系列の傾向によるアラート通知と予測だ。 Nagios や Zabbix などの従来のモニタリングツールと対象的に、そして Prometheus のようなモダンなものと同様に、 Bosun は個別のアラートをサーバーごとに設定する必要がない。単一のしきい値によってすべてのサーバーを横断的に CPU 使用率などの時系列を測定できる。アラートにはしきい値を超えた時系列のリストがあり、問題があったサーバーを特定するのに利用される。
Bosun はストレージとして複数のバック園のをサポートしており Stack Exchange では OpenTSDB (と HBase) が使用されている。これは彼らの泣き所の一つである。彼らはほかに HBase を使用していないため、管理上のオーバーヘッドが大きい、と Bosun の当初の作者のひとりである Kyle Brandt 氏は言う。 Bosun を補助するエージェントとして scollector があり、これは監視対象のマシンからメトリクスを収集する。 scollector は OpenTSDB の tcollector エージェントを Go ベースで置き換えたものだ。アプリケーションのメトリクスは BosunReporter によってプッシュされる。
ヘルスチェックは内部サーバーの状態だけでなくエンドユーザーの体験にも目を向ける。 Pingdom は外部到達可能な URL をチェックする。ホームページなど URL チェックに直面するエンドユーザーはキーとなる。なぜなら、ホームページは私たちがチェックしないかもしれないこともチェックするためであり、そのために全体チェックが重要だ、と Craver 氏は述べる。 Fastly は CDN と Stack Exchange のサイトへのプロキシとして振る舞い、そのヘルスチェックによって、プライマリデータセンターがダウンしたときによってセカンダリデータセンターへフェイルオーバーされることが保証される。サーバーサイドモニタリングだけでなく、クライアントサイドの処理時間も browser API によって記録されている。
これらすべてをつなぎ合わせるのが Grafana と Opserver だ。 Bosun の Grafana プラグインは時系列のメトリクスを表示する。一方で Observer は、インフラ全体のステータス監視に集中する。なぜ彼らは Nagios や同様のツールを使用するのではなく自ら Opserver を開発したのか？ Craver 氏は、いずれのツールも彼らの要求を満たすものではなかったと説明した。 Opserver はその他ツール群と同様に、特定の要件により進化したものだ。 Opserver のダッシュボードは個別のサービスとサーバーについてドリルダウンができる。これは統計的に JSON フォーマットで表現された設定が必要であり、マシンを一時的に使用するクラウド環境を監視する場合には障害となるだろう。