本文の内容は、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コレクターに送って保存し、さらに処理するように設定することができます。
このドキュメントでは、メトリクスとタイムシリーズを同義で使用しています。設定パラメータの説明では「メトリクス」に言及していますが、Prometheusの厳密な用語では、これらはタイムシリーズを意味します。つまり、100メトリクスという制限を適用することは、タイムシリーズの制限を適用することを意味し、すべてのタイムシリーズデータが同じメトリクス名を持たない可能性があります。
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 エクスポーターからメトリクスを自動的に収集するためのサポートを提供します。
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 と名前が変わります。
前提条件とガイドライン
- 最新の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メトリクスをエクスポートしているポートのみをスクレイピングし、接続してスクレイピングしようとしたときにポートがどのように反応したかに基づいて、スクレイピングの試みを停止したり、ポートの再試行を行ったりします。したがって、スクレイピングを試みるプロセスとポートを、エクスポート先の予想される最小範囲に制限する設定を作成することを強くお勧めします。これにより、接続の失敗が繰り返されることで、エージェントとアプリケーションの両方に意図しない副作用が発生する可能性を最小限に抑えることができます。
エンドツーエンドのメトリクス収集は、以下のようにまとめられます:
- プロセスは、一連のプロセスフィルタの包含/除外ルールにポジティブにマッチした場合、スクレイピングの対象となる可能性があると判断されます。詳細については、「プロセスフィルター」を参照してください。
- エージェントは、ポートのサブセットや別のエンドポイント名にスクレイピングを制限する追加の設定がない限り、/metricsエンドポイントのすべてのリスニングTCPポートで適格なプロセスをスクレイピングしようとします。
- agent v9.8.0では、取り込み時のメトリクスのフィルタリングが有効になっています。有効にすると、メトリクスを受信する際にインジェストでフィルタリングルールが適用されます。詳細は「Prometheusメトリクスのフィルタリング」を参照してください。
- メトリクスを受信すると、エージェントは以下のルールを適用してからSysdigコレクターに送信します。
- グローバルなmetrics_filterルールを適用します。
詳細は、「カスタムメトリクスを含める/除外する」を参照してください。
- グローバルなmetrics_filterルールを適用します。
- 設定されたmax_metricsを適用して、メトリクスの数を制限します。
メトリクスは最終的にSysdig Monitor ExploreインターフェースのPrometheusセクションに表示されます。

