ブログ

Prometheusメトリクスの収集

Prometheusメトリクスの収集

本文の内容は、docs.sysdig.com上のCollect Prometheus Metricsを元に日本語に翻訳・再構成した内容となっております。(2021年7月5日現在)

Sysdigは、Prometheusのネイティブメトリクスやラベルの収集、保存、クエリーをサポートします。Sysdigは、Prometheusと同じように、Prometheus Query Language (PromQL)を使ってダッシュボードやアラートを作成することができます。SysdigはPrometheus HTTP APIと互換性があり、PromQLを使ってプログラム的に監視データをクエリーしたり、SysdigをGrafanaのような他のプラットフォームに拡張することもできます。

メトリクス収集の観点からは、軽量のPrometheusサーバーをSysdigエージェントに直接組み込み、メトリクス収集を容易にしています。また、Prometheusの構文を使ったフィルタリングや再ラベル付けで、ターゲット、インスタンス、ジョブをサポートします。エージェントは、自身のホスト上でPrometheusメトリクスエンドポイントを公開しているこれらのプロセスを識別し、Sysdigコレクターに送って保存し、さらに処理するように設定することができます。
prom.png

備考
このドキュメントでは、メトリクスとタイムシリーズを同義で使用しています。設定パラメータの説明では「メトリクス」に言及していますが、PROMETHEUSの厳密な用語では、これらはタイムシリーズを意味します。つまり、100メトリクスという制限を適用することは、タイムシリーズの制限を適用することを意味し、すべてのタイムシリーズデータが同じメトリクス名を持たない可能性があります。

Prometheusのメトリクス収集には、必ずしもPrometheus製品自体がインストールされている必要はありません。

備考
    • SYSDIG AGENT V10.5.0: PROMETHEUSネイティブサービスディスカバリーをサポートするPROMSCRAPE.V2をリリースしました。これをサポートするために、デフォルトのPROMETHEUS.YAMLファイルに、PROMETHEUSのネイティブサービスディスカバリーが有効な場合に使用するKUBERNETESポッドディスカバリールールが追加されました。
    • SYSDIG AGENT V10.0.0以上: PROMETHEUSメトリクスのスクレイピングには、軽量のPROMETHEUSサーバーであるPROMSCRAPEがデフォルトで使用されます。このコンポーネントは、オープンソースのPROMETHEUSをベースにしています。
    • SYSDIG AGENT V9.8.0~V10.0: PROMETHEUSのメトリクスをスクレイピングするために、V9.8.0では軽量のPROMESCRAPEが導入されています。この方法を使用するには、DRAGENT.YAMLファイルでPROMSCRAPEを有効にする必要があります。
    • SYSDIG エージェント V0.70.0 以上: PROMETHEUS エクスポーターからメトリクスを自動的に収集するためのサポートを提供します。

ここでは、サービスディスカバリー、メトリクスの収集、さらに処理を行うためのSysdigエージェントの設定方法について詳しく説明します。

Prometheusメトリクスの使用

Sysdigエージェントは、実行中のすべてのプロセス(ホストとコンテナの両方のレベル)に対する可視性を利用して、Prometheusメトリクスをスクレイピングするための適格なターゲットを見つけます。デフォルトでは、スクレイピングは行われません。この機能が有効になると、エージェントは対象となるターゲットのリストを作成し、フィルタリングルールを適用して、Sysdigコレクターに送信します。

エージェントv10.0.0で導入されたPrometheusの機能

以下の機能を利用するには、Sysdigエージェントv10.0以上が必要です。

  • Prometheusのデータを利用する新しい機能
    • PromQLクエリを使用してデータを可視化する機能。PromQLの使用を参照してください
    • PromQLベースのダッシュボードからアラートを作成する。パネルアラートの作成を参照してください
    • ダッシュボード v2 とアラートの後方互換性
備考
新しいPROMQLデータは、DASHBOARD V2のヒストグラムを使用して視覚化できません。ヒストグラムメトリクスにタイムシリーズベースの視覚化を使用します。
  • エージェントごとに新しいメトリクスの制限を設けました。
    • カスタムメトリクス: 10,000 :これは、ホスト、コンテナ、Kube State Metricsなど、アウトオブボックスで提供するエージェントメトリクスに加えた値です。
    • Prometheusメトリクス: 8000
    • StatsDのメトリクス:1000
    • JMXメトリクス: 500
    • AppChecks:500
  • 10秒単位のデータ粒度
  • 新しいメトリクスストアの保持期間が長くなりました。
  • 新しいメトリクスの命名規則
    • legacy Prometheusメトリクスは、promlegacyという接頭辞を付けて利用できます。命名規則は promlegacy.<metrics> です。例えば、cortex_build_info は promlegacy.cortex_build_info と名前が変わります。
    • prom_legacy_metrics.png

前提条件とガイドライン

  • 最新のPrometheus機能を利用するには、Sysdig agent v 10.0.0以上が必要です。
  • Prometheus機能はdragent.yamlファイルで有効になります。
prometheus:
  enabled: true
詳しくは、「環境の設定」をご覧ください。
  • ターゲットのエンドポイントは、エージェントへのTCP接続が利用可能である必要があります。エージェントは、dragent.yamlのIP:PortまたはURLで指定されたリモートまたはローカルのターゲットをスクレイピングします。

サービスディスカバリー

Prometheusネイティブサービスディスカバリーを使用するには、Prometheusネイティブサービスディスカバリーの有効化で説明したようにpromscrape.v2を有効にします。このセクションでは、Sysdigエージェントでプロセスフィルターを設定するSysdigにおけるサービスディスカバリーの設定方法について説明します。

Sysdigエージェントでのサービスディスカバリーの方法は、Prometheusサーバーでの方法とは異なります。Prometheusサーバーには、いくつかのサービスディスカバリーメカニズムとの統合が組み込まれており、設定を読み取るためのprometheus.ymlファイルがありますが、Sysdigエージェントは、dragent.yamlファイルの仕様にマッチするプロセス(エクスポーターまたはインスツルメンテッド)を自動的に検出し、組み込みの軽量Prometheusサーバーにメトリクスを取得するよう指示します。

エージェント内の軽量Prometheusサーバはpromscrapeという名前で、dragent.yamlファイル内の同名のフラグによって制御されます。詳細は「Sysdigエージェントの設定」を参照してください。

クラスター内のすべてのマシンで実行されているプロセスをスクレイピングできるPrometheusサーバとは異なり、エージェントはインストールされているホストで実行されているプロセスのみをスクレイピングできます。

