Terlalu banyak log  -> noise, cost tinggi, query lambat, alert fatigue
Terlalu sedikit log -> blind spot, incident sulit direkonstruksi, RCA lemah

TRACE -> detail sangat rendah untuk debugging lokal/diagnostik terbatas
DEBUG -> detail teknis untuk debugging, biasanya off di production
INFO  -> event operasional normal yang penting untuk memahami lifecycle
WARN  -> kondisi tidak ideal, tetapi sistem masih bisa lanjut
ERROR -> operasi gagal atau sistem kehilangan kemampuan yang seharusnya berhasil

log.error("User entered invalid quote id");

log.info("quote lookup rejected due to invalid format quote_id_present={} actor_id={} correlation_id={}",
        quoteId != null,
        actorId,
        correlationId);

log.info("Processing item {}", itemId);

Apakah event ini normal atau abnormal?
Apakah operator harus peduli?
Apakah event ini membantu rekonstruksi incident?
Apakah level ini akan menyebabkan alert/noise/cost yang tidak perlu?
Apakah field-nya aman dan cukup untuk debugging?

Level log harus merepresentasikan dampak operasional, bukan emosi developer.

Apakah operasi yang diminta gagal?
Apakah sistem kehilangan kemampuan penting?
Apakah failure memerlukan intervensi?
Apakah failure akan terlihat oleh user/customer?
Apakah retry otomatis sudah cukup?
Apakah ini expected dalam domain?

log.trace("entered price rule evaluation rule_id={} quote_id={}", ruleId, quoteId);
log.trace("candidate discount rule evaluated rule_id={} matched={}", ruleId, matched);

TRACE aktif di production terlalu lama
TRACE mengandung PII/secrets
TRACE dipakai pada loop besar
TRACE menghasilkan log lebih mahal daripada traffic utama
TRACE membuat log backend sulit dipakai saat incident

log.trace("request body={}", requestBody);

[ ] Apakah TRACE disabled by default di production?
[ ] Apakah ada runtime log level change dengan approval/process?
[ ] Apakah TRACE pernah digunakan untuk request body, response body, SQL parameter, atau token?
[ ] Apakah ada TTL/process untuk menurunkan log level setelah debugging?
[ ] Apakah log backend bisa menahan volume jika TRACE sementara diaktifkan?
[ ] Apakah TRACE event punya privacy guardrail?

log.debug("pricing rule candidate selected quote_id={} rule_count={} strategy={}",
        quoteId,
        rules.size(),
        strategyName);

log.debug("order state changed from {} to {} order_id={}", oldState, newState, orderId);

log.info("order state transitioned order_id={} from_state={} to_state={} transition={} actor_type={}",
        orderId,
        oldState,
        newState,
        transitionName,
        actorType);

if (log.isDebugEnabled()) {
    log.debug("pricing candidates quote_id={} candidates={}", quoteId, buildDebugSummary(candidates));
}

log.debug("large payload summary={}", expensiveSerialize(payload));

if (log.isDebugEnabled()) {
    log.debug("large payload summary={}", safeSummary(payload));
}

[ ] Apakah DEBUG disabled by default di production?
[ ] Apakah DEBUG tidak menyimpan event lifecycle penting?
[ ] Apakah DEBUG tidak mengandung PII, token, body lengkap, atau SQL parameter sensitif?
[ ] Apakah expensive debug argument dijaga dengan isDebugEnabled()?
[ ] Apakah runtime log level change dapat dibatasi per logger/package?
[ ] Apakah ada prosedur menyalakan DEBUG sementara saat incident?

http.request.completed
quote.pricing.started
quote.pricing.completed
order.submission.accepted
order.state.transitioned
kafka.message.published
rabbitmq.message.consumed
background.job.completed
workflow.task.completed
cache.warmup.completed

log.info("quote pricing completed quote_id={} tenant_id={} price_version={} latency_ms={} item_count={}",
        quoteId,
        tenantId,
        priceVersion,
        latencyMs,
        itemCount);

