はじめに
2025年3月よりLog Analysis、Activity Trackerのサービスが終了し、Cloud Logsへ移行された方も多いと思います。
少額利用であればあまり気にされない方もいるかもしれませんが、費用が数万円、数十万円となってくると、ログ収集のサービスにいったいどんなログを送っているのか確認したいところです。
しかし、IBM Cloudの使用量のページにはCloud Logsのインスタンス毎に、サービス機能別(Store＆Search、7日間高速検索等)の使用総量(GB)の確認は可能ですが、何から送られてきたものか？は見ることができません。Cloud Logsのダッシュボードから確認しましょう。
ダッシュボードにアクセスしよう
ダッシュボードにアクセスしたは良いですが、どこを確認するべきでしょうか？
左側のメニューにUsageがあり、その中で Data usage を選択してください。
Data usage
下記のような画面が表示されます。
デフォルトではその月の日毎の集計データ量が表示されます。
右上の集計期間は次の3つから選ぶことができます。
- Current month
- Last 30 days
- Last 90 days
グラフ内のバーにカーソルを当てると内容について少し表示されますが、これではどこから収集されたログなのかを判断することはできないです。
右下にある Export as CSV を選択してください。
Exportの条件を確認されますが、必ず Detailed usage report を指定するようにしてください。期間は先ほどの集計期間と同じように3つから選択することが出来ます。
Exportをすると次のようにzipで圧縮されたファイルがダウンロードされます。
中にCSVファイルがあるので確認しましょう。
CSVの見方
ダウンロードされたCSVファイルは次のような内容になります。
これはログ転送された日の Application Subsystem Severity Priority 単位で集計されているので、内容を確認する際は注意してください。
Date
ログがCloud Logsに転送された日付です。
Application
これは内容が多岐に渡ります、Cloud LogsのAgentを導入してApplication名を指定すればその名称が表示されますし、OpenShiftやKubernetes環境に導入している場合、Namespace名がここに表示されます。
重要なものとして ibm-audit-event があります。これは従来のActivity Trackerで収集していたようなIBM Cloud自体や各サービスに対する監査ログになります。
data-usage-to-metrics metric-metadata <空欄>がありますが、これは内容を見る限り課金対象にならずCloud Logsの内部的に利用されて集計されている項目のようです。
全体の使用量を把握する際には除外して良い項目になります。
Subsystem
これはCloud Logsの転送元の情報が出ています。例えばICOSであれば cloud-object-storage:XXXXXXX-XXXXXX-XXXXXX-XXXX (XXXXX-...はインスタンスID)というように、どのICOSのインスタンスから転送されているか判断することができますし、VPCの操作であれば is.network といったどういった操作なのかの傾向を把握することもできます。
Severity
Agentを導入したログもそうですし、PaaSのログやIBM Cloudの操作ログに対してSeverityが設定されており、どのSeverityのログが出たのかがわかります。以下のパターンがあります。
debug Verbose Info Warnning Error Critical
転送されたログがこれのどれかに分類される形なので、実際に転送されるログのSeverityが上記に該当しないケースもあります。
例えば、ICOSでの操作ログで正常な場合、Cloud Logsに転送されるSeverityは Normal になりますが、Cloud Logsでは Info 扱いとなって集計されています。
Priority
これは次のいずれかになります。
- High : 高速ストレージ保管&検索の対象となっているログ
- Middle : ログはICOS保管ですが、監視アラートを上げられるログ
- Low : ICOS保管されダッシュボードで検索だけ可能なログ
- Block : TCO Optimizerで処理しない対象としたログ
Blockのログは、Cloud LogsのUsage Reportには入ってきますが、課金対象としては集計外になります。費用発生元を探す場合は考慮不要になりますので注意してください。
Policy name/Parsing rule
TCO Optimizerで作成したPolicyに合致する場合は、こちらにそのPolicyが表示されます。
type
これは Logs と metrics の2つがあります。metricsはApplicationの説明に記載したdata-usage-to-metrics metric-metadata <空欄> が該当する項目になります。使用状況の調査の場合はこの metrics の項目は除外するようにしましょう。
GB sent
これはCloud Logsとして処理したログデータ量(GB)になります。
内容を確認する上での注意(再掲)
単純なサービス利用調査の場合もありますが、多くは費用発生元の確認等であれば、費用に関与しない項目は見ない必要があります。
つまり、 typeの項目で metrics の項目は確認対象外、Priorityで Block にしているログは対象外にする必要があります。
この上で GB sentの合計の大きいものが、費用発生の元と言えるでしょう。
費用発生元の原因がわかったらどうするか？
まずはTCO Optimizerでの制御を考慮する必要があります。
TCO Optimizerでは、先ほどの項目である Application Subsystem Severityを指定して、それに該当するログを、例えばなるべく価格の低い Low (保管と検索のみ)に転送することや、そもそも Block にしてCloud Logsでは処理しない、という方法もあります。
見る必要のないログについては Block にしてなるべく処理しないようにするのが良いです。例えばICOSに対するAudit Eventはアプリケーションがファイルを参照したり配置したりするたびに書き込まれるので、すごい量になります。細かくバケットの指定や、誰の操作か、といった指定はできないですが、INFOログは権限を有する人が操作したログではあるので、そこは収集しない、といった判断も必要かもしれません。
もう1点できることを考慮するならば、送信元での制御です。
先に話したICOSの場合、Cloud Logsへの転送について少し制御が可能です。
バケット単位になりますが、下記のようにバケットへの 読み取り 書き込み Management Data Eventの送信可否を選択できます。
残しておきたいログが書込みや、バケットの設定変更等であれば、読み取りの送信設定はオフにして、Cloud Logsに転送されるログ量を減らすというのも1つの手段になります。
送信元で削減する手段があれば、そちらも検討してみましょう。
さいごに
いかがでしたでしょうか？Cloud Logsは以前のLog AnalysisやActivity Trackerとは異なり、ログの保存期間に制限が無かったり、サービスの設定が細かくなっていますが、逆に設定を最適化しないと変に課金が発生する可能性があります。
利用状況を正しく確認して、予期せぬ費用が発生しないよう注意して頂ければ幸いです。