オンプレミスのOpenShift基盤構築事例からの監視運用方法

オンプレミスのOpenShift基盤構築事例から学ぶ監視運⽤⽅法可観測性を⾼めるモニタリング／ロギング情報を既存の監視体系に連携 2023/07/28 OpenShift Lounge+ "TALKs" 〜 Ops/Monitoring編〜 Tetsushi
Ayukawa

2 ⾃⼰紹介 • Tetsushi Ayukawa (@t_sweetfish) • IBM Japan Systems
Engineering Co., Ltd.

3 Agenda • はじめに • Observability • エンタープライズ企業の監視運⽤ • モニタリング
• ロギング • まとめ

4 はじめに • オンプレミスの本番環境にRed Hat® OpenShift® Container Platform (OCP) 基盤を構築した事例を通して得られ
た知⾒をご紹介します。 • 当セッションではOCPが提供するロギングやモニタリングの機能を⽤いたOCP基盤の監視⽅法をご紹介させて頂きます。 - Observability - エンタープライズ企業の監視運⽤ - インフラノード - モニタリング - ロギング • 当セッションのポイント - エンタープライズのお客様では既存の運⽤体系があり、OCPで監視した内容をこれらの既存運⽤に合わせるための考慮が必要になります。これらを実現する実装⽅法・⼯夫についての⼀例をご紹介します。 (※)本資料は 2022年4⽉時点で得られた情報をもとに作成しています。(⼀部2023年7⽉現在の最新の情報を補⾜として追記しています。) クラウド・ネイティブのソフトウェアや製品は変⾰が早いため、参照する際は必ず最新情報をご確認ください。 (※)本セッションは個⼈の⾒解であり、所属組織の⽴場、戦略、意⾒を代表するものではありません。また、技術的な内容にも⾔及しますが、正確性を保証するものではありません。

Observability

7 Observability - 可観測性 • システムが外部提供する情報から、システムの内部状態やステータスを観測できること - 「いつ、何が、どこで起こっているのかを観測可能に保つ」こと - Observabilityを備えることで、システムの状態を正しく理解し、問題の検出やその根本原因の特定を⾏える
• Metrics - システムの状態を定量化したもの - サーバーのリソース状況（CPU使⽤率など）やサービス状況（レイテンシー、トランザクション量、エラーレートなど）といった、指標となる数値データ Observability Whitepaper https://github.com/cncf/tag-observability/blob/main/whitepaper.md • Logging - システムに起きたことを記録したもの - 各サーバーやミドルウェア、アプリケーションなどにおいて、個別のイベント（何が発⽣しているのかの情報）を表す、⼈間が読める詳細な構造化情報 • Tracing - 分散トレーシング - 複数コンポーネントにまたがるリクエスト全体の流れを呼び出しの依存関係を考慮して可視化するもの • Application Profile • Dump

8 Observability - 可観測性 • システムが外部提供する情報から、システムの内部状態やステータスを観測できること - 「いつ、何が、どこで起こっているのかを観測可能に保つ」こと - Observabilityを備えることで、システムの状態を正しく理解し、問題の検出やその根本原因の特定を⾏える
• Metrics - システムの状態を定量化したもの - サーバーのリソース状況（CPU使⽤率など）やサービス状況（レイテンシー、トランザクション量、エラーレートなど）といった、指標となる数値データ Observability Whitepaper https://github.com/cncf/tag-observability/blob/main/whitepaper.md • Logging - システムに起きたことを記録したもの - 各サーバーやミドルウェア、アプリケーションなどにおいて、個別のイベント（何が発⽣しているのかの情報）を表す、⼈間が読める詳細な構造化情報 • Tracing - 分散トレーシング - 複数コンポーネントにまたがるリクエスト全体の流れを呼び出しの依存関係を考慮して可視化するもの • Application Profile • Dump 今回の対象

9 Observability - 可観測性 Collect Metrics Monitoring Service Viewer Metrics
Setting Process System Resources Agent Monitoring Target Manage Config Collect Metrics Monitoring Service Process System Resources Monitoring Target Service Discovery Viewer / Analytics Observability Service 従来の監視クラウドネイティブな監視・既存サーバー環境とは異なり、コンテナ環境では稼働するコンテナ数や稼働するノードも動的に変化・監視対象サーバーにエージェント型の監視は困難・動的に監視を運⽤できる必要がある・監視対象に監視エージェントを導⼊し監視サーバーで監視・監視対象は動的に変化しない監視対象サーバー、アプリケーションは固定 Agentによる監視 node数、Pod数、Podの稼働するnodeも動的に変化 RHCOSにはAgentの導⼊も不可

10 Observability - 可観測性 • OpenShiftのObservability • Metrics -> OpenShift
Monitoring • Logging -> OpenShift Logging • Tracing -> OpenShift Service mesh Prometheus® Grafana® fluentd® Elasticsearch® Kibana® Jaeger® Istio® Kiali® (※1) (※2) (※1) OpenShift Monitoring OCP 4.11からはGrafanaが削除され、モニタリングのダッシュボードはOCPのコンソールに統合 OCP 4.11 Docs / リリースノート / 1.5.2.3. モニターリングスタックから削除された Grafana コンポーネント (※2) OpenShift Logging Logging 5.5からLoki OperatorおよびVectorがGA、Logging 5.6からデフォルトのコレクターがFluentdからVectorに変更 OCP 4.13 Docs / ロギング / 1. ロギングのリリースノート / 1.18. Logging 5.5 / 1.18.1. 機能拡張 OCP 4.13 Docs / ロギング / 1. ロギングのリリースノート / 1.8. Logging 5.6 / 1.8.2. 機能拡張 (※) 当資料は案件実施のOpenShift Monitoring (Prometheus, Grafana)、OpenShift Logging (EFK)の構成をもとに記載していますのでご注意ください。

11 Observability - 可観測性 • OpenShiftのObservability • Metrics -> OpenShift
Monitoring • Logging -> OpenShift Logging • Tracing -> OpenShift Service mesh Prometheus® Grafana® fluentd® Elasticsearch® Kibana® Jaeger® Istio® Kiali® (※1) (※2) 今回の対象 (※1) OpenShift Monitoring OCP 4.11からはGrafanaが削除され、モニタリングのダッシュボードはOCPのコンソールに統合 OCP 4.11 Docs / リリースノート / 1.5.2.3. モニターリングスタックから削除された Grafana コンポーネント (※2) OpenShift Logging Logging 5.5からLoki OperatorおよびVectorがGA、Logging 5.6からデフォルトのコレクターがFluentdからVectorに変更 OCP 4.13 Docs / ロギング / 1. ロギングのリリースノート / 1.18. Logging 5.5 / 1.18.1. 機能拡張 OCP 4.13 Docs / ロギング / 1. ロギングのリリースノート / 1.8. Logging 5.6 / 1.8.2. 機能拡張 (※) 当資料は案件実施のOpenShift Monitoring (Prometheus, Grafana)、OpenShift Logging (EFK)の構成をもとに記載していますのでご注意ください。