Apa yang terjadi?
Untuk entity mana?
Dalam konteks request/trace/correlation mana?
Berhasil atau gagal?
Berapa durasinya?
Apa outcome pentingnya?

log.info("Entering method A");
log.info("Calling method B");
log.info("Received result from method B");
log.info("Mapping result");
log.info("Returning response");

log.info("quote retrieval completed quote_id={} tenant_id={} source={} latency_ms={} status={}",
        quoteId,
        tenantId,
        source,
        latencyMs,
        status);

quote.created
quote.priced
quote.submitted_for_approval
quote.approved
quote.rejected
quote.accepted
order.created
order.validated
order.decomposed
fulfillment.started
fallout.created
cancellation.requested
amendment.requested

log.info("kafka publish completed topic={} event_type={} event_id={} correlation_id={} latency_ms={}",
        topic,
        eventType,
        eventId,
        correlationId,
        latencyMs);

[ ] Apakah INFO berisi lifecycle event penting, bukan method tracing?
[ ] Apakah setiap INFO punya event name atau message yang stabil?
[ ] Apakah INFO membawa correlation_id/trace_id/request_id?
[ ] Apakah business entity key seperti quote_id/order_id dicatat sesuai policy?
[ ] Apakah INFO tidak terlalu banyak pada hot path?
[ ] Apakah event volume INFO dipantau?
[ ] Apakah event yang harus audit masuk audit log terpisah?

log.warn("dependency call retry scheduled dependency={} operation={} attempt={} max_attempts={} reason={} correlation_id={}",
        "pricing-service",
        "calculate-price",
        attempt,
        maxAttempts,
        reason,
        correlationId);

for (int attempt = 1; attempt <= 5; attempt++) {
    try {
        callDependency();
        return;
    } catch (Exception ex) {
        log.warn("dependency failed", ex);
    }
}

log.warn("dependency retry scheduled dependency={} operation={} attempt={} max_attempts={} error_class={} error_code={}",
        dependency,
        operation,
        attempt,
        maxAttempts,
        ex.getClass().getName(),
        errorCode);

log.warn("cache lookup failed using database fallback cache={} operation={} key_hash={} correlation_id={}",
        "redis-quote-cache",
        "getQuoteSummary",
        safeKeyHash,
        correlationId);

cache_fallback_total{cache="quote-cache", reason="redis_timeout"}

log.warn("duplicate event ignored event_id={} event_type={} idempotency_key={} consumer={} offset={}",
        eventId,
        eventType,
        idempotencyKey,
        consumerName,
        offset);

[ ] Apakah WARN dipakai untuk recoverable abnormal condition?
[ ] Apakah WARN tidak menjadi spam pada retry loop?
[ ] Apakah WARN punya reason, attempt, dependency, dan correlation field?
[ ] Apakah WARN yang sering terjadi punya metric?
[ ] Apakah fallback path terlihat?
[ ] Apakah duplicate/idempotency behavior tidak salah diklasifikasikan sebagai ERROR?
[ ] Apakah WARN tertentu dipakai alert? Jika iya, apakah actionable?

log.error("order submission failed order_id={} quote_id={} tenant_id={} error_code={} retryable={} correlation_id={}",
        orderId,
        quoteId,
        tenantId,
        errorCode,
        retryable,
        correlationId,
        ex);

service
operation/event
correlation_id
trace_id
request_id
tenant_id jika allowed
business key jika allowed
error_code
exception_class
retryable
dependency jika dependency failure
attempt jika retry exhausted
latency_ms jika relevant

throw new ValidationException("invalid quote status");

try {
    service.submit(order);
} catch (Exception ex) {
    log.error("submit failed", ex);
    throw ex;
}

log.error("request failed", ex);

[ ] Apakah ERROR benar-benar final failure atau unexpected failure?
[ ] Apakah expected 4xx tidak diperlakukan sebagai ERROR secara default?
[ ] Apakah stack trace tidak digandakan antar layer?
[ ] Apakah ERROR membawa error_code dan correlation_id?
[ ] Apakah dependency final failure memiliki dependency name dan operation?
[ ] Apakah retry exhausted dicatat sebagai final failure?
[ ] Apakah ERROR dipetakan ke metric/alert yang meaningful?
[ ] Apakah ERROR tidak mengandung PII/secrets dalam message atau stack trace custom?

