Mackerelのログ機能は気軽に試し始めることができますが、本格的に運用する際にはデータ量とコストの見通しを立てておくことが大切です。このヘルプでは、ログの課金の仕組み、データ量の見積もり方、利用状況の確認方法について説明します。
いきなりすべてのサービスのログを送信するのではなく、まずは小さく始めて見積もることをおすすめします。
Mackerelのログ機能は現在β版として提供しています。以下の点についてはあらかじめご了承ください。
- 今後、仕様や画面デザインが変更される可能性があります。
- 機能改善や不具合修正のために、臨時のメンテナンスを実施する場合があります。
- お預かりしているログデータの保持を保証することはできません。
- β版期間中は課金対象にはなりませんが、投稿量等に制限をかけさせていただくことがあります。
目次
ログの課金の仕組み
インジェスト課金とは
Mackerelのログ機能では、インジェスト（取り込み）量に基づいて課金されます。すなわち、Mackerelに送信されたログデータのサイズ（バイト数）が計測対象です。
ポイントは、保存期間やクエリの実行回数ではなく、送信したデータ量によってコストが決まるという点です。つまり、送信するログの量をコントロールすることが、コスト管理のカギになります。
なお、このヘルプおよび料金ページで使用しているGB・TBなどの単位は、10の累乗を基準とした国際単位系（SI）表記です（1GB = 109バイト、1TB = 1012バイト）。ログファイルのサイズを確認する際、OSのコマンドやツールによっては2の累乗を基準としたGiB・TiBで表示されることがあり、同じ数値でも約7%の差が生じるため、見積もりの際はご注意ください。
OpenTelemetryログのデータサイズに影響する要素
Mackerelのログ機能はOpenTelemetry（以下、OTel）形式でログを扱います。OTel形式のログには、アプリケーションが出力したメッセージ本文だけでなく、さまざまな属性やメタデータが含まれます。
ログ1件あたりのデータには、以下の要素が含まれます。
- タイムスタンプ：ログが記録された日時
- Severity Number：ログの重要度を示す数値（1〜24）
- サービス名：ログを送信したサービスの名前
- リソース属性：
service.name、service.version、host.nameなど、ログの送信元を識別するための情報 - ログ属性：OTel SDKやログブリッジが自動的に付与する属性のほか、アプリケーションコードで付与したカスタム属性（リクエストID、ユーザーIDなど）やエラー発生時のバックトレースも含まれます
- ログ本文（
msg）：アプリケーションが出力したメッセージそのもの
ログ本文以外のデータによるサイズの増加
ここで注意しておきたいのは、OTel形式のログデータは、アプリケーションが出力した元のログよりもサイズが大きくなるという点です。
例えば、アプリケーション側で100バイト程度のログメッセージを出力した場合でも、リソース属性やログ属性などのメタデータが付加されることで、実際のインジェスト量は数倍になることがあります。特に、アプリケーションコードで多くのカスタム属性を付与している場合や、バックトレースを含むエラーログが多い場合は、データサイズが膨らみやすくなります。
このため、アプリケーションのログ出力量だけを基準にコストを見積もると、実際のインジェスト量との間にギャップが生じる可能性があります。次のセクションで紹介する方法で、実際のインジェスト量を確認しながら見積もりを行いましょう。
小さく始めて見積もる
まず1サービス・1日で試す
全サービスのログを一度に送信するのではなく、まずは1つのサービスで1日だけログを送信してみることをおすすめします。この短期検証で、以下の情報を把握できます。
- 1日あたりのログ件数
- 1日あたりのインジェスト量（データサイズ）
- ログの重要度の分布（INFOが大半を占めるのか、ERRORがどの程度含まれるのか）
1日分のデータがあれば、月間のコストを概算するための基礎データとして十分です。
見積もりの計算方法
1日の検証結果から、月間のインジェスト量を概算してみましょう。基本的な計算式は次のとおりです。
1日のインジェスト量 x 30日 x サービス数 = 月間インジェスト量（概算）
例えば、1つのサービスで1日あたりのインジェスト量が500MBだった場合、そのサービス単体の月間概算は 500MB x 30日 = 15GB です。同様の構成のサービスが5つあれば 15GB x 5 = 75GB が月間の目安になります。
ただし、いくつか注意点があります。
- トラフィック量による変動：ログの出力量は、アプリケーションの処理量やアクセス数に応じて変動します。検証日がピーク日なのか平常日なのかによって結果が変わるため、ピーク時間帯のデータも確認しておくと安心です
- サービスごとの差異：サービスによってログの出力量や属性の数は異なります。主要なサービスについては、それぞれ個別に検証することをおすすめします
利用状況を確認する
Webコンソールでの確認方法
Mackerelのオーガニゼーションページの「利用状況」タブで、前日までのインジェスト量を日次で確認できます。
送信を開始したら、定期的にこの画面をチェックして、想定どおりの推移になっているかを確認しましょう。
想定より多い場合のチェックポイント
インジェスト量が想定よりも多い場合は、以下の点を確認してみてください。
- ログレベルの見直し：DEBUGやTRACEレベルのログが大量に含まれていないか確認してください。開発時に有効にしたログレベルがそのまま残っていることがあります
- 不要なログの確認：ヘルスチェックやポーリングによる定期的なログが大量に出力されていないか確認してください。これらは件数が多くなりやすく、インジェスト量を押し上げる要因になります
- 属性の見直し：リソース属性やログ属性が過剰に付与されていないか確認してください。不要な属性を減らすことで、1件あたりのデータサイズを削減できます
データ量を削減するための具体的な方法については、「フィルタリングとサンプリングによるログデータ量の最適化」ヘルプで詳しく説明しています。
送信を始める前の注意事項
ログ送信を始める前に、以下のポイントを意識しておくと、想定外のコスト発生を防ぐことができます。
段階的に送信する
まずは1つのサービスで検証し、データ量やコストを把握してから、他のサービスに広げていきましょう。一度にすべてのサービスのログを送信すると、想定以上のインジェスト量になった場合に対応が難しくなります。
本番環境への送信は検証後に
最初はステージング環境やカナリア環境など、本番以外の環境で試すことをおすすめします。本番環境は一般的にトラフィックが多く、ログの出力量も大きくなるため、まずは規模の小さい環境で感覚をつかんでおくと安心です。
ログレベルを意識する
開発環境でDEBUGやTRACEレベルを有効にした設定を、そのまま本番環境に適用しないよう注意してください。DEBUGレベルのログは件数が非常に多くなることがあり、インジェスト量が大幅に増加する原因になります。
定期的に利用状況を確認する
ログ送信を開始した後は、しばらくの間、Webコンソールのインジェスト量確認画面を定期的にチェックする習慣をつけましょう。アプリケーションの変更やトラフィックの変化によって、ログの出力量が増減することがあります。
まとめ
ログ機能を本格的に活用するうえで、データ量とコストの見通しを立てておくことは重要です。
- 小さく始める：まずは1つのサービスで1日だけ送信し、インジェスト量を把握してから範囲を広げましょう
- 利用状況を定期的に確認する：Webコンソールでインジェスト量の推移を把握しておくことで、想定外のコストを防げます
- データ量が多い場合は最適化を検討する：フィルタリングやサンプリングを活用することで、必要なログだけを効率的に送信できます。詳しくは「フィルタリングとサンプリングによるログデータ量の最適化」ヘルプをご覧ください
まずは1つのサービスから始めて、データ量の感覚をつかんでみてください。
