Prometheusユーザーへのインタビューシリーズを続け、HostingerのDonatas Abraitis氏がモニタリングの道のりについて語ります。
自己紹介とHostingerの事業内容について教えてください。
私はDonatas Abraitis、Hostingerのシステムエンジニアです。Hostingerはその名前が示す通り、ホスティング会社です。2004年以来、約3,000万人の顧客を抱えており、無料ウェブホスティングプロバイダーである000webhost.comプロジェクトも含まれています。
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コレクターを使用してカスタムのビジネス関連メトリクスを公開しています。
切り替え後、どのような改善が見られましたか？
新しいセットアップにより、時間分解能が5分から15秒に改善され、きめ細かく、非常に詳細な分析が可能になりました。平均検出時間 (MTTD) も4分の1に短縮されました。
HostingerとPrometheusの将来についてどのように考えていますか？
2015年以降、インフラストラクチャをN倍に拡張したため、PrometheusとAlertmanagerが主なボトルネックになりました。私たちのPrometheusは約2TBのディスク容量を消費します。そのため、メンテナンスのためにノードを再起動または変更すると、しばらくの間モニタリングデータが失われます。現在、Prometheusバージョン2.4.2を実行していますが、近い将来、2.6にアップグレードする予定です。特に、パフォーマンスとWAL関連の機能に興味があります。Prometheusの再起動には約10〜15分かかります。これは許容できるものではありません。もう1つの問題は、単一のロケーションがダウンした場合、モニタリングデータも失われることです。そこで、可用性の高いモニタリングインフラストラクチャを実装することにしました。2つのPrometheusノード、2つのAlertmanagerを別々の大陸に配置します。
私たちの主な可視化ツールはGrafanaです。プライマリがダウンした場合、GrafanaがバックアップPrometheusノードにクエリできることが非常に重要です。これは簡単です。HAProxyを前に置いて、ローカルで接続を受け入れるだけです。
もう1つの問題: ユーザー (開発者やその他の内部スタッフ) がPrometheusノードに過負荷をかけるダッシュボードを悪用するのをどのように防ぐか。
または、プライマリがダウンした場合のバックアップノード - 激しいアクセス集中問題。
目的の状態を達成するために、Tricksterを試してみました。これはダッシュボードの読み込み時間を信じられないほど高速化します。時系列データをキャッシュします。私たちの場合、キャッシュはメモリ内にありますが、保存場所の選択肢は他にもあります。プライマリがダウンしてダッシュボードを更新しても、Tricksterはメモリにキャッシュされている時系列データについて2番目のノードにクエリしません。TricksterはGrafanaとPrometheusの間に位置します。Prometheus APIと通信するだけです。
Prometheusノードは独立していますが、Alertmanagerノードはクラスタを形成します。両方のAlertmanagerが同じアラートを検出した場合、重複を排除し、複数回ではなく1回だけ発火します。
多数の*blackbox_exporter*を実行し、Hostingerのすべてのクライアントのウェブサイトを監視する計画があります。なぜなら、監視できないものは評価できないからです。
将来的には、より多くのPrometheusノードを実装して、複数のPrometheusインスタンス間でノードをシャーディングできるようにしたいと考えています。これにより、リージョンごとに1つのインスタンスがダウンした場合でもボトルネックが発生しなくなります。