🌲 📴 👵🏾 Prometheusによるサービス監視 😔 💍 🤞🏿

以前の出版物では、メトリックの監視と収集の問題に既に取り組んでいます。今日の記事では、このトピックに戻り、プロメテウスと呼ばれる興味深いツールについてお話したいと思います。 2012年に悪名高いSoundCloudプロジェクトの内部監視システムとして作成されましたが、その後さらに普及しました。

Prometheusは完全に新しいツールであり（最初の公開リリースは2015年の初めに行われました）、ロシア語ではほとんど公開されていません（数か月前にHacker誌に記事が掲載されましたが、購読者のみが利用できます）。

SoundCloud開発者は、マイクロサービスアーキテクチャへの移行に関連して新しい監視ツールが必要であったことに注意してください（こちらの詳細レポートを参照）。マイクロサービスへの関心の高まりは、ここ数年の特徴的な傾向の1つです。

マイクロサービスアプローチの観点から見ると、アプリケーションはモノリスとしてではなく、サービスのセットとして理解されます。これらの各サービスは独自のプロセスで動作し、単純なメカニズム（通常はHTTPプロトコルを使用）を使用して環境と対話します。

マイクロサービスの監視は簡単な作業ではありません。リアルタイムで、個々のコンポーネントの状態とシステム全体の状態の両方を監視する必要があります。技術的なものに加えて、ビジネス関連のインジケータも確認する必要がある場合、タスクは複雑です。プロメテウスの開発者自身が多数の記事やレポートで指摘しているように、既存の監視システムを使用してそれを解決することには問題があります。したがって、彼らは独自のツールを作成しました。

Prometheusは、監視フレームワークと独自の一時データベースの両方を含む完全なソリューションです。一部のレビューでは、「新世代監視システム」とも呼ばれています。

私たちはプロメテウスに関する出版物に興味があり、このツールをよりよく知ることにしました。

プロメテウスアーキテクチャ

次のコンポーネントは、Prometheusの一部です。

メトリックを読み取り、それらを時系列データベースに保存するサーバー。
さまざまなプログラミング言語のクライアントライブラリ（Go、Java、Python、Ruby。コミュニティはBash、Node.js、Haskell、.NET / C＃のライブラリも作成しました）。
Pushgateway-短期プロセスのメトリックを受信するためのコンポーネント。
PROMDASH-メトリックのダッシュボード。
サードパーティのアプリケーション（Statsd、Ganglia、HAProxyなど）からデータをエクスポートするためのツール。
AlertManager通知マネージャー（現在ベータテスト中）。
データを照会するためのコマンドラインクライアント。

それらのほとんどはGoで書かれており、非常に小さな部分はRubyとJavaで書かれています。

すべてのPrometheusコンポーネントは、HTTPを介して相互に通信します。

プロメテウスアーキテクチャ

システム全体の主要コンポーネントは、Prometheusサーバーです。自律的に動作し、すべてのデータをローカルデータベースに保存します。サービスの検出は自動的に行われます。これにより、展開手順が簡素化されます。単一のサービスを監視するために、分散監視システムを展開する必要はありません。サーバーとメトリックの収集とエクスポートに必要なコンポーネントをインストールするだけです。 Haproxy、MySQL、PostrgreSQLなど、特定のサービス向けに「調整」されたそのようなコンポーネントが既に多数あります（ GitHubのほか、こちらの全リストをご覧ください）。

プロメテウスメトリックは、プルメカニズムを使用して収集されます。プッシュメカニズムを使用してメトリックを収集することもできます（このために、個別にインストールされる特別なプッシュゲートウェイコンポーネントが使用されます）。これは、何らかの理由でプルを使用してメトリックを収集できない場合に必要になる場合があります。たとえば、ファイアウォールで保護されたサービスを監視する場合です。また、プッシュメカニズムは、ネットワークに定期的に短時間接続するサービスを監視する場合に役立ちます。

Prometheusは、時系列として表示されるデータの収集と分析に適しています。すべてのメトリックを独自の一時データベースに保存します（OpenTSDBおよびInfluxDBとの比較はこちらを参照してください）。 IndexDはLevelDBを使用します。

