Geekly Articles each Day

KubernetesのPrometheusオペレーターの操作のデバイスとメカニズム

この記事は、デプロイおよび保守されたKubernetesクラスターでPrometheusオペレーターの制御下でPrometheusがどのように機能するかを説明するDevOpsエンジニア向けの内部ドキュメントに基づいています。

画像

一見、 プロメテウスはかなり複雑な製品のように見えますが、よく設計されたシステムのように、明示的な機能コンポーネントで構成され、本質的に3つのことのみを行います。時系列データ。 この記事は、Prometheus自体ではなく、このシステムをKubernetesと統合する方法について説明します。Kubernetesでは、 Prometheus Operatorというヘルパーツールを積極的に使用しています。 しかし、あなたはまだプロメテウス自体から始める必要があります...

プロメテウス：彼は何をしていますか？


したがって、プロメテウスの最初の2つの機能について詳しく説明すると、次のように機能します。


プロメテウス：どのように構成されていますか？


Prometheusサーバーには、構成ファイルとルールファイルがあります 。

configには次のセクションがあります。


プロメテウス：目標リストはどこから来たのですか？


プロメテウスの一般的なアルゴリズムは次のとおりです。



  1. Prometheusは、 scrape_configsセクションを読み取り、それに応じて内部サービス検出メカニズムを構成します。
  2. Service DiscoveryメカニズムはKubernetes APIと対話します（主にエンドポイントを受信するため）。
  3. Kubernetesからのデータに基づいて、 Service Discoveryメカニズムはターゲット （ 目標のリスト）を更新します。

scrape_configsは、 scrape_configs （これはPrometheusの内部概念です）をリストします。それぞれは次のように定義されます：

 scrape_configs: #   - job_name: kube-prometheus/custom/0 #   scrape job' #    Service Discovery scrape_interval: 30s #     scrape_timeout: 10s #    metrics_path: /metrics # path,   scheme: http # http  https #  Service Discovery kubernetes_sd_configs: # ,  targets    Kubernetes - api_server: null #   API-   #  (    ) role: endpoints # targets   endpoints namespaces: names: #  endpoints    namespaces - foo - baz #  "" ( enpoints ,  — )  "" # (     —    ) relabel_configs: #     prometheus_custom_target, #   service,   endpoint - source_labels: [__meta_kubernetes_service_label_prometheus_custom_target] regex: .+ #      action: keep #     - source_labels: [__meta_kubernetes_endpoint_port_name] regex: http-metrics # ,    http-metrics action: keep #   job,    prometheus_custom_target #  service,     "custom-" # #  job —   Prometheus.    , #     target   targets,     #   ,    targets (    #   rules  dashboards) - source_labels: [__meta_kubernetes_service_label_prometheus_custom_target] regex: (.*) target_label: job replacement: custom-$1 action: replace #   namespace - source_labels: [__meta_kubernetes_namespace] regex: (.*) target_label: namespace replacement: $1 action: replace #   service - source_labels: [__meta_kubernetes_service_name] regex: (.*) target_label: service replacement: $1 action: replace #   instance (    ) - source_labels: [__meta_kubernetes_pod_name] regex: (.*) target_label: instance replacement: $1 action: replace

したがって、プロメテウス自体は以下を追跡します。


次の場合、構成の変更が必要です。


Prometheusの基本を取り扱ったので、クラスタリアリティでのPrometheusの展開と操作を簡素化するKubernetesの特別な補助コンポーネントである「演算子」に進みましょう。

プロメテウス演算子：それは何をしているのですか？


悪名高い「単純化」のために、まず、CRD（ カスタムリソース定義 ）メカニズムを使用するプロメテウスオペレーターで、3つのリソースが定義されています。

  1. prometheus -Prometheusのインストール（クラスター）を定義します。
  2. servicemonitorサービスのセットを監視する方法を定義します（つまり、メトリックを収集します）。
  3. alertmanager - alertmanagerクラスターを定義します（SlackやTelegramとの統合など、さまざまなソースからデータを受信、集計、ランク付けする通知システムにメトリックを直接送信するため、アラートマネージャーのクラスターは使用しません）。