対象となるプロセス/ポート/エンドポイントのセットの中で、エージェントはPrometheusメトリクスをエクスポートしているポートのみをスクレイピングし、接続してスクレイピングしようとしたときにポートがどのように反応したかに基づいて、スクレイピングの試みを停止したり、ポートの再試行を行ったりします。したがって、スクレイピングを試みるプロセスとポートを、エクスポート先の予想される最小範囲に制限する設定を作成することを強くお勧めします。これにより、接続の失敗が繰り返されることで、エージェントとアプリケーションの両方に意図しない副作用が発生する可能性を最小限に抑えることができます。

エンドツーエンドのメトリクス収集は、以下のようにまとめられます:

  1. プロセスは、一連のプロセスフィルタの包含/除外ルールにポジティブにマッチした場合、スクレイピングの対象となる可能性があると判断されます。詳細については、「プロセスフィルター」を参照してください。
  2. エージェントは、ポートのサブセットや別のエンドポイント名にスクレイピングを制限する追加の設定がない限り、/metricsエンドポイントのすべてのリスニングTCPポートで適格なプロセスをスクレイピングしようとします。
  3. agent v9.8.0では、取り込み時のメトリクスのフィルタリングが有効になっています。有効にすると、メトリクスを受信する際にインジェストでフィルタリングルールが適用されます。詳細は「Prometheusメトリクスのフィルタリング」を参照してください。
  4. メトリクスを受信すると、エージェントは以下のルールを適用してからSysdigコレクターに送信します。
    • 設定されたmax_metricsを適用して、メトリクスの数を制限します。


メトリクスは最終的にSysdig Monitor ExploreインターフェースのPrometheusセクションに表示されます。
373654583.png


環境の設定

クイックスタート Kubernetes環境の場合

すでにKubernetes Service Discoveryを活用しているPrometheusユーザー(特にこのサンプルprometheus-kubernetes.ymlのアプローチ)は、スクレイピングの対象となるPodにアノテーションを付けているかもしれません。そのような環境では、いくつかの簡単なステップで、Sysdig エージェントを使って同じメトリクスのスクレイピングをすぐに始めることができます。

SysdigエージェントでPrometheusメトリクス機能を有効にする。DaemonSetsを使用してデプロイしている場合、DaemonSetのYAMLに以下を含めることで、必要な設定をエージェントのdragent.yamlに追加できます(sysdig-agentコンテナのenvセクションに配置):

- name: ADDITIONAL_CONF
  value: "prometheus:\n  enabled: true"

Prometheus エクスポーターを含む Kubernetes ポッドが、スクレイピングを可能にするために以下の Annotations でデプロイされていることを確認してください(listing exporter-TCP-port を代用しています):

spec:
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "exporter-TCP-port"


上記の構成では、エクスポーターが典型的なエンドポイントである「/metrics」を使用することを想定しています。エクスポーターが別のエンドポイントを使用している場合は、次のようにオプションのアノテーションを追加して、exporter-endpoint-nameの代わりに指定することもできます。

prometheus.io/path: "/exporter-endpoint-name"


シンプルなエクスポーターのKubernetesデプロイメントを試してみると、自動検出されたPrometheusのメトリクスがSysdig Monitorに表示されるのがすぐにわかります。この例を参考にして、自分のエクスポーターにも同様のアノテーションを施すことができます。

アノテーションされたKubernetesポッドにデプロイされていないPrometheusエクスポーターでスクレイピングしたいものがある場合は、以下のセクションでエージェントがメトリクスを検出してスクレイピングするためのオプションを説明していきます。

コンテナ環境のクイックスタート

Dockerベースのコンテナ環境でPrometheusスクレイピングを動作させるには、アプリケーションコンテナに以下のラベルを設定し、<exporter-port>と<exporter-path>を、アプリケーションによってメトリクスがエクスポートされる正しいポートとパスに置き換えてください。

  • io.prometheus.scrape=true

  • io.prometheus.port=<exporter-port>

  • io.prometheus.path=<exporter-path>

たとえば、mysqld-exporterをスクレイピングする場合、以下のようにコンテナを立ち上げます。

docker -d -l io.prometheus.scrape=true -l io.prometheus.port=9104 -l io.prometheus.path=/metrics mysqld-exporter

Sysdigエージェントの設定

エージェントの典型的な例として、機能のデフォルト設定は dragent.default.yaml で指定されており、 dragent.yaml でパラメーターを設定することでデフォルトを上書きすることができます。dragent.yamlで設定しなかった各パラメーターについては、dragent.default.yamlのデフォルトが有効になります。

主な設定パラメーター

パラメーター

デフォルト

説明

prometheus

下記参照 

Prometheusのスクレイピングをオン、オフにします。

process_filter

下記参照   

スクレイピングの対象となるプロセスを指定します。後述の「プロセスフィルター」の項を参照してください。

use_promscrape

下記参照

Prometheus メトリクスのスクレイピングに promscrape を使用するかどうかを決定します。

エージェント v9.8.0 以降では、このパラメータはデフォルトで無効になっています。

エージェント v10.0.0 では、このパラメータはデフォルトで有効になっています。



promscrape

Promscrapeは、Sysdigエージェントに組み込まれた、軽量のPrometheusサーバーです。use_promscrapeパラメータは、Prometheusのエンドポイントをスクレイピングするために使用するかどうかを制御します。

パラメーター

デフォルト

説明

use_promscrape

true   

Iagent v10.0.0では、このフラグはデフォルトで有効になっています。

agent v9.8.0以降では、スクレイピングにpromscrapeを使用するために、このオプションを明示的に有効にします。有効にすると、ユーザーは取り込みの前にソースでPrometheusメトリクスをフィルタリングできます。

詳細については、「Prometheusメトリクスのフィルタリング」を参照してください。

prometheus

prometheusセクションでは、Prometheusメトリクスの収集と分析に関する動作を定義します。このセクションでは、機能をオンにしたり、エージェント側からスクレイピングされるメトリクスの数に制限を設けたり、ヒストグラムメトリクスをレポートするかどうか、スクレイピングの失敗を記録するかどうかなどを決定します。

パラメーター

デフォルト

説明

enabled

false    

Prometheusのスクレイピングをオン、オフにします。

interval

10

エージェントがPrometheusメトリクスのためにポートをスクレイピングする頻度(秒単位)

prom_service_discovery

false

この値がtrueに設定されている場合、ネイティブのPrometheusサービスディスカバリーを有効にします。無効の場合は、promscrapeを使用してターゲットをスクレイピングします。「Prometheus Native Service Discoveryの有効化」を参照してください。