Process/service tidak dapat melanjutkan secara aman.

ERROR log + process exit + failed readiness/startup probe

[ ] Apakah logging framework memiliki FATAL atau tidak?
[ ] Apakah startup failure dicatat jelas sebelum process exit?
[ ] Apakah readiness/startup probe mencerminkan fatal misconfiguration?
[ ] Apakah fatal condition tidak disembunyikan sebagai WARN?
[ ] Apakah orchestrator/Kubernetes menangkap restart reason?

log.info("quote approved quote_id={} tenant_id={} actor_id={} approval_level={} correlation_id={}",
        quoteId,
        tenantId,
        actorId,
        approvalLevel,
        correlationId);

audit_event: quote.approved
actor_id
target_entity
before_state
after_state
time
reason
source_ip

log.warn("authorization denied actor_id={} action={} resource_type={} resource_id_present={} reason={} correlation_id={}",
        actorId,
        action,
        resourceType,
        resourceId != null,
        reason,
        correlationId);

[ ] Apakah event business penting masuk application log dan/atau audit log sesuai policy?
[ ] Apakah security event tidak bocor token/header/cookie?
[ ] Apakah audit event tidak hanya mengandalkan INFO log biasa?
[ ] Apakah level security event disepakati dengan security team?
[ ] Apakah business event volume tidak membanjiri log backend?

log.info("quote submission rejected quote_id={} reason={} actor_id={} correlation_id={}",
        quoteId,
        "QUOTE_ALREADY_SUBMITTED",
        actorId,
        correlationId);

log.warn("quote submission rejected due to suspicious actor mismatch quote_id={} actor_id={} owner_id={} correlation_id={}",
        quoteId,
        actorId,
        ownerId,
        correlationId);

log.error("unexpected quote submission failure quote_id={} tenant_id={} error_code={} correlation_id={}",
        quoteId,
        tenantId,
        "QUOTE_SUBMISSION_UNEXPECTED_FAILURE",
        correlationId,
        ex);

[ ] Apakah expected 4xx tidak mencemari ERROR rate?
[ ] Apakah unexpected 5xx selalu memiliki ERROR log dan metric?
[ ] Apakah business rejection dibedakan dari technical failure?
[ ] Apakah conflict/idempotency cases punya log level yang konsisten?
[ ] Apakah client cancellation 499 tidak salah dianggap server ERROR?

Intermediate retry attempt -> DEBUG/WARN depending severity and volume
Final retry exhausted       -> ERROR
Retry success after failure -> INFO or metric, depending usefulness

log.warn("dependency retry scheduled dependency={} operation={} attempt={} max_attempts={} backoff_ms={} error_class={} correlation_id={}",
        dependency,
        operation,
        attempt,
        maxAttempts,
        backoffMs,
        ex.getClass().getSimpleName(),
        correlationId);

log.error("dependency call failed after retries dependency={} operation={} attempts={} latency_ms={} correlation_id={}",
        dependency,
        operation,
        attempts,
        totalLatencyMs,
        correlationId,
        ex);

log.error("message processing failed", ex);
throw ex; // broker redelivers forever

log.warn("message processing retry scheduled topic={} event_id={} attempt={} reason={} correlation_id={}",
        topic,
        eventId,
        attempt,
        reason,
        correlationId);

log.error("message moved to dlq topic={} dlq_topic={} event_id={} attempts={} error_code={} correlation_id={}",
        topic,
        dlqTopic,
        eventId,
        attempts,
        errorCode,
        correlationId,
        ex);

[ ] Apakah retry attempt dan final failure dibedakan levelnya?
[ ] Apakah retry loop tidak menulis stack trace penuh setiap attempt?
[ ] Apakah retry metrics tersedia?
[ ] Apakah DLQ movement dicatat sebagai final outcome?
[ ] Apakah non-retriable business rejection tidak di-retry tanpa henti?
[ ] Apakah retryable flag ada dalam error log atau structured field?

