¿En qué estado se encuentra el recurso?
El uso, la capacidad, la disponibilidad y las señales operativas siguen siendo fundamentales.
OBSERVABILIDAD CLOUD
La nube cambia continuamente. Su capacidad para ver el entorno también debe cambiar.
En los entornos en la nube, los recursos pueden crearse, escalar, cambiar y desaparecer en pocos minutos.
Las aplicaciones atraviesan máquinas virtuales, contenedores, servicios gestionados, bases de datos, APIs, redes y dependencias externas. En este contexto, monitorear componentes de forma aislada no es suficiente.
Add Solution diseña arquitecturas de observabilidad capaces de correlacionar métricas, logs, trazas, eventos, infraestructura, aplicaciones y servicios para construir contexto en entornos en la nube, híbridos y multicloud.
Visibilidad para comprender el comportamiento, investigar incidentes, seguir el rendimiento y operar entornos cada vez más dinámicos.
ON-PREMISESCLOUD ACLOUD B
TELEMETRÍA · CORRELACIÓN
MÉTRICASLOGSTRAZASMETADATOS
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.
DINÁMICO POR DISEÑO
La nube acelera los cambios en la infraestructura. La observabilidad debe seguir ese ritmo.
En entornos dinámicos, monitorear solo los recursos conocidos previamente genera puntos ciegos. Esto no significa que toda infraestructura tradicional sea estática.
01INSTANCIACREATE
02CONTENEDORCREATE
03SERVICIOSCALE / CHANGE
04FUNCIÓNSCALE / CHANGE
05RECURSODESTROY
TENER MÉTRICAS DE CADA SERVICIO NO SIGNIFICA COMPRENDER EL COMPORTAMIENTO DEL ENTORNO COMO UN TODO.
MONITOREO × OBSERVABILIDAD CLOUD
Seguir los recursos es esencial. Conectar el comportamiento y el contexto amplía la investigación.
La CPU, la memoria, el disco y la disponibilidad responden preguntas conocidas. La observabilidad ayuda a comprender los servicios degradados, las dependencias, las cargas de trabajo, las transacciones y los cambios.
¿Cómo se relacionan los comportamientos?
Los servicios, las aplicaciones, los recursos, las dependencias, los cambios y la experiencia se analizan en contexto.
UNA APLICACIÓN · MUCHAS CAPAS
El usuario ve una aplicación. El equipo operativo necesita comprender las dependencias que ofrecen esa experiencia.
La composición varía según la arquitectura, pero una transacción puede atravesar edge, aplicación, cómputo, servicios, bases de datos y APIs externas.
- 01
USUARIO
Entrada e distribuição.
- 02
DNS / EDGE
Entrada e distribuição.
- 03
BALANCEADOR DE CARGA
Entrada e distribuição.
- 04
APLICACIÓN
Processamento e serviço.
- 05
CONTENEDOR / VM
Processamento e serviço.
- 06
SERVICIO
Processamento e serviço.
- 07
BASE DE DATOS
Dados e dependências.
- 08
API EXTERNA
Dados e dependências.
MODELOS CLOUD
Observabilidad más allá de los límites de la infraestructura.
Una transacción puede comenzar dentro de la empresa y terminar en un servicio que se ejecuta a miles de kilómetros de distancia.
Nube pública
Las cargas de trabajo y los servicios en AWS, Microsoft Azure y OCI pueden formar parte de la arquitectura sin convertir a un proveedor en el centro de la estrategia.
Nube privada
La virtualización, la infraestructura definida por software, los contenedores y las plataformas privadas requieren su propio contexto.
Nube híbrida
Las transacciones atraviesan centros de datos, redes, nube pública, SaaS y dependencias externas.
Multicloud
Más proveedores también pueden significar más consolas, modelos de telemetría y contextos operativos.
HÍBRIDO & MULTICLOUD
Cada plataforma puede ver su propia capa. El incidente las atraviesa todas.
El desafío no suele ser la falta de datos, sino de contexto entre la consola de la nube, la aplicación, la red, los logs y la infraestructura.
01ON-PREMISESDOMAIN
02REDDOMAIN
03CLOUD PÚBLICADOMAIN
04SAAS / EXTERNODOMAIN
05CONTEXTO CORRELACIONADOUNDERSTANDING
UNIFICAR EL CONTEXTO ES MÁS IMPORTANTE QUE SIMPLEMENTE COLOCAR TODOS LOS GRÁFICOS EN LA MISMA PANTALLA.
TELEMETRÍA CLOUD
Las métricas, los logs, las trazas y los metadatos cuentan distintas partes de una misma historia.
Las APIs de la nube, los eventos y la telemetría de red y aplicaciones también pueden formar parte de la arquitectura según la disponibilidad y la tecnología.
Métricas
Uso, servicios, aplicaciones, plataforma y métricas personalizadas, según la tecnología.
Logs
Evidencias de aplicaciones, sistemas, contenedores, red, servicios en la nube y eventos operativos.
Trazas
El recorrido de las transacciones por servicios, bases de datos, APIs y dependencias distribuidas.
Metadatos de recursos
Proveedor, cuenta, región, recurso, entorno, tags, clúster, namespace y carga de trabajo.
La telemetría sin identidad pierde contexto.
El proveedor, la cuenta o suscripción, la región, la zona, el recurso, el entorno, los tags, el clúster, el namespace y la carga de trabajo ayudan a explicar dónde se originó una señal y qué representa.
Una buena estrategia comienza por la forma de identificar los recursos.
El entorno, la aplicación, el servicio, el responsable o equipo y el centro de costos, cuando corresponde, hacen más útiles las señales sin convertir la observabilidad en FinOps.
CONTEXTO CLOUD-NATIVE
Un componente puede desaparecer. Las evidencias de lo ocurrido no deberían desaparecer con él.
Cuanta más infraestructura abstrae el proveedor, más importante resulta observar el comportamiento del servicio.
Cargas de trabajo efímeras
Los contenedores, el autoscaling y las instancias temporales convierten el historial en un requisito para investigar.
Kubernetes
Los clústeres, nodes, pods, contenedores, services, namespaces y cargas de trabajo forman relaciones que cambian continuamente.
Serverless
Las funciones, los eventos, la ejecución, las dependencias, la latencia y los errores necesitan contexto cuando corresponde.
Servicios gestionados
Las bases de datos, las colas, el almacenamiento, la mensajería y las APIs gestionadas siguen formando parte del comportamiento de la aplicación.
OBSERVABILIDAD DE KUBERNETES
Las direcciones cambian. La función del componente dentro del servicio debe seguir siendo comprensible.
Cuando Kubernetes forma parte de la arquitectura, cluster, node, pod, container, deployment, namespace, workload y service deben correlacionarse con aplicaciones, métricas, logs y trazas.
01CLUSTERRELACIÓN
02NODORELACIÓN
03PODRELACIÓN
04CONTENEDORRELACIÓN
05SERVICIO DE APLICACIÓNRELACIÓN
La experiencia en la nube comienza antes de llegar a ella.
La red local, WAN o Internet, edge, VPC/VNet, subredes, enrutamiento, gateways, balanceadores de carga y enlaces híbridos pueden formar parte del recorrido hasta la aplicación.
Rendimiento y Visibilidad de Red SD-WAN y ConectividadUn recurso en buen estado no explica una transacción lenta.
APM conecta las transacciones, los servicios, las bases de datos, las llamadas externas, la latencia y los errores con el contexto de la infraestructura en la nube.
Rendimiento de Aplicaciones (APM)TROUBLESHOOTING CLOUD
La nube reduce el tiempo necesario para crear infraestructura. La observabilidad debe reducir el tiempo necesario para comprenderla.
Cuando una aplicación es lenta, la investigación debe relacionar tiempo, cambio, servicio, transacción, dependencia, recurso, región y evidencia, sin prometer la identificación automática de la causa raíz.
01LATENCIA DE BASE DE DATOSSIGNAL
02LATENCIA DEL SERVICIOSIGNAL
03LATENCIA DE APISIGNAL
04EXPERIENCIA DEL USUARIOSIGNAL
05CONTEXTO DE INVESTIGACIÓNEVIDENCE
UN PROBLEMA PUEDE GENERAR MUCHOS SÍNTOMAS. LA CORRELACIÓN AYUDA A ORGANIZAR LAS EVIDENCIAS.
La arquitectura puede cambiar entre el inicio y el final de un incidente.
Los deployments, el autoscaling, la configuración, la creación y la eliminación de recursos deben relacionarse con la telemetría. Cuando es posible, el historial ayuda a comprender cómo estaba el entorno en el momento del problema.
Cuando cambie el rendimiento, pregunte qué cambió a su alrededor.
Las migraciones y modernizaciones deben validarse por el comportamiento, no solo por confirmar que los sistemas se iniciaron.
Nube Consultoría & AssessmentOPENTELEMETRY
Instrumentación abierta para generar, recopilar y exportar telemetría.
OpenTelemetry es un ecosistema y un estándar abierto, no un backend de observabilidad. Los SDKs, la instrumentación automática y los collectors pueden procesar y enrutar métricas, logs y trazas hacia distintos destinos.
01APLICACIÓN / SERVICIOOPEN TELEMETRY
02OTEL INSTRUMENTATIONOPEN TELEMETRY
03OTEL COLLECTOROPEN TELEMETRY
04PROCESAR / ENRUTAROPEN TELEMETRY
05BACKEND DE OBSERVABILIDADOPEN TELEMETRY
LAS ARQUITECTURAS ABIERTAS AYUDAN A SEPARAR LA GENERACIÓN DE TELEMETRÍA DEL DESTINO DONDE SE ANALIZARÁ.
La IA puede acelerar el análisis, la agrupación y la investigación.
La detección de anomalías, el reconocimiento de patrones, la correlación, los resúmenes y la asistencia para identificar causas probables dependen de la tecnología y de la calidad de las señales.
La IA no reemplaza la telemetría. Depende de ella.
La observabilidad también debe ser económicamente sostenible.
La recopilación, la ingesta, la cardinalidad, el procesamiento, la transferencia, la retención y el almacenamiento deben diseñarse según la finalidad operativa, el volumen, el costo, el rendimiento y el cumplimiento.
La observabilidad debe ver lo suficiente y solo lo necesario.
IAM, el privilegio mínimo, las cuentas de servicio, las claves de API, el cifrado, el acceso a la telemetría, el enmascaramiento, la supresión de datos sensibles, la retención y los datos sensibles forman parte del diseño.
Ciberseguridad PAM & SEGURIDAD DE IDENTIDADLa plataforma que observa entornos críticos también debe fallar de forma controlada.
Los collectors, los buffers, el procesamiento, el almacenamiento, la alta disponibilidad, la recuperación y las rutas de red deben definirse según la criticidad.
LÍMITES CLAROS
Capacidades complementarias, no sustitutas.
La mejor arquitectura comienza por las preguntas que deben responderse, no por la herramienta que se sustituirá.
Gestión de la nube
Aprovisionamiento, gobernanza y gestión de recursos. La observabilidad aborda la telemetría, el comportamiento y el contexto.
APM
Se centra en aplicaciones y transacciones. Cloud Observability conecta ese comportamiento con un contexto más amplio.
Monitoreo de infraestructura
Sigue el estado y los recursos. La observabilidad relaciona las dependencias y el comportamiento entre capas.
Asset Intelligence
Responde qué existe. Cloud Observability investiga cómo se comporta y cómo afecta a los servicios.
MÉTODO ADD SOLUTION
Cloud Observability no comienza por elegir dashboards.
Comienza por comprender cómo se ofrecen realmente los servicios.
- 01
Comprender
Arquitetura e cobertura.
- 02
Descubrir
Arquitetura e cobertura.
- 03
Instrumentar
Arquitetura e cobertura.
- 04
Recopilar
Telemetria e contexto.
- 05
Correlacionar
Telemetria e contexto.
- 06
Visualizar
Telemetria e contexto.
- 07
Operar
Operação e evolução.
- 08
Evolucionar
Operação e evolução.
CUÁNDO REVISAR
¿Cuándo debe reevaluar la observabilidad en la nube?
Los puntos ciegos aparecen precisamente entre la aplicación, la nube, la red, la infraestructura y los equipos que operan cada dominio.
Tenemos varias consolas y aun así tardamos demasiado en investigar incidentes.
Una evaluación ayuda a localizar la carencia y priorizar las mejoras.
La aplicación es lenta, pero los recursos en la nube parecen funcionar correctamente.
Una evaluación ayuda a localizar la carencia y priorizar las mejoras.
No podemos correlacionar las aplicaciones y la infraestructura.
Una evaluación ayuda a localizar la carencia y priorizar las mejoras.
Tenemos entornos híbridos y poca visibilidad de extremo a extremo.
Una evaluación ayuda a localizar la carencia y priorizar las mejoras.
Los logs desaparecen junto con los contenedores y las cargas de trabajo efímeras.
Una evaluación ayuda a localizar la carencia y priorizar las mejoras.
Las métricas, los logs y las trazas permanecen en plataformas distintas.
Una evaluación ayuda a localizar la carencia y priorizar las mejoras.
Utilizamos más de un proveedor de nube.
Una evaluación ayuda a localizar la carencia y priorizar las mejoras.
El volumen y el costo de nuestra telemetría siguen creciendo.
Una evaluación ayuda a localizar la carencia y priorizar las mejoras.
ASSESSMENT DE OBSERVABILIDAD CLOUD
Evalúe su observabilidad en la nube ¿Su empresa tiene observabilidad en la nube o solo varias consolas de monitoreo?
Add Solution puede evaluar las cargas de trabajo, las aplicaciones, los servicios en la nube, la telemetría, OpenTelemetry, las dependencias, las redes y los procesos operativos para identificar puntos ciegos y construir una estrategia adecuada a entornos en la nube, híbridos y multicloud.
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.
Comparta el contexto de su entorno, los impactos percibidos y los resultados que busca su organización. Add Solution dirigirá la conversación a los expertos más adecuados.
CONTEXTO DA CONVERSAObservabilidade em CloudOrigem e interesse são registrados automaticamente no atendimento.