Problems processing old SystemOut log files with Grafana-Loki-Alloy stack

Hi community.

I’m new to the Grafana-Loki-Alloy stack. I have a local deployment of the stack in containers, and it’s working correctly.

I want to use the stack to process SystemOut.log files from an IBM WebSphere platform on a monthly basis. Since the processing is monthly, I need to be able to process older log files, ideally maintaining a history of at least 60 days, so I can compare results from one month to the next.

My file structure is similar to:

./alloy ← stack configurations (docker-compose.yaml, config.alloy, loki-config.yaml)
./logs/2026-01/SystemOut*.log ← files to process

Initially, I tried processing the log files separately. Then, using a bash script, I opted to group the files, sort them by date, and generate a single output file for processing like:

./logs/2026-01/CPE.log

In both cases, almost all of the log entries were excluded due to the “timestamp too old” error.

Some examples of logs I’m trying to process are as follows:

[u713] [C-CPE04] [1/13/26 16:23:38:062 CLST] 0000dccb webapp        E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[ListenerNst]: com.filenet.api.exception.EngineRuntimeException: FNRCE0066E: E_UNEXPECTED_EXCEPTION: An unexpected exception occurred. Message was: null
[u713] [C-CPE04] [1/13/26 16:24:18:662 CLST] 000000b3 HardwareInfoC W   ASPS0023W: The logical partition on which this node resides has a mode of shared, a type of uncapped, but performance collection is not enabled.
[u712] [C-CPE03] [1/13/26 16:30:24:236 CLST] 00003da9 LocalTranCoor E   WLTC0017E: Resources rolled back due to setRollbackOnly() being called.
[u712] [C-CPE03] [1/13/26 16:30:24:236 CLST] 00003da9 webapp        E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[ListenerNst]: com.filenet.api.exception.EngineRuntimeException: FNRCE0066E: E_UNEXPECTED_EXCEPTION: An unexpected exception occurred. Message was: null
[u713] [C-CPE02] [1/13/26 16:32:36:028 CLST] 00006b5c LocalTranCoor E   WLTC0017E: Resources rolled back due to setRollbackOnly() being called.

My configuration file for Alloy is:

livedebugging {
  enabled = true
}

// ----------------------------------------------------------------------------
// Procesamiento de logs WAS
// ----------------------------------------------------------------------------
loki.source.file "was" {
	targets = [{
		__path__ = "/var/log/*/CPE.log",
		__path_exclude__ = ".*\\.lck$",
	}]
  forward_to = [loki.process.was.receiver]

  file_match {
    enabled = true
    sync_period = "10s"
  }

  tail_from_end = false
  encoding = "UTF-8"
}

loki.process "was" {
  stage.regex {
    expression = "/var/log/(?P<year>\\d{4})-(?P<month>\\d{2})/"
    source     = "filename"
  }

  stage.static_labels {
    values = {
      type = "SystemOut",
    }
  }

  stage.labels {
    values = {
      year  = "",
      month = "",
    }
  }

  stage.multiline {
    firstline = "^\\[([^\\]]+)\\]\\s+\\[([^\\]]+)\\]\\s+\\[\\d{1,2}\\/\\d{1,2}\\/\\d{2}"
    max_lines = 500
    max_wait_time = "3s"
  }

  // Extraer campos del header del log
  stage.regex {
    expression = "^\\[(?P<host>[^\\]]+)\\]\\s+\\[(?P<jvm>[^\\]]+)\\]\\s+\\[(?P<timestamp>[^\\]]+)\\]\\s+(?P<thread>\\S+)\\s+(?P<category>\\S+)\\s+(?P<level>[A-Z])\\s+(?P<class>\\S+)\\s+(?P<method>[^ ]+)\\s*(?P<message>.*)"
  }

 stage.timestamp {
    source = "timestamp"
    format = "1/2/06 15:04:05:000 MST"
    fallback_formats = [
      "01/02/06 15:04:05:000 MST",
      "1/2/2006 15:04:05:000 MST",
      "01/02/2006 15:04:05:000 MST",
    ]
  }

  stage.labels {
    values = {
      host = "",
      jvm = "",
      level = "",
    }
  }

  // Eliminar líneas vacías o muy cortas, solo aplicar a logs que ya tienen source_type definido (ya clasificados).
  stage.match {
    selector = "{source_type=~\".+\"}"
    
    // descartar líneas completamente vacías o solo con espacios
    stage.drop {
      expression = "^\\s*$"
      drop_counter_reason = "linea_vacia"
    }
    
    // descartar lineas que contengan el patrón
	  stage.drop {
      expression = ".*SystemOut     O (XML|.get).*"
      drop_counter_reason = "patron detectado"
	  }
  }

  // Rate limiting para evitar sobrecarga
  stage.limit {
    rate  = 10000
    burst = 20000
    drop  = true
  }

  forward_to = [loki.write.default.receiver]
}

