Clever Geek Handbook

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



ブログもご覧ください。





More articles:


All Articles