Hostingerとのインタビュー

Prometheusユーザーへのインタビューシリーズを継続し、HostingerのDonatas Abraitis氏が同社のモニタリングジャーニーについて語ります。

ご自身のことと、Hostingerがどのような会社か教えていただけますか？

私はDonatas Abraitis、Hostingerのシステムエンジニアです。Hostingerは、その名前が示す通りホスティング会社です。2004年以来、000webhost.comプロジェクト（無料ウェブホスティングプロバイダー）を含め、約3000万人のクライアントがいます。

Prometheus導入前のモニタリング経験について教えてください。

Hostingerがまだ非常に小さな会社だった頃、オープンソースのモニタリングツールとしてはNagios、Cacti、Gangliaしか市場には存在しませんでした。若い人にはフロッピーディスクが何かを話すようなものですが、NagiosとCactiは今日でも開発サイクルの中にあります。

自動化ツールは存在しませんでしたが、Bash + Perlで対応していました。チームと自身をスケールさせたいのであれば、自動化は決して無視できません。自動化がなければ、より多くの手作業が発生します。

当時は約150台の物理サーバーがありました。比較すると、現在ではVMと物理マシンを含め、約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はキャッシュされた時系列データをセカンドノードにクエリしません。TricksterはGrafanaとPrometheusの間に位置します。Prometheus APIと通信するだけです。

Prometheusノードは独立していますが、Alertmanagerノードはクラスターを形成します。両方のAlertmanagerが同じアラートを検出した場合、複数回ではなく、一度だけ重複排除して発火します。

数多くのblackbox_exporterを実行し、すべてのHostingerクライアントのウェブサイトを監視する計画があります。なぜなら、監視できないものは評価できないからです。

将来的には、さらに多くのPrometheusノードを実行し、複数のPrometheusインスタンス間でノードをシャーディングする計画です。これにより、リージョンごとに1つのインスタンスがダウンしてもボトルネックが発生しなくなります。