Hostinger インタビュー
2019年2月6日筆者: ブライアン・ブラジル
Prometheus ユーザーへのインタビューシリーズの続編として、Hostinger の Donatas Abraitis 氏が彼らのモニタリングの道のりについて語ります。
あなたと Hostinger の事業内容について教えていただけますか？
私は Donatas Abraitis、Hostinger のシステムエンジニアです。Hostinger はその名の通り、ホスティング会社です。2004年以来、000webhost.com プロジェクト（無料ウェブホスティングプロバイダ）を含め、約3,000万人のクライアントを抱えています。
Prometheus 導入以前のモニタリング経験について教えていただけますか？
Hostinger がまだ小規模な会社だった頃、オープンソースのモニタリングツールとして市場に存在していたのは Nagios、Cacti、Ganglia だけでした。これは若い人にフロッピーディスクドライブが何であるかを説明するようなものですが、Nagios と Cacti は現在も開発サイクルにあります。
当時は自動化ツールは存在しませんでした。Bash + Perl で作業をしていました。チームと自分自身をスケールアップしたいなら、自動化を無視すべきではありません。自動化がなければ、より多くの手作業が発生します。
当時、約150台の物理サーバーがありました。比較すると、今日では仮想マシンや物理サーバーを含めて約2000台のサーバーがあります。
ネットワーク機器では、SNMP はまだ広く使用されています。「ホワイトボックス」スイッチの登場により、通常のツールをインストールできるため、SNMP の必要性は低下しています。
SNMP の代わりに、スイッチ内で node_exporter やその他のエクスポーターを実行して、必要なメトリクスを人間が読める形式で公開することができます。美しいは醜いより優れている、ですよね？
私たちは CumulusOS を使用していますが、ほとんどの場合 x86 なので、あらゆる種類の Linux を実行するのに全く問題はありません。
なぜ Prometheus を検討することにしたのですか？
2015年に、自動化できるすべてのものを自動化し始めたとき、私たちは Prometheus をエコシステムに導入しました。当初は、Alertmanager、Pushgateway、Grafana、Graylog、rsyslogd が実行されている単一のモニタリングボックスがありました。
TICK (Telegraf/InfluxDB/Chronograf/Kapacitor) スタックも評価しましたが、当時の機能が限られていたため満足できませんでした。Prometheus は多くの点でよりシンプルで成熟しているように見えました。
どのように移行しましたか？
古いモニタリングスタック（NCG - Nagios/Cacti/Ganglia）からの移行期間中、私たちは両方のシステムを使用し、最終的には Prometheus のみを使用するようになりました。
私たちは約25個のコミュニティメトリクスエクスポーターと、lxc_exporter のようなカスタム作成されたエクスポーターを運用しています。ほとんどの場合、textfile collector を使用して、カスタムのビジネス関連メトリクスを公開しています。
切り替えてからどのような改善が見られましたか？
新しいセットアップにより、時間分解能が5分から15秒に改善され、きめ細かく深い分析が可能になりました。平均検出時間（MTTD）も4分の1に短縮されました。
Hostinger と Prometheus の将来についてどうお考えですか？
2015年以降、インフラストラクチャがN倍に成長したため、主なボトルネックは Prometheus と Alertmanager になりました。私たちの Prometheus は約2TBのディスクスペースを消費しています。そのため、メンテナンス中にノードを再起動したり変更したりすると、しばらくモニタリングデータが失われます。現在、Prometheus バージョン2.4.2を実行していますが、近い将来、2.6にアップグレードする計画があります。特にパフォーマンスと WAL 関連の機能に興味があります。Prometheus の再起動には10～15分かかります。これは許容できません。もう一つの問題は、単一の場所がダウンすると、モニタリングデータも失われることです。そこで、高可用性モニタリングインフラストラクチャを実装することにしました。2つの Prometheus ノードと、別の大陸に2つの Alertmanager を配置します。
私たちの主要な可視化ツールは Grafana です。プライマリノードがダウンした場合に、Grafana がバックアップの Prometheus ノードにクエリできることが極めて重要です。これは簡単です。HAProxy をフロントに配置し、ローカルで接続を受け入れます。
もう一つの問題：ユーザー（開発者や他の内部スタッフ）がダッシュボードを乱用して Prometheus ノードを過負荷にしないようにするにはどうすればよいでしょうか。
あるいは、プライマリがダウンした場合のバックアップノード、つまり「雷鳴の群れ」問題です。
この望ましい状態を達成するために、私たちはTricksterにチャンスを与えました。これにより、ダッシュボードの読み込み時間が驚くほど短縮されます。時系列データをキャッシュします。私たちの場合はキャッシュがメモリに格納されますが、他にも保存場所の選択肢があります。プライマリがダウンしてダッシュボードを更新しても、Trickster はメモリにキャッシュされた時系列データに対して2番目のノードにクエリを送信しません。Trickster は Grafana と Prometheus の間に位置し、Prometheus API と通信するだけです。
Prometheus ノードは独立していますが、Alertmanager ノードはクラスタを形成します。両方の Alertmanager が同じアラートを検知した場合、重複排除され、複数回ではなく一度だけアラートが発報されます。
将来的に多くの blackbox_exporter を実行し、Hostinger のすべてのクライアントのウェブサイトを監視する計画です。なぜなら、監視できないものは評価できないからです。
将来的には、より多くの Prometheus ノードを実装し、複数の Prometheus インスタンス間でノードをシャーディングすることを検討しています。これにより、1つの地域で1つのインスタンスがダウンした場合にボトルネックが生じることを防ぐことができます。