ブログ

エクスポーターとターゲットラベル

Google Cloudとコンテナの継続的なセキュリティ

本文の内容は、2020年8月5日にBrian Brazilが投稿したブログ(https://sysdig.com/blog/exporters-and-target-labels/)を元に日本語に翻訳・再構成した内容となっております。

サードパーティのアプリケーションを Prometheusで監視する場合、アプリケーションがまだ適切な形式でメトリクスを公開していない場合は、 エクスポータが必要になります。適切なエクスポータを見つけるにはどうしたらよいでしょうか。また、エクスポータを見つけたら、インフラストラクチャーを反映するためにラベルの分類をどのように整理したらよいでしょうか。

このような場合には、Prometheus形式のメトリクスをネイティブに公開しないサードパーティ製のアプリケーションが多くなります。例えば、Linux は Prometheus 形式のメトリクスを公開していません。しかし、ノードエクスポーターをダウンロードして実行することで、何百ものマシンレベルのメトリクスを公開することができます。

20200807-00.png

ノードエクスポータをマシン上でローカルに実行しておけば、Prometheusを実行して簡単にスクレイプすることができます。

global:
  scrape_interval: 5s   # Reduced for demo sake
scrape_configs:
  - job_name: node
    static_configs: 
      - targets: ['localhost:9100']

Prometheus を実行したら、PromQL クエリを使用して、CPU 使用率を観察するrate(node_cpu_seconds_total[1m]) のように、メトリクスが時間の経過とともにどのように変化しているかを確認することができます。

20200807-01.png

ノードエクスポータは、Unix システム上でマシンレベルのメトリクスを生成するのには優れていますが、他のすべてのサードパーティ製アプリケーションのメトリクスを公開するのには役立ちません。そのためには、それらのアプリケーションごとにエクスポータを取得する必要があります。

文字通り、あらゆる種類のアプリケーションのための何百ものエクスポータが存在します。中には、さまざまな人が開発した多くのエクスポータが存在するアプリケーションもあります。では、どのようにして特定のアプリケーションのためのエクスポーターを見つけ、どのように評価するのでしょうか?

まず最初に、Prometheus のメインウェブサイトのExporters and Integrationsのページにアクセスしてください。あなたのアプリケーションや、それがメトリクスを提供するプロトコルがリストされている場合、そのエクスポーターが良い選択である可能性があります。また、Sysdigが管理しているpromcat.ioのようなサードパーティのエクスポーターリストもあります。さらに、Default port allocationsのページで見ることもできますが、これは意図せずに、かなり包括的なエクスポーターのリストになってしまっています。最後に、お気に入りの検索エンジンを使って、"myapplication Prometheus exporter "というクエリを使うとうまくいく傾向があります。エクスポーターが存在しない場合もあるかもしれませんが、最近では非常に稀です。

しかし、複数のエクスポーターを見つけた場合、どのエクスポーターを使うかという問題が発生します。メトリクスとエクスポーターのベストプラクティスの多くの側面は、一見して明らかではないので、既存のキュレーションされたリストに頼ることは、将来的にうまく機能しそうなものを見つけるのに役立ちます。また、各候補のエクスポーターがあなたが興味を持っているメトリクスをどの程度提供しているか、また、そのエクスポーターがソフトウェアプロジェクトとしてどの程度健全であるかを見ることもできます。例えば、一人の人間によって何年も前に開発され、最近のアップデートがなく、PR/issues/Githubスターの数が少ないエクスポーターは、未使用でメンテナンスされていない可能性が高いです。一方で、活発なコミュニティは良い兆候である傾向があります。エクスポーターに最近のコード変更がないからといって、それを避けるべきという意味ではないことを心に留めておいてください。多くのアプリケーションでは、エクスポーターの機能が完全であり、継続的なメンテナンスをほとんど必要としないところまで到達させることは難しくありません。

例えば、HAProxyを実行していて、HAProxyを使用しているマシンにhaproxy_exporterをデプロイし、さらにすべてのマシンにノードエクスポーターをデプロイしたとしましょう。Prometheus の設定は以下のようになるでしょう。

global:
  scrape_interval: 5s   # Reduced for demo sake
scrape_configs:
  - job_name: node
    static_configs: 
      - targets:
        - '192.168.1.1:9100'
        - '192.168.1.2:9100'
        - '192.168.1.3:9100'
        - '192.168.1.4:9100'
  - job_name: haproxy
    static_configs: 
      - targets:
        - '192.168.1.1:9101'
        - '192.168.1.2:9101'
        - '192.168.1.3:9101'
        - '192.168.1.4:9101'

avg ignoring (instance)(up{job="haproxy", env="prod"}) のようなクエリーを使用して、HAProxy エクスポータが正常にスクレイプされたプロダクションの割合を見ることができます。これはデモのための小さな例ですが、実際には Consul のようなサービスディスカバリメカニズムからのターゲットがもっとたくさんあるでしょうし、ラベルは relabel_configsを使用して適用されます。

ターゲットにラベルを適用することで、デプロイ戦略に合った方法でターゲットを整理することができます。例えば、バックエンドとアナリティクスの両方のチームがそれぞれの MySQLds を所有しているとします。

また、external_labelsを使用して Prometheusサーバー全体にラベルを適用することもできます。例えば、Prometheusがどの地域やデータセンターにあるかは、ほとんどの場合、外部ラベルになります。セットアップが大きくなってくると、Prometheusサーバをdev用とprod用に分けて運用することになるので、個々のターゲットにラベルを適用するのではなく、external_labelsを使ってenvラベルを適用するのが理にかなっています。

インスツルメンテーションラベルがアプリケーション内部で何が起こっているかを分析するのに便利なように、ターゲットラベルはデプロイメント全体のメトリクスを集約するのに便利です。ターゲットラベルを適切に使用することで、全開発アプリケーションが現在世界でどれくらいのCPUを使用しているか、ヨーロッパのフロントエンドチームが所有する全アプリケーションの総RAM使用量はどれくらいかなどの質問に答えることができます。

SysdigはPrometheusと完全に互換性があり、Prometheusのモニタリングを数百万のメトリクスにスケールアップし、長期的に保持することができます今すぐお試しください。

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top