log_errors

true

対象となるターゲットのスクレイピングに失敗した際に、エージェントが詳細を記録するかどうか

max_metrics

1000

すべてのターゲットでスクレイピングされるPrometheusメトリクスの合計数の最大値です。この10,00という値は、エージェントごとの最大値であり、他のカスタムメトリクス(statsdJMX、その他のアプリケーションチェックなど)とは別の制限です。

max_metrics_per_process

1000

エージェントが1つのスクレイプされたターゲットから保存するPrometheusメトリクスの最大数です。

(エージェントバージョン0.90.3でデフォルトが100から1,000に変更されました。)

agent v10.0.0では非推奨です。

max_tags_per_metric

20

エージェントがスクレイプされたターゲットから保存する、Prometheusメトリクスごとのタグの最大数。

agent v10.0.0では非推奨です。

timeout

1

Prometheusのエンドポイントをスクレイピングする際に、エージェントがタイムアウトするまでの待ち時間を設定するために使用します。デフォルト値は1秒です。

agent v10.0では、このパラメータはpromscrapeが無効な場合にのみ使用されます。promscrapeがデフォルトになったため、timeoutは廃止されたと思われるかもしれませんが、promscrapeを明示的に無効にした場合にはまだ使用されます。

histograms

false

エージェントがヒストグラムメトリクスをスクレイピングしてレポートするかどうか。詳細は、「ヒストグラム」を参照してください。


Process Filter

process_filterセクションでは、エージェントが知っているプロセスのうち、スクレイピングの対象となるものを指定します。

dragent.yaml で process_filter を指定すると、dragent.default.yaml で示される Prometheus process_filter セクション全体 (つまり、すべてのルール) が置き換えられることに注意してください。

プロセスフィルターは、エージェントが知っている各プロセスに対して上から下へと評価される一連のinclude規則とexclude規則で指定されます。プロセスがincludeルールにマッチした場合、プロセスの各リッスンTCPポート上の/metricsエンドポイントを介してスクレイピングが試みられます。ただし、プロセスのスクレイピング方法をさらに制限するために、ルール内にconfセクションが表示されている場合はこの限りではありません(以下のconfを参照)。

1つのルールで複数のパターンを指定することができますが、その場合はすべてのパターンが一致しないとルールが成立しません(AND論理)。

パターン値の中では、単純な「glob」ワイルドカードを使用することができ、「*」は任意の数の文字にマッチし(何もない場合も含む)、「?」は任意の1文字にマッチします。なお、YAMLの構文上、ワイルドカードを使用する場合は、必ず値を引用符("*")で囲んでください。

以下の表は、プロセスフィルタのルールでサポートされているパターンを示しています。現実的な例を示すために、シンプルなPrometheus exporterのサンプル(ソースコードはこちら)を使用します。このサンプルは、以下のDockerコマンドラインを使用してコンテナとしてデプロイできます。設定オプションの一部を説明するために、このサンプルエクスポーターは、より一般的な /metrics エンドポイントの代わりに、/prometheus に Prometheus のメトリクスを表示しますが、これは後述の設定例で示します。

# docker run -d -p 8080:8080 \
    --label class="exporter" \
    --name my-java-app \
    luca3m/prometheus-java-app
 
# ps auxww | grep app.jar
root     11502 95.9  9.2 3745724 753632 ?      Ssl  15:52   1:42 java -jar /app.jar --management.security.enabled=false
 
# curl http://localhost:8080/prometheus
...
random_bucket{le="0.005",} 6.0
random_bucket{le="0.01",} 17.0
random_bucket{le="0.025",} 51.0
...

パターン名

説明

container.image

指定されたイメージを実行しているコンテナ内でプロセスが実行されているかどうかにマッチします

- include:

container.image: luca3m/prometheus-java-app

container.name

指定された名前のコンテナ内でプロセスが実行されているかどうかにマッチする

- include:

container.name: my-java-app

container.label.*

与えられた値と一致するLabelを持つコンテナでプロセスが実行されている場合にマッチする

- include:

container.label.class: exporter

kubernetes.<object>.annotation.* kubernetes.<object>.label.*

与えられた値にマッチするAnnotation/LabelでマークされたKubernetesオブジェクト(Pod、Namespaceなど)にプロセスがアタッチされているかどうかにマッチします。

注:このパターンは、上で示したDockerのみのコマンドラインには適用されず、代わりに、この例のYAMLを使用してKubernetes Deploymentとしてエクスポーターをインストールした場合に適用されます。

注:サポートされているアノテーションとラベルの全セットに関する情報は、以下のKubernetes Objectsを参照してください。

- include:

kubernetes.pod.annotation.prometheus.io/scrape: true

process.name

実行中のプロセスの名前に一致する

- include:

process.name: java

process.cmdline

コマンドラインの引数にマッチする

- include:

process.cmdline: "*app.jar*"

port

プロセスが1つまたは複数のTCPポートをリッスンしている場合にマッチします。

1つのルールのパターンには、この例のように1つのポート、または1つの範囲(例:8079-8081)を指定できますが、ポート/範囲のカンマ区切りリストには対応していません。

注:このパラメータは、プロセスがリッスンしているポートに基づいて、スクレイピングの対象となるかどうかを確認するためにのみ使用されます。例えば、あるプロセスがアプリケーショントラフィックのために1つのポートをリッスンしていて、Prometheusメトリクスをエクスポートするために2つ目のポートを開いている場合、ここでアプリケーションポートを指定し(エクスポートポートは指定しない)、confセクションでエクスポートポートを指定する(アプリケーションポートは指定しない)ことで、プロセスは適格であると照合され、エクスポートポートがスクレイピングされることになります。

- include:

port: 8080

appcheck.match

特定の名前またはパターンのアプリケーションチェックがプロセスに対して実行されるようにスケジュールされているかどうかにマッチします。

- exclude:

appcheck.match: "*"


前述のように複数のパターンを1つのルールにまとめることができるため、上記のようなincludeの例ではなく、次のような非常に厳しい設定でもマッチします。

- include:
    container.image: luca3m/prometheus-java-app
    container.name: my-java-app
    container.label.class: exporter
    process.name: java
    process.cmdline: "*app.jar*"
    port: 8080


conf

port_filterの各includeルールには、対象となるプロセスでどのようにスクレイピングが試みられるかをさらに記述したconf部分を含めることができます。conf部分が含まれていない場合は、一致するプロセスのすべてのリスニングポート上の/metricsエンドポイントでスクレイピングが試みられます。可能な設定は:

