Prometheusユーザーインタビューシリーズの続きとして、iAdvizeのLaurent COMMARIEU氏が、レガシーのNagiosとCentreon監視をPrometheusに置き換えた方法について語ります。
iAdvizeについて教えていただけますか？
私はiAdvizeのシステムエンジニア、Laurent COMMARIEUです。60名体制のR&D部門内の5名体制のシステムエンジニアチームで勤務しています。私たちの仕事は主に、アプリケーション、サービス、および基盤システムの稼働を確保することです。開発者と協力して、コードを本番環境に最も簡単にデプロイするためのパスを確保し、各ステップで必要なフィードバックを提供しています。そこで監視が重要になります。
iAdvizeはフルスタックのコンバーセーショナルコマースプラットフォームです。ブランドがコミュニケーションチャネル（チャット、通話、ビデオ、Facebookページ、Facebook Messenger、Twitter、Instagram、WhatsApp、SMSなど）に関係なく、顧客と一元的にやり取りするための簡単な方法を提供します。当社の顧客は、40カ国にまたがるEコマース、銀行、旅行、ファッションなどの業界で活動しています。フランス、英国、ドイツ、スペイン、イタリアにオフィスを構える200名の従業員を抱える国際的な企業です。2015年には1600万ドルを調達しました。
Prometheus導入前の監視経験について教えていただけますか？
私は2016年2月にiAdvizeに入社しました。それ以前は、ネットワークおよびアプリケーション監視を専門とする企業で勤務していました。Nagios、Cacti、Centreon、Zabbix、OpenNMSなどのオープンソースソフトウェア、およびHP NNM、IBM Netcoolスイート、BMC Patrolなどの商用ソフトウェアを使用していました。
iAdvizeは以前、監視を外部プロバイダーに委託していました。彼らはNagiosとCentreonを使用して24時間365日の監視を確保していました。このツールセットは、レガシーの静的アーキテクチャ（ベアメタルサーバー、仮想マシンなし、コンテナなし）では正常に機能していました。この監視スタックを補完するために、Pingdomも使用していました。
モノリシックアプリケーションをマイクロサービスアーキテクチャ（Dockerを使用）に移行し、現在のワークロードをインフラストラクチャクラウドプロバイダーに移行しようとしたため、監視の制御と柔軟性を高める必要がありました。同時に、iAdvizeは3人を採用し、インフラストラクチャチームは2名から5名に増えました。古いシステムでは、Centreonに新しいメトリクスを追加するのに少なくとも数日または1週間かかり、時間と費用がかかっていました。
なぜPrometheusを選択することにしたのですか？
Nagiosなどは適切な選択肢ではないと認識していました。当時、Prometheusは台頭しつつある存在であり、PoCを行うことにしました。Sensuも当初候補にありましたが、Prometheusの方が私たちのユースケースに適しているように思えました。
サービスディスカバリシステムであるConsulと統合できるものが必要でした。私たちのマイクロサービスにはすでに/healthルートがありました。/metricsエンドポイントの追加は簡単でした。使用したほぼすべてのツールについて、エクスポーターが利用可能でした（MySQL、Memcached、Redis、nginx、FPMなど）。
紙の上ではうまくいきそうでした。
どのように移行しましたか？
まず、開発チーム（40名）にPrometheusが最適なツールであり、アプリにエクスポーターを追加する必要があることを納得させる必要がありました。そこで、RabbitMQで簡単なデモを行い、RabbitMQエクスポーターをインストールして、簡単なGrafanaダッシュボードを作成し、使用状況メトリクスを開発者に表示しました。Pythonスクリプトを使用して、いくつかのキューを作成し、メッセージの発行/消費を行いました。
キューとメッセージがリアルタイムで表示されるのを見て、彼らは非常に感銘を受けました。それ以前は、開発者は監視データにアクセスできませんでした。Centreonはインフラストラクチャプロバイダーによって制限されていました。今日では、Google認証統合を使用して認証を行い、iAdvizeの全員がGrafanaを使用できます。78のアクティブアカウントがあります（開発チームからCEOまで）。
ConsulとcAdvisorを使用して既存のサービスの監視を開始した後、コンテナの実際の存在を監視しました。Pingdomチェックを使用して監視していましたが、十分ではありませんでした。
データベース（MySQLとRedis）からいくつかのビジネスメトリクスをスクレイピングするためのカスタムエクスポーターをGoでいくつか開発しました。
すぐに、すべてのレガシー監視をPrometheusで置き換えることができました。
切り替えてからどのような改善が見られましたか？
ビジネスメトリクスが非常に人気になり、販売期間中は誰もがGrafanaに接続して、記録を破れるかどうかを確認しています。同時会話数、ルーティングエラー、接続されているエージェント数、iAdvizeタグを読み込んでいる訪問者数、APIゲートウェイへの呼び出し数などを監視しています。
NewrelicエクスポーターとGrafana用Perconaダッシュボードに基づいた分析を使用して、MySQLサーバーを1か月間最適化しました。これは大きな成功であり、非効率性を発見し、最適化を実行することで、データベースサイズを45％、ピークレイテンシを75％削減することができました。
他にもたくさんあります。AMQPキューにコンシューマーがいない場合、または異常なほどいっぱいになっている場合がわかります。コンテナが再起動したときもわかります。
可視性は素晴らしいです。
これはレガシープラットフォームの場合です。
ますます多くのマイクロサービスがクラウドにデプロイされるようになり、Prometheusを使用してそれらを監視しています。Consulを使用してサービスを登録し、Prometheusを使用してメトリクスルートを検出しています。すべてがうまく機能しており、多くの重要なビジネス、アプリケーション、システムメトリクスを含むGrafanaダッシュボードを作成できます。
Nomadを使用してサービスをデプロイするためのスケーラブルなアーキテクチャを構築しています。NomadはConsulで正常なサービスを登録し、タグの再ラベル付けにより、「metrics=true」というタグ名を持つサービスをフィルタリングできます。これにより、監視のデプロイにかかる時間が大幅に短縮されます。何もする必要はありません^^。
EC2サービスディスカバリも使用しています。これは、自動スケーリンググループで非常に役立ちます。インスタンスをスケーリングおよびリサイクルし、既に監視されています。本番環境で何が起こっているかに気付くために、外部のインフラストラクチャプロバイダーを待つ必要がなくなりました。
Alertmanagerを使用して、SMSまたはFlowdockにアラートを送信します。
iAdvizeとPrometheusの将来についてどう思いますか？
- 容量計画のための長期的なスケーラブルなストレージを簡単に追加する方法を待っています。
- いつか、自動スケーリングがPrometheusのアラートによってトリガーされることを夢見ています。応答時間とビジネスメトリクスに基づいて自律システムを構築したいと考えています。
- 以前はNetuitiveを使用していましたが、自動相関機能を備えた優れた異常検出機能がありました。Prometheusにもそのような機能があれば素晴らしいです。