for (OrderLine line : lines) {
    log.info("Processing order line order_id={} line_id={}", orderId, line.id());
}

log.info("order lines processed order_id={} line_count={} failed_count={} latency_ms={}",
        orderId,
        lines.size(),
        failedCount,
        latencyMs);

log.warn("order line processing failed order_id={} line_id={} reason={} correlation_id={}",
        orderId,
        failedLineId,
        reason,
        correlationId);

log.info("Health check called");

Tidak log per health check success.
Log only health check failure or state transition healthy <-> unhealthy.

log.info("Cache hit key={}", key);

cache hit/miss -> metric
cache failure/fallback -> WARN log
cache warmup completed -> INFO log

[ ] Apakah ada INFO log di loop besar?
[ ] Apakah health check success dilog?
[ ] Apakah cache hit/miss dilog per request, bukan metric?
[ ] Apakah retry menghasilkan stack trace spam?
[ ] Apakah framework logger terlalu verbose?
[ ] Apakah top noisy logger diketahui?
[ ] Apakah log volume per service dipantau?

HTTP inbound
HTTP outbound
DB transaction
Kafka/RabbitMQ publish
Kafka/RabbitMQ consume
Redis fallback/failure
Camunda job/task failure
background job start/end/failure
state transition
external side effect
security decision
audit-relevant mutation

[ ] Apakah setiap request failure punya log dengan correlation_id?
[ ] Apakah setiap state transition penting tercatat?
[ ] Apakah setiap external side effect punya success/failure evidence?
[ ] Apakah Kafka/RabbitMQ DLQ movement terlihat?
[ ] Apakah retry exhausted terlihat?
[ ] Apakah fallback path terlihat?
[ ] Apakah audit-relevant mutation masuk audit log?
[ ] Apakah config/deployment/feature flag change bisa dikorelasikan dengan incident?

log.error("validation failed field=name");
log.error("quote not found quote_id={}", quoteId);
log.error("duplicate request ignored idempotency_key={}", key);

log.info("database unavailable");
log.info("message moved to dlq");
log.info("audit write failed");

catch (Exception ex) {
    log.error("failed", ex);
    throw ex;
}

log.error("Order failed");

http_errors_total{error_message="timeout after 5032ms calling /api/order/123"}

http_errors_total{error_code="DOWNSTREAM_TIMEOUT"}

[ ] Apakah expected business rejection tidak menjadi ERROR?
[ ] Apakah critical failure tidak hanya INFO?
[ ] Apakah stack trace tidak diduplikasi di banyak layer?
[ ] Apakah setiap ERROR punya structured fields?
[ ] Apakah error_code stabil dipakai, bukan raw exception message sebagai dimension?

NGINX / ingress
  -> Servlet container
  -> JAX-RS filter
  -> resource method
  -> service layer
  -> database / Redis / messaging / downstream
  -> ExceptionMapper
  -> response

log.info("http request completed method={} route={} status={} latency_ms={} correlation_id={} trace_id={}",
        method,
        routeTemplate,
        status,
        latencyMs,
        correlationId,
        traceId);

log.info("http request rejected method={} route={} status=400 error_code={} correlation_id={}",
        method,
        routeTemplate,
        errorCode,
        correlationId);

log.warn("http request forbidden method={} route={} actor_id={} action={} resource_type={} reason={} correlation_id={}",
        method,
        routeTemplate,
        actorId,
        action,
        resourceType,
        reason,
        correlationId);

log.error("http request failed method={} route={} status=500 error_code={} correlation_id={} trace_id={}",
        method,
        routeTemplate,
        errorCode,
        correlationId,
        traceId,
        ex);

Did app continue expensive work after client disconnected?
Did gateway timeout before app finished?
Is cancellation normal or due to latency regression?

log.warn("slow database query operation={} latency_ms={} threshold_ms={} rows={} correlation_id={}",
        operation,
        latencyMs,
        thresholdMs,
        rowCount,
        correlationId);