loki.write "default" {
	endpoint {
		url = "http://loki:3100/loki/api/v1/push"
	}
	external_labels = {}
}

My configuration for Loki is:

---
# This is a complete configuration to deploy Loki backed by the filesystem.
# The index will be shipped to the storage via tsdb-shipper.

auth_enabled: false

limits_config:
  allow_structured_metadata: true
  volume_enabled: true
  reject_old_samples: false
  reject_old_samples_max_age: 12w

server:
  http_listen_port: 3100

common:
  ring:
    instance_addr: 0.0.0.0
    kvstore:
      store: inmemory
  replication_factor: 1
  path_prefix: /tmp/loki
  storage:
    filesystem:
      chunks_directory: /tmp/loki/chunks
      rules_directory: /tmp/loki/rules

schema_config:
  configs:
    - from: 2020-05-15
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

storage_config:
  tsdb_shipper:
    active_index_directory: /tmp/loki/index
    cache_location: /tmp/loki/index_cache
  filesystem:
    directory: /tmp/loki/chunks

pattern_ingester:
  enabled: true

# Note: We are setting the max chunk age far lower than the default expected value
# This is due to the fact this scenario is used within the LogCLI demo and we need a short flush time.
# To show how logcli stats --since 24h '{service_name="Delivery World", package_size="Large"}' works.
ingester:
  max_chunk_age: 5m  # Should be 2 hours

I would greatly appreciate your help in identifying where my problem lies, as I haven’t been able to find a solution yet. The example and configurations I’ve attached are for processing the single unified file. If it’s advisable to revert to separate processing, I have no problem reverting my configuration.

Thank you in advance for your help.

Regards.
Sergio

You’ll get “timestamp is good old” error from Loki if you send logs to a stream where newer logs already exist. This is because of how Loki stores chunks.

This happens to me from time to time as well, especially when I am testing a data stream, the easiest way to get around this is to just add a new label to your alloy configuration so that a new stream is created instead of using the same one.

For example, let’s say your first ingestion attempt you use label set app=123,hostname=myhost. And you want to test ingestion again, you can then do app=123,hostname=myhost,attempt=2, this will allow you to get around the timestamp too old error.

Hi @tonyswumac … First of all, thanks for replying.

I understand your point, but the problem occurs even if I start my stack for the first time and load only my consolidated log file, sorted by date. In that case, I should never find older logs as I process the log file. Unless Alloy splits it into parts and sends it to Loki in parallel over multiple threads (I don’t know if that’s how it works).

Thanks again for your help.
Sergio

Curious, how many alloy instances are you running?

Can you give me a sample scenarios where you can consistently reproduce your problem, please? I’ll see if i can run some tests for you.

Hi @tonyswumac… I’m running only one instance of Alloy, and as I mentioned before, every time I try to process data, I start from scratch, removing my containers to ensure my environment is clean.

My complete configuration files for Alloy and Loki are in the case description. I also included some sample log lines to validate the data parsing. If you need more examples, I can attach them without any problem.

I’m including my docker-compose file. It’s almost standard.

---
# version: '3.8'

