Investigar un informe de fallo de una aplicación móvil

El Crash report de monitoreo de aplicaciones móvilesproporciona un resumen y detalles detallados sobre fallas, que incluyen:

• Desglose del dispositivo y del sistema operativo
• Version de aplicacion
• Recuento de ocurrencias
• Usuario único afectado
• Una cronología de la interacción y el evento asociado con el accidente.
• Detalles en profundidad de una muestra de sucesos

Ver el informe de fallos

Para ver un informe de fallos:

1. Vaya a

   one.newrelic.com > All capabilities > Mobile > (select an app) > Exceptions > Crash analysis

   .

2. En la tabla

   Crash list

   , seleccione cualquier fila.

3. Revise el resumen y la información detallada del informe de fallos seleccionado.

4. Opcional: consultar o compartir los datos del gráfico.

5. Opcional: exporte a Xcode o resimbolice su código fuente para facilitar la depuración.

6. Para presentar un ticket, seleccione cualquiera de las opciones integradas con su sistema.

7. Para cerrar el informe de fallos: en la parte superior del informe, seleccione

   Mark resolved

   .

8. Para volver a la tabla

   Crash list

   : en la parte superior del informe, seleccione

   Back to crash analysis

   .

Ver detalles detallados del informe de fallos

Utilice cualquiera de las funciones UI estándar de New Relic para profundizar en información detallada. La página Crash report incluye varias opciones adicionales.

Resumen de fallos

El resumen de fallos contiene información agregada sobre todas las ocurrencias de este fallo:

• Crash identifier:

  El identificador único de este fallo, que contiene información como el nombre de la excepción, el archivo que falla, la línea, el mensaje y la función.

• Crash occurrences chart:

  Un gráfico que muestra el número de ocurrencias de este accidente en particular durante el período de tiempo seleccionado desde la primera vez que se detectó el accidente.

• Breakdown of crash type:

  Un gráfico de barras apiladas que muestra el desglose de las versiones del sistema operativo donde ocurrió este bloqueo o los dispositivos afectados

• Users affected and occurrences:

  Cuenta para la cantidad de usuarios únicos y la cantidad de veces que ocurrió el bloqueo.

Las ocurrencias cuentan

Si el agente móvil ha recopilado más de una ocurrencia del bloqueo, puede desplazarse por los ejemplos.

Traza de evento

La traza de evento muestra todos los tipos de eventos cronológicos que condujeron a un accidente.

Puedes ordenar la traza de evento cronológicamente en ambas direcciones, aunque de forma predeterminada muestra primero el evento más antiguo, generalmente el lanzamiento de una aplicación. Filtre los eventos por tipo de evento (es decir, interacción, solicitud o error de solicitud), reordene los eventos de manera ascendente o descendente y haga clic para expandir cada evento para ver más detalles sobre lo que sucedió. Por ejemplo, si desea investigar un evento de solicitud, puede ampliar el evento y observar el tiempo de respuesta y la URL de solicitud.

Detalles

Cada muestra de falla proporciona detalles sobre el dispositivo donde ocurrió la falla, incluyendo:

• App version: La versión de la aplicación donde ocurrió el bloqueo.

• Device type: El dispositivo específico donde ocurrió el accidente.

• OS version: La versión del sistema operativo del dispositivo.

• RAM used: La cantidad de memoria utilizada por la aplicación en el momento del bloqueo.

• Disk free: La cantidad de espacio libre en disco en el dispositivo en el momento del fallo.

• Attributes: Detalles sobre el atributo relacionado con el informe de fallos que puede contraer o expandir para un análisis más profundo

  Si corresponde, puede Export crash details usar Xcode o volver a simbolizar su código fuente para facilitar la depuración.

Rastreo del stack

El rastreo del stack del subproceso que generó la excepción de bloqueo aparece debajo de los detalles del bloqueo. Cada marco de la stack muestra la biblioteca o el nombre del paquete y el método asociado con ese marco stack .

El agente intenta detectar qué marco de la stack contiene el defecto de programación responsable del error. Si se detecta, ese marco stack aparece en rojo.

Para ver el estado de subprocesos distintos del subproceso que falla, seleccione See all threads.

• Las aplicaciones de iOS solo mostrarán los nombres de los métodos del código fuente y los números de línea si ha cargado el dSYM para cada compilación de su aplicación.
• Las aplicaciones de Android que usan ProGuard tendrán los nombres de los paquetes y métodos desenfocados si ha habilitado la carga de mapas de ProGuard.
• Los informes de fallos nativos de Android solo mostrarán el nombre del archivo fuente y las compensaciones relativas del código.