第二に、オペレーターはprometheusリソースを監視し、それぞれに対して生成します：

  1. StatefulSet （Prometheus自体を使用）;
  2. prometheus.yaml （Prometheusの構成）およびconfigmaps.json （ prometheus-config-reloader configmaps.json ）による秘密 。

最後に、オペレーターはルールを使用してservicemonitorリソースとConfigMapsも監視し、それに基づいてprometheus.yamlおよびconfigmaps.json更新します（これらは秘密にされます）。

プロメテウスの最新情報


潜水艦は2つのコンテナで構成されています：

  1. prometheus -プロメテウス自体;
  2. prometheus-config-reloader - prometheus.yamlへの変更を監視し、必要に応じてPrometheus構成のリロードを引き起こすバインディング （特別なHTTPリクエスト-詳細は以下を参照）、およびConfigMapsを規則で監視するバインディング （ configmaps.jsonで指定されconfigmaps.json -参照）以下で詳細を確認してください）、必要に応じてそれらをダウンロードし、Prometheusを再起動します。



サブは3つのボリュームを使用します：

  1. configマウントされたシークレット（2つのファイル： prometheus.yamlおよびconfigmaps.json ）。 両方のコンテナに接続。
  2. rules emptyDir prometheus-config-reloader emptyDirを読み込み、 prometheus-config-reloader emptyDir 両方のコンテナに接続されていますが、 prometheus -読み取り専用モードで。
  3. data-プロメテウスデータ。 prometheusのみ装着されています。

Service Monitorはどのように処理されますか？




  1. プロメテウスオペレーターは、 サービスモニターを読み取ります （また、追加/削除/変更も監視します）。 prometheusリソースprometheus指定されているService Monitor （詳細については、 ドキュメントを参照）。
  2. 各Service Monitorについて、名前空間の特定のリストを指定しない場合（つまり、 any: true指定されている場合）、Prometheus Operatorは（Kubernetes APIを使用して） Service Monitorで指定されたラベルに一致するサービスを含む名前空間のリストを計算します。
  3. 読み込まれたservicemonitorリソース（ ドキュメントを参照）および計算された名前空間に基づいて、Prometheus Operatorは構成の一部（ scrape_configsセクション）を生成し、対応するシークレットに構成を保存します。
  4. Kubernetes自体の通常の手段により、シークレットからのデータがサブにprometheus.yamlます（ prometheus.yamlファイルprometheus.yaml更新されます）。
  5. ファイルを変更すると、 prometheus-config-reloader通知されます。これは、リブートするHTTP要求をPrometheusに送信します。
  6. Prometheusは設定を再読み込みし、 scrape_configsの変更を確認します。操作のロジックに従って処理します（上記の詳細を参照）。

ConfigMapはルールでどのように処理されますか？




  1. Prometheusオペレーターは、 prometheusリソースで指定されたruleSelectorに一致するruleSelectorモニターします。
  2. 新しい（または既存の） ConfigMapが表示された場合、Prometheusオペレーターはprometheus.yaml更新し、その後、 Service Monitorsの処理（上記を参照）に正確に対応するロジックがトリガーされます。
  3. ConfigMapを追加/削除する場合 、およびConfigMapの内容を変更する場合と同様に 、Prometheus Operatorはconfigmaps.jsonファイルを更新します（ ConfigMapとそのチェックサムをリストします）。
  4. Kubernetes自体の通常の手段により、シークレットからのデータがサブにconfigmaps.jsonます（ configmaps.jsonファイルconfigmaps.json更新されます）。
  5. ファイルを変更すると、 prometheus-config-reloader reloaderがemptyDirます。これは、変更されたConfigMapをrulesディレクトリ（これはemptyDir ）にダウンロードします。
  6. 同じprometheus-config-reloaderはHTTP要求をPrometheusに送信して再起動します。
  7. プロメテウスは設定を再読み込みし、変更されたルールを確認します。

以上です！


KubernetesでのモニタリングにPrometheus（だけでなく）を使用する方法の詳細については、 RootConf 2018カンファレンスで5月28日と29日にモスクワで開催される予定をお話しする予定です。

PS


ブログもご覧ください。

Source: https://habr.com/ru/post/J353410/

More articles:


All Articles