Summit Integration / SAP telemetry costs
SAP telemetry is expensive the moment it starts flowing.
A single production SAP landscape can emit more observability data than the rest of the estate combined: ABAP runtime traces, work process and dialog metrics, IDoc and RFC volumes, job and batch history, and the transaction detail that makes it worth collecting at all. It lands on the same statement as everything else, and it is rarely the part anyone has tuned.
What PowerConnect is, and what we are not
PowerConnect is Rhondos intellectual property. It has an official integration path with Dynatrace and is distributed through SoftwareOne. We do not own it, we do not resell it, and we are not affiliated with Rhondos, SoftwareOne or Dynatrace.
Where we are useful is on either side of it. If you already have PowerConnect and a Dynatrace contract, your first call about the product itself should be to the people who sold it to you. If what you have is a Dynatrace statement that grew after SAP monitoring went in, that one is ours.
Volume, cardinality and a retention policy nobody chose.
Transaction-level detail multiplies
Telemetry tagged per transaction code, per user, per client or per job name behaves like any other high-cardinality dimension: each distinct value becomes its own billable series. SAP estates produce a great many distinct values, and the tags that make the data useful for a Basis team are the same ones that multiply the line item.
Batch windows produce ingest spikes
Nightly batch, month-end and period-close generate volume that bears no relation to the daytime baseline. Sized against the peak, which is how it usually gets sized, the estate pays peak pricing for a load that occurs a few hours a month.
Everything is retained as though it were audit data
Some SAP telemetry genuinely has a retention requirement. Most of it does not, and gets the same retention anyway, because separating the two takes a conversation between Basis, the platform team and whoever owns compliance. That conversation is harder to schedule than a retention setting is to leave alone.
It sits outside the normal cost conversation
SAP monitoring is usually owned by the SAP team and billed through the observability platform. Neither side treats the resulting number as theirs, so it is the part of the estate least likely to have been reviewed since it was switched on.
What we do about it.
Mostly on Dynatrace, because that is where most SAP telemetry ends up and where we spend most of our time. The same work applies if your estate is somewhere else.
On Dynatrace
SAP telemetry arrives as logs, metrics and events like anything else, so the same DPS levers apply. It is usually the highest-volume source in the estate, which makes it the one where the levers pay back fastest.
OpenPipeline filtering before ingest
Drop the SAP records nobody will query at the edge, mask what carries personal or commercial data, and route the rest to the bucket it belongs in. Filtering here is worth more on SAP than on almost any other source, purely because of the volume.
Bucket and retention split by purpose
Separate the SAP telemetry with a genuine compliance retention requirement from the SAP telemetry that is operationally useful for a fortnight, and give each its own Grail bucket and its own period.
Custom metric and event cardinality
Keep the dimensions your Basis team relies on queryable, without keeping every combination of transaction code, client and user billable.
Monitoring mode across the SAP landscape
Application servers and database hosts rarely need the same depth. Full-Stack where code-level detail earns its place, Infrastructure Monitoring on the rest.
Sizing for the baseline, not the batch window
Handle period-close and batch spikes as spikes, buffered or sampled, rather than sizing the whole month against them.
On other platforms
Most SAP observability tooling assumes Dynatrace at the other end. If your estate standardised on something else, getting SAP data into it with usable structure, rather than as a firehose of text, is engineering work rather than configuration.
SAP telemetry into Datadog, Elastic or Splunk
Structured, typed and mapped so it is queryable by the people who need it, not just present. This is the part that tends not to exist off the shelf.
Filtering and aggregation at the same point
Index-time filtering and Ingest Actions on Splunk, ingest pipelines and mapping discipline on Elastic, exclusion filters and cardinality control on Datadog. Different controls, same decision about what is worth keeping.
This is the cost work, applied to the most expensive corner of the estate.
SAP is not a separate business for us. It is the same engagement as everything else on this site: find what the telemetry costs, cut what is not earning its place, and put governance around it so the number stays down. Applied to the part of the estate that is usually largest and least reviewed.
So the route in is the same one. Send last month’s statement and a usage export, and we will come back within 48 hours with where the money is going. If the SAP portion is the problem, that will be obvious from the statement, and we will say so.