FAQ sur la surveillance des applications mobiles

Outre la surveillance Instana, l'agent mobile collecte automatiquement les informations suivantes de l'application :

• Identifiant du bundle ou de l'application
• Version de l'application et de la compilation
• Langue actuelle de l'application
• iOS/Android version, modèle de l'appareil, matériel, appareil et fabricant
• Qu'un appareil soit jailbreaké ou rooté
• Taille et résolution de l'écran
• Nom du transporteur et type de connexion (2G, 3G, 4G...)

Pour éviter de bloquer l'unité d'exécution principale (UI), le signalement et la gestion des files d'attente sont effectués dans une unité d'exécution en arrière-plan.

L'agent stocke toutes les balises reçues dans une file d'attente persistante au sein de l'appareil, de sorte que les balises ne soient pas perdues en cas d'imprévus tels que des plantages ou des arrêts forcés. Chaque balise requiert environ 600 octets d'espace de stockage.

Les balises sont supprimées une seconde après l'arrêt de leur génération (dix secondes si la batterie est faible) afin d'éviter tout impact sur les performances réseau de votre application.

Avant la purge, les balises se sont connectées par lots de 100. Chaque lot est ensuite transmis via une seule requête « HTTP » (compressée si l'appareil le permet, via la même connexion « HTTP » si l'appareil le permet).

Si l'appareil est hors ligne lorsque l'agent tente de les envoyer, celui-ci attend que l'appareil se reconnecte pour envoyer les balises.

La file d'attente a une limite maximale par défaut de 1000 balises. Si d'autres balises sont générées alors que la file d'attente est pleine, les nouvelles balises sont ignorées.

Si la transmission des balises reçoit une réponse d'erreur du serveur, l'agent relance automatiquement la transmission jusqu'à trois fois en utilisant un mécanisme de recul exponentiel de type « 10s ». Si cette nouvelle tentative automatique échoue, les balises ne seront toujours pas supprimées; elles resteront dans la file d'attente pour être réessayées en même temps que le reste de la file d'attente lorsque de nouvelles balises seront générées.

Les demandes de transmission de données des utilisateurs de l'application à nos serveurs peuvent ne pas fonctionner. Dans ces cas, nous essayons de distribuer les balises dans le cadre de la prochaine transmission de données de surveillance, par exemple, au démarrage de l'application mobile suivante.

En raison de problèmes réseau, la génération de rapports sur les balises peut échouer. Les balises sont conservées dans la file d'attente pour la prochaine tentative de transmission.

Oui, prenons comme exemple la limite de 100 balises décrite ici. Lorsque la file d'attente est pleine et ne peut pas être vidée (en raison de problèmes réseau), toutes les balises à venir sont ignorées.

Instana recommande de ne pas tenter de passer par un proxy pour les points de terminaison de l' HTTP. Instana ne propose aucune assistance pour la configuration de proxys ni pour les problèmes pouvant survenir suite à l'utilisation d'un proxy. Si vous souhaitez (ou avez) encore faire cela, vous pouvez trouver ces pointeurs utiles:

• Définissez des en-têtes HTTP Host appropriés.
• Respectez la différence entre les serveurs eum.instana.io et eum-{region}.instana.io.
• Assurez-vous que nos serveurs connaissent les adresses IP des utilisateurs. Envoyer X-FORWARDED-FOR l'en-tête aux serveurs avec l'adresse IP de l'utilisateur. Vous pouvez également envoyer un en-tête X-REALER-IP « HTTP » (oui, c'est bien intentionnel X-REAL-IP) aux serveurs Instana, qui contient l'adresse IP de l'utilisateur.
• Transmettez tous les en-têtes HTTP que les serveurs d'Instana incluent dans le corps de réponse.
• Ne procédez à aucune mise en cache dans le proxy.

Actuellement, vous pouvez utiliser Gradle pour obtenir des informations sur l'utilisation conditionnelle des plug-ins :

Consultez les exemples suivants dans le instana-example répertoire du dépôt Instana :

