Cloud account hierarchy
Organize accounts, subscriptions, projects, regions and zones while preserving authoritative tenant and resource identity.
Hybrid estates & service telemetry
Connect cloud infrastructure, Kubernetes and service telemetry.
AmrudAi’s documented hybrid cloud model connects provider resources, Kubernetes workloads and OpenTelemetry evidence through shared identity, source health and incident time. This overview explains how those collection paths work together. Use the specialist cloud, Kubernetes and OTLP pages to evaluate the permissions, signals and release scope required for each part of your environment.
Choose the operational question
Which cloud evidence do you need first?
Start with the question the incident raises. A provider resource, a Kubernetes workload and an application signal have different identities and collection paths. AmrudAi’s documented model relates them, but each source retains its permissions, freshness and coverage. Use this overview to choose the specialist workflow rather than treating every cloud symptom alike.
| Question | Primary evidence | Boundary to preserve |
|---|---|---|
| Is a provider resource or network path affected? | Account, region, instance, route, security policy, provider event and API health. | A throttled connector is not evidence that the resource is down. |
| Did a workload, rollout or cluster dependency change? | Namespace, workload, pod, node, ingress, volume and incident-time events. | Keep disappearing instances connected to their workload history. |
| What did the service emit? | Authorized OTLP metrics, logs, trace context and bounded sampled spans. | Sampling, cardinality and retention limit what the evidence can establish. |
Continue with: Cloud resource and network monitoring · Kubernetes workload investigation · OpenTelemetry collection boundaries .
The application experience
Cloud infrastructure within the hybrid service
See the complete workspace. Enlarge any image to inspect its panels, navigation and evidence at actual size.
Multi-Cloud Infrastructure & Networks — illustrative product view with sample data. Illustrative product view · Sample data
Connect provider resources, hybrid connectivity and service endpoints across cloud accounts. Kubernetes & Container Operations — illustrative product view with sample data. Illustrative product view · Sample data
Follow workload identity through pod replacement, node pressure and east-west traffic. The capability in detail
See cloud resources and workloads in context.
Compute, storage and databases
Bring supported cloud instances, storage, database resources and load balancers into inventory, health and capacity views.
Cloud network context
Follow VPC/VNet, subnet, route-table, route, interface and security-policy relationships. Include NAT, transit, interconnect and private endpoints where the provider and pack support them.
Provider and connector health
Separate a provider/API problem, exhausted quota or throttled connector from the health of a monitored resource. Expose freshness and last successful collection.
Ephemeral-resource reconciliation
Track resource creation, change and disappearance without creating duplicate entities or silently erasing operational history.
Kubernetes hierarchy
Navigate clusters, nodes, namespaces, workloads, pods, containers, services and ingress with health, capacity and dependency context.
Workload and container evidence
Inspect CPU/memory, restarts, pending or failed states, events, network, disk and selected logs, with the related node and host in reach.
OpenTelemetry metrics and logs
Receive OTLP metrics, structured logs and bounded sampled span evidence over compatible gRPC or HTTP profiles. Preserve resource identity, service identity and trace context to connect telemetry with operational dependencies.
Governed telemetry onboarding
Preview connectivity, signal selection, entity mapping, cardinality, sensitive fields and capacity before activating a source.
Changes and service impact
Correlate material provider-control-plane, workload and deployment changes with operational signals, topology, synthetics and incidents.
Explicit telemetry boundaries
Apply source binding, rate/cardinality limits, redaction and bounded backpressure. Make rejects, drops, partial coverage and provider-flow-log conditions visible.
From information to action
A connected operational workflow.
- 01
Connect the source
Validate endpoint, authentication, permissions and the intended account or cluster scope.
- 02
Reconcile the estate
Map provider resources and Kubernetes identities to canonical entities and relationships.
- 03
Inspect signal quality
Review metrics/logs, freshness, API quotas, cardinality and source health.
- 04
Investigate in context
Follow the service through cloud networks, workloads and the underlying infrastructure.
Connect cloud and runtime evidence
Fit the way your team operates.
Bring AWS, Azure, Google Cloud, OCI and Kubernetes into the same inventory, topology and incident workflow as your on-premises estate.
- Collect resource health, provider events, network relationships and control-plane changes using customer-scoped credentials and API permissions.
- Configure provider flow logs with account permissions, privacy, cost and quota requirements visible to the operating team.
- Use OpenTelemetry metrics, structured logs, trace context, bounded sampled spans and trace-derived dependency summaries to connect services with infrastructure.
- Keep sampling, retention and telemetry quality explicit. Sampled evidence supports an investigation without claiming complete coverage of every request.
How do cloud and Kubernetes signals fit together?
How does AmrudAi use application telemetry?
AmrudAi connects OpenTelemetry metrics, logs and sampled span evidence with network, host, cloud and Kubernetes context. Teams can investigate service dependencies and infrastructure causes while continuing to use specialist developer APM, profiling or user-experience tools where those workflows are required.
Do we have to deploy AmrudAi on Kubernetes?
No. Monitoring Kubernetes is independent of how you deploy AmrudAi. Core and Sensors run as native Linux services on virtual machines or bare metal.
Can cloud collection create provider costs?
Some APIs, logs and provider features may have their own charges or quotas. Evaluate the selected services and collection settings against the customer account configuration.
What happens when a cloud API is unavailable?
AmrudAi exposes connector degradation and stale or partial evidence. It checks source health and independent observations before interpreting a failed API request as a resource or service outage.
See the workflow in your environment.
Explore the technology, service dependencies and operating requirements that matter to your team.