プロメテウス

すべてに良い。 私たちはここでコースの準備の一環としてつまずいた非常に興味深い記事を共有しています。 翻訳はそのままです（いくつかのコメントを除く）。



背景



一言で言えば-信念の監視と魅力についての紹介。 多くの人が知っているように、分散システムを監視するためのイベントフロー処理ツールであるリーマンに同行します。 監視に関する私の本では 、リーマンを新しい監視手法とパターンを調査するための主要なツールとして使用し、プッシュモデルを使用したホワイトボックス監視（選択的ブラックボックス監視）のアーキテクチャについて説明しました。



私が話していることを理解するために、いくつかの概念を説明します。 ブラックボックスモニタリングは、サービスまたはアプリケーションの外部特性をチェックする役割を果たします。サービスの開いているポートに接続すること、正しいデータまたは応答コードが返されることは可能ですか。 ブラックボックス監視の例は、ICMP要求と応答の確認です。



ホワイトボックスモニタリングは、サービスまたはアプリケーション内で発生していることに焦点を当てます。 適切なツールを備えたアプリケーションは、それ自体または内部コンポーネントの状態、トランザクションまたはイベントの結果を返します。 このデータは、「アプリケーションの動作」という質問ではなく、「アプリケーションの動作」という質問に回答します。 ホワイトボックス監視は、イベント、ログ、またはメトリックを特別な監視ツールに転送するか、監視ツールによるその後の収集のために情報を外部に提供します。



最新の監視に携わるほとんどの人は、ホワイトボックス監視に大規模な投資が必要であることを理解しています。 アプリケーション内から取得された情報は、表面上で取得された情報よりも、ビジネスおよび運用にとって非常に価値があります。 これは、ブラックボックスの監視がリソースの浪費であることを意味するものではありません。 サービスとアプリケーションの外部監視は、特に制御できないサービスや、外部から見た場合、たとえばルーティングやDNSの問題など、内部からアクセスできないコンテキストを提供する場合に役立ちます。



この本では、プルではなくプッシュモデルでの作業に焦点を当てています。 また、この本では、プルモデルよりプッシュモデルベースの監視の利点に多くの注意が払われています。 多くの（ほとんどではないにしても）監視システムは、プル/ポーリングモデルに基づいて特別に構築されています。 このモデルでは、システムは監視するサービスまたはアプリケーションをポーリングします。 次に、プッシュモデルでは、アプリケーションとサービス自体がデータを監視システムに送信します。



多くの理由（その一部は一見して明らかではありません）のため、私はプッシュモデルを好みます。 しかし、両方のアプローチの機能は、多くの理由で（たとえば、規模の理由で）実装に干渉しません。 そして、成功の可能性は、実装またはツールに関する紛争に依存しません。 まず第一に、ツールはあなたに適しているべきであり、トレンドや独断主義を軽率に追うことは意味がありません。



プルモデルに基づいた主要な監視ツールの1つであるプロメテウスの入門チュートリアルを書くようになったきっかけは、カテゴリに属さないという欲求と、コミュニティによる違いの理解の欠如でした。 特にコンテナとKubernetesの世界では非常に人気があります。



プロメテウスの紹介



Prometheusは、以前Googleで働いていたSoundcloudエンジニアによって開発されました。 Goで書かれており、オープンソースであり、 Cloud Native Computing Foundationのサポートで開発されています。 このプロジェクトのインスピレーションは、GoogleのBorgmonでした。



プロメテウスはホワイトボックス監視に焦点を当てています。 アプリケーションおよびサービスから取得した時系列データを収集します。 アプリケーションは、このデータを単独で、またはエクスポーターと呼ばれるプラグインを介して提供します。



Prometheusプラットフォームは、時系列データを収集および保存するサーバーに基づいています。 メタデータのラベルと呼ばれるメトリック名とキー/値のペアを組み合わせた多次元時系列モデルがあります。 時系列データはサーバーに保存され、個々のサーバーは自律的であり、分散ストレージから独立しています。



プラットフォームには、クライアントライブラリと、特定の機能とコンポーネントの多数のエクスポーターも含まれています。 たとえば、StatsDエクスポーターは、時系列のStatsDデータをPrometheus形式に変換します。 さらに、少量の着信データを受信するためのプッシュゲートウェイと、トリガーによって作成された通知を処理できるアラートマネージャー、またはPrometheusによって収集されたデータのしきい値を超えた場合にアラートマネージャーがあります。



より詳細なアーキテクチャについては、Prometheusのドキュメントをご覧ください。



設置



プロメテウスサーバー-同じ名前のプロメテウスのバイナリファイル。 最新バージョンを取得して解凍します。

$ wget https://github.com/prometheus/prometheus/releases/download/v1.8.0/prometheus-1.8.0.darwin-amd64.tar.gz $ tar -xzf prometheus-*.tar.gz $ cd prometheus-1.8.0.darwin-amd64/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

