Examen2 14 - 06 - 2019
Examen2 14 - 06 - 2019
Examen2 14 - 06 - 2019
Dynatrace stores the full details of every user action for 10 days. This enables you to analyze
individual user actions and get all details including waterfall analysis, JavaScript errors, and
mobile crashes for 10 days.
Aggregated user action metric (used in tables like Top user actions, Top JavaScript errors, and
Top mobile crashes) are available for 35 days. After 10 days, user actions data is optimized for
aggregated views and some individual user actions become unavailable for individual analysis.
However the sample set is large enough for statistical correct aggregations.
Includes Session Replay data. All user session data is stored for 35 days. Note that waterfall
analysis, JavaScript error, and crash data are stored with RUM non-aggregated user action
data.
In Managed deployments, the Session Replay data storage directory is a dedicated file store
that's used exclusively for Session Replay data.
Log Analytics
Log Analytics enables you to store all logs centrally within external storage. This makes log data
available independent of log files themselves.
For Dynatrace SaaS customers, log files are stored in Amazon Elastic File System in the zone
where your Dynatrace environment resides. You don’t have to worry about storage
performance, availability, or free space. Disk storage costs are included in your Log Analytics
subscription.
To store log files centrally on your Dynatrace Managed cluster, you must provide a common
Network File System (NFS) mount point (path) that is identical and available from all cluster
nodes. With this approach, it's your responsibility to ensure appropriate levels of performance,
availability, and free space on the mounted NFS volume.
Timeseries metrics
0-14 days: 1-minute interval granularity available for dashboarding and API access.
14-28 Days: 5-minute interval granularity available for dashboarding and API access.
28-400 days: 1-hour interval granularity available for dashboarding and API access.
400+ days: 1-day interval granularity available for dashboarding and API access.
Updates de Managed Cluster y OneAgent
8443 (https)
(…)
Live user sessions se diferencian de las completas porque vienen en un color distinto, así
pueden ser identificadas de un vistazo.
Cuando termina:
USER ACTIONS:
User action: Interaccion con el navegador que implica una llamada al servidor web
Page load
XHR action
Custom action
La diferencia clave entre estos tres tipos de user action está en la forma en que se calcula la
duración de la acción y que para cada tipo hay metricas distintas
Frontend time
Network time
Server time
Son las que marcamos como clave. Se almacenan durante más tiempo y podemos crear
thresholds y Appdex distintos para tratarlos.
0 – 14: 1 minuto
14 – 28: 5 minutos
28 – 400: 1 hora
+400: 1 dia
Network health:
Processes
Hosts
Volume
Key metrics
Traffic
Retransmission
Connectivity
Traffic:
Traffic in
Traffic out
Retransmissions
Sent
Received
Connectivity
Connections refused
Connections timeout
Memoria:
Reclaimable
Used
CPU:
Anomaly Detection
Identifica eventos o mediciones inusuales. Puede leerse como “estadísticamente improbable”
y depende en gran medida de un conocimiento profundo del performance del baseline
Dynatrace aprende los patrones de trafico de una aplicacion durante una semana y envía
alertas cuando se detectan anomalías dentro de esos patrones. Despues de una semana de
aprendizaje, Dynatrace puede predecir el tráfico de la semana siguiente
Problem Detection
Para poder identificar los root cause de los problemas Dynatrace analiza la correlacion de
eventos a traves de:
Tiempo
Procesos
Hosts
Servicios
Aplicaciones
Y todo esto desde una perspectiva de monitorizacion topologica horizontal y vertical
Deteccion de problemas
Reponse time degradations en rápido aumento para aplicaciones y servicios Cada 5 min
Response time degradations en lento aumento para aplicaciones y servicios Cada 15 min
Thresholds
Dos tipos:
Problem Analisis
Una vez se detecta un problema se puede analizar sus consecuencias desde la pagina de
problemas. Dynatrace te permite ver:
Impact Analisis
Bussiness Impact Analisis
Event Types
1. Availability events
2. Error events
3. Slowdown events
4. Resource events
5. Custom alerts
6. Info events
Impact Analysis
La página de Problems muestra un análisis de impacto de todos los Problems que se revelan en
base a un automated and multidimensional performance baselining
El business impact analysis no se activa para todos los problemas detectados, por ejemplo, no
se incluyen para los problemas detectados por los tests sinteticos ni para eventos de sólo
infraestructura como puede ser un pico de CPU
Clicando sobre un service call se abre el Service Flow que contiene las transacciones afectadas
por el problema. Service Flow te permite un analisis de cada transaccion individual con el
Purepath view
Root Cause Analysis
No solo a traves de una correlacion en el tiempo, sino que tambien hace correlacion de
EVENTOS a traves del tiempo, procesos, hosts, servicios, aplicaciones y topologia (horizontal y
vertical)
Porque no y punto
La inteligencia artificia (IA) de Dynatrace aprende los valores de referencia de los response
times de aplicaciones y servicios, sus error rates y su trafico
Trafico: periodo de aprendizaje de una semana completa (para aprender los patrones
de trafico diarios y semanales). Despues pronostica el trafico de la semana siguiente y
luego compara el trafico de aplicaciones reales entrantes con la prediccion
Error Rates: Para los failures, el cubo de baseline está listo cuando la aplicacion lleva
corriendo, al menos, el 20% de una semana. Se adapta a las versiones de los
navegadores, que pueden mostrar una tasas mayor o menor que el resto.
Response Times: para response times Dynatrace usa la mediana (median)(por encima
de la cual se encuentra el 50% mas lento de todos los calls) y usa tambien el 90%
percentil (el 10% más lento de todos los calls). Dynatrace pone especial interes en
estos ultimos. El cubo de baseline es el 20% de una semana.
Multidimensionalidad
Baselining dimensions:
User action
Geo
Browser
Operating System
Service Method
Service Method Group
Por ejemplo, las peticiones web que se envían a un servidor Tomcat específico son un ejemplo
de un servicio del lado del servidor
Se ve en:
Transactions & Sevices Seleccionar Seccion “Understand Dependecies” click en “View
Service Flow”
Nota: No muestra cuando se realizan las service calls en relacion con las demas. No muestra
necesariamente el orden en que se realizaron las llamadas entre si.
Los candidatos inactivos a la monitorizacion (que no se han comunicado con un host durante
más de dos horas) ni se incluyen en SmartScape ni en la pagina de hosts
NAMING:
Servicios:
Custom Services
Si tus servicios de aplicacion no están construidon en una tecnología estandar y no se
reconocen out-of-the-box. Se pueden monitorizar, pero como Custom Services.
Solo se soporta:
JAVA
.NET
Memory: