How is the resource doing?
Utilisation, capacity, availability and operational signals remain essential.
CLOUD OBSERVABILITY
Cloud changes continuously. Your ability to see the environment needs to change too.
In cloud environments, resources can be created, scale, change and disappear within minutes.
Applications span virtual machines, containers, managed services, databases, APIs, networks and external dependencies. Monitoring components in isolation is not enough.
Add Solution designs observability architectures that correlate metrics, logs, traces, events, infrastructure, applications and services to build context across cloud, hybrid and multicloud environments.
Visibility to understand behaviour, investigate incidents, track performance and operate increasingly dynamic environments.
ON-PREMISESCLOUD ACLOUD B
TELEMETRY · CORRELATION
METRICSLOGSTRACESMETADATA
ENGENHARIA APLICADA
Ambientes dinâmicos exigem telemetria que acompanhe recursos, serviços e mudanças.
A Add Solution conecta sinais nativos, aplicações, custos e dependências para compreender workloads cloud e híbridos.
Arquitetura, execução e operação tratadas como partes da mesma responsabilidade.
DYNAMIC BY DESIGN
Cloud accelerates infrastructure change. Observability needs to keep pace.
In dynamic environments, monitoring only previously known resources creates blind spots. That does not mean all traditional infrastructure is static.
01INSTANCECREATE
02CONTAINERCREATE
03SERVICESCALE / CHANGE
04FUNCTIONSCALE / CHANGE
05RESOURCEDESTROY
HAVING METRICS FOR EACH SERVICE DOES NOT MEAN UNDERSTANDING THE BEHAVIOR OF THE ENVIRONMENT AS A WHOLE.
MONITORING × CLOUD OBSERVABILITY
Tracking resources is essential. Connecting behaviour and context deepens investigation.
CPU, memory, disk and availability answer known questions. Observability helps explain degraded services, dependencies, workloads, transactions and changes.
How are behaviours connected?
Services, applications, resources, dependencies, changes and experience are analysed in context.
ONE APPLICATION · MANY LAYERS
The user sees an application. The operations team needs to understand the dependencies delivering that experience.
The composition varies by architecture, but a transaction may span edge, application, compute, services, databases and external APIs.
- 01
USER
Entrada e distribuição.
- 02
DNS / EDGE
Entrada e distribuição.
- 03
LOAD BALANCER
Entrada e distribuição.
- 04
APPLICATION
Processamento e serviço.
- 05
CONTAINER / VM
Processamento e serviço.
- 06
SERVICE
Processamento e serviço.
- 07
DATABASE
Dados e dependências.
- 08
EXTERNAL API
Dados e dependências.
CLOUD MODELS
Observability across infrastructure boundaries.
A transaction can start inside the company and finish in a service running thousands of kilometres away.
Public cloud
Workloads and services in AWS, Microsoft Azure and OCI can form part of the architecture without making one provider the centre of the strategy.
Private cloud
Virtualisation, software-defined infrastructure, containers and private platforms require their own context.
Hybrid cloud
Transactions span data centres, networks, public cloud, SaaS and external dependencies.
Multicloud
More providers can also mean more consoles, telemetry models and operational contexts.
HYBRID & MULTICLOUD
Each platform may see its own layer. The incident crosses them all.
The challenge is often not a lack of data, but a lack of context connecting the cloud console, application, network, logs and infrastructure.
01ON-PREMISESDOMAIN
02NETWORKDOMAIN
03PUBLIC CLOUDDOMAIN
04SAAS / EXTERNALDOMAIN
05CORRELATED CONTEXTUNDERSTANDING
UNIFYING CONTEXT IS MORE IMPORTANT THAN SIMPLY PUTTING ALL THE CHARTS ON THE SAME SCREEN.
CLOUD TELEMETRY
Metrics, logs, traces and metadata tell different parts of the same story.
Cloud APIs, events, network telemetry and application telemetry can also form part of the architecture, depending on availability and technology.
Metrics
Utilisation, services, applications, platform and custom metrics, depending on the technology.
Logs
Evidence from applications, systems, containers, network, cloud services and operational events.
Traces
The path of transactions through services, databases, APIs and distributed dependencies.
Resource metadata
Provider, account, region, resource, environment, tags, cluster, namespace and workload.
Telemetry without identity loses context.
Provider, account or subscription, region, zone, resource, environment, tags, cluster, namespace and workload help explain where a signal originated and what it represents.
A sound strategy starts with how resources are identified.
Environment, application, service, owner or team, and cost centre where appropriate make signals more useful without turning observability into FinOps.
CLOUD-NATIVE CONTEXT
A component may disappear. Evidence of what happened should not disappear with it.
The more infrastructure a provider abstracts away, the more important it becomes to observe service behaviour.
Ephemeral workloads
Containers, autoscaling and temporary instances make historical data a requirement for investigation.
Kubernetes
Clusters, nodes, pods, containers, services, namespaces and workloads form relationships that change continuously.
Serverless
Functions, events, execution, dependencies, latency and errors need context where applicable.
Managed services
Managed databases, queues, storage, messaging and APIs still contribute to application behaviour.
KUBERNETES OBSERVABILITY
Addresses change. The component's role in the service needs to remain understandable.
When Kubernetes is part of the architecture, cluster, node, pod, container, deployment, namespace, workload and service need to be correlated with applications, metrics, logs and traces.
01CLUSTERRELATION
02NODERELATION
03PODRELATION
04CONTAINERRELATION
05APPLICATION SERVICERELATION
The cloud experience begins before the cloud.
The local network, WAN or Internet, edge, VPC/VNet, subnets, routing, gateways, load balancers and hybrid links may all be part of the path to the application.
Network Performance & Visibility SD-WAN & ConnectivityA healthy resource does not explain a slow transaction.
APM connects transactions, services, databases, external calls, latency and errors to the cloud infrastructure context.
Application Performance (APM)CLOUD TROUBLESHOOTING
Cloud reduces the time to create infrastructure. Observability needs to reduce the time to understand it.
When an application is slow, investigation needs to connect time, change, service, transaction, dependency, resource, region and evidence—without promising automatic root cause identification.
01DATABASE LATENCYSIGNAL
02SERVICE LATENCYSIGNAL
03API LATENCYSIGNAL
04USER EXPERIENCESIGNAL
05INVESTIGATION CONTEXTEVIDENCE
ONE PROBLEM CAN GENERATE MANY SYMPTOMS. CORRELATION HELPS ORGANIZE THE EVIDENCE.
The architecture may change between the start and end of an incident.
Deployments, autoscaling, configuration, resource creation and removal need to be connected to telemetry. Where possible, history helps explain the environment's state at the time of the problem.
When performance changes, ask what changed around it.
Migrations and modernisation should be validated by behaviour, not simply by confirming that systems started.
Cloud Consulting & AssessmentOPENTELEMETRY
Open instrumentation to generate, collect and export telemetry.
OpenTelemetry is an ecosystem and open standard—not an observability backend. SDKs, auto-instrumentation and collectors can process and route metrics, logs and traces to different destinations.
01APPLICATION / SERVICEOPEN TELEMETRY
02OTEL INSTRUMENTATIONOPEN TELEMETRY
03OTEL COLLECTOROPEN TELEMETRY
04PROCESS / ROUTEOPEN TELEMETRY
05OBSERVABILITY BACKENDOPEN TELEMETRY
OPEN ARCHITECTURES HELP SEPARATE TELEMETRY GENERATION FROM THE DESTINATION WHERE IT WILL BE ANALYZED.
AI can accelerate analysis, grouping and investigation.
Anomaly detection, pattern recognition, correlation, summarisation and assistance in identifying probable causes depend on the technology and signal quality.
AI does not replace telemetry. It depends on it.
Observability also needs to be economically sustainable.
Collection, ingestion, cardinality, processing, transfer, retention and storage need to be designed around operational purpose, volume, cost, performance and compliance.
Observability needs to see enough—and only what is necessary.
IAM, least privilege, service accounts, API keys, encryption, telemetry access, masking, redaction, retention and sensitive data are part of the design.
Cybersecurity PAM & Identity SecurityA platform observing critical environments also needs to fail in a controlled way.
Collectors, buffers, processing, storage, high availability, recovery and network paths must be defined according to criticality.
CLEAR BOUNDARIES
Complementary capabilities, not replacements.
The best architecture starts with the questions that need answering—not the tool to be replaced.
Cloud management
Resource provisioning, governance and management. Observability deals with telemetry, behaviour and context.
APM
Focuses on applications and transactions. Cloud Observability connects that behaviour to the broader context.
Infrastructure monitoring
Tracks health and resources. Observability connects dependencies and behaviour across layers.
Asset Intelligence
Identifies what exists. Cloud Observability investigates how it behaves and affects services.
ADD SOLUTION METHOD
Cloud Observability does not start with choosing dashboards.
It starts with understanding how services are actually delivered.
- 01
Understand
Arquitetura e cobertura.
- 02
Discover
Arquitetura e cobertura.
- 03
Instrument
Arquitetura e cobertura.
- 04
Collect
Telemetria e contexto.
- 05
Correlate
Telemetria e contexto.
- 06
View
Telemetria e contexto.
- 07
Operate
Operação e evolução.
- 08
Evolve
Operação e evolução.
WHEN TO REVIEW
When should you reassess cloud observability?
Blind spots appear precisely between application, cloud, network, infrastructure and the teams operating each domain.
We have several consoles, yet incident investigation still takes too long.
An assessment helps locate the gap and prioritise improvements.
The application is slow, but cloud resources appear healthy.
An assessment helps locate the gap and prioritise improvements.
We cannot correlate applications and infrastructure.
An assessment helps locate the gap and prioritise improvements.
We have hybrid environments and limited end-to-end visibility.
An assessment helps locate the gap and prioritise improvements.
Logs disappear along with containers and ephemeral workloads.
An assessment helps locate the gap and prioritise improvements.
Metrics, logs and traces remain on different platforms.
An assessment helps locate the gap and prioritise improvements.
We use more than one cloud provider.
An assessment helps locate the gap and prioritise improvements.
Our telemetry volume and cost keep growing.
An assessment helps locate the gap and prioritise improvements.
CLOUD OBSERVABILITY ASSESSMENT
Assess your cloud observability Does your company have cloud observability—or just several monitoring consoles?
Add Solution can assess workloads, applications, cloud services, telemetry, OpenTelemetry, dependencies, networks and operational processes to identify blind spots and build a strategy suited to cloud, hybrid and multicloud environments.
PERGUNTAS FREQUENTES
Decisões importantes sobre Observabilidade em Cloud
Respostas objetivas para dúvidas técnicas e operacionais que costumam surgir antes de um projeto.
01Como a Add Solution aborda um projeto de Observabilidade em Cloud?
Casos de uso, permissões mínimas, coleta, tags, dashboards, alertas e controle de volume estruturam a implantação. A solução é dimensionada a partir do contexto do cliente, com responsabilidades e critérios de aceite definidos antes da execução.
02Quais informações precisam ser avaliadas antes da definição da solução?
Contas, subscriptions, regiões, serviços, workloads, tags, SLIs, logs, traces, custos e limites de API. Esse diagnóstico evita recomendações genéricas e ajuda a priorizar aquilo que efetivamente reduz risco ou melhora a operação.
03A solução pode aproveitar o ambiente tecnológico existente?
Telemetria nativa pode integrar APM, logs, infraestrutura, rede, ITSM e ambientes on-premises. O que deve ser mantido, modernizado, integrado ou substituído é decidido por aderência técnica e valor operacional, não por uma premissa de renovação total.
04Como a Add Solution reduz riscos durante implantação ou mudança?
A execução considera dependências, janelas, validações, comunicação, evidências e rollback quando aplicável. Mudanças críticas são divididas em etapas verificáveis para preservar a continuidade.
05Como o ambiente continua evoluindo após a entrega?
Novos recursos, custos de telemetria, mudanças, cobertura e comportamento exigem revisão constante. A continuidade pode ser assumida pela equipe do cliente, pela Add Solution ou por um modelo combinado, conforme o escopo contratado.
FALE COM UM ESPECIALISTA
Vamos conversar sobre Observabilidade em Cloud.
Share the context of your environment, the perceived impacts and the results your organization seeks. Add Solution will direct the conversation to the most appropriate experts.
CONTEXTO DA CONVERSAObservabilidade em CloudOrigem e interesse são registrados automaticamente no atendimento.