Understanding Application Logging Fundamentals on SAP BTP

Explanation

When applications run on SAP BTP, whether on Cloud Foundry or Kyma, they behave differently from traditional on-premise ABAP systems where developers are used to transaction-based tools like ST22 or SLG1. In a cloud-native environment, applications are ephemeral, distributed across multiple instances, and can be restarted or scaled at any time. This makes application logging a critical foundation of observability, because without centralized, structured logs, a consultant or developer has no reliable way to understand what happened inside a running application after the fact. Application logging refers to the practice of capturing runtime events, errors, warnings, and informational messages generated by custom applications, integration flows, or extension code, and making them available for search, filtering, and analysis. On SAP BTP, this is commonly supported through the Application Logging service (built on open-source technology, typically exposed as a service instance you bind to your Cloud Foundry application) or through Kyma's native logging stack when running on Kubernetes. Both approaches aim to solve the same core problem: aggregating logs from many application instances into one searchable location, since logs written only to a container's local filesystem disappear when that container is recycled. A key beginner concept is the log level. Applications typically emit logs at different severities: DEBUG (fine-grained diagnostic detail, usually disabled in production), INFO (normal operational events, such as a message being processed successfully), WARN (something unexpected but not fatal, such as a retry), and ERROR (a failure that likely needs attention). Choosing the right log level is important because logging everything at DEBUG in production creates noise, inflates storage costs, and can even leak sensitive data, while logging too little makes root cause analysis nearly impossible during an incident. Another foundational idea is structured logging versus plain text logging. Structured logs are written as JSON objects with well-defined fields such as timestamp, correlation ID, component name, and message, rather than free-form text lines. Structured logs are far easier to filter and correlate in a centralized logging tool, especially when you need to trace a single business transaction across multiple microservices or integration flows. Many SAP-provided libraries and buildpacks on BTP encourage or default to structured JSON output for this reason. It is also important to distinguish application logs from other observability signals: metrics (numeric time-series data like response time or memory usage) and traces (end-to-end request paths across services). Logs answer 'what exactly happened and why', while metrics answer 'how is the system performing' and traces answer 'where did the request go'. A mature BTP support model uses all three together, but logging is usually the first and most accessible tool a project team learns, because most developers already know how to write a log statement in their code. Finally, beginners should understand the lifecycle: an application writes a log line, the runtime environment (Cloud Foundry garden container or Kyma pod) captures stdout/stderr, a log agent or sidecar forwards this to a log aggregation backend, and then the logs become searchable through a dashboard, CLI command, or API query. Understanding this flow is essential before diving into configuration, because most beginner troubleshooting questions ('why don't I see my log') come down to a break somewhere in this pipeline: the log wasn't written, it went to the wrong stream, or the aggregation service instance wasn't properly bound.

Code example

// Simple structured log example in Node.js on Cloud Foundryconst log = {  timestamp: new Date().toISOString(),  level: "INFO",  component: "order-service",  correlationId: req.headers['x-correlation-id'] || 'unknown',  message: "Order received and validated successfully",  orderId: order.id}; // Writing structured JSON to stdout so the platform log agent can pick it upconsole.log(JSON.stringify(log)); // Example of an ERROR level log for a failed downstream callconst errorLog = {  timestamp: new Date().toISOString(),  level: "ERROR",  component: "order-service",  correlationId: req.headers['x-correlation-id'] || 'unknown',  message: "Failed to call payment service",  error: err.message};console.error(JSON.stringify(errorLog));

Real project scenario

A project team deployed a custom Node.js microservice on Cloud Foundry to enrich sales order data before forwarding it to an S/4HANA Cloud system. During UAT, business users reported that some orders silently failed to reach S/4HANA, but the service showed no errors in its dashboard. The support consultant discovered the application was only using console.log with plain text and no ERROR-level classification, so failures were indistinguishable from normal informational messages in the aggregated log view. After introducing structured JSON logging with explicit log levels and correlation IDs, the team could immediately filter for ERROR entries and trace failed orders back to a specific malformed payload field.

Common mistakes

• Logging everything at DEBUG level in production, causing excessive noise and higher log storage costs • Writing plain text logs without timestamps or correlation identifiers, making it impossible to trace a transaction across services • Assuming logs written to a local file inside the container will persist after a restart or scale event • Logging sensitive data such as passwords, tokens, or full customer payloads without masking • Not distinguishing INFO from ERROR levels, so real failures get lost among routine operational messages

Best practices

• Use structured JSON logging with consistent fields like timestamp, level, component, and correlationId • Set log levels appropriately per environment: verbose in development, restrained in production • Never log secrets, credentials, or unmasked personal data • Always include a correlation or trace identifier so a single business transaction can be followed across services • Treat logs written to stdout/stderr as the standard integration point with the platform's log aggregation pipeline

Interview angle

Interviewers often ask candidates to explain the difference between logs, metrics, and traces, and why centralized logging is necessary in a cloud-native BTP environment compared to a traditional on-premise system. Being able to explain the ephemeral nature of Cloud Foundry containers or Kyma pods, and why local file-based logging is insufficient, demonstrates genuine cloud operations understanding rather than just on-premise ABAP debugging experience.