【IBM Cloud】 Log AnalysisからCloud LogsへのLogs Routingサービス変更の流れ

## はじめに
2024年6月頃、IBM Cloudでは既存の監視ツールであるLog AnalysisとActivity Trackerの後継サービスであるIBM Cloud LogsをFrankfurtとMadridリージョンにGAし、2024年9月にはTokyoとOsakaリージョンでGAされました。
そのため、既存のLog AnalysisとActivity Trackerのインスタンスを後継のCloud Logsに移行する検証を行いました。

今回は既存のログがLog Analysisに表示されるように設定されていたLogs Routing機能をCloud Logsに表示されるように設定変更する流れを整理します。

:::note warn
Log AnalysisとActivity Trackerは2025年3月30日でEOSされる予定です。
そのため、EOSまでに既存インスタンスのマイグレーションが必要となりますので、ご注意ください。
:::

また、今回の内容にはIBM Cloudの[アカウント](https://cloud.ibm.com/docs/account?topic=account-accounts)（無料利用可能）が前提となっています。

## Logs Routing機能とは
![スクリーンショット 2024-09-30 15.35.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/26e4096b-5d97-fdaf-0b80-4c3e66629f8f.png)
Logs Routingとは、プラットフォームログやAgentからのログを特定のインスタンス（Cloud Logs、Cloud Log Analysis）に送信できるように設定する機能です。これによって、複数リージョンから発生するログを一つのインスタンスに集約することができます。

現在、Cloud Logs Routingは以下のリージョンで使用可能です。
- 東京、大阪、シドニー、ダラス、ワシントンDC、トロント、フランクフルト、ロンドン、マドリッド、サンパウロ

## 全体的な流れ
まずはLogs Routing設定をする事前準備として、必要な各インスタンス（IBM Cloud Object Storage、Cloud Logs）を以下の手順に沿って作成し、インスタント間のマウント設定を行います。
### IBM Cloud Object Storage（ICOS）のインスタンス作成
ログデータの永続化のためには保管ストレージとしてICOSが必要でるため、まずはICOSインスタンスを作成します。
ICOS画面にて`インスタンスの作成`をクリックします。
![スクリーンショット 2024-07-11 17.19.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/f3e791d5-e4fa-6b8c-1f63-033a7e838412.png)
インフラの選択やインスタンス名、リソースグループなどの設定を行ってインスタンスを作成します。
![FireShot Capture 008 - Cloud Object Storage - IBM Cloud - cloud.ibm.com.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/ae4d4473-d2b4-1911-008c-c37102528c80.png)

ICOSのインスタンスが作成されたら、次は「バケット」を作成します。
「バケット」とは、インタンス内で実際ログデータが保管される論理的区域であり、名前通りデータを入れておく箱のようなものとなります。

まずは`バケットの作成`をクリックします。
![スクリーンショット 2024-07-11 17.20.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/8955139f-37aa-e773-3e8d-3c9acaea3840.png)

Quick Startテンプレートを含め、複数のテンプレートが用意されていますが、今回はカスタムテンプレートにて作成しました。
![スクリーンショット 2024-07-11 17.21.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/d89934ba-8432-f7b3-b307-fb1963f15dbe.png)

バケット名や可用性の設定、リージョン、Storage Tierなどを設定し、バケットを作成します。こちらの設定はバケット作成後には変更ができませんのでご注意ください。
なお、今回の検証を実施した際にはまだ国内リージョンがGAされる前だったため、フランクフルト（eu-de）リージョンで作成しています。
![FireShot Capture 009 - Cloud Object Storage - IBM Cloud - cloud.ibm.com.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/3900cd59-cdd1-4615-1ef6-2a9ed6542f16.png)

### Cloud Logsのインスタンス作成
次は上記の通りログデータを集約するためのCloud Logsのインスタンスを作成します。
コンソールでロギングインスタンスにアクセスすると、既存のLog Analysisに加え、Cloud Logsのカテゴリーが新たに表示されています。ここで`作成`をクリックします。
![スクリーンショット 2024-07-11 17.04.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/c9088c77-3f44-b304-a498-4cd844f1fae7.png)

また、リージョンはICOSと同様にフランクフルトに設定し、7日間の保管で作成しています。こちらの設定はご用件に応じて適宜可能です。
![FireShot Capture 002 - Cloud Logs - IBM Cloud - cloud.ibm.com.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/d77dc402-25ad-5bf3-e59c-84cd62bc3c02.png)
![スクリーンショット 2024-07-11 17.13.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/26718c07-d337-c531-ab4a-8e7f63d8ebf0.png)

インスタンスが作成されたら、Cloud Logsからのログデータを永続的に保管するためにCloud LogsとICOSを間でマウントさせる必要があります。
Cloud Logsインスタンスのストレージタブに入って`ログ・データ`→`接続`にて、使用するICOSのバケットとマウントします。
なお、`メトリック・データへのイベント`はActivity Trackerからのイベントを接続する項目となり、今回は使用しません。

:::note info
こちらの段階ではS2S許可が前提となります。もしS2S許可前の場合、`サービス許可が必要です`という画面が表示されるケースがありますが、`今すぐ許可`をクリックするとインスタンスが表示されます。
もしうまくいかない場合、[S2S許可の作成](https://cloud.ibm.com/docs/cloud-logs?topic=cloud-logs-iam-service-auth-cos&interface=ui)を参考ください。
:::

![スクリーンショット 2024-07-11 17.50.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/64ce8e1f-c572-0fab-9371-481112e402f8.png)
先ほど作成したICOSのインスタンスを検索し、使用するバケットを選択して接続します。
![スクリーンショット 2024-07-11 17.52.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/8d6adb01-3df3-2de9-2aed-20f8c3067db4.png)

### Cloud Logs Routingの設定
次はリージョンで収集されたプラットフォームログのターゲットの宛先を定義します。

「ルーティング」タブにアクセスすると、各リージョンごとの宛先インスタンスを設定することができます。
現在はリージョンごとの`ルールの状況`に「未構成」と表示されていますが、こちらのルールを構成する必要があり、今回は前の段階で作成したCloud Logsのインスタンスに全て絞って設定しています。
まずは`︙`ボタンをクリックし、Logs Routingのターゲット設定画面に入ります。
![スクリーンショット 2024-07-11 17.59.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/8f809a83-a5a5-bdd7-0dec-9f7107ef3101.png)
その後、ログを流すターゲット・インスタンスを選択します。今回はCloud Logsに集約しますので、先ほど作成したCloud Logsインスタンスを選択します。
![スクリーンショット 2024-07-11 18.00.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/c90e7116-16fc-d08a-7d12-11ba5a8eeecb.png)
全てのターゲット・インスタンスを設定すると、以下のように「ルールの状況」部分に`アクティブ`マークが付くようになり、問題なくルール設定できたことがわかります。
![スクリーンショット 2024-07-11 18.02.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/3747a1ae-005e-7279-7b94-bffbcac2bd76.png)
これでインスタンスの作成とLogs Routingの設定は完了です。

### ログの確認
マイグレーション実行から少し時間が経ったら、最初デプロイしてCloud LogsとマウントしたICOSのバケットにデータが入ってきていることがわかります。
![FireShot Capture 010 - Cloud Object Storage - IBM Cloud - cloud.ibm.com.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/5a663588-3603-cab0-c728-fde02906e262.png)
また、Cloud Logsのダッシュボードを確認したら、デプロイした時間からのログが記録されていることがわかります。
![スクリーンショット 2024-07-11 20.38.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/89adec1b-dea5-7dd9-f07d-aaaac7cc449f.png)
![スクリーンショット 2024-07-11 20.40.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/32175e31-8b88-8a33-a918-42eff3837876.png)
![スクリーンショット 2024-07-11 20.40.52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2626032/fa98c8b5-3fa0-d2a5-d6d2-bd8bc80bae2f.png)

ログの内容を既存のLog Analysisのログと比較してみたところ、`correlationId` `generation` `logSourceCRN` `messageID` `msg_timestamp` `requestId` など、Log Analysisログと表示される内容が全く同じであることも確認でき、違和感なくすぐ利用することができるかと思います。

## 参考
IBM Cloud Docs
- https://cloud.ibm.com/docs/cloud-logs?topic=cloud-logs-getting-started
- https://cloud.ibm.com/docs/logs-router?topic=logs-router-getting-started
- https://cloud.ibm.com/docs/cloud-logs?topic=cloud-logs-migration-instance-resources