パラメーター名

説明

port

スクレイピングされる1つのTCPポートの固定番号、または中括弧で指定されたコンテナ/Kubernetesのラベル名またはKubernetesのアノテーションのいずれか。プロセスがこのLabelでマークされたコンテナ内で実行されている場合、またはこのAnnotation/LabelでマークされたKubernetesオブジェクト(Pod、Namespaceなど)に接続されている場合、Label/Annotationの値として指定されたポートでのみスクレイピングが試みられます。

注:照合するLabel/Annotationには、赤で示されたテキストは含まれません。

注:サポートされているアノテーションとラベルの全セットに関する情報は、Kubernetes Objectsfを参照してください。

注: エクスポーターをコンテナ内で実行する場合、コンテナがホストに公開しているポートではなく、コンテナ内のエクスポータープロセスがリッスンしているポート番号を指定する必要があります。

port: 8080

- or -

port: "{container.label.io.prometheus.port}"

- or -

port: "{kubernetes.pod.annotation.prometheus.io/port}"

port_filter

includeルールとexcludeルールのセットで、スクレイピングを試みることができる適格なプロセスのリスニングTCPポートの究極のセットを定義します。この構文は、process_filterの上位のincludeルールの中にあるport patternオプションとは異なることに注意してください。このルールでは、単一のポート、カンマで区切られたポートのリスト(角括弧で囲まれたもの)、または連続したポートの範囲(角括弧なし)を含めることができます。

port_filter:

- include: 8080 - exclude: [9092,9200,9300] - include: 9090-9100

path

スクレイピングされるエンドポイントの静的な指定、または中括弧で指定されたコンテナ/KubernetesのLabel名またはKubernetesのAnnotationのいずれかです。プロセスがこのLabelでマークされたコンテナ内で実行されている場合、またはこのAnnotation/LabelでマークされたKubernetesオブジェクト(Pod、Namespaceなど)にアタッチされている場合、Label/Annotationの値として指定されたエンドポイント経由でスクレイピングが試みられます。

pathが指定されていない場合、またはパスが指定されていてもエージェントがプロセスに添付されたラベル/アノテーションを見つけられない場合は、一般的なPrometheusエクスポーターのデフォルトである/metricsが使用されます。

注:照合するLabel/Annotationには、赤で示されたテキストは含まれません。

注:サポートされているアノテーションとラベルの全セットに関する情報は、Kubernetes Objectsを参照してください。

path: "/prometheus"

- or -

path: "{container.label.io.prometheus.path}"

- or -

path: "{kubernetes.pod.annotation.prometheus.io/path}"

host

ホスト名またはIPアドレス。デフォルトはlocalhostです

host: 192.168.1.101
- or -
host: subdomain.example.com
- or -
host: localhost

use_https

trueに設定すると、エクスポーターへの接続は、HTTPではなくHTTPSでのみ試みられます。デフォルトではfalseに設定されています。

エージェントのバージョン0.79.0以降で使用できます。

use_https: true

ssl_verify

trueに設定すると、HTTPS接続時にサーバー証明書の検証が行われます。デフォルトではfalseです。0.79.0より前のバージョンでは、検証はデフォルトで有効でした。

エージェントのバージョン0.79.0以降で使用できます。

ssl_verify: true

認証の統合

エージェントバージョン0.89から、Sysdigは認証を必要とするエンドポイントからPrometheusメトリクスを収集できるようになりました。この機能を有効にするには、以下のパラメータを使用します。

  • ユーザ名/パスワード認証の場合
    • username

    • password

  • トークンを使った認証の場合
    • auth_token_path

  • 証明書キーを用いた証明書認証の場合
    • auth_cert_path

    • auth_key_path

備考
トークンの置き換えは、すべての認証パラメータでサポートされています。例えば、KUBERNETESのアノテーションからユーザー名を取得するには、次のように指定します。
username: "{kubernetes.service.annotation.prometheus.openshift.io/username}"

conf 認証例

以下は、Prometheus認証のすべての設定オプションを示すdragent.yamlセクションの例で、OpenShift、Kubernetes、およびetcd上のものです。

この例では:

  • username/passwordは、OpenShiftで使用されているデフォルトのアノテーションから取得しています。
  • auth tokenパスは、Kubernetesのデプロイメントで一般的に使用されます。
  • ここでetcdに使用されているcertificatekeyは、通常、エージェントからは簡単にアクセスできない場合があります。このケースでは、ホストのネームスペースから抽出し、Kubernetesのシークレットに構築して、エージェントコンテナにマウントしています。
prometheus: 
  enabled: true
  process_filter: 
    - include: 
        port: 1936
        conf: 
            username: "{kubernetes.service.annotation.prometheus.openshift.io/username}"
            password: "{kubernetes.service.annotation.prometheus.openshift.io/password}"
    - include: 
        process.name: kubelet
        conf: 
            port: 10250
            use_https: true
            auth_token_path: "/run/secrets/kubernetes.io/serviceaccount/token"
    - include: 
        process.name: etcd
        conf: 
            port: 2379
            use_https: true
            auth_cert_path: "/run/secrets/etcd/client-cert"
            auth_key_path: "/run/secrets/etcd/client-key"


Kubernetes Objects

上記のように、Kubernetesのラベルおよび/またはアノテーションの自動発見された値に基づいて設定できる複数の構成オプションがあります。それぞれのケースでのフォーマットは、"kubernetes.OBJECT.annotation."または "kubernetes.OBJECT.label."で始まり、OBJECTは以下のサポートされたKubernetesオブジェクトタイプのいずれかになります。

  • daemonSet

  • deployment

  • namespace

  • node

  • pod

  • replicaSet

  • replicationController

  • service

  • statefulset


最後のドットの後に追加する設定テキストは、エージェントが検索するKubernetes Label/Annotationの名前になります。ラベル/アノテーションがプロセスに添付されていることが発見された場合は、そのラベル/アノテーションの値が設定オプションに使用されます。

なお、KubernetesのLabel/Annotationが特定のプロセスに添付される方法は複数あります。最もシンプルな例としては、「Quick Start For Kubernetes Environments」で紹介されているPodベースのアプローチがあります。しかし、Podレベルでのマーキングに代わる例として、Namespaceレベルでラベル/アノテーションを添付することができます。この場合、自動検出された設定オプションは、Deployment、DaemonSet、ReplicaSetなどの中にあるかどうかにかかわらず、そのNamespaceで実行されているすべてのプロセスに適用されます。


Prometheus ネイティブサービスディスカバリーの有効化

