保持期間別の保存容量
| 保持期間 | 保存容量 |
|---|
| 7日 | 314.5GB（292.9GiB） |
|---|
| 30日 | 1.348TB（1.226TiB） |
|---|
| 90日 | 4.044TB（3.678TiB） |
|---|
| 365日 | 16.4TB（14.91TiB） |
|---|
報告・見積もり用テキスト
500events/sec、平均800B/event、保持期間30日、係数1.3倍で見積もると、必要な保存容量は約1.348TB（1.226TiB）です。
生ログ量は1日あたり約34.56GB（32.19GiB）、取り込み帯域の目安は約3.2Mbpsです。
実際の容量はインデックス、圧縮、メタデータ、レプリカ数、フィールド抽出、保持階層により変わります。
この結果はログ基盤や監視基盤の初期容量見積もり用の概算です。
計算例
計算式
保存容量 = events/sec * bytes/event * 86,400秒 * 保持日数 * 保存係数。保存係数はインデックス、メタデータ、レプリカ、圧縮差分をまとめて扱うための概算係数です。
入力項目の見方
- イベント数は平均またはピーク時のログ発生数です。余裕を見たい場合はピーク寄りに設定します。
- 平均イベントサイズはログ1件あたりの平均バイト数です。
- 保存係数は圧縮で小さくなる場合も、インデックスやレプリカで大きくなる場合もあります。
実務で使う場面
- SIEMやlog platformの初期保存容量を概算するとき。
- retention変更時に、7日、30日、90日、365日の容量差を比較するとき。
- 収集帯域とstorage requirementを同じ入力条件から見積もるとき。
- replicaやindex overheadを保存係数へ含め、複数scenarioを比較するとき。
結果の読み方
- 必要な保存容量は、1日あたり生ログへ保持日数と保存係数を適用した値です。
- 1日あたり生ログは保存係数適用前、取り込み帯域はraw log payloadをbit/secへ換算した概算です。
- storageはdecimalのGB/TBとbinaryのGiB/TiBを併記します。
- 保持期間比較は、同じevents/sec、event size、保存係数を7日、30日、90日、365日へ適用します。
- 表示値は読みやすく丸めているため、容量設計の概算として読みます。
注意事項
- 平均events/secだけではpeak burstや障害時の急増を表しません。
- 保存係数はcompression ratio単体ではなく、index、metadata、replicaなどをまとめる概算係数です。
- field extractionやstorage tierによっても実容量は変わります。
- protocol overhead、TLS、batch、queue trafficは取り込み帯域へ含めません。
- retention設定が、期限到達時の即時削除を保証するわけではありません。
- backup、snapshot、replication先の容量は別途見積もってください。
- growthと運用headroomを別途確保し、ベンダー実測値がある場合は実測を優先してください。
- この概算値は実際の保存容量を保証しません。
関連ツールと次の流れ
- 監視データ容量計算metricsのseries数と収集間隔から監視データ容量を見積もります。
- Syslog帯域見積syslog転送時の帯域と日次データ量を別条件で確認します。
- 容量成長計算現在使用量と成長率からcapacity到達時期を見積もります。
- バックアップ保持世代計算保存基盤のbackup世代数と保持容量を別途計画します。
実務上の注意
- ログ基盤ではインデックス、圧縮、メタデータ、レプリカ数、保持階層により実容量が大きく変わります。
- ピークEPS、障害時のログ急増、監査要件の保持期間も容量設計に含めてください。
- この計算は概算です。実際のログサンプルから平均サイズと圧縮率を確認すると精度が上がります。