services:
  alloy:
    image: grafana/alloy:latest
    ports:
      - 12345:12345
      - 4318:4318
    volumes:
      - ../logs:/var/log
      - ./config.alloy:/etc/alloy/config.alloy
    command: run --server.http.listen-addr=0.0.0.0:12345 --stability.level=experimental --storage.path=/var/lib/alloy/data /etc/alloy/config.alloy
    depends_on:
      - loki

  loki:
    image: grafana/loki:latest
    ports:
      - 3100:3100
    volumes:
      - ./loki-config.yaml:/etc/loki/local-config.yaml
    command: -config.file=/etc/loki/local-config.yaml

  grafana:
    image: grafana/grafana:latest
    environment:
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_AUTH_BASIC_ENABLED=false
    ports:
      - 3000:3000/tcp
    entrypoint:
      - sh
      - -euc
      - |
        mkdir -p /etc/grafana/provisioning/datasources
        cat <<EOF > /etc/grafana/provisioning/datasources/ds.yaml
        apiVersion: 1
        datasources:
        - name: Loki
          type: loki
          access: proxy
          orgId: 1
          url: http://loki:3100
          basicAuth: false
          isDefault: false
          version: 1
          editable: false
        EOF
        /run.sh
    depends_on:
      - loki

Thanks again for your help.

Regards.
Sergio

Can you provide a bit of sample logs?

Hi @tonyswumac sure… I’m copying some examples here. I think I’m not allowed to upload a file.
Regards.

