オンプレミスの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

6 Agenda • はじめに • 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)の構成をもとに 記載していますのでご注意ください。

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

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

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の場合

16 エンタープライズ企業の監視運⽤ 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の場合

17 エンタープライズ企業の監視運⽤ 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、メモリー) 基盤担当者 既存監視 システム オペレーター ルーム 運⽤担当者 Slackはない 監視基盤以外から メールは送信不可 運⽤担当者が⾒るのはオペ レータールームの既存の監視 基盤のコンソール お客様の運⽤体系 に合った監視基盤 に連携して初めて 「Observabilityが ある」といえる 連携でき ていない Prometheus Adapter (※) OCP 4.10の場合

18 エンタープライズ企業の監視運⽤ 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 運⽤管理サーバー (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の場合

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

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コマンドで情報を取得

22 監視項⽬ 監視対象 監視項⽬ 監視⽅法 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コマンドで情報を取得 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 [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のア ラートにする・・・など要件に応じたスクリプトを作成

26 監視項⽬ 監視対象 監視項⽬ 監視⽅法 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

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% ・・・ など

35 監視項⽬ 監視対象 監視項⽬ 監視⽅法 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

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. モニタリング mpMetrics-3.0 monitor-1.0 「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使⽤率 などのグラフも作成可能

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

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にログを転 送

50 監視項⽬ 監視対象 監視項⽬ 監視⽅法 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 ) 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)

60 監視項⽬ 監視対象 監視項⽬ 監視⽅法 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にログを転 送

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の設定例 @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 @type none @type forward @id forward_message_log host xx.xxx.xx.x port 24224 アプリPodのサイドカーのfluentd.conf タグを付与 Libertyコンテナから出⼒されるmessage.logを収集する例 収集対象の設定 転送の設定 収集の対象 転送対象のタグ 転送先のホストと ポートを指定 @type forward @id in_forward port 24224 @type file @id file_message_log path /logs/${namespace}/${node}/fluentd-message add_path_suffix true append true @type single_value 受信側の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