log.error("database connection pool exhausted pool={} active={} idle={} pending={} timeout_ms={} correlation_id={}",
        poolName,
        active,
        idle,
        pending,
        timeoutMs,
        correlationId,
        ex);

log.info("optimistic lock conflict detected entity_type={} entity_id={} operation={} retryable={} correlation_id={}",
        entityType,
        entityId,
        operation,
        true,
        correlationId);

log.warn("optimistic lock retry exhausted entity_type={} entity_id={} attempts={} correlation_id={}",
        entityType,
        entityId,
        attempts,
        correlationId);

[ ] Are SQL parameters logged?
[ ] Can SQL logs expose customer data, commercial pricing, identifiers, or secrets?
[ ] Is slow query correlation possible without raw parameter leakage?

log.info("message processed topic={} event_type={} event_id={} latency_ms={} correlation_id={}",
        topic,
        eventType,
        eventId,
        latencyMs,
        correlationId);

log.warn("message redelivered queue={} event_id={} redelivery_count={} correlation_id={}",
        queue,
        eventId,
        redeliveryCount,
        correlationId);

log.error("message moved to dlq source={} dlq={} event_type={} event_id={} attempts={} error_code={} correlation_id={}",
        source,
        dlq,
        eventType,
        eventId,
        attempts,
        errorCode,
        correlationId,
        ex);

log.info("duplicate message ignored event_id={} idempotency_key={} consumer={} correlation_id={}",
        eventId,
        idempotencyKey,
        consumerName,
        correlationId);

cache_miss_total{cache="quote-summary"}

log.warn("redis cache unavailable using fallback operation={} cache={} key_hash={} correlation_id={}",
        operation,
        cacheName,
        keyHash,
        correlationId);

log.info("distributed lock not acquired lock_name={} owner={} operation={} correlation_id={}",
        lockName,
        owner,
        operation,
        correlationId);

log.error("distributed lock operation failed lock_name={} operation={} correlation_id={}",
        lockName,
        operation,
        correlationId,
        ex);

log.info("workflow task completed process_instance_id={} task_type={} business_key={} latency_ms={} correlation_id={}",
        processInstanceId,
        taskType,
        businessKey,
        latencyMs,
        correlationId);

log.warn("workflow job failed retry scheduled process_instance_id={} job_type={} retries_left={} error_code={} correlation_id={}",
        processInstanceId,
        jobType,
        retriesLeft,
        errorCode,
        correlationId);

log.error("workflow incident created process_instance_id={} activity_id={} business_key={} error_code={} correlation_id={}",
        processInstanceId,
        activityId,
        businessKey,
        errorCode,
        correlationId,
        ex);

Every noisy INFO becomes platform ingestion cost.
Every multiline stack trace must be parsed correctly.
Every wrong ERROR may affect alerting or dashboards.
Every missing structured field makes log query harder.

log.error("application startup failed reason={} config_key={} environment={} version={}",
        reason,
        safeConfigKey,
        environment,
        version,
        ex);

[ ] Apakah stdout/stderr parsing mempertahankan level field?
[ ] Apakah stack trace multiline diparse benar?
[ ] Apakah Kubernetes probe success tidak noisy?
[ ] Apakah startup failure punya ERROR sebelum exit?
[ ] Apakah log level berbeda per environment?
[ ] Apakah cloud/on-prem retention dan cost diketahui?

log.info("order submitted order_id={} item_count={} latency_ms={}",
        orderId,
        itemCount,
        latencyMs);

log.info("order submitted payload={}", objectMapper.writeValueAsString(order));

log.warn("slow path detected", new RuntimeException("stack trace"));

[ ] Apakah hot path logging menggunakan parameterized logging?
[ ] Apakah expensive serialization dijaga?
[ ] Apakah object besar tidak dilog?
[ ] Apakah async appender queue dipantau?
[ ] Apakah logging pernah menjadi bottleneck?
[ ] Apakah GC pressure dari logging pernah terlihat?

log.warn("authorization failed actor_id={} action={} resource_type={} reason={} correlation_id={}",
        actorId,
        action,
        resourceType,
        reasonCode,
        correlationId);

log.warn("authorization failed token={} headers={}", token, headers);

