Fifth post in the HPE OpsRamp track. O-4 built the “unified observability” case on a single estate — infrastructure to service. This post tests whether that same model holds when the estate spans AWS, Azure and Google Cloud alongside the on-prem racks it was built for.
The claim worth testing
Every OpsRamp post in this track has repeated the same pitch: one platform, one attribute model, one alert pipeline, covering everything. O-1 put it plainly — HPE OpsRamp Software (OpsRamp) is a SaaS platform for hybrid discovery, monitoring, event correlation and automated remediation across on-prem infrastructure, public cloud, and cloud-native workloads. The documentation’s own solutions overview says the same thing in its own words: OpsRamp handles IT assets running in your data center, public cloud, and cloud-native environments.
That’s the promise. The honest question is what changes when the resource you’re monitoring isn’t a physical host or a KVM guest with an agent installed, but an AWS Lambda function, an Azure Storage account, or a GCP-managed database — things you can’t SSH into and that don’t have a BIOS to fingerprint.
What’s confirmed, and what isn’t
I want to be direct about sourcing here, because this post breaks from the pattern of the rest of the track. Every other OpsRamp post in this series has cited specific documentation pages describing a specific mechanism — gateway ports, discovery attributes, template contents. For hybrid and multi-cloud monitoring specifically, the public documentation at docs.opsramp.com is thinner and, in places, JavaScript-rendered in a way that keeps the detailed configuration steps out of reach of a plain fetch. What I can confirm, from the docs and from the platform’s own navigation structure:
- The Integrations catalogue has a dedicated Public Cloud category, with individual pages for AWS and Azure (docs.opsramp.com/integrations/public-cloud/). OpsRamp Gateway documentation references deployment guides for the gateway appliance itself on VMware, AWS, Azure, and GCP — meaning the collection appliance can run as a VM inside any of those clouds, not only on-prem.
- The Discovery solutions page, in its own words, scopes discovery as identifying assets “across the on-premise and private cloud environments,” and its documented discovery methods (agent, SNMP, WMI, Linux agentless) are all infrastructure-shaped — none of them describe API-based discovery of managed cloud services.
- Log Management integrations explicitly list AWS (including Lambda), Azure, and Google Cloud as log sources.
Put together, this tells a consistent but incomplete story: OpsRamp treats public cloud as its own integration category, separate from the on-prem discovery mechanisms this track has covered so far, and the depth of that category’s public documentation doesn’t match the depth available for gateways, agents, and templates. The specific AWS/Azure/GCP resource types, required IAM/credential scopes, and polling intervals against the current Public Cloud integration pages for your OpsRamp tenant version before designing a rollout — this is exactly the kind of detail that’s better checked live in the product than assumed from documentation structure.
Why cloud resources aren’t just more inventory
Even without the granular configuration detail, the architectural shift is predictable from everything else this track has established, and worth reasoning through explicitly.
On-prem discovery is push-and-poll against something you can reach on the network — SNMP, WMI, SSH, an agent phoning home through the gateway (O-2, O-3). Cloud discovery is necessarily different: there’s no IP address to poll for an S3 bucket’s utilization, and no SNMP community string for a managed Kubernetes control plane. It has to be API-based, authenticated against the cloud provider’s own control plane, and it inherits that provider’s rate limits and resource model rather than a network topology.
That has three concrete consequences worth planning around, even before you’ve confirmed the exact mechanics for your tenant:
Credentials replace network reachability as the discovery gate. Where on-prem discovery fails because of a missing SNMP community string or a closed firewall port, cloud discovery fails because of an IAM policy that’s missing a permission, or a service principal that’s scoped to the wrong subscription. The failure mode moves from “can’t reach it” to “can’t see it” — same symptom (resource never appears, or appears incomplete), different root cause, different team who has to fix it.
Resource types don’t map one-to-one onto the infrastructure model. A VM in AWS still looks like the hosts this track has already covered — CPU, memory, network interfaces. A managed database, a serverless function, or an object storage bucket doesn’t have most of those dimensions at all, and has others (invocation count, storage class, request latency) that don’t exist for anything on-prem. The attribute model from O-3 — environment, tier, application, owner — still applies, but the metric model underneath it, from O-4, has to be built per cloud-native service type, not inherited from a generic server template.
Cost becomes a first-class signal cloud accounts bring that on-prem infrastructure mostly doesn’t. On-prem, spend is mostly sunk (the hardware is already bought). In a public cloud account, resource existence and cost are the same signal in near-real-time — which is why cloud cost visibility shows up as its own numbered post later in this track (O-14 — planned), rather than folded into general monitoring.
Where “unified” is genuinely unified, and where it isn’t
Give the platform credit for the part that’s architecturally sound: once a cloud resource is discovered and categorized, it lands in the same resource inventory, gets grouped by the same attribute model, can be attached to the same monitoring templates and device management policies, and feeds the same alert pipeline — severity, suppression, correlation, forecasting — covered in O-4. That’s not a small claim. It means a production-tier attribute doesn’t care whether the resource behind it is a KVM guest on an HVM cluster or an EC2 instance, and a service map can span both without a second tool.
Where the unification is weaker, on the evidence available:
- The discovery mechanism genuinely forks. Gateway/agent-based discovery and API-based cloud integration are different subsystems with different failure modes, different credential models, and — per the documentation gap above — apparently different levels of public documentation depth. “Unified” describes where the data ends up, not how uniformly it’s collected.
- Topology and correlation depend on relationships the cloud side may not surface the same way. was explicit that correlation and topology mapping require SNMP discovery specifically — a mechanism that has no cloud equivalent, whether OpsRamp’s Public Cloud integrations populate topology/service-map relationships (which Lambda function fronts which database) the way SNMP does for a switch and the hosts behind it, or whether cross-cloud correlation is a manual service-map exercise – This has to be built manually, for which I will publish bits.
- Alert design has to be redone per cloud-native resource type, not inherited. The tuning sequence from O-4 — baseline, then tune per group — still applies, but “per group” now includes groups of resources that don’t have an on-prem analogue to borrow a starting threshold from.
A practical starting sequence
Given the confirmed pieces, the sequence I’d actually run, extending the O-3 sequence rather than replacing it:
- Treat each cloud account as its own site-equivalent in the attribute model — environment and owner still apply, but add a
cloud-providerandaccount/subscription/projectattribute pair from day one, since nothing else will backfill that distinction later. - Set up the Public Cloud integration credentials with least-privilege, read-only access first. Confirm discovery populates the expected resource types before granting anything broader.
- Confirm what lands in inventory, and how it’s categorized, exactly as O-3 recommended for on-prem discovery — scope the first cloud account narrowly, don’t point it at every subscription in the tenant at once.
- Build (or find and adapt) monitoring templates per cloud-native resource type rather than assuming a generic template covers a managed service. This is where the O-4 “design your own thresholds” guidance matters most, since there’s no existing on-prem baseline to lean on for, say, a managed database’s connection-pool behavior.
- Check whether service maps span providers before you rely on them for an incident. If a production incident touches both an on-prem tier and a cloud tier, confirm the map actually shows that relationship rather than assuming it because both sides live in OpsRamp.
Gotchas and caveats
GCP support at the same URL pattern as AWS and Azure its current name, location, and feature parity before assuming three-cloud symmetry, but do check with HPE once you commit for product.
Cloud discovery credentials are a different failure surface than network discovery. A resource that stays Undefined in a cloud account is more likely an IAM/permission gap than a network problem — don’t debug it like a firewall issue.
SNMP-dependent correlation doesn’t have an obvious cloud analogue. Don’t assume cross-cloud or on-prem-to-cloud topology mapping “just works” the way switch-to-host correlation does; verify it explicitly for any service that spans both.
Cost and monitoring are adjacent but distinct here. This post covers monitoring; cloud cost visibility is a separate, later capability in this track (O-14 — planned) — don’t conflate “I can see the resource” with “I can see what it costs.”
Key takeaways
- OpsRamp’s own framing — infrastructure, public cloud, and cloud-native, one platform — is architecturally real at the inventory, attribute, template, and alert layer, which cloud and on-prem resources genuinely share once discovered.
- Cloud discovery is API-based and credential-gated, a different mechanism from the SNMP/WMI/agent discovery this track has covered so far — different failure modes follow from that.
- Public Cloud is its own Integrations category, with confirmed AWS and Azure pages; GCP parity at the same pattern.
- Cloud-native resource types need their own monitoring templates — there’s often no on-prem analogue to borrow a threshold from.
- Topology correlation’s SNMP dependency (O-4) doesn’t obviously extend to cloud — cross-environment service maps before trusting them in an incident.
- Treat cloud account/subscription/project as a first-class attribute from day one of extending discovery into a new cloud.
What’s next
Next in this track: O-6 — Metrics, Logs and Traces. Moving from “the resource is monitored” to “you can actually see inside it” — what each of OpsRamp’s three observability data types covers, and where they overlap versus where each one is load-bearing on its own.
Sources: OpsRamp Documentation · Platform Features · Solutions Overview · Discovery · Integrations — Public Cloud · OpsRamp Gateway.