Prometheusのサービスディスカバリーは、メトリクスのためにスクレイピングするエンドポイントを見つけるための標準的な方法です。prometheus.yamlを設定して、スクレイピングメカニズムをセットアップします。agent v10.5.0以降、SysdigはネイティブのPrometheusサービスディスカバリーをサポートしており、ネイティブのPrometheusと同じ方法でprometheus.yamlを設定することができます。

dragent.yamlで有効にすると、新バージョンのpromscrapeは、エージェントがprocess_filterルールを使って見つけたエンドポイントではなく、設定されたprometheus.yamlを使ってエンドポイントを見つけます。新バージョンのpromscrapeはpromscrape.v2と名付けられました。

Promscrape V2

  • promscrape.v2は、metric_relabel_configsに加えて、Prometheusネイティブのrelabel_configをサポートします。Relabel configurationでは以下のことが可能です。
    • ラベルをスクレイピングする前に、ターゲットのラベルフォーマットを編集する
    • メトリクスから不要なメトリクスや不要なラベルを削除する
  • promscrape.v2では、通常のサンプルフォーマット(メトリクス名、ラベル、メトリクスの読み方)に加えて、エージェントに送られるすべてのサンプルにメトリクスタイプ(カウンター、ゲージ、ヒストグラム、サマリー)が含まれます。
  • promscrape.v2は、フェデレーション、ブラックボックスエクスポーターなど、あらゆるタイプのスクレイピング設定をサポートします。
  • メトリクスは、Prometheusのラベル名を既知のエージェントタグにマッピングするソースラベルを使用することで、そのソース(ポッド、プロセス)にマッピングすることができます。

Promscrape V2の制限事項

  • promscrape.v2は計算済みメトリクスをサポートしていません。
  • promscrape.v2は、レコーディングルールやアラート管理などのクラスターワイドな機能をサポートしていません。
  • promscrapepromscrape.v2のサービスディスカバリー設定には互換性がなく、翻訳できません。
  • promscrape.v2を有効にすると、エージェントを実行しているすべてのノードで実行され、prometheus.yamlファイルで指定されたローカルまたはリモートのターゲットからメトリクスを収集することを目的としています。
prometheus.yamlはすべてのpromscrapeインスタンスで共有されます。リモートターゲットをスクレイピングするようにpromscrapeを設定することは、この場合、メトリクスの重複が発生するため意味がありません。
  • promscrape.v2はクラスタビューを持たないため、クラスタ全体のメトリクス収集で使用されるレコーディングルールやアラートの設定を無視しています。

そのため、以下のPrometheus Configurationsには対応していません。

Promscrape V2の有効化

Prometheusのネイティブサービスディスカバリーを有効にするには:

dragent.yamlファイルを開きます。
以下のPrometheus Service Discoveryパラメータをtrueに設定します。

prometheus:
  prom_service_discovery: true
trueの場合、promscrape.v2が使用されます。それ以外の場合は、promscrapeがターゲットのスクレイピングに使用されます。


エージェントを再起動します。

Prometheusのデフォルト設定ファイル

ここでは、デフォルトのprometheus.yamlファイルを紹介します。

global:
  scrape_interval: 10s
scrape_configs:
- job_name: 'k8s-pods'
  tls_config:
    insecure_skip_verify: true
  kubernetes_sd_configs:
  - role: pod
  relabel_configs:
    # Trying to ensure we only scrape local targets
    # __HOSTIPS__ is replaced by promscrape with a regex list of the IP addresses
    # of all the active network interfaces on the host
  - action: keep
    source_labels: [__meta_kubernetes_pod_host_ip]
    regex: __HOSTIPS__
  - action: keep
    source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
    regex: true
  - action: replace
    source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme]
    target_label: __scheme__
    regex: (https?)
  - action: replace
    source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
    target_label: __metrics_path__
    regex: (.+)
  - action: replace
    source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
    regex: ([^:]+)(?::\d+)?;(\d+)
    replacement: $1:$2
    target_label: __address__
    # Holding on to pod-id and container name so we can associate the metrics
    # with the container (and cluster hierarchy)
  - action: replace
    source_labels: [__meta_kubernetes_pod_uid]
    target_label: sysdig_k8s_pod_uid
  - action: replace
    source_labels: [__meta_kubernetes_pod_container_name]
    target_label: sysdig_k8s_pod_container_name


Prometheusの設定ファイルには、ローカルノードで稼働しているポッドをスクレイピングするためのデフォルトの設定が用意されています。この設定には、Kubernetes State MetricsやSysdigのネイティブメトリクスとの相関性を高めるために、ポッドUIDやコンテナ名のラベルを保存するルールも含まれています。

スクレイプの間隔

デフォルトのスクレイプ間隔は10秒です。ただし、この値はスクレイピングジョブごとにオーバーライドできます。prometheus.yamlで設定したスクレイプ間隔は、エージェントの設定とは関係ありません。

promscrape.v2は、prometheus.yamlを読み込み、スクレイピングジョブを開始します。

ターゲットからのメトリクスは、各ターゲットのスクレイピングインターバルごとに収集され、直ちにエージェントに転送されます。エージェントは10秒ごとにメトリクスをSysdigコレクターに送信します。前回の送信以降に受信されたメトリクスのみがコレクターに送信されます。あるジョブのスクレイピングインターバルが10秒よりも長い場合、エージェントの送信にはそのジョブのすべてのメトリクスが含まれないことがあります。

ホスト名の選択

__HOSTIPS__ は、ホストIPアドレスに置き換えられます。ホストIPアドレスによる選択は、信頼性が高いため好ましいとされています。

__HOSTNAME__は、promscrapeがターゲットのスクレイピングを開始する前に、実際のホスト名に置き換えられます。これにより、promscrapeは他のホスト上で実行されているターゲットを無視することができます。

リラベリング設定

デフォルトのPrometheus設定ファイルには、以下の2つのリラベル設定が含まれています。

- action: replace
  source_labels: [__meta_kubernetes_pod_uid]
  target_label: sysdig_k8s_pod_uid
- action: replace
  source_labels: [__meta_kubernetes_pod_container_name]
  target_label: sysdig_k8s_pod_container_name

これらのルールは、ローカルターゲットから収集したすべてのメトリクスに、sysdig_k8s_pod_uidsysdig_k8s_pod_container_nameという2つのラベルを追加し、それぞれポッドIDとコンテナ名を含みます。これらのラベルは、メトリクスをSysdigコレクターに送信して処理する前に、メトリクスから削除されます。

