More Related Content
Similar to cluster-monitoringで困ったこと学んだこと (20)
cluster-monitoringで困ったこと学んだこと
- 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」だし何だかすごい!!
でもひとたびエラーが起こると、何をしたらいいのか全くわかりません
コントローラスケジューラ
ぜんぶ
おまじないの
世界
- 30. Grafanaダッシュボードの失敗…
1. Javaアプリケーションコンテナのダッシュボードを作りたい!
2. ラベルの値を「Pull Down」や「チェックリスト」として表示する機能を追加
しよう!
3. 「Pod」ラベルのリストを作りたいけど、Java以外のPod名もたくさん表示さ
れる…
4. PrometheusのJava用のScrape設定に「java_pod 」ラベルを追加
5. フィルタリングに合わせて、ダッシュボード内全パネルのPromQLに
「java_pod」追加
6. こんなことしなくても、「regex」と「query: query_result()」をくみあわせ
て、JavaPodだけ表示する「Pull Down」や「チェックリスト」を作れる
scrape-config設定
Javaのジョブ:java_podラベルあり
kube-state-metricsのジョブ:java_podラベルなし
ダッシュボード機能の理解不足
ダッシュボード設定
PromQL「java_pod」でフィルタリング
「java_pod」ラベルのないメトリクスがダッ
シュボード内に混在するとPromQLの設定が
複雑に…
ラベル設定の考慮不足
- 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
などなど
デフォルト監視項目 追加したい監視項目
Editor's Notes
- 本日は貴重なお時間をいただきありがとうございます。
株式会社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をベースとしたコンテナオーケストレーションツールで、複数のコンテナやノードを運用管理のに便利な機能を提供してくれるツールです。
このスライドはOpenShift4時点の機能ですが、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」のデフォルト設定を参考に、監視対象について検討しました。