instana-example/app/build.gradle

instana-example/app/src/main/java/com/instana/mobileeum/DemoApp.kt

Si vous ne souhaitez pas que les codes de l' Instana soient exécutés dans votre application, procédez comme suit :

1. Consultez l' BuildType s actuelles sur Gradle.

   Dans votre code app/build.gradle, utilisez l'extrait de code suivant pour récupérer le type de build actuel, puis définissez enableInstana en fonction de ce type de build.

   def buildType = gradle.startParameter.taskRequests.stream()
       .flatMap { it.args.stream() }
       .map { it.contains("Release") ? "Release" : it.contains("Debug") ? "Debug" : null}
       .filter(Objects::nonNull)
       .findFirst()
   
   buildType.ifPresent { println "buildType is ${it}" }
   def enableInstana = buildType.orElse("").matches("Debug")
    

2. Appliquez Instana plugin de manière conditionnelle.

   if (enableInstana) {
       println "instana> apply instana plugin"
       apply plugin: 'com.instana.android-agent-plugin'
   }
    

3. Ajoutez la clé « Instana » de manière conditionnelle dans le fichier « Gradle ».

   Dans ce cas, le INSTANA_REPORTING_URL champ contient une chaîne vide si l'option « Instana » est désactivée.

   android {
       defaultConfig {
           def instanaProperties = new Properties()
           instanaProperties.load(new FileInputStream("$project.projectDir/instana.properties"))
           buildConfigField 'String', 'INSTANA_KEY', enableInstana ? "${instanaProperties["instana.key"]}" : '""'
           buildConfigField 'String', 'INSTANA_REPORTING_URL', enableInstana ? "${instanaProperties["instana.reportingURL"]}" : '""'
       }
   }
    

4. Initialiser le moteur d'exécution d' Instana.

   Désormais, l'environnement d'exécution d' Instana s ne sera plus initialisé avec un type de compilation indésirable.

   if (BuildConfig.INSTANA_REPORTING_URL.isNotBlank()) {
       Instana.setup(this, InstanaConfig(
                   reportingURL = BuildConfig.INSTANA_REPORTING_URL,
                   key = BuildConfig.INSTANA_KEY
               ))
   }
    

1. Une session démarre automatiquement chaque fois que l'application est démarrée, lorsque l'agent est configuré
2. Un sessionID est automatiquement généré pour la session
3. Le sessionID reste inchangé tant que l'application est active (au premier plan de l'arrière-plan)
4. Toutes les balises envoyées par l'agent Android Instana ou l'agent iOS contiennent les mêmes sessionID
5. Le sessionID est supprimé lorsque l'application est arrêtée ; lorsque le processus lui-même est arrêté
6. Lors du prochain démarrage de l'application, un nouveau sessionID sera automatiquement généré

• La durée de la demande
• HTTP méthode (POST, GET……)
• URL s complètes et chemin d'accès
• Code d'état (par exemple 200)
• Taille des réponses (en-tête, corps, corps décodé)
• Toute erreur sous-jacente
• Identifiant de traçage du backend pour la corrélation du backend

Oui, vous pouvez créer votre propre protocole URLProtocol pour transmettre vos demandes et réponses via une session URLSession personnalisée. Instana HTTP La surveillance ignore automatiquement tout élément URLSession dont le délégué est URLProtocol . Mais vous pouvez également ignorer explicitement les URLSession personnalisés qui ne sont pas surveillés via Instana.ignore(yourURLSession). Si vous utilisez URLSession à l'intérieur de votre propre URLProtocol sans délégué, vous devez ignorer cette session dans l'agent Instana iOS. Sinon, la requête et la réponse font l'objet d'un double contrôle.

Pas toujours. Le swizzling dans l'environnement d'exécution est principalement effectué en ajoutant une méthode:

func swizzled_touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) {
  // looks weird, but it calls the original implementation
   swizzled_touchesBegan(touches, with: event)
   print("do some custom magic here")
 }
 