Prometheusのメトリクス収集に制限をかける

Sysdigでは、処理・保存されるPrometheusメトリクスの数に制限を設けています。そのため、すべてのタイムシリーズデータがSysdig Monitor UIに表示されるわけではありません。指定された制限を超えたデータは、エージェントによって廃棄されます。

データ収集に制限を設けることで、メトリクスの集計に必要なディスクスペースや時間などのリソース使用量を削減することができます。この制限の実施は、2つの異なるフェーズで行われます。

Prometheusメトリクスのフィルタリング

Sysdig agent 9.8.0では、軽量のPrometheusサーバがpromscrapeという名前でエージェントに組み込まれており、prometheus.yamlファイルが設定ファイルの一部として含まれています。オープンソースのPrometheusの機能を利用して、Sysdigは取り込み前にPrometheusのメトリクスをソースでフィルタリングできるようにしました。そのためには、以下のことを行います。

  • dragent.yamlファイルでPrometheusのスクレイピングが有効になっていることを確認します。
prometheus:
  enabled: true
  • エージェント v9.8.0 以降では、dragent.yaml の use_promscrape パラメーターを true に設定して、この機能を有効にします。詳細は、「取り込み時のフィルタリングの有効化」を参照してください。agent v10.0では、メトリクスのスクレイピングにデフォルトでpromscrapeが使用されます。
  • prometheus.yaml ファイルの設定を編集します。「Prometheus設定ファイルの編集」を参照してください。
  • Sysdig固有の設定はprometheus.yamlファイルにあります。


取り込み時のフィルタリングの有効化

エージェントv9.8.0において、ターゲットフィルタリングが機能するためには、dragent.yamlのuse_promscrapeパラメータがtrueに設定されている必要があります。設定の詳細については、Sysdig Agentの設定を参照してください。

use_promscrape: true
備考
AGENT V10.0では、デフォルトでUSE_PROMSCRAPEが有効になっています。PROMETHEUSのメトリクスをスクレイピングするためにPROMSCRAPEが使用されることを意味します。
フィルタリングの設定はオプションです。prometheus.yamlがなくても、エージェントの既存の動作は変わりません。

Prometheus設定ファイルの編集

prometheus.yamlファイルには、filtering/relabelingの設定のほとんどが、対象となるプロセスの属性を表すキーと値のペアのリストに含まれています。

キーと値は、環境に応じて必要なタグに置き換えます。

このファイルでは、以下の設定を行います。

  • デフォルトのスクレイプ間隔(オプション)。
例:scrape_interval: 10s
  • Prometheusが提供するラベリングパラメータのうち、Sysdigはmetric_relabel_configsのみをサポートしています。relabel_configパラメータはサポートされていません。
  • 0個以上のプロセス固有のフィルタリング設定(オプション)。
Kubernetes EnvironmentsDocker Environmentsを参照してください。

フィルタリング構成には:
    • フィルタリングのルール
例:- source_labels: [container_label_io_kubernetes_pod_name]
    • スクレイピングするサンプル数の制限(オプション)
例: sample_limit: 2000
  • デフォルトのフィルタリング設定(オプション)。 「デフォルト構成」を参照してください。
フィルタリング構成には
    • フィルタリングのルール
例:- source_labels: [car]
    • スクレイプされるサンプル数の制限(オプション)
例: sample_limit: 2000


prometheus.yamlファイルはdragent.yamlと一緒にインストールされます。prometheus.yamlの構文は、ほとんどの場合、Prometheusの標準的な設定に準拠しています。

デフォルトの設定

キーと値のペアが空のコンフィギュレーションは、デフォルトのコンフィギュレーションとみなされます。デフォルト設定は、スクレイピングされるプロセスのうち、フィルタリング設定が一致していないものすべてに適用されます。Sample Prometheus Configuration Fileでは、job_name: 'default'セクションがデフォルト設定を表しています。

Kubernetes環境

エージェントがKubernetes環境(Open Source/OpenShift/GKE)で動作する場合、以下のKubernetesオブジェクトをキーバリューペアとして含めます。エージェントのインストールについては、「エージェント インストール Kubernetes」を参照してください。

例えば、以下のようなものがあります:

sysdig_sd_configs:
- tags:
    namespace: backend
    deployment: my-api


前述のタグに加えて、これらのオブジェクトタイプのいずれもマッチさせることができます。

daemonset: my_daemon
deployment: my_deployment
hpa: my_hpa
namespace: my_namespace
node: my_node
pod: my_pode
replicaset: my_replica
replicationcontroller: my_controller
resourcequota: my_quota
service: my_service
stateful: my_statefulset

Kubernetes/OpenShift/GKEのデプロイメントでは、prometheus.yamlはdragent.yamlと同じConfigMapを共有します。

Docker環境

Docker環境では、コンテナ、ホスト、ポートなどの属性を含める。例えば、以下のようになります。

sysdig_sd_configs:
- tags:
    host: my-host
    port: 8080


Dockerベースのデプロイメントでは、prometheus.yamlをホストからマウントできます。

Prometheusの設定ファイルのサンプル

global:
  scrape_interval: 20s
scrape_configs:
- job_name: 'default'
  sysdig_sd_configs: # default config
  relabel_configs:
- job_name: 'my-app-job'
  sample_limit: 2000
  sysdig_sd_configs:  # apply this filtering config only to my-app
  - tags:
      namespace: backend
      deployment: my-app
  metric_relabel_configs:
  # Drop all metrics starting with http_
  - source_labels: [__name__]
    regex: "http_(.+)"
    action: drop
  metric_relabel_configs:
  # Drop all metrics for which the city label equals atlantis
  - source_labels: [city]
    regex: "atlantis"
    action: drop


Prometheusメトリクス収集の制限

メトリクスの制限はSysdigのバックエンドが指示し、実施された制限はSysdigのエージェントが消費します。さらに、エージェントはPrometheusメトリクスエンドポイントから読み込まれてメトリクスストアに送信されるメトリクスの数にも制限を課します。管理者は、エージェントのdragent.yamlファイルを設定することで、Sysdigのメトリクス制限値を超えない範囲で制限値を上書きすることができます。

メトリクスの制限

エージェントv10.0.0では、エージェントごとの新しいメトリクス制限は以下の通りです。

  • カスタムメトリクス: 10,000
  • Prometheusメトリクス: 8,000
他のカスタムメトリクスの制限値をゼロにすると、Prometheusメトリクスの制限値が10,000になります。

エージェントの設定