エンタープライズ企業の監視運⽤

14 エンタープライズ企業の監視運⽤ • 既存環境のモニタリング・ロギング - お客様標準の運⽤体系や監視基盤がある既存監視システム既存システム(AIX) ・プロセス監視
・リソース監視・ログ監視オペレータールーム運⽤担当者・コンソール確認・アラート通知エージェント Server A AIX アプリログエージェント Server B AIX アプリログエージェント Server C AIX アプリログ既存システム(Linux) エージェント Server D Linux アプリログエージェント Server E Linux アプリログエージェント Server F Linux アプリログその他の運⽤・ログメンテナンス・ログ保管・性能情報レポートなど運⽤担当者が事前に決められた運⽤⼿順に従って対応 (例) criticalのものは即時対応 warningは翌営業⽇対応など (例) ローカルxx⽇保管リモートxx年保管⽉次性能情報レポート提出など

15 エンタープライズ企業の監視運⽤ worker node (RHCOS) openshift-state-metrics kube-state-metrics node-exporter kube-apiserver node-exporter
node-exporter コアコンポーネントコアコンポーネントコアコンポーネント PV アプリログ *-exporter OpenShift (Kubernetes) Alertmanager Prometheus (default) Grafana (default) Prometheus (user) Grafana (user追加) Thanos Querier Thanos Ruler openshift- monitoring (default) openshift- user-workload- monitoring infra node (RHCOS) master node (RHCOS) アプリ Pod システムログ⽤の journald コンテナーログ⽤の /var/log/containers/*.log fluentd fluentd fluentd Elasticsearch Kibana OpenShiftクラスター ocコマンド・ノード監視・Pod監視・リソース監視 (CPU、メモリー、ディスク容量(OS)、PV使⽤率) ・アプリ監視・ログ監視・リソース監視 (CPU、メモリー) 基盤担当者 OpenShiftの提供する「モニタリング」と「ロギング」の機能で Observabilityがある︕ Prometheus Adapter ® ® (※) OCP 4.10の場合

node-exporter コアコンポーネントコアコンポーネントコアコンポーネント PV アプリログ *-exporter OpenShift (Kubernetes) Alertmanager Prometheus (default) Grafana (default) Prometheus (user) Grafana (user追加) Thanos Querier Thanos Ruler openshift- monitoring (default) openshift- user-workload- monitoring infra node (RHCOS) master node (RHCOS) アプリ Pod システムログ⽤の journald コンテナーログ⽤の /var/log/containers/*.log fluentd fluentd fluentd Elasticsearch Kibana OpenShiftクラスター ocコマンド・ノード監視・Pod監視・リソース監視 (CPU、メモリー、ディスク容量(OS)、PV使⽤率) ・アプリ監視・ログ監視・リソース監視 (CPU、メモリー) 基盤担当者 OpenShiftの提供する「モニタリング」と「ロギング」の機能で Observabilityがある︕ ・・・と本当に⾔えるのかどうか︖ Prometheus Adapter (※) OCP 4.10の場合

node-exporter コアコンポーネントコアコンポーネントコアコンポーネント PV アプリログ *-exporter OpenShift (Kubernetes) Alertmanager Prometheus (default) Grafana (default) Prometheus (user) Grafana (user追加) Thanos Querier Thanos Ruler openshift- monitoring (default) openshift- user-workload- monitoring infra node (RHCOS) master node (RHCOS) アプリ Pod システムログ⽤の journald コンテナーログ⽤の /var/log/containers/*.log fluentd fluentd fluentd Elasticsearch Kibana OpenShiftクラスター ocコマンド・ノード監視・Pod監視・リソース監視 (CPU、メモリー、ディスク容量(OS)、PV使⽤率) ・アプリ監視・ログ監視・リソース監視 (CPU、メモリー) 基盤担当者既存監視システムオペレータールーム運⽤担当者 Slackはない監視基盤以外からメールは送信不可運⽤担当者が⾒るのはオペレータールームの既存の監視基盤のコンソールお客様の運⽤体系に合った監視基盤に連携して初めて「Observabilityがある」といえる連携できていない Prometheus Adapter (※) OCP 4.10の場合

node-exporter コアコンポーネントコアコンポーネントコアコンポーネント PV アプリログ *-exporter OpenShift (Kubernetes) Alertmanager Prometheus (default) Grafana (default) Prometheus (user) Grafana (user追加) Thanos Querier Thanos Ruler openshift- monitoring (default) openshift- user-workload- monitoring 運⽤管理サーバー (Linux) infra node (RHCOS) master node (RHCOS) 既存監視システムアプリ Pod システムログ⽤の journald コンテナーログ⽤の /var/log/containers/*.log fluentd fluentd fluentd オペレータールーム運⽤担当者スクリプト Alertmanager API Thanos API Elasticsearch API fluentd fluentd (podman) Elasticsearch Kibana スクリプトスクリプトスクリプトスクリプト OpenShiftクラスター監視⽤ログ監視⽤ログ監視⽤ログ監視⽤ログ性能情報レポート⽤ (基盤) 監視⽤ログエ " ジ $ ント ocコマンド・ログ監視(アプリ) ・ノード監視・Pod監視・リソース監視 (CPU、メモリー、ディスク容量(OS)、PV使⽤率) ・アプリ監視・ログ監視・リソース監視 (CPU、メモリー) 各種API、ocコマンドカスタム・スクリプトでログファイルを出⼒し、既存監視基盤のエージェントで監視し、お客様標準の監視基盤に連携 Thanos API Prometheus Adapter (※) OCP 4.10の場合

20 モニタリング(全体図) (※) OCP 4.10の場合

21 監視項⽬監視対象監視項⽬監視⽅法 ocコマンド or メトリクス備考 Application
アプリ監視(アプリケーション固有メトリクス) Thanos API (user-workload- monitoring) Applicationが公開するメトリクス Applicationによる Kubernetes クラスター監視(Cluster Operator) ocコマンド oc get co (oc get clusteroperator) 「AVAILABLE」列が「False」、「PROGRESSING」列が「True」、「DEGRADED」列が「True」のいずれかの場合に異常ノード監視(Nodeステータス) ocコマンド oc get node 「Status」列が「NotReady」の場合に異常 Pod監視(Podステータス) ocコマンド oc get pod 「Status」列が「Running」かつ「READY」列の分⺟(Pod内コンテナ数)と分⼦(正常起動したコンテナ数)が⼀致している場合に正常リソース監視(ディスク使⽤率 (PV) Thanos API kubelet_volume_stats_used_bytes kubelet_volume_stats_capacity_bytes node、pvc、namespace単位のディスク使⽤率(%)を計算 (この例ではlocal-storage operatorでlocalvolumeを作成し、各nodeに割り当てられた仮想ディスクをPVとして使⽤しているため、「node」単位にも表⽰) Node リソース監視(CPU使⽤率) ocコマンド oc adm top node node単位の「CPU%」列の値 (より詳細なメトリクスを監視したい場合はThanos APIも検討) リソース監視(メモリー使⽤率) ocコマンド oc adm top node node単位の「MEMORY%」列の値 (より詳細なメトリクスを監視したい場合はThanos APIも検討) リソース監視(ディスク使⽤率 (OS)) Thanos API node_filesystem_avail_bytes node_filesystem_size_bytes node、(RHCOSの)mountpoint単位のディスク使⽤率(%)を計算 ※他の項⽬(I/Oなど)や、より詳細な項⽬を監視する要件がある場合は、該当項⽬のメトリクスを調査し、Thanos API経由でメトリクスを取得して監視することを検討 ※今後のスクリプトのメンテナンス性も考慮し、ocコマンドで取得可能な項⽬は、Thanos API経由でメトリクスを取得せず、ocコマンドで情報を取得

アプリ監視(アプリケーション固有メトリクス) Thanos API (user-workload- monitoring) Applicationが公開するメトリクス Applicationによる Kubernetes クラスター監視(Cluster Operator) ocコマンド oc get co (oc get clusteroperator) 「AVAILABLE」列が「False」、「PROGRESSING」列が「True」、「DEGRADED」列が「True」のいずれかの場合に異常ノード監視(Nodeステータス) ocコマンド oc get node 「Status」列が「NotReady」の場合に異常 Pod監視(Podステータス) ocコマンド oc get pod 「Status」列が「Running」かつ「READY」列の分⺟(Pod内コンテナ数)と分⼦(正常起動したコンテナ数)が⼀致している場合に正常リソース監視(ディスク使⽤率 (PV) Thanos API kubelet_volume_stats_used_bytes kubelet_volume_stats_capacity_bytes node、pvc、namespace単位のディスク使⽤率(%)を計算 (この例ではlocal-storage operatorでlocalvolumeを作成し、各nodeに割り当てられた仮想ディスクをPVとして使⽤しているため、「node」単位にも表⽰) Node リソース監視(CPU使⽤率) ocコマンド oc adm top node node単位の「CPU%」列の値 (より詳細なメトリクスを監視したい場合はThanos APIも検討) リソース監視(メモリー使⽤率) ocコマンド oc adm top node node単位の「MEMORY%」列の値 (より詳細なメトリクスを監視したい場合はThanos APIも検討) リソース監視(ディスク使⽤率 (OS)) Thanos API node_filesystem_avail_bytes node_filesystem_size_bytes node、(RHCOSの)mountpoint単位のディスク使⽤率(%)を計算 ※他の項⽬(I/Oなど)や、より詳細な項⽬を監視する要件がある場合は、該当項⽬のメトリクスを調査し、Thanos API経由でメトリクスを取得して監視することを検討 ※今後のスクリプトのメンテナンス性も考慮し、ocコマンドで取得可能な項⽬は、Thanos API経由でメトリクスを取得せず、ocコマンドで情報を取得 ocコマンド

23 モニタリング(ocコマンド) (※) OCP 4.10の場合

24 モニタリング(ocコマンド) [root@bastion-01 ~]# oc get co NAME VERSION AVAILABLE
PROGRESSING DEGRADED SINCE MESSAGE authentication 4.10.6 True False False 2d17h baremetal 4.10.6 True False False 10d cloud-controller-manager 4.10.6 True False False 10d (略) [root@bastion-01 ~]# [root@bastion-01 ~]# oc get node NAME STATUS ROLES AGE VERSION infra-01 Ready worker 10d v1.23.5+b0357ed infra-02 Ready worker 10d v1.23.5+b0357ed infra-03 Ready worker 10d v1.23.5+b0357ed master-01 Ready master 10d v1.23.5+b0357ed master-02 Ready master 10d v1.23.5+b0357ed master-03 Ready master 10d v1.23.5+b0357ed worker-01 NotReady worker 10d v1.23.5+b0357ed worker-02 Ready worker 10d v1.23.5+b0357ed [root@bastion-01 ~]# [root@bastion-01 ~]# oc get pod -A NAMESPACE NAME READY STATUS RESTARTS AGE openshift-apiserver-operator openshift-apiserver-operator-5b68b48c76-7dr29 1/1 Running 2 9d openshift-apiserver apiserver-644c5b6558-92cdm 2/2 Running 0 7d17h openshift-apiserver apiserver-644c5b6558-dqmdn 2/2 Running 0 7d17h openshift-apiserver apiserver-644c5b6558-scg78 2/2 Running 0 7d17h openshift-authentication-operator authentication-operator-7cd5cc55dd-8pr7j 1/1 Running 4 9d 「AVAILABLE」列が「False」、「PROGRESSING」列が「True」、「DEGRADED」列が「True」のいずれかの場合に異常「Status」列が「NotReady」の場合に異常「Status」列が「Running」のことだけでなく、「READY」列の分⺟(Pod内コンテナ数)と分⼦(正常起動したコンテナ数)が⼀致していることも確認クラスター監視(cluster opeerator) ノード監視(Nodeステータス) Pod監視(Podステータス)

25 モニタリング(ocコマンド) [root@bastion-01 ~]# oc adm top node NAME CPU(cores)
CPU% MEMORY(bytes) MEMORY% infra-01 538m 7% 5863Mi 7% infra-02 314m 4% 5458Mi 6% infra-03 144m 1% 2129Mi 2% master-01 461m 13% 7112Mi 65% master-02 489m 13% 7548Mi 69% master-03 442m 12% 6532Mi 60% worker-02 120m 3% 1313Mi 8% worker-01 <unknown> <unknown> <unknown> <unknown> [root@bastion-01 ~]# node単位で「CPU%」列の値、「MEMORY%」の値を取得リソース監視(CPU使⽤率、メモリー使⽤率) 値が取得できない場合のエラーハンドリングなども必要 (例) 上述で取得した値を元に、カスタム・スクリプトで以下のような監視⽤のログファイルを作成 YYYYMMDD hhmmss Info nodeのステータスが正常 node name: infra-01 status: Ready YYYYMMDD hhmmss Warning nodeのステータスが異常 node name: worker-01 status: NotReady YYYYMMDD hhmmss Critical nodeのCPU使⽤率がCritical node name: infra-02 CPU使⽤率: 95% 閾値(Critical): 80% ・・・など (例) cronまたはジョブスケジューラーなどで1分間隔でカスタム・スクリプトを実施 1回閾値を超えるだけでアラート発報しないように直近5回中x回超えたらCritical/Warningのアラートにする・・・など要件に応じたスクリプトを作成

アプリ監視(アプリケーション固有メトリクス) Thanos API (user-workload- monitoring) Applicationが公開するメトリクス Applicationによる Kubernetes クラスター監視(Cluster Operator) ocコマンド oc get co (oc get clusteroperator) 「AVAILABLE」列が「False」、「PROGRESSING」列が「True」、「DEGRADED」列が「True」のいずれかの場合に異常ノード監視(Nodeステータス) ocコマンド oc get node 「Status」列が「NotReady」の場合に異常 Pod監視(Podステータス) ocコマンド oc get pod 「Status」列が「Running」かつ「READY」列の分⺟(Pod内コンテナ数)と分⼦(正常起動したコンテナ数)が⼀致している場合に正常リソース監視(ディスク使⽤率 (PV) Thanos API kubelet_volume_stats_used_bytes kubelet_volume_stats_capacity_bytes node、pvc、namespace単位のディスク使⽤率(%)を計算 (この例ではlocal-storage operatorでlocalvolumeを作成し、各nodeに割り当てられた仮想ディスクをPVとして使⽤しているため、「node」単位にも表⽰) Node リソース監視(CPU使⽤率) ocコマンド oc adm top node node単位の「CPU%」列の値 (より詳細なメトリクスを監視したい場合はThanos APIも検討) リソース監視(メモリー使⽤率) ocコマンド oc adm top node node単位の「MEMORY%」列の値 (より詳細なメトリクスを監視したい場合はThanos APIも検討) リソース監視(ディスク使⽤率 (OS)) Thanos API node_filesystem_avail_bytes node_filesystem_size_bytes node、(RHCOSの)mountpoint単位のディスク使⽤率(%)を計算 ※他の項⽬(I/Oなど)や、より詳細な項⽬を監視する要件がある場合は、該当項⽬のメトリクスを調査し、Thanos API経由でメトリクスを取得して監視することを検討 ※今後のスクリプトのメンテナンス性も考慮し、ocコマンドで取得可能な項⽬は、Thanos API経由でメトリクスを取得せず、ocコマンドで情報を取得 Thanos API

27 モニタリング(OpenShift) (※) OCP 4.10の場合

28 モニタリング(OpenShift) • Thanos API経由でのメトリクス取得の流れ Service Accountの作成 Thanosに参照権限のあるRoleまたはClusterRoleの作成 Service AccountにRoleBindingまたはClusterRoleBinding
Thanos Querierのホスト名を取得 Thanos APIからメトリクスを取得取得したメトリクスをログファイルに出⼒するスクリプトで監視⽤ログファイルを作成カスタム・スクリプトの事前準備監視項⽬のメトリクス取得監視⽤ログファイルの作成

29 モニタリング(OpenShift) [user01@bastion-001 ~]$ oc project liberty-test Already on project
"liberty-test" on server "https://api.test-1.example.com:6443". [user01@bastion-001 ~]$ [user01@bastion-001 ~]$ oc create sa script-user serviceaccount/script-user created [user01@bastion-001 ~]$ Service Accountの作成、RoleまたはClusterRoleの付与 - 今回の例では作成したService Accountにcluster-admin roleを付与 - 管理者ユーザーでクラスターにログインして実施 Service Accountの作成 [user01@bastion-001 ~]$ oc adm policy add-cluster-role-to-user cluster-admin -z script-user clusterrole.rbac.authorization.k8s.io/cluster-admin added: "script-user" [user01@bastion-001 ~]$ ClusterRoleBinding (cluster-admin roleの付与) 実際は必要最⼩限なRoleのみを付与することを検討

30 モニタリング(OpenShift) Service Accountの作成、Roleの付与 [user01@bastion-001 ~]$ token=$(oc serviceaccounts get-token script-user)
[user01@bastion-001 ~]$ echo ${token} xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [user01@bastion-001 ~]$ [user01@bastion-001 ~]$ oc login --token ${token} https://api.test-1.example.com:6443 Logged into "https://api.test-1.example.com:6443" as "system:serviceaccount:liberty-test:script-user" using the token provided. You have access to 67 projects, the list has been suppressed. You can list all projects with ' projects' Using project "liberty-test". [user01@bastion-001 ~]$ [user01@bastion-001 ~]$ oc whoami system:serviceaccount:liberty-test:script-user [user01@bastion-001 ~]$ Service AccountのtokenでOCPクラスターにログイン Thanos Querierのホスト名の取得 [user01@bastion-001 ~]$ thanos_querier_host=$(oc get route -n openshift-monitoring thanos-querier -o jsonpath="{.spec.host}") [user01@bastion-001 ~]$ [user01@bastion-001 ~]$ echo ${thanos_querier_host} thanos-querier-openshift-monitoring.apps.test-1.example.com [user01@bastion-001 ~]$ Thanos Querierのホスト名取得 (※1) サービスアカウントトークンの取得以下の例 (oc serviceaccounts get-token)はOCP 4.11以前のやり⽅となり、今後は使⽤できない OCP 4.11以降でのサービスアカウントトークンの取得や対応⽅法ついては以下を参照 KB / Getting the authentication token for a Service Account in OpenShift KB / How to create kubeconfig for a certain serviceaccount in OpenShift 4.11? OCP 4.13 Docs / 認証および認可 / 11. Using service accounts in applications / 11.2.3. ⾃動⽣成されるサービスアカウントトークンシークレット (※1)

31 モニタリング(OpenShift) Thanos APIからメトリクスを取得 (例)リソース監視(ディスク使⽤率(OS)) メトリクス: node_filesystem_avail_bytes (ノードのファイルシステムの使⽤可能な容量) node、(RHCOSの)mountpoint単位でクエリーを実施 sum(node_filesystem_avail_bytes)by(instance,mountpoint)

32 モニタリング(OpenShift) Thanos APIからメトリクスを取得 (例)リソース監視(ディスク使⽤率(PV)) メトリクス: kubelet_volume_stats_used_bytes (PVCのディスク使⽤量) node、pvc、namespace単位でクエリーを実施 sum(kubelet_volume_stats_used_bytes)by(node,persistentvolumeclaim,namespace)

33 モニタリング(OpenShift) Thanos APIからメトリクスを取得 [user01@bastion-001 ~]$ curl_auth="Authorization: Bearer $(oc whoami
-t)" [user01@bastion-001 ~]$ curl_option="-k -s -X GET -H" [user01@bastion-001 ~]$ curl ${curl_option} "${curl_auth}" https://${thanos_querier_host}/api/v1/query?query="sum(node_filesystem_size_bytes)by(instance,mountpoint)" | jq -r { "status": "success", "data": { "resultType": "vector", "result": [ { "metric": { "instance": "infra-003", "mountpoint": "/sysroot" }, "value": [ 1649581220.165, "63859306496" ] }, (略) [user01@bastion-001 ~]$ curl ${curl_option} "${curl_auth}" https://${thanos_querier_host}/api/v1/query?query="sum(node_filesystem_size_bytes)by(instance,mountpoint)" | jq -r '.data.result[] | select(.metric.mountpoint == "/sysroot") | {instance:.metric.instance, value:.value[1]}' { "instance": "master-002", "value": "42384470016" } { "instance": "worker-002", "value": "42384470016" } { "instance": "worker-001", "value": "42384470016" } 略 (例)リソース監視(ディスク使⽤率(OS)) メトリクス: node_filesystem_size_bytes (ノードのファイルシステムの容量) node、(RHCOSの)mountpoint単位でクエリーを実施 Thanos APIでメトリクスを取得 jqなどで必要な情報をフィルターして取得

34 モニタリング(OpenShift) 取得したメトリクスをログファイルに出⼒するスクリプトで監視⽤ログファイルを作成 (例) 前ページまでで取得した値を元に、カスタム・スクリプトで以下のような監視⽤のログファイルを作成 YYYYMMDD hhmmss Info ディスク使⽤率が正常 node:
infra-01 mountpoint: /sysroot ディスク使⽤率 10% YYYYMMDD hhmmss Warning ディスク使⽤率が異常 node: infra-02 mountpoint: /sysroot ディスク使⽤率 83% 閾値(警告): 80% YYYYMMDD hhmmss Critical PVC使⽤率が異常 node: worker-01 PVC: liberty-test-xxxxx ディスク使⽤率 95%. 閾値(Critical):90% ・・・など

アプリ監視(アプリケーション固有メトリクス) Thanos API (user-workload- monitoring) Applicationが公開するメトリクス Applicationによる Kubernetes クラスター監視(Cluster Operator) ocコマンド oc get co (oc get clusteroperator) 「AVAILABLE」列が「False」、「PROGRESSING」列が「True」、「DEGRADED」列が「True」のいずれかの場合に異常ノード監視(Nodeステータス) ocコマンド oc get node 「Status」列が「NotReady」の場合に異常 Pod監視(Podステータス) ocコマンド oc get pod 「Status」列が「Running」かつ「READY」列の分⺟(Pod内コンテナ数)と分⼦(正常起動したコンテナ数)が⼀致している場合に正常リソース監視(ディスク使⽤率 (PV) Thanos API kubelet_volume_stats_used_bytes kubelet_volume_stats_capacity_bytes node、pvc、namespace単位のディスク使⽤率(%)を計算 (この例ではlocal-storage operatorでlocalvolumeを作成し、各nodeに割り当てられた仮想ディスクをPVとして使⽤しているため、「node」単位にも表⽰) Node リソース監視(CPU使⽤率) ocコマンド oc adm top node node単位の「CPU%」列の値 (より詳細なメトリクスを監視したい場合はThanos APIも検討) リソース監視(メモリー使⽤率) ocコマンド oc adm top node node単位の「MEMORY%」列の値 (より詳細なメトリクスを監視したい場合はThanos APIも検討) リソース監視(ディスク使⽤率 (OS)) Thanos API node_filesystem_avail_bytes node_filesystem_size_bytes node、(RHCOSの)mountpoint単位のディスク使⽤率(%)を計算 ※他の項⽬(I/Oなど)や、より詳細な項⽬を監視する要件がある場合は、該当項⽬のメトリクスを調査し、Thanos API経由でメトリクスを取得して監視することを検討 ※今後のスクリプトのメンテナンス性も考慮し、ocコマンドで取得可能な項⽬は、Thanos API経由でメトリクスを取得せず、ocコマンドで情報を取得 Thanos API

36 モニタリング(アプリケーション) (※) OCP 4.10の場合

37 モニタリング(アプリケーション) • Thanos API経由でアプリケーション固有のメトリクス取得の流れユーザー定義ワークロード・モニタリングの設定(ConfigMap) アプリケーション側でメトリクスの公開 ServiceMonitorの設定 Thanos Querierのホスト名を取得
Thanos APIからメトリクスを取得取得したメトリクスをログファイルに出⼒するスクリプトで監視⽤ログファイルを作成アプリケーションのメトリクスの公開監視項⽬のメトリクス取得監視⽤ログファイルの作成 OCP 4.10 Docs / モニタリング / 2. モニタリングスタックの設定 OCP 4.10 Docs / モニタリング / 4. ユーザー定義プロジェクトのモニタリングの有効化 OCP 4.10 Docs / モニタリング / 6. メトリクスの管理ユーザー定義ワークロードの有効化 Prometheus (user) に連携 ※Thanos APIでメトリクスを取得するスクリプトを作ることまではせずに、ユーザーが導⼊したGrafanaでダッシュボードを作成してアプリ固有のメトリクスを参照するだけにする、などは運⽤の要件に応じて対応を検討

38 モニタリング(アプリケーション) ユーザー定義ワークロード・モニタリングの設定(ConfigMap) apiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config
namespace: openshift-user-workload-monitoring data: config.yaml: | enableUserWorkload: true prometheusOperator: nodeSelector: node-role.kubernetes.io/infra: "" prometheus: retention: 24h nodeSelector: node-role.kubernetes.io/infra: "" volumeClaimTemplate: spec: storageClassName: local-prometheus-user resources: requests: storage: 40Gi ユーザー定義ワークロード・モニタリングConfigmapの設定例以下の⼿順に従ってユーザー定義のワークロード・モニタリングを有効化する OCP 4.10 Docs / モニタリング / 2. モニタリングスタックの設定 OCP 4.10 Docs / モニタリング / 4. ユーザー定義プロジェクトのモニタリングの有効化 thanosRuler: nodeSelector: node-role.kubernetes.io/infra: "" volumeClaimTemplate: spec: storageClassName: local-thanosruler resources: requests: storage: 10Gi (例)ユーザー定義ワークロード・モニタリングを有効化し、Prometheus (user)、 ThanosRulerを導⼊ (例としてインフラノードで稼働させPVも使⽤する設定も追加)

39 モニタリング(アプリケーション) アプリケーション側でメトリクスの公開 server.xmlの設定例アプリケーション側でメトリクスの公開するよう設定する (例) libertyの場合は、server.xmlにフィチャーを追加するだけでliberty固有のメトリクスが公開 - mpMetrics-3.0フィーチャー(or 1.1)
+ monitor-1.0フィーチャー WebSphere Liberty on OpenShift Container Platform 利⽤ガイド / Liberty関連メトリクスの取得 WebSphere Liberty on OpenShift Container Platform 利⽤ガイド ~ Helm編 ~ / 7. モニタリング <featureManager> <feature>mpMetrics-3.0</feature> <feature>monitor-1.0</feature> </featureManager> <mpMetrics authentication="false"/> 「mpMetrics-3.0」と「monitor-1.0」フィーチャーの追加 mpMetricsの項⽬で、authenticationをfalseに指定することで、 Prometheus側でメトリクスを取得することを許容 Podの/metricsにアクセスするとメトリクス情報が取得可能 [user01@bastion-001 ~]$ oc rsh -n liberty-test mylibertyapp-ibm- websphe-0 curl http://localhost:9080/metrics # TYPE base_gc_total counter # HELP base_gc_total Displays the total number of collections that have occurred. This attribute lists -1 if the collection count is undefined for this collector. base_gc_total{name="global"} 15 base_gc_total{name="scavenge"} 67 # TYPE base_cpu_systemLoadAverage gauge (略)

40 モニタリング(アプリケーション) ServiceMonitorの設定 Prometheusがアプリケーション固有のメトリクスを取得するためにServiceMonitorリソースを作成する ServiceMonitorとServiceはラベルで紐付けする OCP 4.10 Docs / モニタリング
/ 6. メトリクスの管理アプリケーションのServiceの例 apiVersion: v1 kind: Service metadata: (略) labels: app: mylibertyapp-ibm-websphe (略) spec: clusterIP: 172.30.246.143 ports: - name: http port: 9080 protocol: TCP targetPort: 9080 selector: app: mylibertyapp-ibm-websphe sessionAffinity: None type: ClusterIP アプリケーションのServiceに紐づくServiceMonitorリソースを作成 apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: libertymonitor namespace: liberty-test spec: endpoints: - port: http path: /metrics interval: 30s selector: matchLabels: app: mylibertyapp-ibm-websphe 9080ポートのServiceとラベルで紐付けメトリクスをスクレイプするパスや間隔を指定

41 モニタリング(Alertmanager) (※) OCP 4.10の場合

42 モニタリング(Alertmanager) • OpenShift Monitoringのアラートルールソース「プラットフォーム」レベルのアラートルールは、デフォルトの OpenShift Container Platform プロジェクトにのみ関連し修正不可
ソース「User」のユーザー定義のワークロードアラートルールはユーザーによって定義可能多くのアラートルールが事前定義

43 モニタリング(Alertmanager) Alertmanagerのホスト名の取得 [user01@bastion-001 ~]$ alertmanager_host=$(oc get route -n openshift-monitoring
alertmanager-main -o jsonpath="{.spec.host}") [user01@bastion-001 ~]$ [user01@bastion-001 ~]$ echo ${alertmanager_host} alertmanager-main-openshift-monitoring.apps.test-1.example.com [user01@bastion-001 ~]$ Alertmanagerのホスト名取得

44 モニタリング(Alertmanager) Alertmanager APIからアラートを取得 [user01@bastion-001 ~]$ curl_auth="Authorization: Bearer $(oc whoami
-t)" [user01@bastion-001 ~]$ curl_option="-k -s -X GET -H" [user01@bastion-001 ~]$ curl ${curl_option} "${curl_auth}" https://${alertmanager_host}/api/v2/alerts | jq -r [ { "annotations": { "message": "Alerts are not configured to be sent to a notification system, meaning that you may not be notified in a timely fashion when important failures occur. Check the OpenShift documentation to learn how to configure notifications with Alertmanager." }, "endsAt": "2022-04-11T04:58:06.662Z", "fingerprint": "14298351083980ef", "receivers": [ { "name": "Default" } ], "startsAt": "2022-04-11T03:35:36.662Z", "status": { "inhibitedBy": [], "silencedBy": [], "state": "active" }, "updatedAt": "2022-04-11T04:54:06.784Z", "generatorURL": "https://prometheus-k8s-openshift-monitoring.apps.test-1.example.com/graph?g0.expr=cluster%3Aalertmanager_routing_enabled%3Amax+%3D%3D+0&g0.tab=1", "labels": { "alertname": "AlertmanagerReceiversNotConfigured", "prometheus": "openshift-monitoring/k8s", "severity": "warning" } }, { "annotations": { "message": "Job openshift-logging/elasticsearch-im-audit-1649647800 failed to complete." }, (略) Alertmanager APIでメトリクスを取得

45 モニタリング(Alertmanager) Alertmanager APIからアラートを取得 $ curl ${curl_option} "${curl_auth}" https://${alertmanager_host}/api/v2/alerts?filter="{severity="warning"}" |
jq -r $ curl ${curl_option} "${curl_auth}" https://${alertmanager_host}/api/v2/alerts?filter="{alertname="KubeJobFailed"}" | jq -r (例)アラート名、重⼤度などでフィルター [user01@bastion-001 ~]$ curl ${curl_option} "${curl_auth}" https://${alertmanager_host}/api/v2/alerts | jq -r '.[] | [.labels.alertname, .labels.severity, .labels.namespace, .labels.pod] | @csv' | sed "s/¥"//g" AlertmanagerReceiversNotConfigured,warning,, KubeJobFailed,warning,openshift-logging,kube-state-metrics-68778b958b-w2wbr KubeJobFailed,warning,openshift-logging,kube-state-metrics-68778b958b-w2wbr KubeJobFailed,warning,openshift-logging,kube-state-metrics-68778b958b-w2wbr (略) [user01@bastion-001 ~]$ (例)CSVに変換しアラートから必要な情報のみ取得 (例) 上述で取得した値を元に、カスタム・スクリプトで監視⽤のログファイルを作成 YYYYMMDD hhmmss Warning xxxxxxxxxx alertname: xxxxx sevirity: warnint namespace: xxxxxx pod: xxxxxxx ・・・など

46 (補⾜)性能情報収集

47 (補⾜)性能情報収集 • 性能情報収集レポート - (例)既存の環境(AIX、Linux)などで各OS毎の性能情報を、⽇次、⽉次でグラフにして提出 - nmon、vmstatなどでcpu、memory、disk usageなどのデータを取得してグラフ作成 -
障害時の問題判別や傾向分析 etc • OCP環境での作成⽅法 - Grafanaコンソールからcsvエクスポート - データ⻑期保管していないため⻑期のレポートの作成は難しい - 表⽰期間が⻑いとサンプリングレートが⻑くなる - Thanos APIから性能情報をAPI経由で取得し、csvに書き出すスクリプトを作成 - cronやジョブスケジューラーで(⽇次などで)定期実⾏ - 取得された(⽇次などの)csvファイルからExcelでグラフを作成 - Qiita / Prometheus Metrics の利⽤（ CPU by Node ） - (この記事ではPrometheus APIを使⽤しているが、Thanos APIに置き換えても⼿順は同じ) Thanos API経由で取得したCPU関連のメトリクスからグラフを作成 (この例は⽇次のグラフ) (iowait, system, user, idleの値でグラフ化) 同様の⽅法で、Memor使⽤率、ディスク使⽤率(OS)、PV使⽤率などのグラフも作成可能

49 監視項⽬監視対象監視項⽬監視⽅法 index 備考ログログ監視(システムログ) Elasticsearch
API 各node(RHCOS)のシステムログ⽤の journald ログ監視(コンテナログ)(infra) Elasticsearch API infrastructure (infra) 各node(RHCOS)のコンテナーログ⽤の /var/log/containers/*.log インフラストラクチャー・コンポーネントは、openshift*、 kube*、または default プロジェクトで実⾏される Pod で⽣成されるログログ監視(コンテナログ)(app) Elasticsearch API application 各node(RHCOS)のコンテナーログ⽤の /var/log/containers/*.log インフラストラクチャー・コンポーネント以外のユーザーアプリケーションのPodで⽣成されるログログ監視(アプリログファイル) fluentd(side- car) アプリケーション固有のPod内のログファイルの監視アプリPodのサイドカーとしてfluentdのコンテナを導⼊し、運⽤管理サーバーなどの別途Linuxサーバーに導⼊したfluentdにログを転送

51 ロギング(OpenShift) (※) OCP 4.10の場合

52 ロギング(OpenShift) • OpenShift Logging インスタンスの構成 collection (fluentd)、logStore (elasticsearch)、visualization (kibana)の設定
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: "openshift-logging" spec: managementState: "Managed" logStore: type: "elasticsearch" retentionPolicy: application: maxAge: 1d infra: maxAge: 1d audit: maxAge: 1d elasticsearch: nodeCount: 3 nodeSelector: node-role.kubernetes.io/infra: "" storage: storageClassName: local-elasticsearch size: 80G redundancyPolicy: "SingleRedundancy" Cluster Loggingインスタンスのカスタムリソースの設定例 visualization: type: "kibana" kibana: replicas: 1 nodeSelector: node-role.kubernetes.io/infra: "" curation: type: "curator" curator: nodeSelector: node-role.kubernetes.io/infra: "" schedule: "30 3 * * *" collection: logs: type: "fluentd" fluentd: {} infra、application、auditのindexのログの保持期間 nodeCount: 3、singleRedundancy 各インデックスのプライマリーシャードのコピーを1 つ作成し、1台の耐障害性を保証 ※デフォルトではauditのログは Elasticsearchに転送されない logStore、visualization、collectionのそれぞれで必要に応じて、limit、requestの値もチューニンングする

53 ロギング(OpenShift) • ログの可視化(Kibana) indexがinfraのログの表⽰フィルターを追加、または検索フィールドに検索⽂字を⼊れて必要なログを検索ログに含まれるフィールドの中で右下のログの列として表⽰したいものを指定することも可能
indexが「infra*」のものを表⽰

54 ロギング(OpenShift) • ログの可視化(Kibana) indexがappのログの表⽰フィルターを追加、または検索フィールドに検索⽂字を⼊れて必要なログを検索ログに含まれるフィールドの中で右下のログの列として表⽰したいものを指定することも可能
indexが「app*」のものを表⽰

55 ロギング(OpenShift) • Elasticsearch API経由でのログ取得の流れ Service Accountの作成 Elasticsearchに参照権限のあるRoleまたはClusterRoleの作成 Service AccountにRoleBindingまたはClusterRoleBinding
Elasticsearchのrouteの公開とホスト名を取得 Elasticsearch APIからログを取得取得したログをログファイルに出⼒するスクリプトで監視⽤ログファイルを作成カスタム・スクリプトの事前準備監視対象のログの取得監視⽤(保管⽤)ログファイルの作成 OCP 4.10 Docs / ロギング / 4.3.9. ログストアサービスのルートとしての公開

56 ロギング(OpenShift) Elasticsearchのrouteの公開とホスト名を取得 [user01@bastion-001 ~]$ elasticsearch_host=$(oc get route elasticsearch -n
openshift-logging -o jsonpath={.spec.host}) [user01@bastion-001 ~]$ [user01@bastion-001 ~]$ echo ${elasticsearch_host} elasticsearch-openshift-logging.apps.test-1.example.com [user01@bastion-001 ~]$ Elasticsearchのホスト名取得以下の⼿順に従ってElasticsearchのrouteを公開 OCP 4.10 Docs / ロギング / 4. ロギングデプロイメントの設定 / 4.3. ログストアの設定 / 4.3.9. ログストアサービスのルートとしての公開

57 ロギング(OpenShift) Elasticsearch APIからログを取得 token=$(oc serviceaccounts get-token script-user -n <sa
namespace>) elasticsearch_host=$(oc get route elasticsearch -n openshift-logging -o jsonpath={.spec.host}) start_date=$(date -d now "+%Y-%m-%dT%H:%M:%S+09:00") end_date=$(date -d "${date_to} 1 min ago" "+%Y-%m-%dT%H:%M:%S+09:00") scroll="100m" max_size="10000" index_name="app-*" namespace_name="liberty-test" pod_name="mylibertyapp-ibm-websphe-0" query_json=" { ¥"size¥": ¥"$max_size¥", ¥"query¥": { ¥"bool¥": { ¥"filter¥": [ { ¥"regexp¥": { ¥"kubernetes.namespace_name¥": ¥"$namespace_name¥" } }, { ¥"regexp¥": { ¥"kubernetes.pod_name¥": ¥"$pod_name¥" } }, { ¥"range¥": { ¥"@timestamp¥": { ¥"gte¥": ¥"$end_date¥", ¥"lt¥": ¥"$start_date¥" } } } ] } } }" output_query="[ ._source.¥"@timestamp¥", ._source.kubernetes.namespace_name, ._source.kubernetes.pod_name, ._source.message]" curl_option="-k -s" curl_auth="Authorization: Bearer ${token}" curl_content_type="Content-Type: application/json" curl ${curl_option} -H "${curl_auth}" -H "${curl_content_type}" -XGET https://${elasticsearch_host}/${index_name}/_search?scroll=100m -d "${query_json}" | jq -r ".hits.hits[] | ${output_query} | @csv" Elasticsearch APIからログを取得するスクリプト例事前にログインしSAのtokenと elasticssearchのホスト名の取得ログ取得の開始と終了時間ログ件数が超えた場合にscrollなどを⽤いてカスタマイズするログ対象のindex、namespace、 pod名など、query条件にしたいものを定義 jsonで取得した情報をcsvで出⼒する際のフォーマットを定義検索条件をjsonで定義 jsonの検索条件で取得した結果を csv形式で出⼒ (¥はバックスラッシュ)

58 ロギング(OpenShift) Elasticsearch APIからログを取得 "2022-04-11T17:20:09.039187+00:00","liberty-test","mylibertyapp-ibm-websphe-0","{""type"":""liberty_message"",""host"":""mylibertyapp-ibm-websphe- 0.mylibertyapp-ibm-websphe.liberty- test.svc.cluster.local"",""ibm_userDir"":""¥/opt¥/ibm¥/wlp¥/usr¥/"",""ibm_serverName"":""defaultServer"",""message"":""CWWKF0008I: Feature update completed
in 1.509 seconds."",""ibm_threadId"":""0000002d"",""ibm_datetime"":""2022-04- 11T17:20:09.038+0000"",""ibm_messageId"":""CWWKF0008I"",""module"":""com.ibm.ws.kernel.feature.internal.FeatureManager"",""loglevel"":""INFO"",""ibm_sequ ence"":""1649697609038_000000000002D""}" "2022-04-11T17:20:09.039474+00:00","liberty-test","mylibertyapp-ibm-websphe-0","{""type"":""liberty_message"",""host"":""mylibertyapp-ibm-websphe- 0.mylibertyapp-ibm-websphe.liberty- test.svc.cluster.local"",""ibm_userDir"":""¥/opt¥/ibm¥/wlp¥/usr¥/"",""ibm_serverName"":""defaultServer"",""message"":""CWWKF0011I: The defaultServer server is ready to run a smarter planet. The defaultServer server started in 2.445 seconds."",""ibm_threadId"":""0000002d"",""ibm_datetime"":""2022-04- 11T17:20:09.039+0000"",""ibm_messageId"":""CWWKF0011I"",""module"":""com.ibm.ws.kernel.feature.internal.FeatureManager"",""loglevel"":""AUDIT"",""ibm_seq uence"":""1649697609039_000000000002E""}" "2022-04-11T17:20:20.272646+00:00","liberty-test","mylibertyapp-ibm-websphe-0","{""type"":""liberty_accesslog"",""host"":""mylibertyapp-ibm-websphe- 0.mylibertyapp-ibm-websphe.liberty- test.svc.cluster.local"",""ibm_userDir"":""¥/opt¥/ibm¥/wlp¥/usr¥/"",""ibm_serverName"":""defaultServer"",""ibm_remoteHost"":""10.131.2.1"",""ibm_requestP rotocol"":""HTTP¥/1.1"",""ibm_requestHost"":""10.131.2.83"",""ibm_bytesReceived"":13283,""ibm_requestMethod"":""GET"",""ibm_requestPort"":""9080"",""ibm_ elapsedTime"":1291,""ibm_responseCode"":200,""ibm_uriPath"":""¥/"",""ibm_userAgent"":""kube-probe¥/1.19"",""ibm_datetime"":""2022-04- 11T17:20:20.272+0000"",""ibm_sequence"":""1649697620271_0000000000003""}" "2022-04-11T17:20:06.461657+00:00","liberty-test","mylibertyapp-ibm-websphe-0","" "2022-04-11T17:20:07.453593+00:00","liberty-test","mylibertyapp-ibm-websphe-0","{""type"":""liberty_message"",""host"":""mylibertyapp-ibm-websphe- 0.mylibertyapp-ibm-websphe.liberty- test.svc.cluster.local"",""ibm_userDir"":""¥/opt¥/ibm¥/wlp¥/usr¥/"",""ibm_serverName"":""defaultServer"",""message"":""CWWKG0093A: Processing configuration drop-ins resource: ¥/opt¥/ibm¥/wlp¥/usr¥/servers¥/defaultServer¥/configDropins¥/defaults¥/keystore.xml"",""ibm_threadId"":""00000024"",""ibm_datetime"":""2022-04- 11T17:20:07.451+0000"",""ibm_messageId"":""CWWKG0093A"",""module"":""com.ibm.ws.config.xml.internal.ServerXMLConfiguration"",""loglevel"":""AUDIT"",""ibm _sequence"":""1649697607451_0000000000002""}" Elasticsearch APIからログを取得するスクリプトの出⼒例 (例) 上述で取得した値を元に、監視、または保管⽤のログファイルを作成 (要件に応じてカスタマイズしたログファイル)

59 ロギング(OpenShift) • (補⾜) LokiStack + Vector - Qiita /
ベアメタルUPIで導⼊したオンプレのOpenShift 4.11に LokiStack + Vectorを⼊れてみた - Qiita / LogCLIでLokiのログを検索してみた (OpenShift 4.11 + LokiStack 5.5) - Qiita / OpenShiftのロギング(LokiStack)でログの保持期間の設定をする(OpenShift 4.12 + LokiStack 5.6)

61 ロギング(アプリケーション) (※) OCP 4.10の場合

62 ロギング(アプリケーション) • アプリログファイルの監視 - コンテナログ(各node(RHCOS)のコンテナーログ⽤の /var/log/containers/*.log)ではなく、アプリ固有のログファイル (libertyのmessage.logなど)がある場合は、OCPのCluster Loggingのfluentd、Elasticsearch経由では監視できない -
アプリケーションが起動するPodにサイドカーとしてfluentdのコンテナを追加で実装 - 各Podのfluentdコンテナが監視対象のアプリログファイルを読み取り、運⽤管理サーバーのfluentdに転送 - ログファイルとして出⼒し、これを既存環境のエージェントで監視コンテナ(fluentd) PV アプリログファイル (message.log etc) 既存監視システムアプリPod fluentd fluentd (podman) 監視⽤ログエ " ジ $ ント OpenShiftクラスターコンテナ(アプリ) 各Podで保有する共通領域にログファイルを出⼒運⽤管理サーバー (Linux) (例)podmanのコンテナとしてfluentdを起動

63 ロギング(アプリケーション) • fluentdの設定例 <source> @type tail @id tail_message_log tag
message.log path /pvroot/applogs/message.log pos_file /pvroot/fluentd-pos-file/message.log-pos follow_inodes true read_from_head true <parse> @type none </parse> </source> <match message.log> @type forward @id forward_message_log <server> host xx.xxx.xx.x port 24224 </server> </match> アプリPodのサイドカーのfluentd.conf タグを付与 Libertyコンテナから出⼒されるmessage.logを収集する例収集対象の設定転送の設定収集の対象転送対象のタグ転送先のホストとポートを指定 <source> @type forward @id in_forward port 24224 </source> <match message.log> @type file @id file_message_log path /logs/${namespace}/${node}/fluentd-message add_path_suffix true append true <format> @type single_value </format> </match> 受信側のfluentdのfluentd.conf 受信対象のタグ受信の設定監視⽤ファイル出⼒の設定ファイルの出⼒先出⼒はファイル

まとめ

65 まとめ • Observabilityを⾼めるためにOCPが提供するモニタリング、ロギングの機能を活⽤ • エンタープライズ企業の監視運⽤ - エンタープライズのお客様では既存の運⽤体系があり、OCPで監視した内容をこれらの既存運⽤に合わせるための考慮が必要 - これらを実現する実装⽅法・⼯夫についての⼀例をご紹介

66 まとめ • 今回のご紹介した事例はあくまでもお客様のクラウドネイティブ・ジャーニーの第⼀歩 - OCPを導⼊しビジネスのアジリティーを⾼めるシステムを構築 - まずは、既存運⽤体系にきちんと連携することで、OCP環境への安⼼したリフトを実現 • 次のステップ
- 継続した改善 - オープンソースをベースとしたOpenShiftのような製品は短いスパンで「改善」 = 「変更」される - (例) ElasticsearchのバージョンアップによるURLの変更、API、Metricsの変更、LokiStackなど - 継続した改善の中で、運⽤担当者にクラウドネイティブなロギング、モニタリングの機能をよりご活⽤頂く - 将来的には既存監視運⽤体系からクラウドネイティブな監視運⽤体系にプロセスも含めてシフト - OCPのモニタリング、ロギング機能をより効果的に活⽤ - ユーザーが導⼊したGrafanaのダッシュボードをカスタマイズしお客様固有のメトリクスを可視化 - Kibanaのダッシュボードのカスタマイズ、フィルター条件の保存など - Observabilityを⾼めるためにロギング、モニタリング以外のSignalも活⽤ - トレーシングなど - クラウドネイティブな環境に特化したObservabilityを⾼めるソリューションを検討 - IBM Cloud Pak for Watson AIOps - IBM Observability by Instana APM AIOpsによる運⽤⾼度化の実現〜Watson AIOpsが実装する運⽤管理機能の概要

End of Document

オンプレミスのOpenShift基盤構築事例からの監視運用方法

オンプレミスのOpenShift基盤構築事例からの監視運用方法

Other Decks in Technology

Featured

Transcript