はじめに
今回の記事ではIBM Cloud LogsのTCO Optimizerについての簡単なご紹介とTCO Optimizerを構成する流れについて作成しています。
すでにIBM Cloud Logsのインスタンスを作成していることを前提としていますので、必要に応じて以下の記事もご参考ください。
①【IBM Cloud】 Log AnalysisからCloud LogsへのLogs Routingサービス変更の流れ
②【IBM Cloud】 Activity TrackerからCloud LogsへのActivity Tracker Event Routing設定変更の流れ
③【IBM Cloud】 Log AnalysisからCloud Logsへのマイグレーションの流れ
なお、今回の内容にはIBM Cloudのアカウント（無料利用可能）も前提となっています。
TCO Optimizerとは
TCO Optimizerとは、IBM Cloud Logsのログに優先度をつけることでログの表示方法や保管方法を設定し、ログ運用やコストの最適化を実現することができる機能です。
例えば、優先度の高いログにはホットストレージを利用した高速なログ検索、優先度の低いログは低コストで保管、など、ユーザーから定義したポリシーに伴ってログの優先度を選択することができます。
- Store and search（保管および検索）、Low
- ICOSに対するログ保管・検索が可能
- 例：監査に必要なログ
- Analyze and alert（分析とアラート）、Medium
- 上記機能に加え、アラート通知や処理が必要なログ保管
- 例：監視や統計分析に使用されるログ
- Priority insights（優先順位の洞察）、High
- ログを期間限定でSSDに保管 (7〜90日間で指定)
- 保管期間に応じて、課金額が変更
- 上記2つの機能に加え、高速検索・クエリ実行が可能
- 例：優先度の高いログまたはビジネス・クリティカルなログ
Analyze and alertやPriority insightsのアラート機能を利用する場合は、別途Event Notificationsを立ち上げ、IBM Cloud Logsインスタンスと統合させる必要があります。
構成の流れ
まずはすでに作成されたIBM Cloud Logsダッシュボードに入り、データ・パイプライン→TCO optimizerをクリックします。
現在のTCO Optimizerで設定されている優先度が表示されます。
デフォルト設定は Priority insights（High）になっていますので、もしTCO Optimizerの設定を実施したことがなければ、基本全てのログがPriority insights（High） 100%と表示されているかと思います。
そのため、今回の構成の流れとしては表示させたいログやイベントはデフォルトのHighのままにし、あまり重要ではない項目をStore and search（Low）に設定する流れで操作しています。
下段のAdd new policyをクリックします。
ポリシーの設定画面が表示されますが、ここでポリシー名を適宜設定し、設定を行う対象を選択します。
なお、ApplicationsおよびSubsystemsの設定では、値がAll、Is、Is Not、Includes、またはStarts With の条件を利用することができて、これは条件に当てはまるログを表示させるためのフィルター機能と理解いただくとイメージしやすいかと思います。
設定自体は非常に簡単で、Applications、Subsystems、Severitiesの３項目を入力し、最後重要度を選択する流れとなりますが、ここでApplicationsはログやイベントのルーティング設定などによって作成されたアプリケーション（ibm-platform-logs、ibm-audit-eventなど）であり、Subsystemsはそのログとイベントの括りとなります。最後にSeveritiesは「debug」や「info」などのログの重要度となります。
まずはApplications設定を行いますが、上記の通り値とアプリケーションを選択します。今回は値をIs、対象アプリケーションは過去の記事にてLog Analysisから引っ張ってきたログデータであるibm-platform-logsを選択しています。
Subsystemsでは値をStarts With、項目はcontainers-kubernetesに設定しました。なお、こちらの項目は他にもdatabases-for-postgresqlなど、設定したい項目を適宜書き込むことができます。
Severitiesの設定ですが、上記の通り今回の検証はコスト削減のため重要ではないログをStore and search（Low）に変更する前提のため、表示させなくてもいいinfoとwarning（正常稼働状態を想定）のみ選択しています。繰り返しとなりますが、ここでも重要度に沿って表示させたい項目、表示させなくてもいい項目などがあれば修正いただいても構いません。
最後に優先度の設定ですが、上記のApplications、Subsystems、Severitiesで設定した値の優先度を設定する画面となります。ここで前提のようにLowを選択します。
注意：verbose/info/warningなどのSeverityが付与されていないログを受信した場合は、その重要度がdebugとして扱われます。
全てのポリシー設定が完了したら、右上のApplyをクリックします。
ポリシー設定後、ダッシュボードをリフレッシュすると、パイプラインの割合が変更されたことを確認できます。繰り返しとなりますが、Store and search（Low）は重要度が低い分、ログ管理機能も最小限で安価なため、このようにコストの最適化を実現することができます。