[ ] Apakah log review mencakup PII/secrets?
[ ] Apakah lower environment juga punya secure logging policy?
[ ] Apakah debug/trace tidak bisa menyalakan payload logging sembarangan?
[ ] Apakah security team punya guideline sensitive fields?
[ ] Apakah masking/redaction utility dipakai konsisten?

High-frequency normal event -> metric first, sampled log if needed
Low-frequency important event -> INFO log
Recoverable abnormal event -> WARN, possibly aggregated/sampled
Final failure -> ERROR
Audit-relevant event -> audit log with retention policy

[ ] Apakah top log volume per logger diketahui?
[ ] Apakah high-volume INFO bisa diganti metric?
[ ] Apakah retry logs dibatasi?
[ ] Apakah DEBUG/TRACE punya approval dan TTL?
[ ] Apakah log retention sesuai value signal?
[ ] Apakah audit retention dipisahkan dari application log retention?

Validation failure dilog ERROR -> terlihat seperti service outage
DLQ movement dilog INFO -> failure critical tersembunyi
Retry attempt dilog ERROR -> error rate palsu
Audit write failure dilog WARN -> compliance risk diremehkan
Cache miss dilog WARN -> alert noise

[ ] Apakah log level mencerminkan user impact?
[ ] Apakah log level mencerminkan final vs intermediate failure?
[ ] Apakah log level mencerminkan expected vs unexpected?
[ ] Apakah log level mencerminkan recoverable vs unrecoverable?
[ ] Apakah log level konsisten antar service?

[ ] Apakah log event benar-benar perlu ada?
[ ] Apakah level log sesuai dampak operasional?
[ ] Apakah expected error tidak menjadi ERROR?
[ ] Apakah unexpected/final failure tidak disembunyikan sebagai INFO/WARN?
[ ] Apakah retry attempt dan retry exhausted dibedakan?
[ ] Apakah stack trace hanya ditulis di boundary yang tepat?
[ ] Apakah log membawa correlation_id/trace_id/request_id?
[ ] Apakah business key seperti quote_id/order_id dipakai sesuai policy?
[ ] Apakah log tidak mengandung PII, secrets, token, cookie, raw body, atau SQL parameter sensitif?
[ ] Apakah log berada di hot path atau loop besar?
[ ] Apakah high-volume event lebih cocok menjadi metric?
[ ] Apakah event audit-relevant masuk audit log, bukan hanya application log?
[ ] Apakah log message stabil dan queryable?
[ ] Apakah structured fields konsisten dengan log schema?
[ ] Apakah log akan membantu incident reconstruction?
[ ] Apakah log akan meningkatkan alert noise?
[ ] Apakah ada cost impact yang perlu dipertimbangkan?

[ ] Logging framework apa yang digunakan?
[ ] Apakah ada dokumen internal logging standard?
[ ] Apakah ada definisi internal untuk INFO/WARN/ERROR?
[ ] Apakah ERROR log memicu alert atau dashboard tertentu?
[ ] Apakah expected 4xx dihitung dalam error dashboard?
[ ] Apakah runtime log level change tersedia?
[ ] Siapa yang boleh mengubah log level di production?
[ ] Apakah ada TTL atau approval untuk DEBUG/TRACE production?
[ ] Apakah top noisy loggers diketahui?
[ ] Apakah log cost dipantau per service/team?
[ ] Apakah security/privacy review diperlukan untuk log baru?
[ ] Apakah audit log dipisahkan dari application log?
[ ] Apakah incident notes pernah menyebut missing log atau noisy log?
[ ] Apakah retry/DLQ/fallback logging sudah konsisten?
[ ] Apakah service owner punya dashboard untuk error/warn trend?

Event penting terlihat.
Event normal tidak menutupi failure.
Expected error tidak membuat noise.
Unexpected error tidak tersembunyi.
Retry dan final failure dibedakan.
Business, security, audit, dan operational event tidak dicampur sembarangan.
Log membantu incident reconstruction.
Log tidak membocorkan data sensitif.
Log tidak membuat cost meledak.