データモデル

プロメテウスはデータを時系列の形式で保存します-タイムスタンプに関連付けられた値のセット。

時系列の要素（ディメンション）は、メトリックの名前、タイムスタンプ、およびキーと値のペアで構成されます。タイムスタンプはミリ秒単位の精度で、値は64ビットの精度で表示されます。

メトリック名は、データが収集されているシステムパラメータを示します。たとえば、特定のAPIへのHTTPリクエストの数に関する情報を含むメトリックでは、名前はapi_http_requests_totalのようになります。このメトリックの時系列は、コード200の応答が返されたアドレス/ API /トラックへのすべてのGETリクエストに関する情報を保存できます。この時系列は、次の表記の形式で表すことができます。

api_http_requests_total{method="GET", endpoint="/api/tracks", status="200"}

Prometheusが使用するデータモデルは、OpenTSDBが使用するデータモデルに似ています。すべてのメトリックには名前がありますが、複数の行で同じになる場合があります。

さらに、各時系列には少なくとも1つのタグを付ける必要があります。 1つのタグの測定値は連続して保存されるため、高速のデータ集約が保証されます。

次のタイプのメトリックがサポートされています。

カウンター （カウンター）-時間とともに増加する値（たとえば、サーバーへの要求の数）を格納します。
スケール （ゲージ）-時間とともに増加および減少する可能性のある値（たとえば、使用されるRAMの量やI / O操作の数）を保存します。
ヒストグラム （ヒストグラム）-一定期間にわたるパラメーターの変更に関する情報を保存します（たとえば、11時間から12時間までのサーバーへのリクエストの合計数と11.30から11.40までの同じサーバーへのリクエスト数）。
結果の要約（要約）-ヒストグラムのように、時間間隔にわたるパラメーターの値の変化に関する情報を保管しますが、移動時間間隔の変位値を計算することもできます。

設置

次に、Prometheusを使用する実際的な側面を見てみましょう。インストール手順の説明から始めましょう。

最近では、Prometheusは公式のDebian 8およびUbuntu 15.10リポジトリに含まれています。

Ubuntu 14.04では、標準パッケージマネージャーを使用してインストールすることもできます。当然、これには適切なリポジトリを接続する必要があります。

 $ echo 'deb http://deb.robustperception.io/ precise nightly' > /etc/apt/sources.list $ wget https://s3-eu-west-1.amazonaws.com/deb.robustperception.io/41EFC99D.gpg $ sudo apt-key add 41EFC99D.gpg $ sudo apt-get update $ sudo apt-get install prometheus node-exporter alertmanager

上記のコマンドを使用して、Prometheusサーバーと、追加のコンポーネントnode_exporterおよびalertmanagerをインストールしました。 Node_exporterはサーバーステータスデータを収集し、指定された条件が満たされているか満たされていない場合にアラートマネージャー（詳細については後述します）を送信します。

インストールは完了しましたが、もう1つ小さなタッチがあります。node_exporterがバックグラウンドでメトリックを常に収集するようにする必要があります。これを行うには、まず/ usr / binにシンボリックリンクを作成します。

 $ sudo ln -s ~/Prometheus/node_exporter/node_exporter /usr/bin

次に、ファイル/etc/init/node_exporter.confを作成し、次の行を追加します。

 # Run node_exporter start on startup script /usr/bin/node_exporter end script

変更を保存して、コマンドを実行します。

 $ sudo service node_exporter start

systemdに切り替えたディストリビューション（Ubuntu 15.10など）で、node_exporterをバックグラウンドで実行するには、/ etc / systemd / system / node_exporter.serviceファイルを作成し、次の行を追加する必要があります。

 [Unit] Description=Node Exporter [Service] ExecStart=/usr/sbin/node_exporter Restart=Always [Install] WantedBy=default.target

変更を保存したら、コマンドを実行する必要があります。

 $ sudo systemctl enable node_exporter.service $ sudo systemctl start node_exporter

構成

デフォルトのPrometheus設定は、ローカルマシンで発生するすべてを追跡するのに十分です。必要に応じて、設定ファイル/etc/prometheus/prometheus.ymlで追加の設定を常に指定できます。その構造をより詳細に検討してください。それはグローバルセクションから始まります：

 global: scrape_interval: 15s evaluation_interval: 15s rule_files:

