ベアメタルUPIで導入したオンプレのOpenShift 4.11に LokiStack + Vectorを入れてみた

# 概要

OpenShift (以下OCP)のロギング 5.5で、`LokiStack`がGAになっていました。
- [OCP 4.11 Docs / ロギング / 1. ロギングのリリースノート / 1.5. Logging 5.5 / 1.5.1. 機能拡張](https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.11/html-single/logging/index#openshift-logging-5-5-0-enhancements)

> 今回の更新では、'LokiOperator' Operator および Vector コレクターがテクニカルプレビュー機能から一般提供機能 (GA) に移行します。以前のリリースとの完全な機能パリティーに関しては作業中で、一部の API はテクニカルプレビュー機能のままです。詳細については LokiStack を使用したロギング のセクションを参照してください。

また、Logging 5.3のリリースノートで、Elasticsearch Operatorは非推奨となり、今のところ時期はわかりませんが、将来的には削除されていくようです。
- [OCP 4.11 Docs / ロギング / 1. ロギングのリリースノート / 1.10. Logging 5.4.3 / 1.10.1. Elasticsearch Operator の非推奨通知](https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.11/html-single/logging/index#openshift-logging-elasticsearch-dep)

> **1.10.1. Elasticsearch Operator の非推奨通知**  
> logging サブシステム 5.4.3 では、Elasticsearch Operator は非推奨となり、今後のリリースで削除される予定です。Red Hat は、この機能に対して現在のリリースライフサイクル中にバグ修正とサポートを提供しますが、拡張機能の提供はなく、この機能は今後削除される予定です。Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。


(補足) ライフサイクルポリシーの方には、特に関連した記載はなさそうでした。
- [Red Hat OpenShift Container Platform Life Cycle Policy / OpenShift Logging](https://access.redhat.com/support/policy/updates/openshift#logging)


今までロギングとして`OpenShift Elasticsearch Operator`と、`Red Hat OpenShift Logging Operator`を使用して`EFK`スタックを導入していた人にとって、いつかは移行する必要があるかもしれません。
永続ボリューム(PV)を`Local Storage Operator`のみで構成していたような人とかも対応が必要です。

Lokistackでは、前提として、オブジェクトストレージが必要ですが、オンプレミスではオブジェクトストレージを用意するのはなかなか大変です。

そこで、ベアメタル UPIの方法でオンプレミスにOCPを導入している環境で、オブジェクトストレージとして新規にOpenShift Data Foudation (ODF)をインストールしてみました。(minioとかでも良いみたいですが、サポートのあるODFを使用しました。)

今回は、そのODFで作成したオブジェクトストレージを使用して、LokiStack + Vectorを導入してみたのでその際のメモを記載します。

((注)ちなみにオブジェクトストレージは必要なのですが、幾つかのコンポーネントでBlock(volumeMode: Filesystem)の永続ボリュームも合わせて作成されていました。ですので、なおさら、ODFが必要なのかなと思います。)


今回は、検証時に最新だったLogging ５.5.5 を使用しています。

**OCP**
| OCP | version | notes |
|:----|:--------|:------|
| OCP | 4.11.16 |       |

**Operators**
| Operator                  | version | notes                                         |
|:--------------------------|:--------|:----------------------------------------------|
| Local Storage             | 4.11.0  | For Storage (Prerequise of ODF on on-pre env) |
| OpenShift Data Foundation | 4.11.4  | For Storage (Block and Object)                |
| Loki Operator             | 5.5.5   | For Logging (Lokistack)                       |
| Red Hat OpenShift Logging | 5.5.5   | For Logging (ClusterLogging and Vector)       |



# 参考リンク

**LokiStack**
- [OCP 4.11 Docs / ロギング / 5. Loki / 5.1. LokiStack](https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.11/html-single/logging/index#about-logging-loki_cluster-logging-loki)
- [Loki Operator Docs](https://loki-operator.dev/docs/prologue/introduction.md/)
- [Grafana Loki](https://grafana.com/docs/loki/latest/)


**OpenShift Data Foudation (ODF)**
- [ODF 4.11 Docs](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11)


**OpenShift Data Foudation (ODF) - (MultiCloud Gateway (MCG))**
- [ODF 4.11 Docs / ハイブリッドおよびマルチクラウドリソースの管理](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/managing_hybrid_and_multicloud_resources/index#doc-wrapper)
- [ODF 4.11 Docs / ハイブリッドおよびマルチクラウドリソースの管理 / 4. ハイブリッドまたはマルチクラウド用のストレージリソースの追加](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/managing_hybrid_and_multicloud_resources/index#adding-storage-resources-for-hybrid-or-multicloud_rhodf)
- [ODF 4.11 Docs / ハイブリッドおよびマルチクラウドリソースの管理 / 10. Object Bucket Claim（オブジェクトバケット要求）](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/managing_hybrid_and_multicloud_resources/index#object-bucket-claim)


**Loki Document**

Loki + ODF の場合の設定例
- [Loki Operator Docs / LOKISTACK / Object Storage / OpenShift Data Foudation](https://loki-operator.dev/docs/object_storage.md/#openshift-data-foundation)
- [Loki Operator Docs / LOKI OPERATOR / API](https://loki-operator.dev/docs/api.md/)

Lokiのコンポーネントの概要
- [Grafana Loki / Fundamentals / Architecture / Components](https://grafana.com/docs/loki/latest/fundamentals/architecture/components/)

**その他参考**

- [Qiita / 【作業ログ】OpenShift 4.10でVector/Loki/Grafanaのログ基盤をデプロイしてみる](https://qiita.com/shin7446/items/30d8bdf081738aa4a0ab)
- [赤帽ブログ / OpenShiftにおけるMultiCloud Gateway(MCG)とレジストリ](https://rheb.hatenablog.com/entry/2022/09/26/151603)



# 検証環境


**OCP構成**

今回の検証環境の、OCPクラスタの構成は、以下のリンク先でインストールしたOCP 4.11 の構成となります。

(参考) [Qiita / OpenShift 4.10 ベアメタルUPI (iPXE) インストール](https://qiita.com/t_sweetfish/items/81268b29a3a7ad2f3f09)

- OCP 4.10をベアメタルのUPIでインストールしています。
- ベアメタルのUPIの構成ですが、node自体はVMwareの仮想マシンで作成しています。
- その後、OCP 4.10からOCP 4.11にアップデートした環境を使用します。

```bash
[root@bastion-01 ~]# oc version
Client Version: 4.11.16
Kustomize Version: v4.5.4
Server Version: 4.11.16
Kubernetes Version: v1.24.6+5157800
[root@bastion-01 ~]#
```


**Infra node**

Infra nodeは以下の手順で作成しています。
OCP内部レジストリ、ルーター、モニタリング、ロギングの運用コンポーネント用をInfra nodeで稼働させています。
- [Qiita / OpenShiftでMachine Config Pool (MCP) を使用してInfra nodeを作成する](https://qiita.com/t_sweetfish/items/a81d23f85c2c18326755)


**ODF**

OpenShift Data Foudation (ODF)は、ODF専用のInfra nodeに導入し、ODFクラスタを作成しています。
- [Qiita / ベアメタルUPIのOpenShift (OCP) 4.11に、OpenShift Data Foudation (ODF)をインストールする](https://qiita.com/t_sweetfish/items/d81cf4da2681c131e6da)


**ノード構成**

Infra node専用のMCPを作成しています。
```bash
[root@bastion-01 ~]# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-bd0eb2d6bddaa13bd9a1fe95217a0e88    True      False      False      6              6                   6                     0                      149d
master   rendered-master-60815c158d00703013c8ffa0f9090be0   True      False      False      3              3                   3                     0                      149d
worker   rendered-worker-bd0eb2d6bddaa13bd9a1fe95217a0e88   True      False      False      2              2                   2                     0                      149d
[root@bastion-01 ~]#
```

Infra nodeとして、運用コンポーネント(内部レジストリ、ルーター、モニタリング、ロギング)用のInfra nodeと、ODF専用のInfra node (storage node)を作成しています。
```bash
[root@bastion-01 ~]# oc get node
NAME         STATUS   ROLES    AGE    VERSION
infra-01     Ready    infra    149d   v1.24.6+5157800        # Infra node (運用コンポーネント用)
infra-02     Ready    infra    149d   v1.24.6+5157800        # 同上
infra-03     Ready    infra    149d   v1.24.6+5157800        # 同上
master-01    Ready    master   149d   v1.24.6+5157800        # Master node
master-02    Ready    master   149d   v1.24.6+5157800        # 同上
master-03    Ready    master   149d   v1.24.6+5157800        # 同上
storage-01   Ready    infra    3d2h   v1.24.6+5157800        # Infra node (ODF専用) 
storage-02   Ready    infra    3d2h   v1.24.6+5157800        # 同上
storage-03   Ready    infra    3d2h   v1.24.6+5157800        # 同上
worker-01    Ready    worker   149d   v1.24.6+5157800        # Worker node
worker-02    Ready    worker   149d   v1.24.6+5157800        # 同上
[root@bastion-01 ~]#
```


**Operator**

事前に以下のバージョンのOperatorを導入しています。

(上述の**Infra node**欄、**ODF**欄の(参考)のリンクの中で導入していました。Operatorの導入手順はそちらをご参照ください。)


| Operator                  | Channel       | 更新承認ストラテジー | CSV                                          | 備考 |
|:--------------------------|:--------------|:---------------|:---------------------------------------------|:-----|
| Local Storage             | `stable`      | Manual         | `local-storage-operator.4.11.0-202211072116` |      |
| OpenShift Data Foundation | `stable-4.11` | Manual         | `odf-operator.v4.11.4`                       |      |


| Operator                            | Channel      | 更新承認ストラテジー | CSV                            | 備考                                                |
|:------------------------------------|:-------------|:---------------|:-------------------------------|:--------------------------------------------------|
| Red Hat OpenShift Logging           | `stable-5.5` | Manual         | `cluster-logging.5.5.5`        | 以前は`Cluster Logging Operator`という名称だったが変更されたもの |
| (※)OpenShift Elasticsearch Operator | `stable-5.5` | Manual         | `elasticsearch-operator.5.5.5` | (すでに導入されていたが今回は不要。新規の場合は導入不要。)        |



(補足)  
- ロギングとして、「OpenShift Elasticsearch Operator」と、「Cluster Logging Operator」は、[Qiita / OpenShiftでMachine Config Pool (MCP) を使用してInfra nodeを作成する](https://qiita.com/t_sweetfish/items/a81d23f85c2c18326755) の [ロギング](https://qiita.com/t_sweetfish/items/a81d23f85c2c18326755#%E3%83%AD%E3%82%AE%E3%83%B3%E3%82%B0) の方法で導入していました。
- その時点では `elasticsearch-operator.5.4.2` ( `stable-5.4` Channel)と `cluster-logging.5.4.2` ( `stable-5.4` Channel)を導入していたので、検証時点では、その時点で最新 `elasticsearch-operator.5.5.5` ( `stable-5.5` Channel)と `cluster-logging.5.5.5` (`stable-5.5` Channel)にアップデートしています。
- (手順は [OCP 4.11 Docs / ロギング / 11. OpenShift Logging について / 11.2. Logging を現在のバージョンに更新する](https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.11/html-single/logging/index#cluster-logging-updating-logging-to_current_cluster-logging-upgrading)に記載があるので、ここでは割愛します。)


  
  
  
今回は、この記事の手順の中で、「Loki Operator」を Infra node (運用コンポーネント用) にデプロイします。

| Operator      | Channel      | 更新承認ストラテジー | CSV                   | 備考 |
|:--------------|:-------------|:---------------|:----------------------|:-----|
| Loki Operator | `stable-5.5` | Manual         | `loki-operator.5.5.5` |      |



# 手順の流れ

ベアメタルUPIのOCPに、ODFを導入してODFクラスタを作成します。

ODFクラスタから、LokiStack用のオブジェクトバケットを作成し、`LokiStack`と`ClusterLogging`をデプロイします(Loki + Vector)。

今回は `LokiStack` は Infra node (運用コンポーネント用) にデプロイします。

手順の流れは以下になります。

**(事前準備)**
- [(1) 既存のロギングサブシステム(Elasticsearch、Fluentd、Kibana)のアンインストール](#1-既存のロギングサブシステムelasticsearchfluentdkibanaのアンインストール)


**前提の確認**
- [(1) デプロイメントのサイズ](#1-デプロイメントのサイズ)


**ODFクラスタの作成**
- [(1) ODFクラスタの作成](#1-odfクラスタの作成)


**オブジェクトストレージの準備**

- [(1) バッキングストアの作成](#1-バッキングストアの作成)
- [(2) バケットクラスの作成](#2-バケットクラスの作成)
- [(3) Object Bucket Claimの作成](#3-object-bucket-claimの作成)
- [(4) オブジェクトバケット接続用のSecretの作成](#4-オブジェクトバケット接続用のsecretの作成)


**LokiStackのデプロイ**
- [(1) Loki Operatorの導入](#1-loki-operatorの導入)
- [(2) LokiStackカスタムリソースの作成](#2-lokistackカスタムリソースの作成)
- [(3) ClusterLoggingカスタムリソースの作成(lokistackのデプロイ、vectorの有効化)](#3-clusterloggingカスタムリソースの作成lokistackのデプロイvectorの有効化)
- [(4) ログコンソールプラグインの有効化](#4-ログコンソールプラグインの有効化)




# 実際の手順

## (事前準備)

### (1) 既存のロギングサブシステム(Elasticsearch、Fluentd、Kibana)のアンインストール

必要に応じて、すでに導入していたロギングサブシステム(Elasticsearch、Fluentd、Kibana)をアンインストールします。

また、Elasticsearch用のPVも削除します。

(今回の環境では、(せっかく導入しているのにまだODFのPVを使っておらず)、Local Storage OperatorでPVを作成していたので、必要に応じてLocalVolumeリソースを削除することになります。)


この場合の流れは以下になります。

- ClusterLoggingリソースの削除
    - Kind: ClusterLogging (LogStore: elasticsearch、visualization: kibana, collection: fluentd)
- Operatorの削除(Elasticsearch Operator)
    - (Elasticsearch Operatorは必要に応じて削除してください。)
    - (※) `Cluster Logging Operator`は、この後も使用するので削除しません。
- PVCの削除(Elasticsearch用)
- LocalVolume(Elasticsearch用)、PV (Elasticsearch用)の削除
  - (※) `Local Storage Operator`も、ODFで使用しているので、削除しないこと。


手順自体は以下のリンクに記載があるので、ここでは割愛します。

- [OCP 4.11 Docs / ロギング / 14. OpenShift Logging のアンインストール](https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.11/html-single/logging/index#cluster-logging-uninstall)
- [OCP 4.11 Docs / ストレージ / 4.10.9. ローカルストレージ Operator のリソースの削除 / 4.10.9.1. ローカルボリュームまたはローカルボリュームセットの削除](https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.11/html-single/storage/index#local-removing-device_persistent-storage-local)


## 前提の確認

### (1) デプロイメントのサイズ

サイジングの指標は以下に記載があります。

Lokiのサイズは、`1x.extra-small`、`1x.small`、`1x.medium`のあります。

`1x.extra-small`はデモ用でサポートされない、とのことなので、今回は`1x.small`を導入することにしました。


- [OCP 4.11 Docs / ロギング / 5. Loki / 5.1. LokiStack / 5.1.1. デプロイメントのサイズ](https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.11/html-single/logging/index#deployment-sizing_cluster-logging-loki)

|                          | 1x.extra-small | 1x.small           | 1x.medium          |
|:-------------------------|:---------------|:-------------------|:-------------------|
| Data transfer            | Demo use only. | 500GB/day          | 2TB/day            |
| Queries per second (QPS) | Demo use only. | 25-50 QPS at 200ms | 25-75 QPS at 200ms |
| Replication factor       | None           | 2                  | 3                  |
| Total CPU requests       | 5 vCPUs        | 36 vCPUs           | 54 vCPUs           |
| Total Memory requests    | 7.5Gi          | 63Gi               | 139Gi              |
| Total Disk requests      | 150Gi          | 300Gi              | 450Gi              |


`1x.small`なので、レプリカ数が2のようです。

レプリカ数が2だと、Infra node x2 で、Total CPU requests と Total Memory requestsを賄えば良いのか？と思えますので、Infra node 1台あたり、18 vCPUs、32Gi Memoryが必要？かもしれません。

ディスクはODFから賄うので1TB使えるので大丈夫と思われます。


また元々のInfra nodeのサイジングも併せて検討する必要があります。

-  [OCP 4.11 Docs / スケーラビリティーおよびパフォーマンス / 2. ホストについての推奨されるプラクティス / 2.11. インフラストラクチャーノードのサイジング](https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.11/html-single/scalability_and_performance/index#infrastructure-node-sizing_recommended-host-practices)

これらを合わせると、Infra node 1台当たり 24 vCPU、48 GBに一旦してみました。

(ちょっと大きすぎて検証環境的にはなかなか厳しい・・・本当にこんなに必要なのか・・・？)

(RHCOSのシステム領域のDiskは40GBは最小要件を満たしていないですが、これは検証環境のリソース的にとりあえず稼働するので元から少なくしていますので無視して下さい。)


(変更前)

| Server     | vCPU | Memory | Disk | Disk2  | notes                |
|:-----------|:-----|:-------|:-----|:-------|:---------------------|
| infra #1   | 8    | 48GB   | 40GB |        | infra node           |
| infra #2   | 8    | 48GB   | 40GB |        | infra node           |
| infra #3   | 8    | 48GB   | 40GB |        | infra node           |
| storage #1 | 16   | 32GB   | 40GB | 1024GB | infra node (for ODF) |
| storage #2 | 16   | 32GB   | 40GB | 1024GB | infra node (for ODF) |
| storage #3 | 16   | 32GB   | 40GB | 1024GB | infra node (for ODF) |


(変更後)

| Server     | vCPU | Memory | Disk | Disk2  | notes                |
|:-----------|:-----|:-------|:-----|:-------|:---------------------|
| infra #1   | 24   | 48GB   | 40GB |        | infra node           |
| infra #2   | 24   | 48GB   | 40GB |        | infra node           |
| infra #3   | 24   | 48GB   | 40GB |        | infra node           |
| storage #1 | 16   | 32GB   | 40GB | 1024GB | infra node (for ODF) |
| storage #2 | 16   | 32GB   | 40GB | 1024GB | infra node (for ODF) |
| storage #3 | 16   | 32GB   | 40GB | 1024GB | infra node (for ODF) |



**(補足)**

最終的にやってみてわかったことですが、オブジェクトストレージ以外に、Lokiの幾つかのコンポーネントでBlock (volumeMode: Filesystem)のPVCがさ作成されていました。

(ODFの`ocs-storagecluster-ceph-rbd`のストレージクラスを指定して動的に作成)


ですので、オブジェクトストレージだけで300Gなのか、それらも合わせて300Gなのかはちょっと分かりませんでした。。

一応、今回はログ保管領域としてのオブジェクトストレージはLoki専用に300GiB のバッキングストアを作成しました。
これに加えて自動で作成される永続ボリュームを合わせて、最終的にはストレージとしては以下のものができていました。  


**オブジェクトストレージ**
| バッキングストア       | size   | notes                                              |
|:---------------|:-------|:---------------------------------------------------|
| Loki用バッキングストア | 300GiB | 最小要件は300GiBだが、念の為少し余裕を持って400GiBなどとかも要検討 |

**永続ボリューム(Block (volumeMode: Filesystem))**

(ODFの`ocs-storagecluster-ceph-rbd`のストレージクラスを指定して動的に作成)
合計 430GiB
| Loki's component | Statefulset name                | replicas | PVC name                                      | size              | notes |
|:-----------------|:--------------------------------|:---------|:----------------------------------------------|:------------------|:------|
| Ingester         | logging-lokistack-ingester      | 2        | storage-logging-lokistack-ingester-[0,1]      | 10 x2 = 20GiB     |       |
|                  |                                 |          | wal-logging-lokistack-ingester-[0,1]          | 150 x2 = 300GiB   |       |
| Index Gateway    | logging-lokistack-index-gateway | 2        | storage-logging-lokistack-index-gateway-[0,1] | 50 x2 = 100 GiB   |       |
| Compactor        | logging-lokistack-compactor     | 1        | storage-logging-lokistack-compactor-0         | 10 x1 GiB = 10GiB |       |


**合計**

オブジェクトストレージ 300GiB + 永続ボリューム 430GiB = 730GiB ...
かなり大きい。。

実際には、PVの方はそこまで容量を使用していないようだったので本当はここまで必要ないのかもしれません。
但し、volumeClaimTemplatesは、Operator側で自動で指定されているため自動で作成されてしまいます。また変更方法はわかりませんでした。。

ですので、`1x.small`を選んだ際はそこそこディスクの容量が必要ということを覚悟しておく必要はあるかなと思います。

今回は [Qiita / ベアメタルUPIのOpenShift (OCP) 4.11に、OpenShift Data Foudation (ODF)をインストールする](https://qiita.com/t_sweetfish/items/d81cf4da2681c131e6da) で、1TBのストレージを作成していたので、これらの容量を賄えていました。


## ODFクラスタの作成

###  (1) ODFクラスタの作成

OpenShift Data Foudation (ODF)は、ODF専用のInfra nodeに導入し、ODFクラスタを作成しました。

構成は以下のリンク先の通りとなります。
- [Qiita / ベアメタルUPIのOpenShift (OCP) 4.11に、OpenShift Data Foudation (ODF)をインストールする](https://qiita.com/t_sweetfish/items/d81cf4da2681c131e6da)



## オブジェクトストレージの準備

### (1) バッキングストアの作成


ODFではデフォルトで`noobaa-default-backing-store`というバッキングストアが作成されていましたが、今回はLoki専用に`loki-backingstore`という名前のバッキングストアを作成しておくことにします。

(補足)ODFのMultiCloud gateway(MCG)を使用すると、ローカルのPVをバックエンドにオブジェクトストレージのバケットを提供できる、というのは、[赤帽ブログ / OpenShiftにおけるMultiCloud Gateway(MCG)とレジストリ](https://rheb.hatenablog.com/entry/2022/09/26/151603) の説明が分かりやすかったです。

今回はバッキングストアはOCPコンソールから作成しました、設定値の説明としては、以下が参考になります。

- [ODF 4.11 Docs / 4. ハイブリッドまたはマルチクラウド用のストレージリソースの追加 / 4.2. MCG コマンドラインインターフェースを使用したハイブリッドまたはマルチクラウドのストレージリソースの追加 / 4.2.5. ローカル永続ボリュームでサポートされるバッキングストアの作成](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/managing_hybrid_and_multicloud_resources/index#creating-a-local-Persistent-Volume-backed-backingstore_rhodf)

(抜粋)
| 設定箇所                                 | 内容                    | notes                                                                       |
|:-----------------------------------------|:------------------------|:----------------------------------------------------------------------------|
| `spec.type`                              | pv-pool                 |                                                                             |
| `spec.pvPool.numVolumes`                 | `<NUMBER OF VOLUMES>`   | 作成するボリューム数に置き換えます。ボリュームの数を増やすと、ストレージが拡大することに注意してください。            |
| `spec.pvPool.resources.requests.storage` | `<VOLUME SIZE>`         | 各ボリュームに必要なサイズ (GB 単位) に置き換えます。文字`G`はそのままにする必要があることに注意してください。   |
| `spec.pvPool.storageClass`               | `<LOCAL STORAGE CLASS>` | ローカルストレージクラスに置き換えます。これは、`ocs-storagecluster-ceph-rbd` を使用する際に推奨されます。 |


サイジングのところで見たように、300GiBにしようとする場合、ボリュームのサイズと数は、以下のような選択肢があると思われます。
- 300Gi x 1
- 100Gi x 3
- ...

一応、100Giづつ増やせた方が柔軟性があるかな、と思い、今回は100Gi x3 で作成してみました。


以降の作業は全てcluster-adminロールのあるユーザーでログインして実行しています。


OCPコンソールの左側のメニューから、ストレージ -> Data Foundation 画面の 「バッキングストア」 タブを選択し、「作成 Backing Store」をクリックします。
![2023-01-05-01-00-42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/0022d4b8-6c92-031e-67b0-8e316dfb1595.png)



「新規バッキングストアの作成」画面で以下の値を入力し、「バックバックストアの作成」をクリックします。

| field                       | default     | 設定値                        | notes                                                                      |
|:----------------------------|:------------|:------------------------------|:---------------------------------------------------------------------------|
| バッキングストア名                  | blank       | `loki-backingstore`           | 任意の名前                                                                  |
| プロバイダー                      | AWS S3      | PVC                           | MCG経由で利用するオブジェクトストレージのバックエンドとしてODFのPVを使用するための設定                    |
| ボリューム数                     | 1           | 3                             |                                                                            |
| ボリュームのサイズ                   | 50 GiB Unit | 100 GiB Unit                  | 100GiB x 3 で 300GiB                                                        |
| blank field (storage class) | blank       | `ocs-storagecluster-ceph-rbd` | `spec.pvPool.storageClass`の説明で推奨とあった`ocs-storagecluster-ceph-rbd`を指定 |

![2023-01-05-01-06-16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/cba339f7-04e1-ed75-2d43-a50e42710214.png)


「バッキングストア」タブで作成した`loki-backingstore`のエントリーが追加されたことを確認します。

![2023-01-05-01-10-01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/029a84a2-9e62-b643-22cc-6f9726a0861e.png)
![2023-01-05-01-10-19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/cfe71727-60f4-a31f-b466-a1801ed33ea3.png)

```bash
[root@bastion-01 ~]# oc get backingstore -n openshift-storage
NAME                           TYPE            PHASE   AGE
loki-backingstore              pv-pool         Ready   2m27s
noobaa-default-backing-store   s3-compatible   Ready   35m
[root@bastion-01 ~]#
```


(補足)
pvPoolで指定した`ocs-storagecluster-ceph-rbd`のストレージクラスから、100GiBのPVが3つ作成されています。

(ここではやっていませんが、例えばボリューム数(`spec.pvPool.numVolumes`)を4に変更すると、100GiBのPVがもう一つ追加されてバッキングストアの容量が大きくなるようです。)

```bash
[root@bastion-01 ~]# oc get pvc -n openshift-storage
NAME                                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
db-noobaa-db-pg-0                        Bound    pvc-c437bda3-1431-4124-82ae-662ee2a54a33   50Gi       RWO            ocs-storagecluster-ceph-rbd   37m
loki-backingstore-noobaa-pvc-3fea5969    Bound    pvc-a5937d8a-6bbb-4914-b8c9-cccf3048f87e   100Gi      RWO            ocs-storagecluster-ceph-rbd   2m41s
loki-backingstore-noobaa-pvc-40a78edf    Bound    pvc-43fca63a-21cf-4b88-936b-bec1fa58a027   100Gi      RWO            ocs-storagecluster-ceph-rbd   2m41s
loki-backingstore-noobaa-pvc-933a9ff4    Bound    pvc-63859b3f-ad89-4470-a481-e9bfaf5aaa03   100Gi      RWO            ocs-storagecluster-ceph-rbd   2m41s
ocs-deviceset-localblock-0-data-022zww   Bound    local-pv-6b3c4558                          1Ti        RWO            localblock                    38m
ocs-deviceset-localblock-0-data-1mpknn   Bound    local-pv-d94c27a1                          1Ti        RWO            localblock                    38m
ocs-deviceset-localblock-0-data-2mz7zn   Bound    local-pv-faa39169                          1Ti        RWO            localblock                    38m
[root@bastion-01 ~]#
```

(注)3つのPVCを使用しているPodが全て同じnode上にいました...。これは設定をする箇所が見当たらなかったので一旦このままにしています。

```bash
[root@bastion-01 ~]# oc get pod -n openshift-storage -o wide | grep loki-backingstore
loki-backingstore-noobaa-pod-3fea5969                             1/1     Running     0             4m31s   10.130.4.23     storage-03   <none>           <none>
loki-backingstore-noobaa-pod-40a78edf                             1/1     Running     0             4m31s   10.130.4.24     storage-03   <none>           <none>
loki-backingstore-noobaa-pod-933a9ff4                             1/1     Running     0             4m31s   10.130.4.25     storage-03   <none>           <none>
[root@bastion-01 ~]#
```


### (2) バケットクラスの作成


バケットクラスの作成をします。

[ODF 4.11 Docs / 4. ハイブリッドまたはマルチクラウド用のストレージリソースの追加 / 4.4. 新規バケットクラスの作成](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/managing_hybrid_and_multicloud_resources/index#creating-a-new-bucket-class_rhodf)


OCPコンソールの左側のメニューから、ストレージ -> Data Foundation 画面の 「バケットクラス」 タブを選択し、「作成 Bucket Class」をクリックします。
![2023-01-05-01-12-56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/56f9cda4-d5d7-f8ad-6231-05473b8aab75.png)


「新規バケットクラスの作成」ウィザードの「一般」セクションで以下を指定して「次へ」をクリックします。

| field       | default | 設定値              | notes                                                         |
|:------------|:--------|:--------------------|:--------------------------------------------------------------|
| バケットクラスのタイプ | 標準    | 標準                | 標準/namespace。Multicloud Object Gateway (MCG)の場合は標準を指定 |
| バケットクラス名   | blank   | `loki-bucket-class` | 任意のバケットクラス名                                                |
| 説明(オプション) | blank   | blank               |                                                               |

![2023-01-05-01-13-36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/2885bf44-5be5-6f10-6051-ca6e9632400a.png)


「配置ポリシー」セクションで以下を指定して「次へ」をクリックします。

| field           | default | 設定値 | notes                                               |
|:----------------|:--------|:-------|:----------------------------------------------------|
| 階層1 - ポリシータイプ | 分散    | 分散   | 分散/ミラー。バッキングストアが1つの場合はとりあえず分散にしておく必要がある模様 |
| 階層の追加       | -       | -      | バッキングストアは1つなので何も指定しない                            |

![2023-01-05-01-14-33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/8fcf0810-8dde-5bcf-e1d1-eb6712f35917.png)


「リソース」セクションでは以下を指定して「次へ」をクリックします。

| field                     | default | 設定値                    | notes                                                                                       |
|:--------------------------|:--------|:--------------------------|:--------------------------------------------------------------------------------------------|
| 階層1 - バッキングストア (Spread) |         |                           |                                                                                             |
| 1つ以上のバッキングストアリソースの選択  | blank   | `loki-backingstore` にチェック | 作成した`loki-backingstore`とODFのデフォルトの`noobaa-default-backing-store`があったが、今回は作成したものだけ指定 |

![2023-01-05-01-15-22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/5d559fb9-9101-9602-79d6-cf2666389b20.png)


「確認」セクションで確認をして「バケットクラスの作成」をクリックします。
![2023-01-05-01-15-42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/f5a03ead-fb13-052a-9991-29131516ed44.png)


バケットクラスが作成されたことを確認します。
![2023-01-05-01-16-13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/3fcd725f-96e2-6b01-d88a-8a095078ef03.png)
![2023-01-05-01-16-27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/2b105736-8af0-6833-9ade-42b482f54dd6.png)



### (3) Object Bucket Claimの作成

作成したバッキングストアのバケットクラスを使用して、Lokiで使用するバケット(`Object Bucket Claim`)を作成します。

[ODF 4.11 Docs / ハイブリッドおよびマルチクラウドリソースの管理 / 10. Object Bucket Claim（オブジェクトバケット要求） / 10.3. OpenShift Web コンソールを使用した Object Bucket Claim（オブジェクトバケット要求）の作成](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/managing_hybrid_and_multicloud_resources/index#creating-an-object-bucket-claim-using-the-openshift-web-console_rhodf)

OCPコンソールの左側のメニューから、ストレージ -> Object Bucket Claims を選択し、表示された「ObjectBucketClaims」画面を表示します。

左上のプルダウンから、ObjectBucketClaimを作成するNamespace(Project)を指定します。

バケットはLokistackからしか使用しないので`openshift-logging` namespaceに作成するのが良いのか、一応ストレージ用の`openshift-storage` namespaceに作成した方が良いのか悩みましたが、`openshift-storage`以外を指定した際にどこかの画面で何かの情報が拾えなかった？気がしたので、今回は`openshift-storage` namespaceを指定してみました。(気のせいかもしれません。)


プロジェクトを`openshift-storage`を指定したら、「オブジェクトバケット要求の作成」をクリックします。
![2023-01-05-01-17-30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/6d439a63-1344-fc03-fab8-a464b54205c4.png)



「オブジェクトバケット要求の作成」画面で以下を指定して「作成」をクリックします。

ストレージクラスは、上述リンクのドキュメントに「`openshift-storage.noobaa.io` は Multicloud Object Gateway (MCG) を使用します。」と書いてて、今回はMCG経由でバケットを作成するので、`openshift-storage.noobaa.io`を指定しました。


| field               | default | 設定値                        | notes                                                                                                                      |
|:--------------------|:--------|:------------------------------|:---------------------------------------------------------------------------------------------------------------------------|
| オブジェクトバケット要求の名前 | blank   | `loki-object-bucket`          | 任意の名前でバケットのprefixになってた                                                                                                 |
| ストレージクラス            | blank   | `openshift-storage.noobaa.io` | 候補として`openshift-storage.noobaa.io`と`ocs-storagecluster-ceph-rgw`が表示されるが、MCGを使用するので`openshift-storage.noobaa.io`を選択 |
| バケットクラス             | blank   | `loki-bucket-class`           | 先ほど作成したバケットクラス名を指定                                                                                                   |

![2023-01-05-01-18-48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/305a9347-86be-a667-b077-68288139d187.png)

オブジェクトバケット要求が作成されたことを確認します。
![2023-01-05-01-20-15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/f14221ee-479c-d031-309c-51dd0f5d04b4.png)
![2023-01-05-01-21-42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/99f706ee-45f5-8ace-0c63-21109ea63590.png)


画面下部の「オブジェクトバケット要求データ」のEndpointや、Bucket Name、Access Key、Secret Keyの情報を指定して、このバケットを使用することができるようになります。
右側の「値を表示する」をクリックして、`Endpint`、`Bucket Name`、`Access Key`、`Secret Key`の値を控えておきます。

![2023-01-05-01-21-58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/15286d5e-e35c-6d2b-103e-f4ae29169a35.png)



### (4) オブジェクトバケット接続用のSecretの作成

Lokiから作成したオブジェクトバケットに使用するために、このバケットのEndpointや、Bucket Name、Access Key、Secret Key 情報を含んだSecretを作成します。

OCPのドキュメントには、AWS S3用のSecretの例しか記載がありませんでした。。
- [OCP 4.11 Docs / ロギング / 5. Loki / 5.2. Lokistack のデプロイ](https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.11/html-single/logging/index#logging-loki-deploy_cluster-logging-loki)

以下の、Loki Operatorのドキュメントには、ODFで作成したバケットを使用する場合のSecretの作成方法が記載されていたので、今回はそちらを参考にSecretを作成します。
- [Loki Operator Docs / LOKISTACK / Object Storage / OpenShift Data Foudation](https://loki-operator.dev/docs/object_storage.md/#openshift-data-foundation)


Secretをコマンドで作成する例しか載っていませんが、指定するKeyは載っているのでSecretのマニフェストファイルを作成してこれを適用します。

(注)一点だけ、`bucketname`のKeyだけは、OCPのドキュメントのS3の例にある`backetnames`と複数形でないといけなかったです。。。どっちも情報不足でなかなかハードルが高い。。。
```bash
[root@bastion-01 logging]# vi secret-loki-object-bucket.yaml
[root@bastion-01 logging]# cat secret-loki-object-bucket.yaml
```
Secretの名前は任意なので今回は`loki-object-bucket`としておきました。
```yaml
apiVersion: v1
kind: Secret
metadata:
  name: loki-object-bucket
  namespace: openshift-logging
stringData:
  access_key_id: "xxxxxxxxxxxxxxxxx"                                     # 作成したオブジェクトバケット要求の`Access Key`の値
  access_key_secret: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"          # 作成したオブジェクトバケット要求の`Secret Key`の値
  bucketnames: "loki-object-bucket-xxxxxxx-xxxx-xxxxx-xxxx-xxxxxxxxxx"   # 作成したオブジェクトバケット要求の`Bucket Name`の値 (注)Keyは`bucketnames`
  endpoint: "https://s3.openshift-storage.svc:443"             # (注)作成したオブジェクトバケット要求の`Endoint`の値を`https://<Endpoint>:443`としたURLを記載
```

Secretのマニフェストを適用します。

```bash
oc apply -f secret-loki-object-bucket.yaml
oc get secret -n openshift-logging 
```
(出力例)
```bash
[root@bastion-01 logging]# oc apply -f secret-loki-object-bucket.yaml
secret/loki-object-bucket created
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get secret -n openshift-logging
NAME                                       TYPE                                  DATA   AGE
builder-dockercfg-pzl47                    kubernetes.io/dockercfg               1      176d
builder-token-c72mt                        kubernetes.io/service-account-token   4      176d
builder-token-lf7m7                        kubernetes.io/service-account-token   4      176d
cluster-logging-operator-dockercfg-lz7sp   kubernetes.io/dockercfg               1      176d
cluster-logging-operator-token-7bwmn       kubernetes.io/service-account-token   4      176d
cluster-logging-operator-token-7zcpm       kubernetes.io/service-account-token   4      176d
default-dockercfg-29s4l                    kubernetes.io/dockercfg               1      176d
default-token-n7xdb                        kubernetes.io/service-account-token   4      176d
default-token-qg2p5                        kubernetes.io/service-account-token   4      176d
deployer-dockercfg-fkz4p                   kubernetes.io/dockercfg               1      176d
deployer-token-trvxd                       kubernetes.io/service-account-token   4      176d
deployer-token-zb7cl                       kubernetes.io/service-account-token   4      176d
loki-object-bucket                         Opaque                                4      16s
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get secret -n openshift-logging loki-object-bucket
NAME                 TYPE     DATA   AGE
loki-object-bucket   Opaque   4      30s
[root@bastion-01 logging]#
```



## LokiStackのデプロイ


LokiStack用のオブジェクトストレージのバケットの準備ができたので、LokiStackを使用してCluster Loggingのインスタンスを作成します。

(なお、前述したように、LokiStackの幾つかのコンポーネントはオブジェクトストレージだけでなく、volumeMode: Filesystemの永続ボリュームも使用)


### (1) Loki Operatorの導入



Loki Operatorをインストールします。

[OCP 4.11 Docs / ロギング / 5. Loki / 5.2. Lokistack のデプロイ](https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.11/html-single/logging/index#logging-loki-deploy_cluster-logging-loki)

| Operator      | Channel      | 更新承認ストラテジー | CSV                   | 備考 |
|:--------------|:-------------|:---------------|:----------------------|:-----|
| Loki Operator | `stable-5.5` | Manual         | `loki-operator.5.5.5` |      |


OCP コンソールにcluster-admin roleのある管理者ユーザーでログインし、左側のメニューからOperator -> OperatorHubを選択します。

検索ボックスで「Loki」という文字列を入力して、「Loki Operator」をクリックします。
![2023-01-05-01-31-13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/d2583ebc-68aa-2e72-8656-1080430f1097.png)

「Loki Operator」画面で「インストール」をクリックします。
![2023-01-05-01-31-40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/7ba2a9f9-2529-10e7-6f5b-765c548f9834.png)

「Operatorのインストール」ページで、「クラスター指定のnamespace」を選択します。デフォルトのopenshift-operators-redhatが表示されており、存在しない場合は自動で作成されます。

その他、「インストールモード」や「更新の承認」などは以下のように設定しました。
設定をしたら「インストール」をクリックします。

| 設定項目            | デフォルト値                                               | 設定値   | 備考                                                                                                                                                        |
|:--------------------|:------------------------------------------------------|:---------|:------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 更新チャネル            | `stable-5.5`                                          | デフォルトのまま | `candidate`、`stable`、`stable-5.5`が表示。バージョンを明示的に指定したので、`stable-5.5`を選択                                                                              |
| インストールモード           | クラスターの特定のnamespace                                  | デフォルトのまま |                                                                                                                                                             |
| インストール済みのnamespace | Operator推奨のnamespace (`openshift-operators-redhat`) | デフォルトのまま |                                                                                                                                                             |
| 更新の承認           | 自動                                                  | 手動     | (※)実案件ではコンポーネントのバージョンは明確に管理する必要があったり、アップデートするタイミングを業務外にする必要があることがあります。<br>そのような場合には、自動でチャネル内の最新のパッチバージョンに更新されないようにするため「手動」にしたりします。 |

![2023-01-05-01-32-44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/b84cdc2a-74d8-44d7-d163-450678a1f669.png)

「承認」をクリックします。
![2023-01-05-01-33-29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/ee646531-e60c-f306-ad32-e1a62ea278a0.png)

`openshift-operators-redhat` namespaceに`Loki Operator`がインストールされたことを確認します。
![2023-01-05-01-35-36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/d4d7e699-a927-787d-8a62-bf12d33f46fd.png)
![2023-01-05-01-36-24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/427ee14c-833f-2c74-1e69-adcd653a15f9.png)


```bash
[root@bastion-01 ~]# oc get pod -n openshift-operators-redhat -o wide
NAME                                               READY   STATUS    RESTARTS   AGE    IP            NODE        NOMINATED NODE   READINESS GATES
elasticsearch-operator-7dcf99db4d-v2w99            2/2     Running   16         24d    10.131.0.2    worker-02   <none>           <none>
loki-operator-controller-manager-b976b54dc-kmvsc   2/2     Running   0          3m6s   10.128.2.27   infra-02    <none>           <none>
[root@bastion-01 ~]#
```

### (2) LokiStackカスタムリソースの作成

LokiStackのカスタムリソースのマニフェストを作成します。

LokiStackのカスタムリソースの例は[OCP 4.11 Docs / ロギング / 5. Loki / 5.2. Lokistack のデプロイ](https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.11/html-single/logging/index#logging-loki-deploy_cluster-logging-loki)にありました。


#### ドキュメントに記載の設定(ODFの場合)

とりあえずベースの設定はドキュメントに従い以下のようになります。

- LokiStackのカスタムリソースの名前は`logging-lokistack`としました。

- `.spec.size`は今回はサイジングのところで検討したように`1x.small`を指定しました。

- `.spec.storageClassName`については、LokiStackはオブジェクトストレージだけではなく、Ingester(logging-lokistack-ingester)、Index Gateway(logging-lokistack-index-gateway)、Compactor(logging-lokistack-compactor)のコンポーネントのStatefulsetがBlock (volumeMode: Filesystem)の永続ボリュームを使用していました。

- この永続ボリュームを切りだすためにODFの`ocs-storagecluster-ceph-rbd`のストレージクラスを指定する必要がありました。

- 作成するnamespaceは`openshift-logging`にしています。

- storageのschemasは、Loki OperatorのDocsを見ると、version v12とv11というのがあるようでしたが、OCPのドキュメント通りに記載しています。

- `.spec.storage.secret`は、[Loki Operator Docs / LOKISTACK / Object Storage / OpenShift Data Foudation](https://loki-operator.dev/docs/object_storage.md/#openshift-data-foundation)を参照して、LokiStack用のオブジェクトバケットの接続用のSecretの名前を指定します。ODFの場合もtypeは`s3`を指定します。

- ドキュメントにはない設定として、`.spec.managementState: Managed`を付け加えています。


**該当部分の設定(ドキュメント記載部分(ODFの場合))**
```yaml
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-lokistack
  namespace: openshift-logging
spec:
  tenants:
    mode: openshift-logging
  managementState: Managed
  storage:
    storage:
      schemas:
      - version: v12
        effectiveDate: '2022-06-01'
    secret:
      name: loki-object-bucket
      type: s3
  size: 1x.small
  storageClassName: ocs-storagecluster-ceph-rbd
```


ただし、上述のOCPのロギングのドキュメントの設定だけでは、うまくいきませんでした。追加で必要なのは以下の2点です。


#### 追加設定(1) LokiStackのコンポーネントをInfra node (運用コンポーネント上)で稼働させる

今回、LokiStackのコンポーネントは、Infra node (運用コンポーネント)上で、稼働させたいと思います。

そのためには、LokiStackのコンポーネントに、nodeSelectorの設定と、もしInfra nodeにTaintが付与されていたら、tolerationの設定もする必要があります。

そのやり方はOCPのドキュメントには記載がありませんが、Loki Operatorのドキュメントの方に記載がありました。

- [Loki Operator Docs / LOKI OPERATOR / API](https://loki-operator.dev/docs/api.md/)


| link                                                                                                                                       | description                                                          | notes                                                                                                                  |
|:-------------------------------------------------------------------------------------------------------------------------------------------|:---------------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------|
| [Loki Operator Docs / LOKI OPERATOR / API / LokiTemplateSpec](https://loki-operator.dev/docs/api.md/#loki-grafana-com-v1-LokiTemplateSpec) | LokiStackのコンポーネントの一覧、このコンポーネント毎にnodeSelector、torelationの設定が必要 | LokiStackのコンポーネントは`compactor`、`distributor`、`ingester`、`querier`、`queryFrontend`、`gateway`、`indexGateway`、`ruler`が存在 |
| [Loki Operator Docs / LOKI OPERATOR / API / LokiTemplateSpec](LokiComponentSpec)                                                           | コンポーネント毎の`nodeSelector`、`tolerations`の記載方法                      | 今回はInfra node (運用コンポーネント)にTaintをつけていなかったのでnodeSelectorだけ設定                                                       |

(補足) OCPコンソールのAPI ExprolerでもLokiStackのスキーマを確認することができます。
![2023-01-04-18-13-58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/8c788627-dc21-e24a-d4a7-c4fb1e31f16b.png)

今回の環境では、Infra nodeとして、運用コンポーネント(内部レジストリ、ルーター、モニタリング、ロギング)用のInfra nodeと、ODF専用のInfra node (storage node)を別個に作成しています。


アプリケーションPodを運用コンポーネント用のInfra nodeとODF専用のInfra node (storage node)で稼働させないようにするために、以下の設定をしていました。

- Infra node (運用コンポーネント用) は taintをつけず、nodeSlectorのみで設定 (参考: [Qiita / OpenShiftでMachine Config Pool (MCP) を使用してInfra nodeを作成する](https://qiita.com/t_sweetfish/items/a81d23f85c2c18326755)の[(1) nodeSelectorのみを使用](https://qiita.com/t_sweetfish/items/a81d23f85c2c18326755#1-nodeselector%E3%81%AE%E3%81%BF%E3%82%92%E4%BD%BF%E7%94%A8) 参照)
- Infra node (ODF専用) もInfra nodeのMCPに属しているため、Infra nodeのnodeSelectorを指定した運用コンポーネントがInfra node (ODF専用)上で稼働しないようにInfra node (ODF専用)にだけ、Taintを付与 (参考: [Qiita / ベアメタルUPIのOpenShift 4.11に、OpenShift Data Foudation (ODF)をインストールする](https://qiita.com/t_sweetfish/items/d81cf4da2681c131e6da)の[(4) ODF専用のInfra nodeのTaintの設定](https://qiita.com/t_sweetfish/items/d81cf4da2681c131e6da#4-odf%E5%B0%82%E7%94%A8%E3%81%AEinfra-node%E3%81%AEtaint%E3%81%AE%E8%A8%AD%E5%AE%9A) 参照)


従って、今回の環境ではInfra node (運用コンポーネント)にはTaintをつけていなかったので、LokiStackの各コンポーネントを明示的に明記してそれぞれnodeSlectorの設定を入れる必要がありました。

**該当部分の設定(nodeSelector)**
```yaml
spec:
  (略)
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
```


#### 追加設定(2) オブジェクトバケットのEndpointに接続するためのTLSの設定

最初何も設定しないでLokiStackカスタムリソースを作成してCluster Loggingの構成をしたら以下のようなエラーでオブジェクトバケットへの接続が失敗していました。。

```log
level=error ts=2022-12-29T11:36:20.020307886Z caller=flush.go:146 org_id=infrastructure msg="failed to flush user" err="store put chunk: RequestError: send request failed\ncaused by: Put \"https://s3.openshift-storage.svc:443/loki-object-bucket-a93ab5a3-ce69-4dd1-960c-b896215f48f0/infrastructure/b82cb2425feb7b89%3A1855daab0be%3A1855daab169%3Ac413371f\": x509: certificate signed by unknown authority"
```

原因は、ODFのオブジェクトバケットのendpointは、`https://s3.openshift-storage.svc:443`だったので、このendpointに接続するためのTLSの設定が必要だったからのようです。

デフォルトでは、OCPクラスターのサービスCA証明書(`service-ca.crt`)と同じものを設定する必要があるようでした。


設定箇所は以下に記載があります。

| link                                                                                                                                               | description                                          | notes                                                                                                                                                                                                                                                             |
|:---------------------------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| [Loki Operator Docs / LOKI OPERATOR / API / ObjectStorageSpec](https://loki-operator.dev/docs/api.md/#loki-grafana-com-v1-ObjectStorageSpec)       | `.spec.storage.tls`                                  | オブジェクトバケットのendpointに接続するTLSの設定箇所                                                                                                                                                                                                                            |
| [Loki Operator Docs / LOKI OPERATOR / API / ObjectStorageTLSSpec](https://loki-operator.dev/docs/api.md/#loki-grafana-com-v1-ObjectStorageTLSSpec) | `.spec.storage.tls.caKey` <br> `.spec.storage.tls.caName` | `caKey`: LokiStackと同じnamespaceにあるConfigMap内のサービスCA証明書。デフォルトではOCPのサービスCA証明書(`service-ca.crt`) <br><br> `caName`: OCPのサービスCA証明書を含むConfigMap名。デフォルトでは`openshift-logging` namespaceも含む、全namespaceに`openshift-service-ca.crt`という名前のConfigMapがあるのでこれを指定。 |

![2023-01-04-18-15-16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/752b1643-d921-78e4-780b-24beb509a3dc.png)

```bash
[root@bastion-01 ~]# oc get configmap -n openshift-logging
NAME                       DATA   AGE
kube-root-ca.crt           1      176d
openshift-service-ca.crt   1      176d
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get configmap -n openshift-logging openshift-service-ca.crt -o yaml
apiVersion: v1
data:
  service-ca.crt: |
    -----BEGIN CERTIFICATE-----
    (略)
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  annotations:
    service.beta.openshift.io/inject-cabundle: "true"
  creationTimestamp: "2022-07-12T13:17:54Z"
  name: openshift-service-ca.crt
  namespace: openshift-logging
  resourceVersion: "143840"
  uid: 1ffccb65-2745-44df-88ac-d418a476d324
[root@bastion-01 ~]#
```

上述を加味すると設定を以下のようにしてみました。

**該当部分の設定(TLS)**
```yaml
spec:
  (略)
  storage:
    storage:
      schemas:
      - version: v12
        effectiveDate: '2022-06-01'
    secret:
      name: loki-object-bucket
      type: s3
    tls:
      caKey: "service-ca.crt"
      caName: "openshift-service-ca.crt"
```

#### 最終的な設定

上述を全て合わせたLokiStackのマニフェストファイルは以下のようにしました。

```bash
[root@bastion-01 logging]# vi lokistack.yaml
[root@bastion-01 logging]# cat lokistack.yaml
```
```yaml
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-lokistack
  namespace: openshift-logging
spec:
  tenants:
    mode: openshift-logging
  managementState: Managed
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
  storage:
    storage:
      schemas:
      - version: v12
        effectiveDate: '2022-06-01'
    secret:
      name: loki-object-bucket
      type: s3
    tls:
      caKey: "service-ca.crt"
      caName: "openshift-service-ca.crt"
  size: 1x.small
  storageClassName: ocs-storagecluster-ceph-rbd
```

(OCPのロギングのドキュメントだけ見てもわからないのはなかなかハードでした。。。)


#### LokiStackのマニフェストの適用

作成したマニフェストファイルを適用します。

```bash
oc apply -f lokistack.yaml
```

(出力例)
```bash
[root@bastion-01 logging]# oc apply -f lokistack.yaml
lokistack.loki.grafana.com/logging-lokistack created
[root@bastion-01 logging]#
```


確認します。

```bash
oc get lokistack -n openshift-logging
oc get pod -n openshift-logging -o wide
```
```bash
oc get statefulset -n openshift-logging
oc get deployment -n openshift-logging
oc get daemonset -n openshift-logging
oc get pod -n openshift-logging -o wide
```

(出力例)
```bash
[root@bastion-01 logging]# oc get lokistack -n openshift-logging
NAME                AGE
logging-lokistack   20s
[root@bastion-01 logging]#
```
```bash
[root@bastion-01 logging]# oc get statefulset -n openshift-logging
NAME                              READY   AGE
logging-lokistack-compactor       1/1     61s
logging-lokistack-index-gateway   2/2     61s
logging-lokistack-ingester        0/2     61s
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get deployment -n openshift-logging
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
cluster-logging-operator           1/1     1            1           176d
logging-lokistack-distributor      2/2     2            2           72s
logging-lokistack-gateway          1/1     1            1           72s
logging-lokistack-querier          2/2     2            2           72s
logging-lokistack-query-frontend   2/2     2            2           72s
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get daemonset -n openshift-logging
No resources found in openshift-logging namespace.
[root@bastion-01 logging]#
```
```bash
[root@bastion-01 logging]# oc get pod -n openshift-logging -o wide
NAME                                                READY   STATUS    RESTARTS   AGE    IP            NODE        NOMINATED NODE   READINESS GATES
cluster-logging-operator-d6cd9585b-mvcpv            1/1     Running   8          23d    10.131.0.8    worker-02   <none>           <none>
logging-lokistack-compactor-0                       1/1     Running   0          108s   10.129.2.18   infra-03    <none>           <none>
logging-lokistack-distributor-7c4ccc589-kppj6       1/1     Running   0          108s   10.129.2.16   infra-03    <none>           <none>
logging-lokistack-distributor-7c4ccc589-zncp8       1/1     Running   0          108s   10.130.2.19   infra-01    <none>           <none>
logging-lokistack-gateway-cbcb87447-49bwj           2/2     Running   0          107s   10.129.2.17   infra-03    <none>           <none>
logging-lokistack-index-gateway-0                   1/1     Running   0          108s   10.128.2.30   infra-02    <none>           <none>
logging-lokistack-index-gateway-1                   1/1     Running   0          80s    10.129.2.19   infra-03    <none>           <none>
logging-lokistack-ingester-0                        1/1     Running   0          108s   10.130.2.21   infra-01    <none>           <none>
logging-lokistack-ingester-1                        0/1     Running   0          43s    10.128.2.31   infra-02    <none>           <none>
logging-lokistack-querier-7f7d45c747-l7xd7          1/1     Running   0          108s   10.129.2.15   infra-03    <none>           <none>
logging-lokistack-querier-7f7d45c747-q67vz          1/1     Running   0          108s   10.128.2.28   infra-02    <none>           <none>
logging-lokistack-query-frontend-6f674d9458-ffnzm   1/1     Running   0          108s   10.128.2.29   infra-02    <none>           <none>
logging-lokistack-query-frontend-6f674d9458-l6ckd   1/1     Running   0          108s   10.130.2.20   infra-01    <none>           <none>
[root@bastion-01 logging]#
```





永続ボリュームは以下のものができていました。

```bash
oc get pvc -n openshift-logging
```

(出力例)
```bash
[root@bastion-01 logging]# oc get pvc -n openshift-logging
NAME                                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
storage-logging-lokistack-compactor-0       Bound    pvc-a1274593-7864-4ce4-826f-6a1c809dbc76   10Gi       RWO            ocs-storagecluster-ceph-rbd   2m36s
storage-logging-lokistack-index-gateway-0   Bound    pvc-d3d6b2b2-e14d-4a5c-9a46-d1b668ce8bd5   50Gi       RWO            ocs-storagecluster-ceph-rbd   2m36s
storage-logging-lokistack-index-gateway-1   Bound    pvc-3e3abe0f-90fb-4116-b643-f7dcada73612   50Gi       RWO            ocs-storagecluster-ceph-rbd   2m8s
storage-logging-lokistack-ingester-0        Bound    pvc-f97a47b6-b76c-41be-b8d5-0f4273dc2111   10Gi       RWO            ocs-storagecluster-ceph-rbd   2m36s
storage-logging-lokistack-ingester-1        Bound    pvc-5517c083-4115-438d-850e-69e8748f0fb0   10Gi       RWO            ocs-storagecluster-ceph-rbd   91s
wal-logging-lokistack-ingester-0            Bound    pvc-b96220ee-4671-4b6e-bde2-2449c9a5016d   150Gi      RWO            ocs-storagecluster-ceph-rbd   2m36s
wal-logging-lokistack-ingester-1            Bound    pvc-1efa22ea-6ceb-4ca1-96dc-28538c711e6d   150Gi      RWO            ocs-storagecluster-ceph-rbd   91s
[root@bastion-01 logging]#
```





### (3) ClusterLoggingカスタムリソースの作成(lokistackのデプロイ、vectorの有効化)


ClusterLoggingのカスタムリソースを作成します。


#### ドキュメントに記載の設定 

今回はLoki + vectorを導入するので、logStoreとして、`lokistack`、collectionとして`vector`を指定しています。

`.spec.collection`の部分の書き方が少し違いました。(後述)

**該当部分の設定(ドキュメント記載部分(ODFの場合))**

```yaml
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: "openshift-logging"
spec:
  managementState: Managed
  logStore:
    type: lokistack
    lokistack:
      name: logging-lokistack
  collection:
    logs:
      type: "vector"
```

そしてやはりこれだけではダメでした。

#### 追加設定(1) Torerationsの設定(vector)

考慮点として、`vector`はdaemonsetとして全てのnode上で稼働する必要があります。

master node上で稼働するための`tolerations`はデフォルトで入っていましたが、その他のnodeにTaintが入っている場合は、`tolerations`の設定を入れる必要があります。

今回はODF専用のInfra nodeに`taint`の設定が入っているので、vectorに対して`tolerations`の設定が必要でした。


fluetdの場合は`tolerations`の設定は [OCP 4.11 Docs / ロギング / 4. ロギングデプロイメントの設定 / 4.7. 容認を使用した OpenShift Logging Pod 配置の制御 / 4.7.3. 容認を使用したログコレクター Pod 配置の制御](https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.11/html-single/logging/index#cluster-logging-collector-tolerations_cluster-logging-tolerations) に記載がありましたが、vectorの場合はここと同じように設定してもうまくいきませんでした。。

OCPのドキュメントにも、OCPのコンソールのAPI ExplorerでClusterLoggingのスキーマを見ても設定箇所の記載がありませんでしたが、ClusterLogging OperatorのCSVの中にそれっぽい設定の記載を見つけました。
```bash
[root@bastion-01 ~]# oc get csv -n openshift-logging
NAME                           DISPLAY                            VERSION   REPLACES                       PHASE
cluster-logging.5.5.5          Red Hat OpenShift Logging          5.5.5     cluster-logging.5.4.2          Succeeded
elasticsearch-operator.5.5.5   OpenShift Elasticsearch Operator   5.5.5     elasticsearch-operator.5.4.9   Succeeded
loki-operator.5.5.5            Loki Operator                      5.5.5                                    Succeeded
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get csv -n openshift-logging cluster-logging.5.5.5 -o yaml
```
```yaml
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  (略)
  name: cluster-logging.5.5.5
  namespace: openshift-logging
  (略)
spec:
  apiservicedefinitions: {}
  cleanup:
    enabled: false
  customresourcedefinitions:
    (略)
    - description: A Red Hat OpenShift Logging instance. ClusterLogging is the Schema
        for the clusterloggings API
      displayName: Cluster Logging
      kind: ClusterLogging
      name: clusterloggings.logging.openshift.io
      (略)
      specDescriptors:
      - description: Define which Nodes the Pods are scheduled on.
        displayName: Collector Node Selector
        path: collection.logs.nodeSelector
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:selector:core:v1:ConfigMap
      - description: The resource requirements for the collector
        displayName: Collector Resource Requirements
        path: collection.logs.resources
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:resourceRequirements
      - description: Define the tolerations the Pods will accept
        displayName: Collector Pod Tolerations
        path: collection.logs.tolerations
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:selector:core:v1:Toleration
      - description: Define which Nodes the Pods are scheduled on.
        displayName: Collector Node Selector
        path: collection.nodeSelector
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:selector:core:v1:ConfigMap
      - description: The resource requirements for the collector
        displayName: Collector Resource Requirements
        path: collection.resources
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:resourceRequirements
      - description: Define the tolerations the Pods will accept
        displayName: Collector Pod Tolerations
        path: collection.tolerations
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:selector:core:v1:Toleration
      - description: The type of Log Collection to configure
        displayName: Collector Implementation
        path: collection.type
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:select:fluentd
        - urn:alm:descriptor:com.tectonic.ui:select:vector
(略)
```

適当にこの辺を参考にして、今回は試しに以下のように設定してみました。
(正しいかは不明です。`.spec.collection.logs.type: "vector"`でもうまくいきましたが、`tolerations`は`collection`の下にしないダメでした。)

```yaml
spec:
  (略)
  collection:
    tolerations:
    - effect: NoSchedule
      key: node.ocs.openshift.io/storage
      value: "true"
    type: "vector"
```


#### 最終的な設定

上述を全て合わせたClusterLoggingのマニフェストファイルは以下のようにしました。

```bash
[root@bastion-01 logging]# vi clo-instance-5.5-lokistack.yaml
[root@bastion-01 logging]# cat clo-instance-5.5-lokistack.yaml
```
```yaml
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: "openshift-logging"
spec:
  managementState: Managed
  logStore:
    type: lokistack
    lokistack:
      name: logging-lokistack
  collection:
    tolerations:
    - effect: NoSchedule
      key: node.ocs.openshift.io/storage
      value: "true"
    type: "vector"
```


#### ClusterLoggingのマニフェストの適用

作成したマニフェストファイルを適用します。

```bash
oc apply -f clo-instance-5.5-lokistack.yaml
```
(出力例)
```bash
[root@bastion-01 logging]# oc apply -f clo-instance-5.5-lokistack.yaml
clusterlogging.logging.openshift.io/instance created
[root@bastion-01 logging]#
```

確認します。

```bash
oc get clusterlogging -n openshift-logging
```
```bash
oc get statefulset -n openshift-logging
oc get deployment -n openshift-logging
oc get daemonset -n openshift-logging
oc get pod -n openshift-logging -o wide
```

(出力例)
```bash
[root@bastion-01 logging]# oc get clusterlogging -n openshift-logging
NAME       MANAGEMENT STATE
instance   Managed
[root@bastion-01 logging]#
```


LokiStackはすでに入っていたので、colectionとしてvectorがdaemonsetとして追加されました。
```bash
[root@bastion-01 logging]# oc get statefulset -n openshift-logging
NAME                              READY   AGE
logging-lokistack-compactor       1/1     6m10s
logging-lokistack-index-gateway   2/2     6m10s
logging-lokistack-ingester        2/2     6m10s
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get deployment -n openshift-logging
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
cluster-logging-operator           1/1     1            1           176d
logging-lokistack-distributor      2/2     2            2           6m20s
logging-lokistack-gateway          1/1     1            1           6m20s
logging-lokistack-querier          2/2     2            2           6m20s
logging-lokistack-query-frontend   2/2     2            2           6m20s
logging-view-plugin                1/1     1            1           79s
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get daemonset -n openshift-logging
NAME        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
collector   11        11        11      11           11          kubernetes.io/os=linux   76s
[root@bastion-01 logging]#
```
vectorはtolerationsの設定が効いて、ODF専用のInfra node上でも稼働しています。
```bash
[root@bastion-01 logging]# oc get pod -n openshift-logging -o wide
NAME                                                READY   STATUS    RESTARTS   AGE     IP            NODE         NOMINATED NODE   READINESS GATES
cluster-logging-operator-d6cd9585b-mvcpv            1/1     Running   8          23d     10.131.0.8    worker-02    <none>           <none>
collector-642qp                                     2/2     Running   0          74s     10.128.0.40   master-01    <none>           <none>
collector-64rd4                                     2/2     Running   0          75s     10.129.4.23   storage-02   <none>           <none>
collector-6kbmt                                     2/2     Running   0          74s     10.128.4.24   storage-01   <none>           <none>
collector-dzszj                                     2/2     Running   0          74s     10.129.2.21   infra-03     <none>           <none>
collector-mqj9p                                     2/2     Running   0          75s     10.130.2.23   infra-01     <none>           <none>
collector-ncgcq                                     2/2     Running   0          75s     10.131.2.12   worker-01    <none>           <none>
collector-njxcf                                     2/2     Running   0          74s     10.129.0.44   master-02    <none>           <none>
collector-r6878                                     2/2     Running   0          74s     10.131.0.13   worker-02    <none>           <none>
collector-s6hs7                                     2/2     Running   0          74s     10.130.0.57   master-03    <none>           <none>
collector-sv5hq                                     2/2     Running   0          74s     10.130.4.27   storage-03   <none>           <none>
collector-xhwqj                                     2/2     Running   0          75s     10.128.2.33   infra-02     <none>           <none>
logging-lokistack-compactor-0                       1/1     Running   0          6m45s   10.129.2.18   infra-03     <none>           <none>
logging-lokistack-distributor-7c4ccc589-kppj6       1/1     Running   0          6m45s   10.129.2.16   infra-03     <none>           <none>
logging-lokistack-distributor-7c4ccc589-zncp8       1/1     Running   0          6m45s   10.130.2.19   infra-01     <none>           <none>
logging-lokistack-gateway-cbcb87447-49bwj           2/2     Running   0          6m44s   10.129.2.17   infra-03     <none>           <none>
logging-lokistack-index-gateway-0                   1/1     Running   0          6m45s   10.128.2.30   infra-02     <none>           <none>
logging-lokistack-index-gateway-1                   1/1     Running   0          6m17s   10.129.2.19   infra-03     <none>           <none>
logging-lokistack-ingester-0                        1/1     Running   0          6m45s   10.130.2.21   infra-01     <none>           <none>
logging-lokistack-ingester-1                        1/1     Running   0          5m40s   10.128.2.31   infra-02     <none>           <none>
logging-lokistack-querier-7f7d45c747-l7xd7          1/1     Running   0          6m45s   10.129.2.15   infra-03     <none>           <none>
logging-lokistack-querier-7f7d45c747-q67vz          1/1     Running   0          6m45s   10.128.2.28   infra-02     <none>           <none>
logging-lokistack-query-frontend-6f674d9458-ffnzm   1/1     Running   0          6m45s   10.128.2.29   infra-02     <none>           <none>
logging-lokistack-query-frontend-6f674d9458-l6ckd   1/1     Running   0          6m45s   10.130.2.20   infra-01     <none>           <none>
logging-view-plugin-56865f7d4d-86gcw                1/1     Running   0          104s    10.131.2.10   worker-01    <none>           <none>
[root@bastion-01 logging]#
```


### (4) ログコンソールプラグインの有効化

OCPのコンソールにロギングのメニューを統合するログコンソールプラグインを有効にします。


OCP コンソールの、左側のメニューからOperator -> インストール済みのOperatorを選択します。
左上のプロジェクトを`openshift-logging`に変更し、「RedHat OpenShift Logging」 Operatorを選択します。

「詳細」タブの右側の「コンソールプラグイン」の下の「無効」のリンクをクリックします。
![2023-01-05-01-52-32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/09795b3e-be2a-9f0d-7285-6f6f42ac1aa3.png)

表示される「コンソールプラグインの有効化」の画面で「無効にする」から「有効にする」に変更し「保存」をクリックします。
![2023-01-05-01-52-54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/00b34bbd-202c-0d93-ea46-444dfaf49510.png)

「コンソールプラグイン」の下の「無効」のリンクが「有効化」という文字列に変わります。
しばらくするとconsoleのPodが再作成されるので「Web コンソールの更新を利用できます。」のメッセーが表示されるので「Webコンソールの更新」のリンクをクリックするか、手動でブラウザを更新します。
![2023-01-05-01-53-30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/3853fbea-294b-e41e-261e-4bd752a7e63e.png)

OCPコンソールの左側の「監視」メニューの下に「Logs」のメニューが追加されます。
「Logs」をクリックすると「Logs」の画面が表示されます。
![2023-01-05-01-54-37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/c92024fc-50ec-488e-1d86-69a06ecbd999.png)


## 確認
### (1) ログの確認

ログの種別としてapplications、infrastructure、auditが選択できます。
- infrastructureに変更するとinfrastructure関連のログが表示されます。
![2023-01-05-01-55-09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/f34d0b4b-be61-1193-ba56-1031c577f831.png)
![2023-01-05-01-55-32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/f0e9e3e6-fffd-7ee6-2486-26b1cfd63ca1.png)


Content、Namespaces、Pods、Containersなどで検索をすることもできます。
- Contentの場合は任意の文字列でログを検索できます。
- Namespaces、Pods、Containresを選択した場合はFilterのプルダウンでNamespace、Pod、Containerの一覧が出てくるので、一つまたは複数選択してログをフィルターして確認できます。
![2023-01-05-01-56-05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/19546101-40c5-5982-9e88-05f88cbee169.png)


Severityもcritical、error、warning、debug、info、trace、unknownなどを一つまたは複数選択できます。
![2023-01-05-01-56-21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/6c7b5ddb-6cd8-5378-f71a-6cae9227c9d1.png)



infrastructureの横のShow Resourcesを選択すると、ログのエントリーにログの関連リソースが明記されます。
右上のShow Histogramをクリックするとグラフ表示もされます。
![2023-01-05-01-57-24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/0f38eda7-9978-ec25-1d1b-6f3bbaee08c5.png)

(もう少し時間が経って表示した場合のHistgramの例)
![2023-01-05-02-03-13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/1259d1ee-2b14-5cb5-ba0c-bb69e3ff45ee.png)


Show Queryをクリックすると上述の選択でどのようなQueryをしているのかが確認できます。
![2023-01-05-01-57-47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/8215a1a6-ccaf-ab79-74dd-a200abb18c63.png)


また、アプリケーションPod用のnamespaceのログがあった場合は、ログの種別としてapplicationを選択することで表示することができます。
![2023-01-05-02-05-39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/f9b816a3-4747-f448-35e7-57c25a2a56bd.png)


# その他

Object Storageを使っているかは、Data Foudationの画面から確認できます。

(以下は導入から4-5日たった時のキャプチャです。また、バッキングストアの容量を300GiBではなく、余裕を持ってボリューム数を4、ボリュームサイズを100Giの、合計400Giで作成していた時のキャプチャです。)
![2023-01-04-17-45-34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/49295cf1-2bdc-d915-c09d-54767c5fa2d5.png)

OCPコンソールの左側のメニューからストレージ -> Data Foudationを選択して「ストレージシステム」タブを選択し、表示されるストレージシステムのエントリー(`ocs-storagecluster-storagesystem`)をクリックします。
![2023-01-04-17-45-56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/59816dc7-780a-4f8b-84fa-bce9688999a5.png)


表示される`ocs-storagecluster-storagesystem`画面の「概要」タブの「ブロック及びファイル」でODFの提供するストレージ全体でどの程度の容量が使用されているかが確認できます。
![2023-01-04-17-47-01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/66530ce0-d4f4-4645-8986-d9fd5882effb.png)
![2023-01-04-17-47-48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/f22f2956-a056-6b1b-eae0-f4cacf118847.png)


「Object」タブを選択すると、ObjectStorageのMulticloud Object Gateway 経由で使用しているバケットの容量が確認できます。
![2023-01-04-17-48-22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/2f3cfb09-f468-b9a9-62f7-9281aaa9b460.png)
![2023-01-04-17-49-02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/ab5f9f66-6974-d31b-a531-52972e0836d2.png)


LokiStackのコンポーネントのPVCや、ODFのバッキングストアのバックエンドのPVCの容量は、ストレージ -> 永続ボリューム要求画面で確認できます。
![2023-01-04-17-49-40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/c83230db-02f9-75ec-53a2-8eca44582da6.png)
![2023-01-04-17-50-10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/4ffe5b4d-276f-de55-bf6a-e1b34c732d44.png)



参考までにメトリクス欄で使用されている容量を表示すると、以下の感じでした。

メトリクス例 (`openshift-storage` namespaceのPVC)
```
sum(kubelet_volume_stats_used_bytes{namespace="openshift-storage"}) by (namespace, persistentvolumeclaim) / (1024 * 1024 * 1024)
```
Lokistack用のバッキングストアのバックエンドのPVC x4 のディスク使用量は少しづつ増えている。  
アプリケーションPodが何もいない状態で、1週間でトータル70GiB程度。
![2023-01-04-17-58-30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/f117bf1a-383b-0e86-64ae-509a03f7aff0.png)
![2023-01-04-17-59-03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/f688e799-547f-3f52-15d5-86cb1325dd8b.png)
![2023-01-04-17-59-22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/2a5d6945-a863-e929-9b25-0e55805cc321.png)
![2023-01-04-17-59-39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/891ee889-9cb0-a255-7b95-e68384f7e689.png)
![2023-01-04-18-00-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/ee29dab6-51cb-f22c-f9eb-4d06cd1f256e.png)


メトリクス例 (`openshift-logging` namespaceのPVC)
```
sum(kubelet_volume_stats_used_bytes{namespace="openshift-logging"}) by (namespace, persistentvolumeclaim) / (1024 * 1024 * 1024)
```
ログが多くない状況ではそこまで容量は多く使われていないようでした。
![2023-01-04-17-54-41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/8c2ca017-3e01-d3f8-ac4f-36079d9fa606.png)
![2023-01-04-17-55-24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/363bf921-1427-468f-dcbe-f8e144467c8e.png)
![2023-01-04-17-55-43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/c498d295-5a2f-5a39-aa2d-e37b887c3eab.png)
![2023-01-04-17-56-12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/ddfc512b-0e90-f2da-ebae-66513bdf0aed.png)
![2023-01-04-17-56-33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/50bfdc23-311d-7f6d-cf03-81c1d208adb3.png)


なお、何日間かログが貯まった後に、Loggingの画面は`Last 1 hours`の場合は、Histgramは表示されるのですが、`Last 2 hours`の場合は、タイムアウトのエラーで表示されませんでした。
この辺のチューニング方法はいずれ調べる必要があるかなと思います。

`Last 1 hours`の場合
![2023-01-04-18-03-25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/34fa17b3-cc8f-c70a-609d-4ba9ae3f3bbe.png)

`Last 2 hours`の場合
![2023-01-04-18-04-39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/9d86b910-b9af-0e3e-d701-13d81a204d3a.png)