How to Size Log Topics in the Avassa Edge Platform

In this blog post, I will describe how to properly size log topics in an Avassa system. Log topics are critical for capturing and reviewing logs from applications and system components, but without proper sizing, they can either consume too much disk space or fail to retain enough history when you need it most.

“We just turned logging on — and then it filled everything up”

A recent conversation with a user highlighted a common pitfall: they had enabled logging on several applications but never adjusted the default sizing of their log topics. A few days later, they discovered that important logs had already been rotated out. This wasn’t due to a bug — just an oversight in configuration.

This scenario is surprisingly easy to fall into. While Avassa’s log system is efficient and self-regulating, it relies on you to define the upper limits for each log topic. These limits — configured through the container-log-size and the container-log-max-days parameters — are what prevent logs from filling up the local disk or disappearing too quickly. In this post, I’ll show you how to size your log topics for predictable retention and reliable operation.

How to Configure Log Topic Sizing in Avassa

Each log topic in Avassa has several configurable properties — one of the most important being max-size, which controls how much disk space the topic is allowed to use per host before older logs are deleted.

If we look at an application log topic, we can see the note the max-size , by default this is 100Mb

supctl show --site robot-cluster volga topics system:container-logs:s3-client.s3-client-1.s3-client

name: system:container-logs:s3-client.s3-client-1.s3-client
tenant: the-company
labels:
  container-name: s3-client
  service-instance: s3-client-1
  service-name: s3-client
  archive-days: "14"
  application: s3-client
  archive: "false"
format: string
max-size: 95.37 MiB
creation-time: 2025-08-18T09:10:15.264Z
requested-replication-factor: 1
current-replication-factor: 1
persistence: disk
assigned-hosts:
  - stockholm-2
unsynced-hosts: []
leader-host: stockholm-2
worker-hosts: []
size: 2.3 MiB
entries: 9357
oldest-entry: 2025-08-18T09:10:18.744Z
last-entry: 2025-08-20T08:38:32.318Z
seqno: 9357
chunkno: 3
dropped-chunks: 0
producers:
  - name: system:container-logs:s3-client.s3-client-1.s3-client-robot-cluster-002
    site: robot-cluster
    host: stockholm-2
consumers: []

You control these settings in the application specification.

name: myapp
services:
  - name: mysvc
    containers:
      - name: mydb
        container-log-size: 100 MiB
        container-log-max-days: 14

It’s also important to understand that the application logs are always stored on the host where the application is running.

How to Calculate a Good container-log-size Value

The container-log-size field determines how much log data is retained per topic. When this limit is reached, the oldest entries are deleted.

Let’s say your application logs about 300 KB per minute and you want to retain 12 hours of logs:

300 KB × 60 minutes × 12 hours = 21600 KB = ~21 MiB

In this case, set container-log-size: 25 MiB to give yourself a bit of buffer.

If you deploy this topic across 50 nodes, your total potential log footprint becomes:

25 MiB × 50 nodes = 1250 MiB (~1.2 GiB)

So you get predictable log retention per host and know what the maximum disk footprint will be across your system.

The container-log-max-days can be further set to possibly purge old logs before the size limit is reached. Note though, container-log-size is always respected.

Conclusion

Sizing log topics might seem like a small detail, but it’s essential for operational clarity and efficient disk usage. With Avassa, setting the right container-log-size ensures that logs are preserved long enough to be useful — without overwhelming your edge nodes. You may also need to place containers that log a lot on hosts with enough disk capacity. Typically this is done using service placement.