次のオプションが含まれます。

scrape_interval-メトリック収集間隔（デフォルトは15秒）;
evaluation_interval-ルールとの調整の間隔（デフォルトでは15秒）。
rule_files-ルールファイル（それらについては後述します）。

以下は、サーバー上のメトリックを収集するための基本設定を含むscrape_configsセクションです。

 scrape_configs: - job_name: "prometheus" - scrape_interval: "15s" target_groups: - targets: - "localhost:9090"

以下の必須パラメーターが含まれます。

job_name-タスク名。
scrape_interval-メトリック収集間隔（この例では、15秒ごと）。
target_groups-メトリックを収集する必要があるサービスおよびサービスのグループ。

同じセクションで、追加の設定を指定できます。

scrape_timeout-データのタイムアウト。
metrics_path-メトリックが送信されるHTTPリソース。
スキーム-メトリックの送信に使用されるプロトコル。
basic_auth-メトリックが収集されるサーバーでの承認の詳細（ユーザー名：、パスワード:)。

構成ファイルでルールファイルを参照できることは既に述べました。ルールは、最も頻繁に使用される、またはリソースを集中的に使用するパラメーターを事前に計算し、新しい時系列として保存するのに役立ちます。事前に計算されたパラメーターによる検索は、各リクエストで値を再計算するよりもはるかに簡単です。これは、たとえば、更新ごとにパラメーター値を要求するダッシュボードを使用する場合に役立ちます。

一般的に、ルールの構文は次のように表すことができます。

 <  >{} = <  >

より具体的で理解しやすい例を次に示します。

 job:http_inprogress_requests:sum = sum(http_inprogress_requests) by (job) new_time_series{label_to_change="new_value",label_to_drop=""} = old_time_series

Prometheusは、設定ファイルのevaluation_intervalパラメーターで指定された特定の頻度でルールをチェックします）。各調整の後、Prometheusはパラメーター値を再カウントし、現在のタイムスタンプを持つ新しい名前で保存します。

そのため、構成ファイルの構造と構文を一般的な用語で調べました。規定の設定を有効にするには、次のコマンドを実行する必要があります（パス/ / / prometheus.ymlの代わりに、構成ファイルへのパスを指定します）。

 $ prometheus -config.file “path/to/prometheus.yml”

Webインターフェース

Prometheus Webインターフェースは、ブラウザのhttp：// [サーバーIP]：9090：で利用できます。

prometheus_web_interface

[式]フィールドで、グラフを表示するメトリックを選択できます。たとえば、サーバー上のアクティブなメモリの量を追跡してみましょう。メトリックnode_memory_activeを選択し、「実行」ボタンをクリックします。

チャートの上には、統計を表示する期間を選択できるボタンがあります。

コンソールテンプレート

確認したメインのPrometheusコンソール。より専門的なチャートを表示するには、カスタムコンソールを使用します。

サーバーでは、/ etc / prometheus / consolesディレクトリに保存されます。カスタムコンソールには、一般的なサーバー統計（node.html）、CPU統計（node-cpu.html）、サーバーI / O統計（cpu-disk.html）などが表示されます。ブラウザでは、http：// [サーバーIP]：9090 / consoles / <コンソール名> .htmlで利用できます。

ここで、たとえば、node.htmlコンソールは次のようになります。

プロメテウス

使用可能なコンソールがどれも自分に合わない場合は、必要な統計を表示する独自のコンソールを作成できます。 PrometheusはGo HTMLテンプレートエンジンを使用してコンソールを記述します。カスタムコンソールを作成するための詳細な手順は、公式ドキュメントに記載されています。

何らかの理由で使用可能なコンソールに満足できない場合は、Prometheus を人気のあるGrafanaツールと統合できます。

Prometheus開発者は、インターフェイス上のGrafanaを連想させるPromdashと呼ばれる独自のダッシュボードツールを作成しました（ GitHubのリポジトリも参照）。私たちの意見では、それはまだやや「生の」状態であり、使用を推奨するには早すぎます。

