TAFJ Log Files: Where to Look When Something Goes Wrong

First-response evidence checklist

Capture this information before a restart, redeployment, queue change, log-level change, or database intervention. The original state is usually the most valuable evidence you will get.

1. Confirm the first reported symptom time in UTC and record the reporter, channel, and affected transaction or service.
2. Confirm the environment, application version, deployed artefact, configuration version, and whether anything changed recently.
3. Capture the current application-server, deployment, TAFJ runtime, service or COB, database, and messaging evidence before restarting anything.
4. Find the earliest relevant error in each layer rather than starting with the loudest later exception.
5. Compare server clocks and record any skew before correlating timestamps across systems.
6. Check whether rotation moved the incident window into a previous or compressed log file.
7. Record the active log level; missing detail may reflect INFO or WARN configuration rather than a healthy component.
8. Redact credentials, customer data, account identifiers, tokens, internal addresses, and sensitive payloads before sharing evidence.

Where the logs are

The locations below are common patterns, not guaranteed paths. Packaging, application-server choice, containers, service wrappers, logging frameworks, and local standards can move or rename every file. Confirm the active configuration, startup command, service definition, and diagnostic output in the affected environment.

Use dependency order, not familiarity

1. Application server: confirm the JVM and server started cleanly, required modules loaded, datasources connected, and no resource exhaustion is visible.
2. Deployment state: verify the expected artefact is deployed on the expected instance and that no failed or stale deployment marker exists.
3. TAFJ runtime: find the first session, runtime, routine, or application error after the lower layers became healthy.
4. Affected service or COB run: inspect the log that owns the work, including its selection, processing, retry, exception, and closeout evidence.
5. Database: check connectivity, recovery state, blocking, resource pressure, and engine errors when the application is healthy but processing is not.
6. Messaging: examine broker and consumer evidence when message flow, redelivery, rollback, or response delivery is part of the symptom.

A later exception may be a consequence of a lower-layer failure. Record the first causal event and the chain that follows it.

Timestamps, timezones, and correlation

Record the current time, timezone, and offset on the application, database, messaging, scheduler, and monitoring systems. Do not assume that a timestamp without an offset is UTC, or that two systems displaying the same clock time share the same timezone.

Use a stable correlation value where available: a transaction reference, message identifier, request ID, service execution ID, record ID, or a tightly bounded time window. Search with the smallest non-sensitive identifier that follows the work across layers. Avoid copying complete OFS messages or customer data into tickets.

Consistent UTC logging and synchronised time sources make incident reconstruction much easier. When that is not yet available, document measured skew explicitly and adjust every search window before drawing conclusions.

Rotation and retention

Size-based, time-based, and startup-based rotation can split one incident across several files. Check modification times, the first and last timestamp in each file, rotated suffixes, compressed archives, container log streams, and central logging.

A restart can rotate or replace the very log that explains why the service failed. Collect the incident window first. Retention should cover the longest realistic delay between a problem occurring and support being asked to investigate it.

Verbosity and sensitive-data handling

INFO may prove lifecycle state but omit field-level diagnostic detail. DEBUG or TRACE may reveal the missing sequence, but can increase volume, affect performance, and expose credentials, tokens, account details, customer information, payment data, complete OFS payloads, or internal paths.

Use the narrowest logger, shortest approved collection window, and a reproducible test. Disable the extra logging immediately after collection. Preserve an unmodified restricted copy where policy requires it, and create a separately redacted evidence pack for tickets, chat, or vendor escalation.

What to search for

• The first exception or failure after a known healthy startup point.
• Deployment failures, missing modules, datasource errors, and authentication failures.
• Transaction, message, service, or record references that cross component boundaries.
• Repeated rollback, retry, timeout, dead-letter, duplicate, or uncertain-outcome patterns.
• Warnings immediately before the visible failure, not only the final fatal message.

Search rotated files and central logging as well as the current local file. A clean current log does not prove the incident window was clean.

Evidence to include before escalation

• Environment, version, business date, affected component, and first symptom time.
• Measured clock skew and the normalised incident window.
• The earliest relevant event from each affected layer, with surrounding context.
• Deployment, configuration, log-level, and recent-change evidence.
• Impact, reproduction steps, containment already attempted, and whether state changed.
• A redaction statement and secure location for any restricted original evidence.