[u713] [C-CPE04] [1/13/26 16:17:44:272 CLST] 0000117e SRTServletRes W com.ibm.ws.webcontainer.srt.SRTServletResponse setHeader SRVE8094W: WARNING: Cannot set header. Response already committed.
[u713] [C-CPE04] [1/13/26 16:17:44:384 CLST] 0000dcd7 SRTServletRes W com.ibm.ws.webcontainer.srt.SRTServletResponse setHeader SRVE8094W: WARNING: Cannot set header. Response already committed.
[u713] [C-CPE04] [1/13/26 16:17:44:384 CLST] 0000dcd7 SRTServletRes W com.ibm.ws.webcontainer.srt.SRTServletResponse setHeader SRVE8094W: WARNING: Cannot set header. Response already committed.
[u713] [C-CPE04] [1/13/26 16:17:44:384 CLST] 0000dcd7 SRTServletRes W com.ibm.ws.webcontainer.srt.SRTServletResponse setStatus WARNING: Cannot set status. Response already committed.
[u713] [C-CPE04] [1/13/26 16:17:44:932 CLST] 000011ab SRTServletRes W com.ibm.ws.webcontainer.srt.SRTServletResponse setStatus WARNING: Cannot set status. Response already committed.
[u713] [C-CPE04] [1/13/26 16:17:44:933 CLST] 000011ab SRTServletRes W com.ibm.ws.webcontainer.srt.SRTServletResponse setHeader SRVE8094W: WARNING: Cannot set header. Response already committed.
[u713] [C-CPE04] [1/13/26 16:17:44:933 CLST] 000011ab SRTServletRes W com.ibm.ws.webcontainer.srt.SRTServletResponse setHeader SRVE8094W: WARNING: Cannot set header. Response already committed.
[u713] [C-CPE04] [1/13/26 16:17:45:014 CLST] 00000226 SRTServletRes W com.ibm.ws.webcontainer.srt.SRTServletResponse setStatus WARNING: Cannot set status. Response already committed.
[u713] [C-CPE04] [1/13/26 16:17:45:015 CLST] 00000226 SRTServletRes W com.ibm.ws.webcontainer.srt.SRTServletResponse setHeader SRVE8094W: WARNING: Cannot set header. Response already committed.
[u713] [C-CPE04] [1/13/26 16:17:45:015 CLST] 00000226 SRTServletRes W com.ibm.ws.webcontainer.srt.SRTServletResponse setHeader SRVE8094W: WARNING: Cannot set header. Response already committed.
[u713] [C-CPE04] [1/13/26 16:17:45:080 CLST] 000011a3 SRTServletRes W com.ibm.ws.webcontainer.srt.SRTServletResponse setHeader SRVE8094W: WARNING: Cannot set header. Response already committed.
[u713] [C-CPE04] [1/13/26 16:17:45:080 CLST] 000011a3 SRTServletRes W com.ibm.ws.webcontainer.srt.SRTServletResponse setStatus WARNING: Cannot set status. Response already committed.
[u713] [C-CPE04] [1/13/26 16:17:45:082 CLST] 000011a3 SRTServletRes W com.ibm.ws.webcontainer.srt.SRTServletResponse setHeader SRVE8094W: WARNING: Cannot set header. Response already committed.
[u713] [C-CPE04] [1/13/26 16:23:38:060 CLST] 0000dccb LocalTranCoor E WLTC0017E: Resources rolled back due to setRollbackOnly() being called.
[u713] [C-CPE04] [1/13/26 16:23:38:060 CLST] 0000dccb ServletWrappe E com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0068E: An exception was thrown by one of the service methods of the servlet [ListenerNst] in application [FileNetEngine]. Exception created : [com.filenet.api.exception.EngineRuntimeException: FNRCE0066E: E_UNEXPECTED_EXCEPTION: An unexpected exception occurred. Message was: null
[u713] [C-CPE04] [1/13/26 16:23:38:062 CLST] 0000dccb webapp E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[ListenerNst]: com.filenet.api.exception.EngineRuntimeException: FNRCE0066E: E_UNEXPECTED_EXCEPTION: An unexpected exception occurred. Message was: null
[u713] [C-CPE04] [1/13/26 16:24:18:662 CLST] 000000b3 HardwareInfoC W ASPS0023W: The logical partition on which this node resides has a mode of shared, a type of uncapped, but performance collection is not enabled.
[u712] [C-CPE03] [1/13/26 16:30:24:236 CLST] 00003da9 LocalTranCoor E WLTC0017E: Resources rolled back due to setRollbackOnly() being called.
[u712] [C-CPE03] [1/13/26 16:30:24:236 CLST] 00003da9 ServletWrappe E com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0068E: An exception was thrown by one of the service methods of the servlet [ListenerNst] in application [FileNetEngine]. Exception created : [com.filenet.api.exception.EngineRuntimeException: FNRCE0066E: E_UNEXPECTED_EXCEPTION: An unexpected exception occurred. Message was: null
[u712] [C-CPE03] [1/13/26 16:30:24:236 CLST] 00003da9 webapp E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[ListenerNst]: com.filenet.api.exception.EngineRuntimeException: FNRCE0066E: E_UNEXPECTED_EXCEPTION: An unexpected exception occurred. Message was: null
[u713] [C-CPE02] [1/13/26 16:32:36:028 CLST] 00006b5c LocalTranCoor E WLTC0017E: Resources rolled back due to setRollbackOnly() being called.
[u713] [C-CPE02] [1/13/26 16:32:36:028 CLST] 00006b5c ServletWrappe E com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0068E: An exception was thrown by one of the service methods of the servlet [ListenerNst] in application [FileNetEngine]. Exception created : [com.filenet.api.exception.EngineRuntimeException: FNRCE0066E: E_UNEXPECTED_EXCEPTION: An unexpected exception occurred. Message was: null
[u713] [C-CPE02] [1/13/26 16:32:36:029 CLST] 00006b5c webapp E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[ListenerNst]: com.filenet.api.exception.EngineRuntimeException: FNRCE0066E: E_UNEXPECTED_EXCEPTION: An unexpected exception occurred. Message was: null
[u713] [C-CPE02] [1/13/26 16:32:59:078 CLST] 00006b6b LocalTranCoor E WLTC0017E: Resources rolled back due to setRollbackOnly() being called.
[u713] [C-CPE02] [1/13/26 16:32:59:078 CLST] 00006b6b ServletWrappe E com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0068E: An exception was thrown by one of the service methods of the servlet [ListenerNst] in application [FileNetEngine]. Exception created : [com.filenet.api.exception.EngineRuntimeException: FNRCE0066E: E_UNEXPECTED_EXCEPTION: An unexpected exception occurred. Message was: null
[u713] [C-CPE02] [1/13/26 16:32:59:078 CLST] 00006b6b webapp E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[ListenerNst]: com.filenet.api.exception.EngineRuntimeException: FNRCE0066E: E_UNEXPECTED_EXCEPTION: An unexpected exception occurred. Message was: null
[u713] [C-CPE02] [1/13/26 16:35:29:789 CLST] 0000182a ServletWrappe E com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0068E: An exception was thrown by one of the service methods of the servlet [ListenerNst] in application [FileNetEngine]. Exception created : [com.filenet.api.exception.EngineRuntimeException: FNRCE0066E: E_UNEXPECTED_EXCEPTION: An unexpected exception occurred. Message was: null
[u713] [C-CPE02] [1/13/26 16:35:29:790 CLST] 0000182a LocalTranCoor E WLTC0017E: Resources rolled back due to setRollbackOnly() being called.
[u713] [C-CPE02] [1/13/26 16:35:29:790 CLST] 0000182a webapp E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[ListenerNst]: com.filenet.api.exception.EngineRuntimeException: FNRCE0066E: E_UNEXPECTED_EXCEPTION: An unexpected exception occurred. Message was: null
[u712] [C-CPE03] [1/13/26 16:38:11:752 CLST] 00003da7 exception E com.ibm.ws.wim.adapter.ldap.LdapAdapter authenticateWithPassword
[u712] [C-CPE03] [1/13/26 16:38:11:752 CLST] 00003da7 exception E com.ibm.ws.wim.adapter.ldap.LdapAdapter authenticateWithPassword CWWIM4520E The ‘javax.naming.NamingException: LDAP response read timed out, timeout used: 20000 ms.’ naming exception occurred during processing.
[u712] [C-CPE03] [1/13/26 16:38:11:832 CLST] 00003da7 LTPAServerObj E SECJ0369E: Authentication failed when using LTPA. The exception is com.ibm.websphere.wim.exception.PasswordCheckFailedException: CWWIM4537E No principal is found from the ‘calfaroz’ principal name..
[u713] [C-CPE04] [1/13/26 16:38:20:440 CLST] 0000119a LdapConnectio C com.ibm.ws.wim.adapter.ldap.LdapConnection getDirContext hasSemaphore = true && blockThread= false
[u713] [C-CPE04] [1/13/26 16:38:20:440 CLST] 0000119a LdapConnectio C com.ibm.ws.wim.adapter.ldap.LdapConnection getDirContext needSemaphore = false
[u713] [C-CPE04] [1/13/26 16:38:20:441 CLST] 0000119a LdapConnectio C com.ibm.ws.wim.adapter.ldap.LdapConnection getDirContext HERE TO ACQUIRE LOCK
[u713] [C-CPE04] [1/13/26 16:38:20:450 CLST] 0000119a LdapConnectio C com.ibm.ws.wim.adapter.ldap.LdapConnection DirContext reCreateDirContext(String errorMessage) hasSemaphore = true && blockThread= false

Are you able to produce the issue with the sample logs provided?

I tried your sample logs with the alloy config in your original message, and it’s working fine for me. The only issue is that the timestamp part isn’t working, so from my test all logs are sent to my test Loki instance at present time. This is probably because you are passing CLST into the timestamp matching with MST. I believe what you want to do instead is to just parse for the actual timestamp (for example just 1/13/26 16:17:45:015), then set the timezone with the stage.timestamp’s location property. Other than that it seems to be fine.

I’d say see if you can give me test case that I can try to reproduce your issue, otherwise maybe consider a programmatic approach and see if that works out better for you.

Hi Tony… all the log examples I included in the case are actual logs I extracted from my own logs as examples.

Regarding the timestamp issue you mentioned, I also noticed that problem and made the following changes to my Alloy configuration to ignore the timezone, but I still can’t get it to log in with the correct timestamp instead of the Loki injection date.

  stage.regex {
    expression = "^\\[(?P<timestamp>\\d{1,2}\\/\\d{1,2}\\/\\d{2}\\s+\\d{1,2}:\\d{1,2}:\\d{1,2}:\\d{3})\\s+[A-Z]{3,4}[^\\]]+\\]\\s+(?P<thread>\\S+)\\s+(?P<category>\\S+)\\s+(?P<level>[A-Z])\\s+(?P<class>\\S+)\\s+(?P<method>[^ ]+)\\s*(?P<message>.*)"
  }

  stage.timestamp {
    source = "timestamp"
    format = "1/2/06 15:04:05:000"
    location = "America/Santiago"
    fallback_formats = [
      "1/2/2006 15:04:05:000",
      "01/02/06 15:04:05:000",
      "01/02/2006 15:04:05:000",
  }

I also added the following configurations to Loki and reduced the number of discarded logs:

limits_config:
  shard_streams:
    enabled: false

Thanks again for your help.

Regards.
Sergio

As mentioned in my previous post, I am unable to reproduce your issue on my end. How many log lines does it usually take for the problem to manifest?