Prometheusは、SREおよび運用監視の世界で昨今、注目されているオープンソースのツールです。 Googleの内部監視サービス（Borgmon）のアイデアに基づき、DockerやKubernetesなどのサービスのネイティブサポートを利用して、クラウドベースのコンテナ化がなされ、グローバル向けに設計されています。
Prometheusの日本語記事はなかなか見つからず、公式のPrometheusドキュメントはありますが、情報が少ないのは事実です。 この記事では、Prometheusの動作、監視の利点と課題、Metricfireが役立つ理由の概要を説明していきます。 また、MetricFireのHosted Prometheusの14日間無料トライアルにて、Hosted Prometheusをすぐに始めることもできますので、ご参照下さい。
#Prometheus（プロメテウス）の構造を理解
Prometheusは、go言語で作られたアプリケーションであり、サーバー上、Dockerコンテナー内、または Kubernetesクラスターの一部として実行できます。 「Scrape Jobs」のリストを構成することで、メトリクスの検索場所を指定します。それぞれを実行するには、スクレイピングするエンドポイントを指定するか、エンドポイントを自動的に取得するようにサービスディスカバリを設定します。たとえば、Kubernetesをスクレイピングするには、Kubernetes APIサーバーエンドポイントが含まれます。次に、Kubernetes APIはエンドポイントを返し、現在のノードまたはポッドをスクレイピングします。
##エンドポイントをPrometheusに
アプリケーションはさまざまな言語で開発されていますが、クライアントライブラリを使用すれば、ほぼ全てのアプリケーションのメトリクスエンドポイントをPrometheusに送信できます。
特定のアプリケーションからメトリクスを収集し、Prometheusで利用できるようにする個別のエクスポーターを使用することもできます。各アプリケーションまたはエクスポーターエンドポイントは、Prometheusが要求するたびに、メトリクス、タグ、および適切なメタデータを提供します。公式および非公式の業者が数十のサービスを提供していますが、人気のあるものはnode_exporterで、Linuxおよびその他のUnixサーバーのシステムメトリクスを収集します。
##データ保管
メトリクスはディスクにローカルに保存され、デフォルトでは15日間のみ保持されるため、長期的なストレージソリューションではなく、スライド式のデータウィンドウが提供されます。 Prometheusには、複数の場所にメトリクスを保存する機能がありません。ただし、リクエストされたときにメトリクスは消費されないため、冗長性を持たせるために、同じサービスに対して複数のPrometheusを実行することが可能です。また、フェデレーションにより、1つのPrometheusサーバーが別のデータをこすり取り、関連または集約されたデータを1つの場所に統合することができます。
別のオプションとして遠隔での保管が出来、Prometheusは、remote_writeおよびremote_readエンドポイントで構成できます。 Prometheusは定期的にデータをremote_writeエンドポイントに転送し、照会すると、remote_readエンドポイントを介してデータを要求し、ローカルデータに追加出来ます。 これにより、メトリクスのはるかに長い時間枠を表示するグラフを生成できます。 Metricfireは、Prometheusインストール用にこれらのリモートストレージエンドポイントを提供出来、数年間のデータ保管も可能です。
#Prometheusを使うメリットは？
-
サービスディスカバリ（Service Discovery)
大規模な展開では常に変化する可能性がありますが、サービスディスカバリにより、Prometheusは現在のすべてのエンドポイントを簡単に追跡できます。サービスディスカバリは、Kubernetes、Openstack、AWS EC2などのさまざまなリソース管理サービスのサポートを介して実現できます。 DNSとファイルベースのサービスディスカバリには、一般的なオプションもあります。 -
停止の検出
Prometheusは監視対象を認識しているため、リクエストが失敗すると、停止は非常に迅速に検出されます。 -
PromQL
PromQLは、非常に柔軟でチューリング完全なクエリ言語です。メトリクスクエリに関数と演算子を適用し、ラベルでフィルタリングおよびグループ化し、正規表現を使用してマッチングとフィルタリングを改善できます。 -
監視されているサービスの負荷が少ない
メトリクスは生成時にメモリに保存され、要求されたときにのみ読み取り可能な形式に変換されます。これは、（Graphiteのようなサービスの場合のように）すべてのメトリクスを文字列に変換して、作成後すぐに送信するよりも少ないリソースで使用出来ます。また、メトリクスはバッチ処理され、HTTP経由で一度に送信されるため、UDPを使用しても、メトリクスごとの負荷は同等のものを送信するよりも低くなります。 -
トラフィック量の制御
プッシュ型のメトリクスサービスは大量のデータポイントによって圧倒される可能性がありますが、Prometheusは、サービス自体が非常に混雑していても、要求されたときにのみメトリクスを受信します。 Jenkinsのユーザーは、バッチが処理されるときにメトリクスボリュームが急上昇するのを見たことがあるかもしれませんが、Prometheusエクスポーターが配置されていると、生成されるイベントの数に関係なく、メトリクスは15秒ごとにクエリされます。これにより、監視サービスが安全に保たれます。 -
ブラウザーのメトリクス
メトリクスエンドポイントを直接見て、いつでも生成されているものを確認できます。 Prometheus独自のメトリクスは、http：// localhost：9090 / metricsで表示できます -
簡単な再構成
Prometheusはメトリクスを取得する責任があるため、必要な構成に変更があった場合、すべての監視対象サービスの構成を変更するのではなく、Prometheusで行うだけで済みます。
Prometheusを使用する上での課題
-
ストレージ
標準のストレージ方式は、サーバー上のスペースとリソースを使用します。これはPrometheus専用ではない場合があり、使用しているプラットフォームによっては高価になる可能性があります（AWSの高IO EBSボリュームは手頃な価格のようですが、コストがかかります）。ストレージが占める実際の容量はかなり簡単に計算でき、監視するサービスが多いほど、保存するデータも多くなります。 -
冗長性
Prometheusは1つの場所にのみ保存します。たとえば、データをストレージクラスターに保存できるGraphiteとは異なります。同じメトリックに対して複数のPrometheusインスタンスを実行することは、与えられたソリューションですが、間違いなく扱いにくく、少し面倒です。 -
イベント駆動型のメトリクスがない
各値はリクエストに応じて取得された特定の時点であり、メトリクスは短期間または断続的にしか利用できないため、短期間のジョブやバッチでは機能しません。 Prometheusは、プッシュゲートウェイを提供することでこの問題を回避します。 -
ネットワークアクセスの制限
監視対象のリソースへのアクセス制限は、それらのリソースへの外部アクセスがない可能性があるため、複数のPrometheusサービスを実行する必要があることを意味します。さまざまなメトリクスを表示するためにPrometheusのさまざまなインスタンスに接続するか、フェデレーションを使用して複数のPrometheusから1つの中央サーバーにメトリクスを取得する必要があります。
#ルールとアラート
Prometheusは、記録ルールとアラートルールの2種類のルールの構成をサポートしています。記録ルールを使用すると、PromQLスタイルのルールを指定して、変換と関数をデータに適用することにより、受信データから新しいメトリクスを作成できます。これは、たとえば、一度に表示するメトリクスが多数あり、それらの取得に時間がかかる場合に便利です。代わりに、その場で合計（）メトリックを作成できます。今後は1つのメトリックを取得するだけで済みます。
アラートルールは、指定された基準に違反した場合、収集されている1つ以上のメトリックを確認してアラート状態になるようにPrometheusに指示します。アラートの状態は、Prometheus UIのアラートページに移動するだけでチェックされます。Prometheusには通知を送信する機能がありません。 AlertManagerはその機能を追加するサービスであり、Prometheusサーバーが実行されているプラットフォームでエラーが発生した場合にアラートを個別に監視します。
MetricFire
Metricfireでは、ホストされたバージョンのPrometheusを提供しています。これには、既存のPrometheusで課題とされてきたものが解決され、ユーザーが大変使いやすい使用になっています。特にPrometheusの長期的なスケーラブルなストレージが組み込まれ、最大2年間の長期保存が可能なオフディスクストレージになっています。
Grafanaサービスも付属しており、Prometheusインストールをデータソースとして構成できます。または、Metricfireデータソースを使用して、すべてのPrometheusサーバーから保存されたデータを1か所にまとめて表示することもできます。各Prometheusサーバーは同じ名前の指標を生成することがあり、多くの場合、それ自体のホスト名をlocalhost：9090と見なします。グローバル構成で「external_labels」オプションを使用して、異なるPrometheusサーバーからの同様のメトリクスを確実に区別できます。
MetricFireの無料トライアルに参加して、製品がどれほど便利なのかを確認してください。また、デモの予約はこちらから、行えます。
何か質問等ございましたら、ご連絡ください。それでは、素晴らしい監視を！