Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 4 of 5

Operations: observability, monitoring and alerting

10 min

Listen to this lesson

0:00 / 5:53

An extension that passed every test can still fail on a Tuesday afternoon in production. Operations design decides whether Contoso learns about it from an alert or from Great Lakes Fleet Services. The goal is observability: the extension emits enough signals that the team can answer new questions about its behavior without shipping new code. Three kinds of signal matter: logs, metrics and traces.

LogsStructured records of events: one line per processed order or event, with correlation ids, outcome and duration
MetricsNumbers over time: requests, errors, latency percentiles, queue depth, breaker state
TracesOne request followed across services: app, destination, S/4HANA API, broker
Health checksEndpoints and synthetic calls that prove the app and its dependencies answer
AlertsRules that page a named owner when a symptom crosses a threshold
The signals of an observable extension.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-401

SAP's observability building blocks

SAP's DevOps reference architecture describes SAP Cloud ALM as a central observability platform for SAP products including SAP BTP, working with local BTP-specific capabilities, and it notes that SAP uses OpenTelemetry, the open instrumentation standard, as the unified approach for instrumenting custom apps for central observability. SAP Cloud ALM for operations offers, among others, health monitoring, integration and exception monitoring (correlating messages into end-to-end flows and searching by business attributes such as an order number), real user monitoring (using SAP Passport to trace performance from front end through cloud services to back ends), job and automation monitoring, business process monitoring, synthetic user monitoring and central alerting. On BTP itself, SAP Cloud Logging stores and analyzes logs, and SAP Alert Notification service routes notifications from BTP services, including the CI/CD and transport services, to channels of your choice.

Where Contoso's operational signals go: apps report to SAP Cloud Logging and SAP Cloud ALM, and alerts reach owners through central alerting and SAP Alert Notification service.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-401
NeedContoso's choiceSignal
Is the fleet order status app up and fast for users?Real user monitoring and a synthetic check of the order search every 5 minutesAvailability, response time
Are events flowing from CMP to the notifier?Integration and exception monitoring plus queue depth metricMessage flow, errors, backlog
Why did one order not reach the portal?Correlated logs in SAP Cloud Logging, searched by order numberLog lines with event id and outcome
Is a dependency failing?Circuit breaker state and error rate per destinationMetrics
Did a deployment or import fail?Alert Notification from CI/CD and transport servicesBuild and import events

Mapping operational questions to signals (illustrative).

Design logs for the person on call

Logs are read under pressure. Contoso's rules: structured (key-value or JSON), one line per business outcome, always with the business key (order number), the technical correlation (event source and id, trace id) and the outcome; no personal data beyond what support needs; levels used consistently. A log line that says "error occurred" is worthless at 02:00; one that says "order 1000473, event id ..., portal update failed after 3 attempts, breaker open for destination FLEET_PORTAL" is a diagnosis.

Alert on symptoms, route to owners

Good alerts describe what users or the business feel, not every internal hiccup: "order lookups slower than 3 seconds for 10 minutes", "notifier queue older than 15 minutes", "error rate above 5%". Each alert has a named owner, a severity, and a runbook: what to check, what to do, who to call. Alerts that fire daily without action get fixed or deleted, because a team that ignores alerts will ignore the real one.

  1. SignalQueue age for the fleet notifier passes 15 minutes
  2. AlertCentral alerting raises it with severity and links
  3. RouteAlert Notification sends it to the integration on-call channel
  4. DiagnoseRunbook: check consumer health, breaker state, S/4HANA API status, dead message queue
  5. Act and recordRestart, scale, or wait for the dependency; record the incident and any follow-up
From signal to action for one alert.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-401
Log onlyRare, low impact: keep the log, no alert
Page with runbookRare but high impact: page the owner with a runbook
Fix the causeFrequent, low impact: noise; fix it or tune the threshold
Design problemFrequent and high impact: an architecture issue, not an alerting one
Deciding what deserves an alert.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-401

What would you do?

The fleet order notifier silently stopped updating the portal for six hours overnight. Nothing alerted; Maria found out from a customer call. The app's health endpoint stayed green all night. What is the most important fix?

Key points
  • Observability rests on logs, metrics and traces, plus health checks and alerts.
  • SAP Cloud ALM is SAP's central observability platform; SAP uses OpenTelemetry for instrumenting custom BTP apps.
  • Structured logs with business key, correlation ids and outcome make diagnosis fast.
  • Alert on symptoms users feel; every alert has an owner, severity and runbook.
  • Operations updates are part of the definition of done.

Check your understanding · not graded

Lesson check

  1. 1. Which open standard does SAP name for instrumenting custom BTP apps for central observability?

  2. 2. Which SAP Cloud ALM capability correlates messages into end-to-end flows searchable by order number?

  3. 3. What makes an alert useful at 02:00?

  4. 4. Why can a green health endpoint be misleading?