Sysdigが処理・保存するPrometheusメトリクスの数の制限は、dragent.yamlファイルの特定のパラメータによって制御できます。

以下に関連する設定とデフォルト値を示します。値の変更は、エージェントの再起動後に有効になります。

prometheus:
  max_tags_per_metric: 20
  max_metrics_per_process: 1000
  max_metrics: 1000

max_metrics

エージェントがターゲットから消費できるPrometheusメトリクスの最大数です。デフォルトでは1,000です。エージェント v10.0.0 以降では、上限は 10,000 です。10.0.0 未満のエージェントバージョンでは、最大限度は 3,000 です。

max_metrics_per_process

このパラメータは agent v10.0.0 で非推奨となりました。

エージェントが1つのプロセスから読み取ることができるPrometheusメトリクスの最大数です。デフォルトは-1(無限大)です。この制限は、max_metricsの値によって課せられます。

max_tags_per_metric

このパラメータは agent v10.0.0 で非推奨となりました。

これは、エージェントが1つのスクレイプされたターゲットから保存するPrometheusメトリクスの最大数です。


設定例

このトピックでは、Prometheusのデフォルトおよび特定の設定について紹介します。

デフォルト設定

上述した設定要素の多くをまとめた例として、dragent.default.yamlから継承したデフォルトのAgent設定を考えてみましょう。

prometheus:
  enabled: true
  interval: 10
  log_errors: true
  max_metrics: 1000
  max_metrics_per_process: 100
  max_tags_per_metric: 20
 
  # Filtering processes to scan. Processes not matching a rule will not
  # be scanned
  # If an include rule doesn't contain a port or port_filter in the conf
  # section, we will scan all the ports that a matching process is listening to.
  process_filter:
    - exclude:
        process.name: docker-proxy
    - exclude:
        container.image: sysdig/agent
    # special rule to exclude processes matching configured prometheus appcheck
    - exclude:
        appcheck.match: prometheus
    - include:
        container.label.io.prometheus.scrape: "true"
        conf:
            # Custom path definition
            # If the Label doesn't exist we'll still use "/metrics"
            path: "{container.label.io.prometheus.path}"
 
            # Port definition
            # - If the Label exists, only scan the given port.
            # - If it doesn't, use port_filter instead.
            # - If there is no port_filter defined, skip this process
            port: "{container.label.io.prometheus.port}"
            port_filter:
                - exclude: [9092,9200,9300]
                - include: 9090-9500
                - include: [9913,9984,24231,42004]
    - exclude:
        container.label.io.prometheus.scrape: "false"
    - include:
        kubernetes.pod.annotation.prometheus.io/scrape: true
        conf:
            path: "{kubernetes.pod.annotation.prometheus.io/path}"
            port: "{kubernetes.pod.annotation.prometheus.io/port}"
    - exclude:
        kubernetes.pod.annotation.prometheus.io/scrape: false


このデフォルトの設定について、以下のように考えてみましょう。

  • デフォルトでは、Prometheusによるスクレイピングはすべて無効になっています。ここで示した構成全体を有効にするには、dragent.yamlに以下を追加するだけです。
prometheus:
  enabled: true
このオプションを有効にすると、正しいアノテーションが設定されているポッド(Kubernetesの場合)や、ラベルが設定されているコンテナ(そうでない場合)は、自動的に廃棄されます。
  • Process Filterルールは、ほとんどの環境に存在する可能性が高いですが、Dockerプロキシーやエージェント自体などのPrometheusメトリクスをエクスポートしないことがわかっているプロセスを除外します。
  • 別のProcess Filterルールにより、従来のPrometheusアプリケーションチェックによってスクレイピングされるように構成されたプロセスがスクレイピングされないことが保証されます。
  • 別のProcess Filterルールは、コンテナラベルを使用するように調整されています。コンテナラベルio.prometheus.scrapeでマークされたプロセスは、スクレイピングの対象となり、さらにコンテナラベルio.prometheus.portおよび/またはio.prometheus.pathでマークされた場合は、このポートおよび/またはエンドポイントでのみスクレイピングが試みられます。コンテナにパスラベルが指定されていない場合は、/metrics エンドポイントのスクレイピングが試みられます。コンテナに指定されたポートラベルが付いていない場合、port_filter に含まれるすべてのリッスンポートに対してスクレイピングが試行されます(デフォルトのこの port_filter は、一般的な Prometheus エクスポーターのポート範囲に設定されており、エクスポーターではない他のアプリケーションで使用されていることが知られている範囲のポートは除外されています)。


シングルカスタムプロセスのスクレイピング

シングルカスタムプロセスをスクレイプする必要がある場合、例えば、ポート9000でパス/prometheusをリッスンしているjavaプロセスの場合は、dragent.yamlに以下を追加します:

prometheus:
  enabled: true
  process_filter:
    - include:
        process.name: java
        port: 9000
        conf:
          # ensure we only scrape port 9000 as opposed to all ports this process may be listening to
          port: 9000
          path: "/prometheus"

この構成は、デフォルト構成で示されたデフォルトのprocess_filterセクションをオーバーライドします。デフォルトの構成から関連するルールをここに追加して、メトリクスをさらに絞り込むことができます。


備考
PORTは、設定のどこに置かれるかによって目的が異なります。INCLUDEセクションの下に置かれた場合、それはINCLUDEルールにマッチするための条件となります。
CONFの下にポートを配置すると、プロセスがリッスンしている可能性のあるすべてのポートではなく、ルールがマッチしたときにその特定のポートだけがスクレイピングされることを示します。

この例では、ポート9000でリッスンしているJAVAプロセスに対して、最初のルールがマッチします。ポート9000のみをリッスンしているJAVAプロセスが消去されます。

コンテナラベルに基づいてシングルカスタムプロセスをスクレイプする

それでもコンテナラベルに基づいてスクレイピングしたい場合は、関連するルールをデフォルトからprocess_filterに追加します。例えば、以下のように:

prometheus:
  enabled: true
  process_filter:
    - include:
        process.name: java
        port: 9000
        conf:
          # ensure we only scrape port 9000 as opposed to all ports this process may be listening to
          port: 9000
          path: "/prometheus"
    - exclude:
        process.name: docker-proxy
    - include:
        container.label.io.prometheus.scrape: "true"
        conf:
            path: "{container.label.io.prometheus.path}"
            port: "{container.label.io.prometheus.port}"