Alertmanager：通知の設定

通知配布コンポーネントなしでは考えられない監視ツールはありません。 Prometheusはこの目的のためにalertmanagerを使用します。通知設定は、alertmanager.conf構成ファイルに保存されます。

次のスニペットを検討してください。

 notification_config { name: "alertmanager_test" email_config { email: "test@example.org" } aggregation_rule { notification_config_name: "alertmanager_test" }

その構文は理解できます。特定の条件が発生したときの通知を電子メールでtest@example.orgに送信する必要があることを示しました。

構成ファイルにルールファイルへのリンクを追加できます（実際、上記のメトリックを収集するためのルールファイルと違いはありません）。ルールは、通知を送信する必要がある条件を指定します。

一般に、ルールの構文は次のようになります。

 ALERT < > IF <   > FOR < > WITH < >> SUMMARY "< >" DESCRIPTION "< >"

より具体的な例については、ルールの機能を考慮してください。

例1：

 ALERT InstanceDown IF up == 0 FOR 5m WITH { severity="page" } SUMMARY "Instance {{$labels.instance}} down" DESCRIPTION "{{$labels.instance}} of job {{$labels.job}} has been down for more than 5 minutes."

このルールは、5分以上インスタンスが利用できない場合に通知を送信することを示します。

例2：

 ALERT ApiHighRequestLatency IF api_http_request_latencies_ms{quantile="0.5"} > 1000 FOR 1m SUMMARY "High request latency on {{$labels.instance}}" DESCRIPTION "{{$labels.instance}} has a median request latency above 1s (current value: {{$value}})"

このルールに従って、APIへのリクエストに対する平均応答時間が1ミリ秒を超えたらすぐに通知を送信する必要があります。

構成ファイルで指定された設定を有効にするには、それを保存してコマンドを実行する必要があります。

 $ alertmanager -config.file alertmanager.conf

複数の構成ファイルを作成し、さまざまな場合にそれらの通知設定を指定できます。

Prometheusは通知をJSON形式で送信します。これらは次のようになります。

 { "version": "1", "status": "firing", "alert": [ { "summary": "summary", "description": "description", "labels": { "alertname": "TestAlert" }, "payload": { "activeSince": "2015-06-01T12:55:47.356+01:00", "alertingRule": "ALERT TestAlert IF absent(metric_name) FOR 0y WITH ", "generatorURL": "http://localhost:9090/graph#%5B%7B%22expr%22%3A%22absent%28metric_name%29%22%2C%22tab%22%3A0%7D%5D", "value": "1" } } ] }

通知は、電子メール、Webフック、およびPagerDuty 、 HipChatなどの専用サービスを使用して送信されます。

Prometheus開発者は、これまでにalertmanagerが「生の」状態にあり、エラーの可能性を警告していることに注意しています。ただし、このコンポーネントの動作に異常はありませんでした。

おわりに

プロメテウスは興味深く、有望なツールであり、注意を払う価値があります。その利点の中で、まず強調する必要があります：

展開の容易さ。
サードパーティのアプリケーションおよびサービスとの広範な統合。
メトリックを操作するための便利なグラフィカルインターフェイス。

Prometheusの使用経験がある場合は、印象を共有してください。有益なコメントや追加に感謝します。

詳細を知りたい人のために、ここにいくつかの便利なリンクがあります：

https://developers.soundcloud.com/blog/prometheus-monitoring-at-soundcloud-SoundCloudブログのPrometheusに関する記事。
http://www.robustperception.io/blog/-プロメテウスブライアンブラジルの開発者の1人のブログ。興味深い実用例があります。
http://agiletesting.blogspot.ru/2015/11/initial-experiences-with-prometheus.html-プロメテウスの実験に関する興味深いレポート。
https://www.digitalocean.com/community/tutorials/how-to-install-prometheus-using-docker-on-centos-7-Dockerに Prometheusをインストールする手順
https://github.com/William-Yeh/ansible-prometheus-PrometheusをインストールするためのAnsibleロール。

何らかの理由でここにコメントを残せない場合は、ブログに招待します。

Prometheusによるサービス監視