Kubernetesの監視にPrometheusを使用する理由とその方法（前半）
Kubernetesの監視にPrometheusを使用する理由とその方法についての記事です。長い記事なので、前半と後半の２つに分けて投稿いたします。今回は前半です。
ZipRecruiterのIcingaとGraphiteからクラウドネイティブなオープンソースモニタリングへの道のり
Site Reliability Engineer（ＳＲＥ，サイト信頼性エンジニアリングや）その他のオペレーターは、システムが健全に機能していることを確認するために常に監視しています。これは、ノートパソコンの画面をちらっと見て電源が入っているかどうかを確認するような簡単なものから、メインのビジネスシステムと一緒に全く別の分散型監視システムを稼働させるような複雑なものまであります。
Icingaは、ZipRecruiter も含め、他のモニタリングサービスは10年以上にわたって組織に素晴らしいサービスを提供してきました。Icingaは、そんな監視システムの1つです。しかし、本番サービス（開発・ステージング環境も含む）をKubernetes（K8s）に移行したことで、Icingaはもはや監視のためのベストな選択ではなくなりました。
ここでは、私たちがPrometheusにたどり着いた理由と、うまく導入するための苦労した点について説明します。
Icingaのサーバー中心モデルとK8sの流体ノードのぶつかり合い
Icingaは、元々NetSaintとして知られていたNagiosから発展した人気のあるオープンソースの監視ツールです。Icingaは、サーバーをインストールしてコンフィギュアし、その上にソフトウェアをデプロイして、数ヶ月から数年間そのように動作させていた時代に設計されています。Icingaは、データ監視モデルの中心的な存在として「サーバー」を持っており、新しいサーバーを追加するには、Icingaのコンフィギュレーションを再生成し、インスタンスを再起動する必要があります。
しかし、Kubernetesは、ユニークで長期的なアイデンティティを考慮することなく、コンピュートパワーを管理することができます。K8sは、「ウェブサイトを動かすのはこの5台、データベースを動かすのはこの2台」などと、今も昔も非難するのではなく、「ノード」というプールを交換可能なサーバーとして扱います。
Kubernetes Schedulerは、ノード間でワークロードを移行することもできます。例えば、クラウドサーバー（ZipRecruiterで行っているAWS EC2など）を使用する場合、Kubernetesは一部のノードが十分に利用されていないと判断し、数台を廃止し、残りのワークロードを廃止予定のノードから利用可能な容量のある継続ノードに移動することができます。このような流動的なアプローチでプロセスを監視するIcingaの機能は非常に限られています。