備考
PORTは、設定のどこに置かれているかによって意味が異なります。INCLUDEセクションの下に置かれた場合、それはINCLUDEルールにマッチするための条件となります。
CONFの下に置かれたPORTは、プロセスがリッスンしている可能性のあるすべてのポートではなく、ルールがマッチしたときにそのポートだけがスクレイピングされることを示します。
この例では、最初のルールは、ポート9000でリッスンしているプロセスに対してマッチします。ポート9000のみをリッスンしているJAVAプロセスはスクレイプされます。

コンテナ環境

このデフォルト設定を有効にすると、以下に示す例のエクスポーターのコンテナ化されたインストールが、エージェントを介して自動的にスクレイピングされます。

# docker run -d -p 8080:8080 \
    --label io.prometheus.scrape="true" \
    --label io.prometheus.port="8080" \
    --label io.prometheus.path="/prometheus" \
    luca3m/prometheus-java-app


Kubernetes環境

Kubernetesベースの環境では、デフォルトの設定を有効にすることで、この例のYAMLに示されるようなアノテーションを持つDeploymentがスクレイピングされます。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: prometheus-java-app
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: prometheus-java-app
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/path: "/prometheus"
        prometheus.io/port: "8080"
    spec:
      containers:
        - name: prometheus-java-app
          image: luca3m/prometheus-java-app
          imagePullPolicy: Always

コンテナ化されていない環境

これは、コンテナ化されていない環境や、ラベルやアノテーションを使用していないコンテナ化された環境の例です。次のdragent.yamlは、デフォルトをオーバーライドして、サンプルのエクスポーターとポート5005上の第2のエクスポーターを、それぞれの非標準エンドポイントで秒単位でスクレイプします。これは、環境内に存在することが知られているエクスポーターと、そのエクスポーターがPrometheusメトリクスをエクスポートすることが知られているポートのみにスクレイピングを制限するため、保守的な「ホワイトリスト」タイプの設定と考えることができます。

prometheus:
  enabled: true
  interval: 1
  process_filter:
    - include:
        process.cmdline: "*app.jar*"
        conf:
          port: 8080
          path: "/prometheus"
    - include:
        port: 5005
        conf:
          port: 5005
          path: "/wacko"
備考
PORTは、設定のどこに置かれているかによって意味が異なります。INCLUDEセクションの下に置かれた場合、それはINCLUDEルールにマッチするための条件となります。CONFの下に置かれたPORTは、プロセスがリッスンしている可能性のあるすべてのポートではなく、ルールがマッチしたときにそのポートだけがスクレイピングされることを示します。
この例では、最初のルールは*APP.JAR*というプロセスに対してマッチします。ポート8080のみをリッスンしているJAVAプロセスは、*APP.JAR*がリッスンしている可能性のあるすべてのポートではなく、スクレイプされます。2つ目のルールは、ポート5005に対してマッチし、5005でのみリッスンしているプロセスがスクレイプされます。

ロギングとトラブルシューティング

ロギング

エージェントがPrometheusメトリクスのスクレイピングを開始した後、Sysdig Monitorでメトリクスが表示されるまでに最大で数分の遅延が発生します。設定が正しいことをすぐに確認できるように、エージェントバージョン0.80.0以降では、エージェントが起動してから初めて、少なくとも1つのPrometheusエクスポーターを見つけてスクレイピングに成功したときに、次のようなログ行がエージェントログに表示されます。

2018-05-04 21:42:10.048, 8820, Information, 05-04 21:42:10.048324 Starting export of Prometheus metrics


これはINFOレベルのログメッセージなので、デフォルトのログ設定を使用しているAgentに表示されます。より詳細な情報を得るためには、AgentのログレベルをDEBUGに上げると、最初に検出された特定のメトリクスの名前を示す以下のようなメッセージが表示されます。このメッセージには、最初に検出された特定のメトリクスの名前が表示されます。このメトリクスは、その後すぐにSysdig Monitorで表示されます。

2018-05-04 21:50:46.068, 11212, Debug, 05-04 21:50:46.068141 First prometheus metrics since agent start: pid 9583: 5 metrics including: randomSummary.95percentile

トラブルシューティング

スクレイピングが成功したときのログメッセージについては、前のセクションを参照してください。Prometheusを有効にしているにもかかわらず、Starting exportメッセージが表示されない場合は、設定を再確認してください。

また、構成オプションをデフォルト設定のlog_errors: trueのままにしておくことをお勧めします。これにより、対象となるプロセスのスクレイピングに問題があった場合、Agentログで明らかになります。

例えば、HTTPリクエストをリッスンしているが受け付けていないTCPポートのスクレイピングに失敗した場合のエラーメッセージを以下に示します。

2017-10-13 22:00:12.076, 4984, Error, sdchecks[4987] Exception on running check prometheus.5000: Exception('Timeout when hitting http://localhost:5000/metrics',) 2017-10-13 22:00:12.076, 4984, Error, sdchecks, Traceback (most recent call last): 2017-10-13 22:00:12.076, 4984, Error, sdchecks, File "/opt/draios/lib/python/sdchecks.py", line 246, in run 2017-10-13 22:00:12.076, 4984, Error, sdchecks, self.check_instance.check(self.instance_conf) 2017-10-13 22:00:12.076, 4984, Error, sdchecks, File "/opt/draios/lib/python/checks.d/prometheus.py", line 44, in check 2017-10-13 22:00:12.076, 4984, Error, sdchecks, metrics = self.get_prometheus_metrics(query_url, timeout, "prometheus") 2017-10-13 22:00:12.076, 4984, Error, sdchecks, File "/opt/draios/lib/python/checks.d/prometheus.py", line 105, in get_prometheus_metrics 2017-10-13 22:00:12.077, 4984, Error, sdchecks, raise Exception("Timeout when hitting %s" % url) 2017-10-13 22:00:12.077, 4984, Error, sdchecks, Exception: Timeout when hitting http://localhost:5000/metrics


以下は、/metricsエンドポイントでHTTPリクエストに応答しているが、有効なPrometheus形式のデータで応答していないポートのスクレイピングに失敗した場合のエラーメッセージの例です。無効なエンドポイントは以下のように応答しています。

# curl http://localhost:5002/metrics
This ain't no Prometheus metrics!

また、Agentログに対応するエラーメッセージが表示されており、最初の失敗の後、これ以上のスクレイピングが試みられないことを示しています。

2017-10-13 22:03:05.081, 5216, Information, sdchecks[5219] Skip retries for Prometheus error: could not convert string to float: ain't 2017-10-13 22:03:05.082, 5216, Error, sdchecks[5219] Exception on running check prometheus.5002: could not convert string to float: ain't

最近の投稿

カテゴリー

アーカイブ

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

top