環境の設定
クイックスタート 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>
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 メトリクスのスクレイピングに promscrape を使用するかどうかを決定します。 |
promscrape
Promscrapeは、Sysdigエージェントに組み込まれた、軽量のPrometheusサーバーです。use_promscrapeパラメータは、Prometheusのエンドポイントをスクレイピングするために使用するかどうかを制御します。パラメーター | デフォルト | 説明 |
---|---|---|
|
| Iagent v10.0.0では、このフラグはデフォルトで有効になっています。 |
prometheus
prometheusセクションでは、Prometheusメトリクスの収集と分析に関する動作を定義します。このセクションでは、機能をオンにしたり、エージェント側からスクレイピングされるメトリクスの数に制限を設けたり、ヒストグラムメトリクスをレポートするかどうか、スクレイピングの失敗を記録するかどうかなどを決定します。パラメーター | デフォルト | 説明 |
---|---|---|
|
| Prometheusのスクレイピングをオン、オフにします。 |
|
| エージェントがPrometheusメトリクスのためにポートをスクレイピングする頻度(秒単位) |
|
| この値がtrueに設定されている場合、ネイティブのPrometheusサービスディスカバリーを有効にします。無効の場合は、promscrapeを使用してターゲットをスクレイピングします。「Prometheus Native Service Discoveryの有効化」を参照してください。 |
|
| 対象となるターゲットのスクレイピングに失敗した際に、エージェントが詳細を記録するかどうか |
|
| すべてのターゲットでスクレイピングされるPrometheusメトリクスの合計数の最大値です。この10,00という値は、エージェントごとの最大値であり、他のカスタムメトリクス(statsd、JMX、その他のアプリケーションチェックなど)とは別の制限です。 |
|
| エージェントが1つのスクレイプされたターゲットから保存するPrometheusメトリクスの最大数です。 |
|
| エージェントがスクレイプされたターゲットから保存する、Prometheusメトリクスごとのタグの最大数。 |
| 1 | Prometheusのエンドポイントをスクレイピングする際に、エージェントがタイムアウトするまでの待ち時間を設定するために使用します。デフォルト値は1秒です。 |
|
| エージェントがヒストグラムメトリクスをスクレイピングしてレポートするかどうか。詳細は、「ヒストグラム」を参照してください。 |
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 ...
パターン名 | 説明 | 例 |
---|---|---|
| 指定されたイメージを実行しているコンテナ内でプロセスが実行されているかどうかにマッチします |
|
指定された名前のコンテナ内でプロセスが実行されているかどうかにマッチする |
| |
| 与えられた値と一致するLabelを持つコンテナでプロセスが実行されている場合にマッチする |
|
| 与えられた値にマッチするAnnotation/LabelでマークされたKubernetesオブジェクト(Pod、Namespaceなど)にプロセスがアタッチされているかどうかにマッチします。 |
|
実行中のプロセスの名前に一致する |
| |
| コマンドラインの引数にマッチする |
|
| プロセスが1つまたは複数のTCPポートをリッスンしている場合にマッチします。 |
|
| 特定の名前またはパターンのアプリケーションチェックがプロセスに対して実行されるようにスケジュールされているかどうかにマッチします。 |
|
前述のように複数のパターンを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エンドポイントでスクレイピングが試みられます。可能な設定は:パラメーター名 | 説明 | 例 |
---|---|---|
| スクレイピングされる1つのTCPポートの固定番号、または中括弧で指定されたコンテナ/Kubernetesのラベル名またはKubernetesのアノテーションのいずれか。プロセスがこのLabelでマークされたコンテナ内で実行されている場合、またはこのAnnotation/LabelでマークされたKubernetesオブジェクト(Pod、Namespaceなど)に接続されている場合、Label/Annotationの値として指定されたポートでのみスクレイピングが試みられます。 |
– or –
– or –
|
| includeルールとexcludeルールのセットで、スクレイピングを試みることができる適格なプロセスのリスニングTCPポートの究極のセットを定義します。この構文は、 |
|
| スクレイピングされるエンドポイントの静的な指定、または中括弧で指定されたコンテナ/KubernetesのLabel名またはKubernetesのAnnotationのいずれかです。プロセスがこのLabelでマークされたコンテナ内で実行されている場合、またはこのAnnotation/LabelでマークされたKubernetesオブジェクト(Pod、Namespaceなど)にアタッチされている場合、Label/Annotationの値として指定されたエンドポイント経由でスクレイピングが試みられます。 |
– or –
– or –
|
| ホスト名またはIPアドレス。デフォルトはlocalhostです | host: 192.168.1.101 - or - host: subdomain.example.com - or - host: localhost |
|
|
|
|
|
|
認証の統合
- ユーザ名/パスワード認証の場合
username
password
- トークンを使った認証の場合
auth_token_path
- 証明書キーを用いた証明書認証の場合
auth_cert_path
auth_key_path
備考
トークンの置き換えは、すべての認証パラメータでサポートされています。例えば、Kubernetesのアノテーションからユーザー名を取得するには、次のように指定します。
conf 認証例
以下は、Prometheus認証のすべての設定オプションを示すdragent.yamlセクションの例で、OpenShift、Kubernetes、およびetcd上のものです。この例では:
- username/passwordは、OpenShiftで使用されているデフォルトのアノテーションから取得しています。
- auth tokenパスは、Kubernetesのデプロイメントで一般的に使用されます。
- ここでetcdに使用されているcertificateとkeyは、通常、エージェントからは簡単にアクセスできない場合があります。このケースでは、ホストのネームスペースから抽出し、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は、レコーディングルールやアラート管理などのクラスターワイドな機能をサポートしていません。
- promscrapeとpromscrape.v2のサービスディスカバリー設定には互換性がなく、翻訳できません。
- promscrape.v2を有効にすると、エージェントを実行しているすべてのノードで実行され、prometheus.yamlファイルで指定されたローカルまたはリモートのターゲットからメトリクスを収集することを目的としています。
- promscrape.v2はクラスタビューを持たないため、クラスタ全体のメトリクス収集で使用されるレコーディングルールやアラートの設定を無視しています。
- Sysdigでは__HOSTNAME__を使用していますが、これはPrometheusの標準的なキーワードではありません。
Promscrape V2の有効化
Prometheusのネイティブサービスディスカバリーを有効にするには:❶ dragent.yamlファイルを開きます。
❷ 以下のPrometheus Service Discoveryパラメータをtrueに設定します。
prometheus: prom_service_discovery: 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_uidとsysdig_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設定ファイルの編集
prometheus.yamlファイルには、filtering/relabelingの設定のほとんどが、対象となるプロセスの属性を表すキーと値のペアのリストに含まれています。キーと値は、環境に応じて必要なタグに置き換えます。
このファイルでは、以下の設定を行います。
- デフォルトのスクレイプ間隔(オプション)。
- Prometheusが提供するラベリングパラメータのうち、Sysdigはmetric_relabel_configsのみをサポートしています。relabel_configパラメータはサポートされていません。
- 0個以上のプロセス固有のフィルタリング設定(オプション)。
フィルタリング構成には:
- フィルタリングのルール
- スクレイピングするサンプル数の制限(オプション)
- デフォルトのフィルタリング設定(オプション)。 「デフォルト構成」を参照してください。
- フィルタリングのルール
- スクレイプされるサンプル数の制限(オプション)
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_statefulsetKubernetes/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
エージェントの設定
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 エクスポーターのポート範囲に設定されており、エクスポーターではない他のアプリケーションで使用されていることが知られている範囲のポートは除外されています)。
- 最終的なProcess Filter Includeルールは、「Quick Start For Kubernetes Environments」で説明したユースケースに合わせています。
シングルカスタムプロセスのスクレイピング
シングルカスタムプロセスをスクレイプする必要がある場合、例えば、ポート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ポートのスクレイピングに失敗した場合のエラーメッセージを以下に示します。
以下は、/metricsエンドポイントでHTTPリクエストに応答しているが、有効なPrometheus形式のデータで応答していないポートのスクレイピングに失敗した場合のエラーメッセージの例です。無効なエンドポイントは以下のように応答しています。
# curl http://localhost:5002/metrics This ain't no Prometheus metrics!また、Agentログに対応するエラーメッセージが表示されており、最初の失敗の後、これ以上のスクレイピングが試みられないことを示しています。