Et puis les nouvelles et les anciennes méthodes sont échangées par:

if let originalMethod = class_getInstanceMethod(UIResponder.self, #selector(touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?))),
   let swizzledMethod = class_getInstanceMethod(UIResponder.self, #selector(swizzled_touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?))) {
        method_exchangeImplementations(originalMethod, swizzledMethod)
}
 

Toutefois, cela peut entraîner un comportement inattendu lorsque l'environnement d'exécution effectue un appel de réacheminement comme dans UIResponder. Il arrive que le moteur d'exécution assure le transfert des messages. Cette technique de redirection peut provoquer un plantage si un message (par exemple, le message « new swizzled_touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?)») est transféré vers un autre destinataire sur lequel la méthode « new » n'existe pas. Dans l'agent « Instana » ( iOS ), il n'est pas possible d'ajouter une deuxième méthode à la classe. Par conséquent, vous définissez directement une nouvelle implémentation (via un bloc) pour le sélecteur d'origine et vous remplacez ainsi l'implémentation d'origine. L'implémentation d'origine, temporairement stockée, est alors appelée à l'intérieur de la nouvelle fonction ; le changement ne laisse donc aucune trace.

Non, car les sous-classes URLProtocol personnalisées ne sont pas disponibles pour les sessions en arrière-plan. (Voir URLSession doc.)

Toutes les demandes HTTP incluent une corrélation back-end automatique dans les back-ends qui sont surveillés par l'agent hôte d'Instana. Il se peut que vous n'ayez pas besoin de suivre ou de configurer quoi que ce soit côté client.

Pour assurer la corrélation côté serveur, l'agent utilise les en-têtes d' HTTP s suivants :

• En-têtes de réponse :
  • Server-Timing

iOS : Instana L'application « iOS » est compatible à partir d' iOS 12.

Swift 5 (depuis la version 10.2 de Xcode) ou une version ultérieure.

Utilisez le gestionnaire de paquets « Swift » dans Xcode. Vous pouvez également utiliser CocoaPods. Pour configurer l'agent Instana iOS, appelez une méthode dans application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions:.

Niveau d'API minimum pris en charge : Android API 16 (Android 4.1 « Jelly Bean »).

AndroidX : la bibliothèque « AndroidX » est prise en charge et requise.

Langages : Java et Kotlin sont pris en charge.

Java Cible de compatibilité : Java 1.8 ou version ultérieure.

Si votre application dépend de Guava, vous risquez de rencontrer l'erreur de compilation suivante après avoir ajouté l'agent Android « Instana ».

Duplicate class com.google.common.util.concurrent.ListenableFuture found in modules guava-25.0-android.jar (com.google.guava:guava:25.0-android) and listenablefuture-1.0.jar (com.google.guava:listenablefuture:1.0)
 

Pour résoudre ce problème, ajoutez la dépendance suivante à votre application :

implementation 'com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava'
 

Cela renvoie à un problème bien connu, qui peut se produire lorsque les versions de vos applications OkHttp-logging-interceptor ne correspondent OkHttp pas. Cette situation est décrite plus en détail à l'adresse suivante : https://github.com/square/okhttp/issues/2839.

Instana L'agent Android utilise OkHttp v4, qui est peut-être plus récent que le OkHttp.

Pour résoudre ce problème, mettez à jour vos applications OkHttp vers OkHttp-logging-interceptor les versions disponibles.

Instana L'agent Android utilise les UUID d' Java.

Un faux positif bien connu est généré par StrictMode sur Android API 18 et les versions antérieures : https://issuetracker.google.com/issues/36969031.

Solution de contournement : désactivez penaltyDeath ou detectDiskReads pour API 18 et les versions antérieures.

Erreur : java.lang.NoSuchMethodError: No virtual method setInitialDelay(JLjava/util/concurrent/TimeUnit;)Landroidx/work/OneTimeWorkRequest$Builder; in class Landroidx/work/OneTimeWorkRequest$Builder; or its super classes (declaration of 'androidx.work.OneTimeWorkRequest$Builder'

WorkManager 2.1.0 a modifié la signature de méthode pour setInitialDelay. Avant WorkManager 2.1.0:

abstract class WorkRequest {
    abstract static class Builder<B extends Builder, W extends WorkRequest> {
    }
}

class OneTimeWorkRequest extends WorkRequest {
   static class Builder extends WorkRequest.Builder<Builder, OneTimeWorkRequest> {
       public @NonNull Builder setInitialDelay(long duration, @NonNull TimeUnit timeUnit) {
          ....
       }
  }
}
 

D'après WorkManager 2.1.0:

abstract class WorkRequest {
    abstract static class Builder<B extends Builder, W extends WorkRequest> {
         public @NonNull B setInitialDelay(long duration, @NonNull TimeUnit timeUnit) {
              ...
         }
    }
}

class OneTimeWorkRequest extends WorkRequest {
   static class Builder extends WorkRequest.Builder<Builder, OneTimeWorkRequest> {
  }
}
 

En effet, toutes les dépendances d'un projet doivent utiliser exclusivement WorkManager 2.1.0 + ou des versions antérieures.

Instana Android Agent utilise WorkManager 2.4.0 +.

Si cette erreur s'affiche, le problème le plus probable est qu'une autre dépendance utilise une version plus ancienne d' WorkManager. Veillez à le mettre à jour.

On sait que cette erreur survient lorsqu'un plugin Gradle, qui nécessite une version antérieure à 3.6.1 du plugin Android Gradle, est compilé à l'aide du plugin Android Gradle 3.6.1 ou d'une version ultérieure.

Par exemple, l'utilisation du plug-in Realm Database 7.0.1 avec le plug-in Android Gradle 4.0.1 et l'agent Android Instana 3.4.0 peut entraîner cette erreur de compilation. Le journal des erreurs résultant contient une référence à l'échec de la tâche du transformateur du domaine en premier, puis peut-être à un autre plug-in (non pertinent):

[...]
Task :app:transformClassesWithRealmTransformerForDevevelopDebug FAILED
[...]
 

Pour résoudre ce problème, essayez de mettre à niveau le plug-in incriminé.

Vous pouvez également:

1. Assurez-vous que le plug-in de l'agent Android « Instana » soit lancé après le plug-in à l'origine du problème. Exemple :

   apply plugin: 'com.android.application'
   apply plugin: 'realm-android'
   apply plugin: 'com.instana.android-agent-plugin'
   
    

2. Revenir à une version antérieure du plug-in Android Gradle de votre application, celle requise par le plug-in problématique

À l'heure actuelle, il semblerait que l'une des transformations de bytecode appliquées par le plug-in Firebase Performance ait pour effet indésirable d'empêcher l'agent Android d' Instana.

Pour éviter ce problème, assurez-vous que l'agent Android d' Instana soit exécuté avant le plug-in Firebase Performance.

Pour ce faire, il suffit de modifier l'ordre dans lequel vous ajoutez chaque plug-in à votre projet :

apply plugin: 'com.instana.android-agent-plugin' // Instana agent will be applied before Firebase Performance
apply plugin: 'com.google.firebase.firebase-perf'
 

Chaque version majeure de l'agent Android d' Instana est compatible avec une branche spécifique du plug-in Android d' Gradle.

Cette erreur est susceptible de se produire lorsque le plug-in d' Gradle s Android utilisé n'est pas pris en charge par l'agent Android d' Instana.

Reportez-vous à la section Plug-in Android Gradle et à la section Gradle version de la documentation pour vérifier la matrice de compatibilité et savoir où trouver la version actuelle du plug-in Android Gradle de votre application.

L'erreur complète est : Fatal Exception: java.lang.NoClassDefFoundError: Failed resolution of: Landroidx/work/impl/utils/futures/AbstractFuture;

Cela peut se produire si les dépendances de votre application nécessitent à un moment donné une dépendance sur 9999.0-empty-to-avoid-conflict-with-guava mais qu'elle n'en a plus besoin.

Si votre application contient la dépendance suivante, essayez de la supprimer:

implementation 'com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava'
 

Le message d'erreur complet est (pour la version DevDebug, par exemple) :

FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:transformClassesWithDexBuilderForDevDebug'.
> There were multiple failures while executing work items
   > A failure occurred while executing com.android.build.gradle.internal.transforms.DexArchiveBuilderTransform$DexConversionWorkAction
      > Failed to process /Users/developer/Projects/mobile-app/android/app/build/intermediates/javac/devDebug/classes
[...]
 

Cette erreur indique une incompatibilité entre la version de l'agent « Instana » et les versions du plug-in « Android Gradle ». Reportez-vous aux instructions d'installation spécifiques à la plateforme pour en savoir plus sur les combinaisons prises en charge.

Lorsque l'agent React Native est mis à jour vers une nouvelle version depuis votre application mobile, exécutez la commande suivante depuis le terminal pour supprimer complètement l'ancienne version mise en cache de l'agent iOS et de l'agent Android :

cd android && ./gradlew clean
cd ..
cd ios && pod cache clean --all && rm -rf build
cd ..
rm -rf node_modules
yarn cache clean --force
yarn install
cd ios && pod install
 

Par défaut, l'agent « Instana » n 'inclut pas de données permettant d'identifier des utilisateurs individuels. En outre, l'agent n'applique pas de techniques telles que l' empreinte digitale du périphérique.

Les données spécifiques à l'utilisateur peuvent être mises à la disposition d' Instana via l 'utilisateur iOS API ou l 'utilisateur Android API.

L'agent Instana peut être configuré par les clients pour transmettre les informations d'identification d'utilisateur à Instana. Ces informations ne sont utilisées que pour fournir les fonctions visibles dans Instana. Instana n'interprète pas ces données d'une autre manière, et elles ne sont pas non plus corrélées entre les clients.

Les demandes de suppression peu fréquentes, par exemple pour se conformer au RGPD, sont prises en charge. Si vous prévoyez de recevoir des demandes de suppression fréquentes ou périodiques, transmettez plutôt des données anonymisées à Instana (par exemple, des identifiants d'utilisateur hachés).

Oui, les adresses IP sont anonymisées. Par défaut, le dernier octet des adresses IPv4 et les 80 derniers bits des adresses IPv6 sont définis sur zéro. Des règles d'anonymisation plus strictes peuvent être définies via l'onglet « Configuration » du tableau de bord d'une application mobile, dans l'interface utilisateur d' Instana.

Le tableau suivant présente les fonctionnalités disponibles pour chaque framework :

L'agent Android de Instana nécessite actuellement des modifications des fichiers ` Gradle ` au niveau du projet et de l'application dans toute application React Native. Pour plus d'informations, consultez les instructions de configuration Android pour React Native.

Cependant, dans un flux de travail géré par Expo, vous ne pouvez pas modifier directement les build.gradle fichiers, car ceux-ci sont générés lors de la compilation. Cette restriction s'applique uniquement lorsque vous utilisez des workflows « Bare » ou « Ejected » qui permettent la gestion manuelle des dépendances.

À titre de solution provisoire, vous pouvez créer un plug-in de configuration Expo personnalisé pour intégrer l'agent Android d' Instana à Expo. Cette approche est expérimentale et pourrait ne pas fonctionner dans tous les environnements Expo. Instana ne prend pas officiellement en charge cette méthode ni les flux de travail gérés par Expo.

Créez un nouveau fichier nommé app.plugin.js à la racine de votre projet et ajoutez-y le contenu suivant :

const {
  withProjectBuildGradle,
  withAppBuildGradle,
  createRunOncePlugin,
} = require('@expo/config-plugins');

const INSTANA_ANDROID_PLUGIN_VERSION = '6.2.5';
const PLUGIN_NAME = 'withInstanaAndroidPlugin';

// Modify android/build.gradle
const withInstanaProjectGradle = (config) => {
  return withProjectBuildGradle(config, (config) => {
    if (config.modResults.language === 'groovy') {
      let buildGradle = config.modResults.contents;

      // Add INSTANA version to ext block if not present
      if (!buildGradle.includes('INSTANA_ANDROID_PLUGIN_VERSION')) {
        buildGradle = buildGradle.replace(
          /ext\s*{([\s\S]*?)}/,
          (match, contents) => {
            return `ext {
    ${contents.trim()}
    INSTANA_ANDROID_PLUGIN_VERSION = "${INSTANA_ANDROID_PLUGIN_VERSION}"
}`;
          }
        );
      }

      // Add classpath dependency
      if (!buildGradle.includes('com.instana:android-agent-plugin')) {
        buildGradle = buildGradle.replace(
          /dependencies\s*{([\s\S]*?)}/,
          (match, contents) => {
            return `dependencies {
    ${contents.trim()}
    classpath "com.instana:android-agent-plugin:$INSTANA_ANDROID_PLUGIN_VERSION"
}`;
          }
        );
      }

      config.modResults.contents = buildGradle;
    }

    return config;
  });
};

// Modify android/app/build.gradle
const withInstanaAppGradle = (config) => {
  return withAppBuildGradle(config, (config) => {
    if (config.modResults.language === 'groovy') {
      let appGradle = config.modResults.contents;

      // Ensure plugin is applied only once
      if (!appGradle.includes("apply plugin: 'com.instana.android-agent-plugin'")) {
        appGradle = `apply plugin: 'com.instana.android-agent-plugin'\n` + appGradle;
      }

      config.modResults.contents = appGradle;
    }

    return config;
  });
};

// Combine both modifications
const withInstanaPlugin = (config) => {
  config = withInstanaProjectGradle(config);
  config = withInstanaAppGradle(config);
  return config;
};

module.exports = createRunOncePlugin(withInstanaPlugin, PLUGIN_NAME, '1.0.0');

Dans votre app.json ou app.config.js, enregistrez le plug-in en ajoutant la configuration suivante :

module.exports = {
  expo: {
    name: 'my-app',
    slug: 'my-app',
    plugins: ['./app.plugin.js'],
  },
};

À l'heure actuelle, Instana ne prend pas en native_dio_adapter charge Flutter. Sur Android, le native_dio_adapter paquet achemine les requêtes HTTP via Cronet, la bibliothèque réseau native d' Google. Cette approche contourne à la fois Dart HttpClient (que l'agent Flutter Instana surveille via HttpOverrides) et les classes réseau standard d'Android, telles que HttpURLConnection et OkHttpClient (que l'agent natif Android surveille via l'instrumentation du bytecode). Comme ces couches sont ignorées, l'agent Android d' Instana ne peut actuellement pas capturer les requêtes réseau effectuées à l'aide de native_dio_adapter.

Instana tient à jour une liste des clients réseau Android pris en charge qui peuvent être surveillés par Instana. Comme native_dio_adapter ne s'appuie pas sur ces classes prises en charge, vous ne verrez apparaître aucun journal ni aucune trace réseau associés dans votre application Android lorsque vous l'utiliserez. Sur iOS,, il se peut que vous constatiez encore une certaine activité réseau, mais les résultats peuvent être incohérents ou faire l'objet de doublons en raison d'un chevauchement entre les données collectées par les couches native et Dart.

En attendant la mise en place d'une prise en charge native_dio_adapter officielle de [...], la solution de contournement recommandée consiste à recourir à une surveillance manuelle de l' HTTP. Grâce à la surveillance manuelle, vous pouvez enregistrer explicitement les détails des requêtes réseau, tels que la latence, l'état de la réponse et les erreurs, via l'agent Flutter Instana. Pour obtenir des instructions de configuration et des exemples, consultez le manuel « Surveillance de l' HTTP ».