Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à cluster-monitoringで困ったこと学んだこと
Similaire à cluster-monitoringで困ったこと学んだこと (20)
Dernier
Dernier (8)
cluster-monitoringで困ったこと学んだこと
- 6. OpenShiftについて、わからないことばかり 何を調べたら良いかもわからない状況から、 コンテナ監視にたどり着くまで沢山の壁がありました 1st OpenShiftのしくみがわからな い 2nd Prometheusの機能がわからな い 3rd なにを監視したらいいの？ 4th 設定カスタマイズができない
- 8. [root@ip-172-31-43-203 ~]# oc apply -f test.yaml deploymentconfig.apps.openshift.io/frontend created [root@ip-172-31-43-203 ~]# oc get po -w NAME READY STATUS RESTARTS AGE frontend-2-5kldg 0/1 ContainerCreating 0 21s frontend-2-deploy 1/1 Running 0 31s frontend-2-n2zrx 0/1 ContainerCreating 0 21s frontend-2-5kldg 1/1 Running 0 64s frontend-2-n2zrx 1/1 Running 0 64s frontend-2-deploy 0/1 Completed 0 75s Manifest test.yaml OpenShiftがなんだかよくわからないまま、コンテナのYAMLファイルをつくってコマンド 実行したら コンテナが増えて、STATUSは「Running」だし何だかすごい！！ でもひとたびエラーが起こると、何をしたらいいのか全くわかりません コントローラスケジューラ ぜんぶ おまじないの 世界
- 9. Cluster KubernetesやOpenShiftのしくみを学びつつ、コンテナを動かし続け… 沢山のエラーと出会いました WorkerノードMasterノード コントローラスケジューラ CLI / API Internet Podが 動かない！！ Manifest Nodeの ステータス異常？ API実行 エラー？ リソース不足？ ヘルスチェックの 失敗？ OpenShiftで問題があったらすぐ知りた い 何が原因か調査、対処したい スケジューラの エラー？
- 10. openshift-monitoring OpenShiftのステータス監視 OpenShiftでは、PromethuesやGrafanaなどの監視機能をもつコンテナによっ て クラスタや個々のオブジェクトの状態、リソースの使用状況などを確認します メトリクス収集 アラート設定 ダッシュボード (例)Podステータスの メトリクスを収集 Podの異常を 管理者へ通知 監視データをグラフで可視 化 OpenShiftの状態を確認 kube-state-metrics Pod
- 15. Promethuesとは CNCFプロジェクトに含まれるオープンソースの監視ツール プラグインによってKubernetesのリソースを ダイナミックに監視できます 主な機能 • メトリクス収集(ServiceDiscovery) どのコンポーネントからどんなメトリクスを 収集するかを設定します • ルール設定 クエリ(PromQL)を使用して、アラートルールやレコードを設定します • アラート設定 アラートルールの閾値を超えた際に、アラート通知方法やタイミングを設 定します
- 16. Prometheusの監視対象 OpenShiftでは、Exporterと呼ばれるメトリクスを配信するためのコンテナや、 Prometheusメトリクス対応のコンテナからデータを取得します Any Project openshift-monitoring node-exporter Pod kube-state-metrics Pod Ｐｒｏｍｅｔｈｕｅｓ Ｐｏｄ kubelet Pod default router Pod api-server Pod ・・・ 対象コンポーネントから メトリクスをPULL メトリクス収集設定 (ServiceDiscovery) kubernetes_sd_configs metric_relabel_configs relabel_configs
- 17. メトリクス収集設定 Prometheus設定ファイルの「scrape_config」にアクセス先を設定します 「kubernetes_sd_configs」を使用すると、IPアドレスを指定しなくても OpenShiftの オブジェクトを特定してアクセス先に設定することができますscrape_configs: - job_name: openshift-monitoring/node-exporter/0 scrape_interval: 30s scrape_timeout: 10s metrics_path: /metrics scheme: https kubernetes_sd_configs: - role: endpoints namespaces: names: - openshift-monitoring bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token tls_config: ca_file: /etc/prometheus/configmaps/serving-certs-ca-bundle/service-ca.crt ~~~~~~~~~~~~~~~~~~~~~~~省略~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 30秒おきにメトリクスを収集 node-exporterのエンドポイントへアクセスするための証明書設 定 「openshift-monitoring」プロジェクトに定義されている エンドポイントをターゲットにする
- 19. メトリクスのラベル設定 「relabel_configｓ」では、ターゲットからメトリクスを取得する前に、ターゲッ トに関する ラベル設定を操作して、取得対象を変更したり、絞り込んだりすることができる scrape_configs: - job_name: openshift-monitoring/node-exporter/0 ~~~~~~~~~~~~~~~~~~~~~~~省略~~~~~~~~~~~~~~~~~~~~~~~~~~~~ relabel_configs: - source_labels: [__meta_kubernetes_service_label_k8s_app] separator: ; regex: node-exporter replacement: $1 action: keep - source_labels: [__meta_kubernetes_endpoint_port_name] separator: ; regex: https replacement: $1 action: keep ~~~~~~~~~~~~~~~~~~~~~~~省略~~~~~~~~~~~~~~~~~~~~~~~~~~~~ サービス名をあらわすラベルが「node-exporter」である メトリクスだけを取得する サービスのエンドポイント名が「https」であるメトリクス だけを取得する
- 28. Grafanaとは CNCFプロジェクトに含まれるオープンソースのデータ可視化ツール Prometheusをデータソースとして設定し、PromQLを使用した柔軟なデータ操 作を 行うことができます。 主な機能 • ダッシュボード作成(線グラフ、棒グラフ、円グラフ、メーター、表など) • CSVデータ取得 Grafanaはパネルごとに取得する必要があるため、ダッシュボード全体のデータ取得には手間がかか ります メトリクスデータの抽出を行う場合は、PrometheusAPIを使っていました • ダッシュボード設定のインポート/エクスポート Configmapで作成したダッシュボード設定はWebUIから変更不可のため 設定変更の際には、WebUIでコピー＆変更したダッシュボードのJsonをエクスポートして毎回 Configmap化
- 30. Grafanaダッシュボードの失敗… 1. Javaアプリケーションコンテナのダッシュボードを作りたい！ 2. ラベルの値を「Pull Down」や「チェックリスト」として表示する機能を追加 しよう！ 3. 「Pod」ラベルのリストを作りたいけど、Java以外のPod名もたくさん表示さ れる… 4. PrometheusのJava用のScrape設定に「ｊava_pod 」ラベルを追加 5. フィルタリングに合わせて、ダッシュボード内全パネルのPromQLに 「java_pod」追加 6. こんなことしなくても、「regex」と「query: query_result()」をくみあわせ て、JavaPodだけ表示する「Pull Down」や「チェックリスト」を作れる scrape-config設定 Javaのジョブ：java_podラベルあり kube-state-metricsのジョブ：java_podラベルなし ダッシュボード機能の理解不足 ダッシュボード設定 PromQL「ｊava_pod」でフィルタリング 「java_pod」ラベルのないメトリクスがダッ シュボード内に混在するとPromQLの設定が 複雑に… ラベル設定の考慮不足
- 31. 3rd なにを監視したらいいの？ 「openshift-monitoring」のデフォルト設定を確認 • メトリクス収集 • アラートルール設定 • ダッシュボード設定 基本構成のProject以外は 監視対象外の設定もあり OpenShiftのCluster管理コンポーネントを 監視するための基本的な設定
- 34. 障害切り分けに必要な情報の整理 OpenShiftで何か問題が起こったときに、何によって気が付くことができるか 何を調べたら原因を特定することができるのか、想定されるパターンを整理す る (例)APPコンテナのネットワーク接続エラー時に確認すること 対象 確認方法 接続先の情報は正しいか アプリ Git コネクションプールが枯渇していないか コンテナ Prometheus networkpolicyの設定は正しいか OpenShift JenkinsJob ネットワークにドロップ/エラーが発生していないか コンテナ Prometheus ipfailoverPODやルータPODは正常に稼働しているか(接続が ルータ経由である場合) OpenShift Prometheus ネットワークインターフェースが正常に稼働しているか ノード JenkinsJob コンテナ標準エラー出力確認 コンテナ Elasticsearch
- 35. 【コンテナステータス監視】 • Project： openshift-.*、kube-.*、default、logging 【クラスタリソース監視】 • ノード リソース： CPU,メモリ,ディスク,ネットワーク,etc • コンテナ リソース： CPU,メモリ,PV Project： openshift-.*、kube-.*、default、logging 【コンポーネントごとのメトリクス監視】 • api-serverコンテナ • etcdコンテナ • メトリクス対応オペレータコンテナ • default-router • default-dns などなど 【コンテナステータス監視】 • Project： ユーザが追加したProject 【クラスタリソース監視】 • コンテナ リソース： CPU,メモリ,ネットワーク,ディスク,PV 対象Project： ユーザが追加したProject 【コンポーネントごとのメトリクス監視】 (ユーザが追加したコンポーネント例) • Javaアプリケーションコンテナ • Istio • AMQStreams などなど デフォルト監視項目 追加したい監視項目
- 36. 管理系コンテナの エラー検知 ノードのリソース 使用状況 管理系コンテナの リソース使用状況 APIサーバやetcd のエラー 【コンテナステータス監視】 • Project： openshift-.*、kube-.*、default、logging 【クラスタリソース監視】 • ノード リソース： CPU,メモリ,ディスク,ネットワーク,etc • コンテナ リソース： CPU,メモリ,PV Project： openshift-.*、kube-.*、default、logging 【コンポーネントごとのメトリクス監視】 • api-serverコンテナ • etcdコンテナ • メトリクス対応オペレータコンテナ • default-router • default-dns などなど デフォルト監視項目 などなど PromQLやアラート通知、ダッシュボードで 確認可能
- 37. 【コンテナステータス監視】 • Project： ユーザが追加したProject 【クラスタリソース監視】 • コンテナ リソース： CPU,メモリ,ネットワーク,ディスク,PV 対象Project： ユーザが追加したProject 【ノード死活監視】 • ICMP(ping) 【コンポーネントごとのメトリクス監視】 (ユーザが追加したコンポーネント例) • Javaアプリケーションコンテナ • Istio • AMQStreams などなど 追加したい監視項目 PrometheusやGrafanaの設定変更
- 40. openshift-monitoring Promethues コンテナ PromethuesOperator コンテナ cluster-monitoring Operator Pod 4th 設定カスタマイズができない GrafanaPod 「openshift-monitoring」で変更できないこと 監視設定のサポート(OpenShift公式ドキュメントを参照) 変更できること • アラート設定 変更できない • メトリクス(ServiceDiscovery)設定 • ルール設定 • ダッシュボード設定 許可されない設定変更は、 Operatorによって元に戻されてしまいます 構成管理
- 42. AMQStreamsコンテナの監視設定例 jmx-exporterを使用して、KafkaブローカやZookeeperなどの状態を監視しま す • AMQStreamsのカスタムリソースにて、メトリクスを有効化 • AMQStreams設定のサンプルを参考に、ブローカ間の冗長化(データ同期) 状況や、レプリカ不足など、ストリーミング機能提供に大きく影響するス テータス監視をアラート設定に追加 Kafkaブローカ Pod CR設定 (exporter設定) jmx-exporter Promethues Pod GrafanaPod Zookeeper Pod jmx-exporter strimzi Operator アラート設定追加 • コンテナclushloopback • コンテナステータス NotRady • ブローカレプリカ不足 • アクティブコントローラ 数 • ISR以下パーティション 数 • Zookeeperリクエスト数 • Zookeeper応答時間 etc... ダッシュボード設定追加 • コンテナリソース使用率 • Java Heap使用率 • ブローカレプリカ不足 • アクティブコントローラ 数 • トピック送受信レート • ISR以下パーティション 数 • Zookeeperリクエスト数 • Zookeeper応答時間 etc...
- 43. Javaアプリケーションコンテナの監視設定例 jmx-exporterを使用して、Javaアプリケーションの状態を監視します • パフォーマンスやステータス確認が無効化されている場合、 Java実行環 境設定(XMLなど)を変更して、データ取得を有効化 • コンテナのベースイメージにｊｍｘ-exporterが対応していない場合、 Exporterをコンテナイメージへ追加 • アプリケーションのパフォーマンス監視のため、JVMのHeapやスレッド プールの使用状況をダッシュボードへ追加 Java AppPod XML設定 (poststartで適用) jmx-exporter Promethues Pod GrafanaPod アラート設定追加 • コンテナclushloopback • コンテナステータス NotRady • JVM Heap使用率 etc... ダッシュボード設定追加 • コンテナリソース使用率 • JVM Heap使用率 • スレッド使用状況 • コネクションプール etc...
Notes de l'éditeur
- 本日は貴重なお時間をいただきありがとうございます。 株式会社IT-Oneの脇田と申します。 このような素敵なイベントでお話しさせていただくのは今日が初めてで大変緊張しております。 スピーカーとしてもOpenShift管理者としても至らない点が多く恐縮ですが あたかかくご清聴いただけましたら嬉しいです。 よろしくお願いいたします。
- はじめてOpenShiftをさわりはじめてから、コンテナ監視に取り組むなかで、 困ったことや学んだこと、反省点などをお話しさせていただきます。
- 本題に入る前に改めまして、少しだけ自己紹介をさせていただきます。 2016年に新卒入社した文系出身のインフラエンジニア5年目です。 入社して初めて黒い画面やCloudサービスを触りはじめました。 Ansibleは使い始めて4年、OpenShiftは2年くらいの駆け出しエンジニアです。 ゆっくりのんびりインフラ周りや自動化技術を勉強しています。
- 私は2年前、金融系システムをコンテナアプリケーション化する検証プロジェクトに参加させていただいた際に、OpenShiftを使い始めました。 当時のプロジェクトでは、現行システムの課題を解消して、開発速度の向上や、開発/運用の低コスト化などを実現するために、 エンタープライズレベルのOpenPaaS機能を提供するOpenShiftの導入を検討しました。 そして所属するチームでは、OpenShift3.11の構築や運用管理、ミドルウェアの導入、リリースフローの整備などといったOpenShift管理作業を行っていました。 私は今別のプロジェクトにおりますが、こちらのシステムは実運用に向けて実装を進められていると伺っています。
- 検証が始まってからしばらく、チームの先輩の後ろについてOpenShiftの構築作業をみているばかりでしたが 画面をみてもわからないし、何を調べたらいいのかもわかりません。 そんななにも分からないなかで、一番最初に深くお世話になったのがOpenShiftの監視ツールです。 OpenShiftだけでなく、監視ツールのPrometheusについてもよくわからないし、何を監視したらいいかも、どうやって監視設定を変更するのかも、しっかり調べて理解する必要がありました。 OpenShift管理初心者がコンテナ監視運用にたどり着くまでに出会った高い壁について、少し冗長になってしまいますが、順番にお話しさせていただきます。
- まずはOpenShiftが分からなければ何ができるのかも、何を管理したらいいのかも見当がつきません。 そこで、OpenShiftについて基本の仕様を調べるところから始まりました。 OpenShiftはKubernetesをベースとしたコンテナオーケストレーションツールで、複数のコンテナやノードを運用管理のに便利な機能を提供してくれるツールです。 このスライドはOpenShift４時点の機能ですが、Kubernetesの基本的な機能に加えて、管理コンソールやコンテナビルドを行うことができるPaaS機能などOpenShift独自の機能も提供されています。
- 概要を調べても、OpenShiftのしくみはまだまだ理解できません。 OpenShiftの構築が終わって、実際にコンテナを動かしたときも、 よくわからないままコマンドを実行したらコンテナが増えたしステータスはRunningだしなんだかすごい！！というような感想しか出てきませんでした。 そんなところでエラーがおこったら、何が起こっているのかもどうしたらいいのかも全くわかりません。
- openshiftもkubernetesもわからないままではいられない...ということで、仕組みをまなびつつコンテナを動かし続けるなかで沢山のエラーたちと出会いました。 これを繰り返していくうちに少しはコンテナ管理の仕組みもわかってきたかな...と思います。 そうしてOpenShiftに少しなじんだころ、OpenShift上のエラー検知や原因の調査、対処をするための監視を検討することになりました。
- OpenShift3.11では、AnsiblePlaybookのインストーラを使ってクラスタを構築しますが、その際に監視機能も一緒にインストールすることができます。 インストーラを使うと、「openshift-monitoring」というプロジェクトに、PrometheusやGrafanaといった監視機能を持つコンテナがあっという間にデプロイされます。 これらのツールでは、例えば、コンテナのステータス異常を検知して管理者にアラートを通知したり、OpenShiftの状態をダッシュボードやグラフでチェックしたりといった監視を行うことができます。
- OpenShift4以降は、インストーラのオプションを有効化しなくてもデフォルトでツールが導入されていて OpenShiftのWebコンソール画面からクラスタのステータスやリソースも確認できるようになります！ 重要な情報がぱっとみてわかるので便利ですね
- でも当時の私は3.11を触っていましたので、監視ツールの最初のイメージはPrometheusのこの画面です。 この画面からいったいどうやって監視を検討したらいいのか、またわからないことが増えてしまいました。
- PrometheusやGrafanaのWebコンソールへアクセスしてみると、クラスタ監視のためのデフォルト設定がはいってましたが 初見ではやっぱり全く理解できません。 そこで、公式ドキュメントや技術書を頼りにツールや設定の理解を深めるようにいたしました。
- このスライドからは、PrometheusやGrafanaの基本的な機能について、お話しします。 メジャーなツールですので、もうご存じの方も多いかと思いますが、軽く聞き流していただけますと幸いです。
- まずは、Prometheusの機能について確認します。 PrometheusはCNCFプロジェクトに含まれるオープンソースの監視ツールで、プラグインによってKubernetesリソースをダイナミックに監視することができます。 OpenShiftのオブジェクトからも監視データを柔軟に収集することができます。 また、監視データを独自のクエリによって計算したり、アラートを設定することも可能です。
- OpenShiftでは、主にExporterと呼ばれるメトリクスを配信するためのコンテナや、Prometheusのメトリクスに対応するコンテナからデータを取得します。 そして、どのようなコンポーネントからどのようなデータを取得するかを設定しているのがServiceDiscoveryです。 このなかで、Node-exporterと呼ばれる、OpenShiftNodeのリソース監視メトリクスを配信するコンテナからデータを取得するケースについてピックアップして確認してみます。
- Prometheusは、「scrape_config」にメトリクス収集のアクセス先を設定します。 まえのスライドでもお話ししましたが、PrometheusはKubernetesのプラグインをつかうことで、IPアドレスを指定しなくてもOpenShiftのオブジェクトを特定してアクセス先に設定することができます。 このことで、コンテナが増えたり再起動したりしてIPが変わっても、設定を変更することなく監視を行うことができます。 node-exporterのせっていでは、「openshift-monitoring」プロジェクトに定義されているエンドポイントへアクセスするように設定されています。
- こうしてコンテナから取得してきたメトリクスには、複数のラベルが付与されています。 このラベルは、そのメトリクスのデータがいったいどこの何のデータにあたるのかを詳細に特定するものです。 node-exporterで配信している「CPU使用量」メトリクスの1つを見てみると、ラベルによって「1つめのCPU」の「idle」の値であることが分かります。 さらに、PrometheusからKubernetesプラグインでデータを取得した時に、kubernetesの構成情報メタデータをラベルとして付与することができます。 このようにラベルをチェックすることで、そのメトリクスがどのノードのリソース監視データであるのかを特定していきます。
- こうしたメトリクスのラベルは、同じく「scrape-config」の「relabel_configs」の設定で操作することができます。 メトリクス取得先のターゲットの変更や絞り込みなども可能で、 こちらでは、サービス名やエンドポイント名に合致するラベルを持っているターゲットにだけアクセスするような設定がされていました。
- この「scrape-config」の設定内容をたどって、Prometheusが最終的にアクセスしに行くターゲットを確認してみます 最初に、Kubernetesプラグインでエンドポイントを特定した状態では、35このエンドポイントが検出されています。 そこから、「relabel_configs」でサービス名が「node-exporter」かつエンドポイント名が「https」のラベルを持つターゲットのみKeepするよう設定がされています。 ここで、メトリクス取得さきのターゲットは2のエンドポイントに絞り込まれています。
- この設定結果は、Prometheus WebコンソールのServiceDiscoveryという項目でチェックすることができます。 Kubernetesプラグインで検出した結果が左側、relabel_configsで絞り込んだ内容が右側に表示されます。 ターゲットになっていないエンドにはDropと表示されるようになります。
- 取得先のターゲットが決まったところで、実際にターゲットからメトリクスを取得できているのかといったところも PrometheusのWebから確認します。 メトリクスが取得できていなければ、認証エラーやネットワークえらーなどのメッセージが赤文字で表示されるのですが このExporterからは正常にデータを取得できているようです。
- 監視データを取得できていることが分かったので、Prometheusから実際にデータを参照してみます。 この画面では、Prometheusのメトリクスに対応する、ラベルベースのクエリ、PromQLを実行してデータを計算しています。 PromQLは、算術、比較、論理、集計などの演算子を使ってデータの計算を行うことができます。 字が小さくて申し訳ないのですが、このクエリは、「Instance」ごとに集計したノードCPU使用率を計算しています。 ここまできてやっと、最初にわからなかった画面を使えるようになってきました。
- Prometheusには、このPromQLを使用して、2種類のルールを設定することができます。 そのひとつが「record」というもので、クエリをレコードとして定義すると、その結果を「レコード名」から参照することができるようになります。 レコードをうまく組み合わせれば、ワンライナーでかけないような複雑なクエリも、シンプルに表現でき、より細かい監視データの計算も可能になります。
- ここまでで、メトリクス収集のしくみと、PromQLやレコードの使い方を確認しました。 次のページから、Promethusにためこんだデータをアラートやダッシュボードから監視する方法を見てみます。
- 最初にPromethusのアラート設定について 比較演算を使用したPromQLで監視対象の状態を判断するルールを設定します。 この画面では、コンテナのクラッシュループバックが起きたらアラートを発砲する、ルールを確認しています。 実際にCluster上のあるコンテナがエラー状態なので、アラートルールの状態も「Failing」になります。
- アラートが発砲状態になったら、PromethusのAlertmanagerというコンテナが設定に基いてアラートを通知します。 メールやSlackなどの通知方法を選択したり通知の間隔、再通知、通知抑制、回復通知などの設定を、アラートルールのグループごとに設定することができます。 検証プロジェクトでは、別システムの監視基盤へアラートを連携するために、FluentdへWebhookでアラートを飛ばしたり、Pythonスクリプトでフォーマットの整形をはさんだりといった実装を行ていました。
- 次に、Grafanaのダッシュボードの設定について確認します。 GrafanaはPrometheusと同じくCNCFプロジェクトに含まれるオープンソースのデータ可視化ツールです。 Prometheusをデータソースとして設定し、PromQLを使用した柔軟なデータ操作を行うことができます。 ダッシュボードは様々なグラフや表を使って設定することができ、パネルごとにデータの取得も可能です。 Webコンソールから取得できて便利ではありますが、全部のデータを取得するには手間がかかるため、メトリクスデータの抽出には、PrometheusAPIを使っていました。 また、ダッシュボードの設定はJson形式でインポート/エクスポートを行うことができます。 OpenShiftのConfigmapで作成したダッシュボードはWebUIから上書きができないので、設定変更の際には、WebUIでコピー＆変更したダッシュボードのJsonをエクスポートして毎回Configmap化したりしていました。 このような手間も含めて、Grafanaに関しては運用面に反省点いくつかありました。 その反省点の一つが、ダッシュボードのフィルタリング設定です。
- Prometheusの機能について学んだうえで、「openshift-monitoring」のデフォルト設定を確認してみると、「OpenShiftのCluster管理コンポーネントを監視するための基本的な設定」が含まれていました。 業務系アプリケーションコンテナやユーザが任意で導入したミドルウェアなどは監視対象に含まれていません 既存のシステムの監視項目や、「openshift-monitoring」のデフォルト設定を参考に、監視対象について検討しました。