Informes de fallos nativos de Android

A partir de la versión 6.7.0 del agente Android New Relic, para ayudar a rastrear y diagnosticar fallas nativas, se han mejorado los informes y análisis para incluir señales de infracción y otras fallas que ocurren en el nivel de código nativo durante el tiempo de ejecución.

Estas mejoras incluyen:

• Informes de fallos nativos: señal de infracción y otros fallos informados por la aplicación durante el tiempo de ejecución, incluidos

  • Señal 4 (instrucción ilegal)
  • Señal 6 (Terminación anormal)
  • Señal 7 (Error de bus/mal acceso a la memoria)
  • Señal 8 (excepción de punto flotante)
  • Señal 11 (Segmentación complicada/referencia de memoria no válida)

• Excepciones de tiempo de ejecución nativas El agente nativo informará cualquier excepción de C++ no controlada generada por la aplicación durante el tiempo de ejecución y las informará como excepciones controladas. Las excepciones no controladas suelen ser fatales y bloquearán la aplicación.

• Condiciones de la aplicación que no responde (ANR) El agente nativo detectará e informará las condiciones de la aplicación que no responde cuando una actividad o hilo de servicio haya estado bloqueado durante más tiempo que el tiempo permitido por Android, que es de 5 segundos para actividades en primer plano y de 5 a 200 segundos para servicios. Las condiciones ANR se informarán como una excepción manejada (en lugar de accidentes), ya que no se consideran condiciones fatales.

Puede ver información detallada sobre fallas nativas en UICrash analysis de New Relic Mobile o recibir una notificación de falla por correo electrónico. También puede explorar los datos del accidente en mayor profundidad con Insights de New Relic o integrarlos con sistemas de tickets para una mayor investigación.

Configuración

La configuración requiere agregar una dependencia adicional en el archivo build.gradle de los proyectos de aplicación que inician el agente New Relic :

dependencies {
    implementation 'com.newrelic.agent.android:agent-ndk:1.+'
}

Los artefactos del agente nativo de Android se pueden encontrar en MavenCentral y siguen las convenciones de control de versiones semánticas. Consulte las notas de la versión del agente de Android para obtener detalles completos sobre lanzamientos y descargas.

Puesta en marcha

En el código de la aplicación donde se agrega el agente New Relic (generalmente MainActivity), habilite el indicador de característica NativeReporting antes de iniciar el agente:

NewRelic.enableFeature(FeatureFlag.NativeReporting);
NewRelic
      .withApplicationToken("<appToken>")
      .start(this.getApplication());

Deshabilitar los informes de fallos nativos

Si desea utilizar otra herramienta nativa de informes de fallos, desactive los informes de fallos nativos de New Relic Mobile llamando al NewRelic.disableFeature{FeatureFlag/NativeReporting) antes de la inicialización del agente. Por ejemplo:

NewRelic.disableFeature(FeatureFlag.NativeReporting);
NewRelic
      .withApplicationToken("<appToken>")
      .start(this.getApplication());

Depurar el reportero de fallos nativo

Los informes de fallos para Android están diseñados para funcionar con otros marcos de informes de fallos mediante la cadena del controlador de excepciones no detectadas si ya está registrado.

Cualquier problema que surja durante la generación de informes aparecerá en logcat. Cada vez que New Relic detecta una infracción, se registra en el nivel DEBUG . Por ejemplo, para una infracción de segmento, vería

Signal 11 intercepted: Segmentation violation (invalid memory reference)
Invoking previous handler for signal 11

La entrega de informes nativos se difiere hasta la siguiente invocación de la aplicación, por lo que no verá informes de fallos en la interfaz de usuario de New Relic Mobile hasta que la aplicación se haya lanzado nuevamente. En caso de una falla, el agente nativo generalmente no tendrá suficiente tiempo ni estabilidad para procesar el informe. En cambio, los datos del informe se escriben rápidamente en el almacenamiento local para procesarlos la próxima vez que se lance la aplicación.

Resolución de problemas

Los informes nativos se almacenan en el dispositivo como archivos JSON en /data/data/{app package name}/cache/newrelic/reports. Este directorio no debe contener ningún informe después del lanzamiento de la aplicación después de un bloqueo. Al igual que con otra información del tiempo de ejecución del agente, el agente nativo escribe su estado en logcat para combinarlo con el estado del tiempo de ejecución del agente. La etiqueta log del agente de Android es com.newrelic.android y se puede aislar de otros registros en tiempo de ejecución ejecutando 'adb logcat | grep "com.newrelic.android" del caparazón.