公式Webサイトは、さまざまな追加コンポーネントもホストしています。通知を送信するためのアラートマネージャーと、さまざまなサービスのエクスポーターです。



カスタマイズ



解凍したばかりのプロメテウスバイナリファイルは、YAMLファイルを介して設定されます。 それが何であるか見てみましょう：

 global: scrape_interval: 15s evaluation_interval: 15s external_labels: monitor: 'codelab-monitor' rule_files: # - "first.rules" # - "second.rules" scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['localhost:9090']
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この構成ファイルでは、3つのYAMLブロックが定義されています。



グローバル

最初のグローバルブロックには、サーバーの動作を制御するためのグローバル設定が含まれています。



scrape_intervalは、アプリケーションまたはサービスのポーリング間隔を設定します。この例では15秒です。 これは、データスケールの解像度、つまり各データポイントがカバーする期間です。



evaluation_intervalは、ルールに従ってデータを処理する頻度をPrometheusに伝えます。 ルールには、記録ルールとアラートルールの2つの主なタイプがあります。 記録ルールを使用すると、頻繁に使用されるリソース集約型の式を事前計算し、結果を新しい時系列データとして保存できます。 アラートルールを使用すると、アラートの条件を決定できます。 プロメテウスは15秒ごとにこれらの状態を（再）チェックします。



External_labelsには、たとえばアラートが生成されたときにサーバー上に存在するメトリックに追加されるラベルのキー/値のペアのリストが含まれます。



ルールファイル

2番目のブロック-rule_filesには、記録または警告のルールを含むファイルのリストが含まれています。



調査構成

最後のscrape_configsブロックには、Prometheusがポーリングするすべての目標が表示されます。 プロメテウスは目標インスタンスを呼び出し、インスタンスグループはジョブを呼び出します。 デフォルトでは、プロメテウスという1つのタスクのみがあります。 その中に、インスタンスのリストを持つstatic_configがあります（デフォルトでは、Prometheusサーバーは1つだけです）。 localhostポート9090をポーリングして、サーバー自体の状態メトリックを取得します。 メトリックは/メトリックであると想定されるため、ローカルホストアドレスはローカルにポーリングされます：9090 /メトリック。 パスは、metric_pathオプションを使用して変更できます。



孤独なタスクは退屈なので、もう1つ追加してローカルDockerデーモンをポーリングします。 Docker ドキュメントの手順を使用して、localhost：9323 / metricsからメトリックを返すようにデーモンを構成します。 その後、dockerという別のタスクを追加します。

 - job_name: 'docker' static_configs: - targets: ['localhost:9323']
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ジョブには、名前と、Dockerデーモンメトリックスを受信するためのアドレスを参照するインスタンスがあります。 デフォルトのパスは再び/メトリックです。



完全な設定ファイルはこちらにあります 。



サーバー起動



サーバーを起動して、何が起こるか見てみましょう。

 $ ./prometheus -config.file "prometheus.yml"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バイナリファイルを実行し、コマンドラインフラグ-config.fileで構成ファイルを指定します。 これで、Prometheusサーバーが実行され、prometheusおよびdockerジョブのインスタンスをポーリングし、結果を返します。



ダッシュボード



Prometheusには、結果を確認できる組み込みのインターフェイスがあります。 これを行うには、 http：// localhost：9090 / graphをブラウザーで開きます 。







[カーソルにメトリックを挿入]をクリックすると、収集されたメトリックの1つを選択できます。 HTTPリクエストを見てみましょう。 これを行うには、メトリックhttp_requests_totalを選択して、「実行」をクリックします。







要素と値のリストが表示されます。次に例を示します。

 http_requests_total{code="200",handler="prometheus",instance="localhost:9090",job="prometheus",method="get"}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの要素は、追加のディメンションで区切られたメトリックです（メトリックラベルで提供されます）。 たとえば、http_requests_totalメトリックには、リクエストを生成するプロセスに関する情報を含むハンドララベルがあります。 これらのラベルのいずれかを含む特定のメトリックを選択すると、メトリックのリストを減らすことができます。

Prometheusサーバーに組み込まれている式言語の柔軟性により、メトリックの検索と集計が簡単になります。







ハンドラーラベルを使用して、プロメテウスハンドラーのみのメトリックを選択しました。

さらに、HTTP要求のメトリックを集約します。 5分以内にHTTPリクエストの数をタスク別に分類する必要があるとしましょう。 これを行うには、リクエストを明確にします。

 sum(rate(http_requests_total[5m])) by (job)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

[実行]をクリックして、クエリを実行します。







さらに、[グラフ]タブを選択すると、結果グラフを表示できます。







その上に、過去5分間のHTTPリクエストの総数がタスクごとにグループ化されて表示されます。



これらのクエリを記録ルールとして保存し、このルールから新しいメトリックを自動的に実行および作成できるようにします。



これを行うには、ファイルをrule_filesブロックに追加します。

 rule_files: - "first.rules" # - "second.rules"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、first.rulesファイルに次のルールを記述します。

 job:http_requests_total:sum = sum(rate(http_requests_total[5m])) by (job)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、新しいジョブが作成されます：http_requests_total：各ジョブの合計メトリック。







これで、メトリックからグラフを作成し、ダッシュボードに追加できます。



アラート



集約のような警告はルールベースです。 警告ルールを追加するには、別のファイルをrule_filesブロックに登録する必要があります。

 rule_files: - "first.rules" - "second.rules"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

second.ruleファイルで、インスタンスが落ちたときに通知する新しいルールを作成します。 これを行うために、収集に標準メトリックの1つを使用します。upは状態メトリックであり、その値は、ポーリングが成功した場合は1、ポーリングが失敗した場合は0です。



ルールファイルにアラートルールを追加します。 次のようになります。

 ALERT InstanceDown IF up == 0 FOR 5m LABELS { severity = "moderate" } ANNOTATIONS { summary = "Instance {{ $labels.instance }} down", description = "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.", }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アラートルールは条件付きリクエストに少し似ています。 InstanceDownという名前と一連のルールを指定します。 InstanceDownアラートは、アップメトリックが0の場合（つまり、メトリックの収集が失敗した場合）、5分間トリガーされます。 アラートにラベルを追加しました：重大度=中（つまり、重大度=中）および注釈。 注釈を使用すると、イベントの説明など、より多くの情報をアラートに追加できます。 アノテーションには{{}}が含まれています-Goでの標準化のための括弧で、変数が登録されています。 そのため、 テンプレートを使用してアラートをカスタマイズできます。 この場合、$ labels変数にはメトリックラベルが含まれます。たとえば、$ labels.instanceはインスタンス名を返し、$ labels.jobはジョブの名前などを返します。



Dockerデーモンを停止してから5分後、Prometheusはアラートを起動し、 Alertmanagerマネージャーにメッセージを送信します（ Alertmanagerマネージャーは、最初に個別にインストールして実行するか、 Alerta toolなどの他のツールを使用する必要があります ）。 現在の通知は、[アラート]タブのダッシュボードで確認できます。



おわりに



Prometheusは、インストールと設定が簡単な優れたプラットフォームです。 設定はYAMLで説明されており、コードとしてのインフラストラクチャ（IaC）アプローチの使用を簡素化します。 スタンドアロンサーバーのおかげで、単純な環境を簡単に監視できます。 残念ながら、より複雑な環境の多くの例を見つけることができなかったため、最適な方法を見つけるために実験とさまざまなアプローチに時間を費やす価値があります。



データモデルは非常に柔軟性があり、特に印象的なのは、メトリックのラベル付けと検索が容易であることです。 私はほとんどのクライアントライブラリといくつかのエクスポーターに会いました。 ツールを作成し、メトリックを生成することはそれほど困難ではありません。



組み込みのインターフェイスはクリーンでエレガントであり、クエリ言語と一緒に、リソースのデバッグまたはスケジューリングに適したツールのように見えます。 記録ルールは、メトリックの集計に適しています。



ストレージ、セキュリティ、サーバー検出、その他の利用可能な統合を少し研究しました。可能性は包括的に見えます。 GitHubをすばやく検索すると、ツール、統合、およびサンプルの印象的なセットが示されており、これは間違いなく開始に十分なはずです。



メインプラットフォームには十分なドキュメントがありますが、一部の関連プロジェクトではかなり混chaとして不完全です。 Prometheusの知識が限られていても、わずか1時間で動作する構成を作成できました。



初期化スクリプトやパッケージ化スクリプトなしで単一のバイナリファイルを配布することは、すぐに使用できるソリューションとは言えませんが、それでも多くのプロジェクトで有効なソリューションです。 また、使用できる構成管理システムにはさまざまな準備スクリプトがあります。 ただし、Prometheusのようなほとんどの研究ツールは、インストールを単独で処理する可能性が高くなります。 コンテナとKubernetesのサポートは、これらのツールを使用している人々にとって魅力的です。 また、（マイクロ）サービスと動的またはクラウドスタックの研究者は、サーバーの自律性と移植性に関心を持つでしょう。



監視を実装する必要があるプロジェクトがある場合は、Prometheusをお勧めします。 アクティビティにDockerやKubernetesなどのコンテナやツールが関係している場合も、時間をかける価値があります。 柔軟性があるため、他の既存のプラットフォームよりもはるかに優れたツールやアーキテクチャに適しています。



PSこの投稿のインスピレーションは、Cindy Sridharanによって書かれたCloud Nativeの時代のMonitoringでした。 シンディありがとう！



終わり



役に立つことを願っています。