Le Health Monitor (HM) est un agent SDV qui s'exécute sur chaque machine virtuelle (VM) pour suivre l'état des packs de services, déterminer l'état de santé de la VM et générer périodiquement un rapport sur l'état de santé de la VM.
Les offres de services définies par l'OEM doivent écouter les différents signaux de santé signalés par le HM et, en fonction des données, effectuer des actions de récupération. Par exemple, une instance SDV avec des bundles de services en panne peut avoir besoin d'être redémarrée ou mise à jour.
Vous pouvez configurer l'agent HM pour qu'il effectue le suivi des éléments suivants :
- État d'activité des entités effectuant des tâches périodiques, en surveillant les pulsations d'activité. Cette surveillance peut être configurée pour les instances de bundle de services et les agents OEM personnalisés.
- État de récupération des instances de lot de services. Dans SDV 2.0, vous pouvez configurer des ensembles de services pour qu'ils redémarrent automatiquement en cas de plantage. Le HM fournit des signaux pour surveiller ce processus de récupération.
- QoS pour les communications
- État actif des agents personnalisés SDV et OEM
Pour référence, le catalogue VSIDL complet, y compris les définitions proto, est disponible sur //system/software_defined_vehicle/health_monitor/catalog/health_monitor.vsidl.
Terminologie
Ces termes sont utilisés sur cette page.
Utiliser le sous-système HM
Pour utiliser les fonctionnalités HM, une implémentation OEM doit :
- Configurez le système de surveillance de l'état en fournissant des fichiers de configuration, comme indiqué dans Configurer le système HM.
- Utilisez un bundle de services d'écouteur HM défini par l'OEM pour écouter la sortie HM et prendre les mesures appropriées.
- Développez des ensembles de services qui publient activement des signaux, conformément à leur configuration d'état. Cette publication permet au HM d'évaluer son état de santé. Pour en savoir plus, consultez les guides de développement des groupes de services.
Configurer le système HM
Toute configuration liée à la gestion des identités et des accès réside dans l'un de ces types de configuration :
- Configuration de l'état globale par VM
- Configuration de l'état de santé par bundle de services, définissant les paramètres d'état de santé pour toutes les instances du bundle
Configuration de l'état par VM
Lors de l'exécution, l'agent HM attend une configuration d'état à l'échelle de la VM. Il s'agit d'un fichier textproto (avec l'extension .textproto) de type VMHealth défini sur //system/software_defined_vehicle/health_monitor/catalog/health_monitoring_config.proto.
La configuration de l'état de santé de la VM doit se trouver au chemin d'accès spécifié à l'aide de la propriété système au moment du démarrage androidboot.sdv.health_monitor.config_path.
Vous pouvez également configurer cette option de manière dynamique lors de l'exécution en définissant la propriété système persist.sdv.health_monitor.config_path sur un chemin d'accès personnalisé. Le paramètre persist.* est prioritaire sur le paramètre androidboot.*. Vous devez redémarrer l'appareil pour que la nouvelle configuration prenne effet.
La configuration de l'état de santé de la VM vous permet de définir les éléments suivants :
Périodicité du rapport sur l'état de santé des VM via
period_ms. Le choix de cette valeur est un compromis entre la rapidité de signalement des cas de non-respect des règles de santé et les performances du sous-système HM. Nous vous recommandons de définir une valeur de 100 ms.Les agents dont les plantages doivent être surveillés (voir Surveillance des plantages d'agent).
Des exemples de fichiers de configuration sont disponibles dans //system/software_defined_vehicle/health_monitor/src/prod_configs/. Voici un exemple de fichier de configuration :
period_ms: 100
monitored_agent {
agent_name: "sdv_dt_agent"
binder_interface_name: "google.sdv.data_tunnel.IAgentService/default"
}
monitored_agent {
agent_name: "sdv_rpc_agent"
binder_interface_name: "google.sdv.rpc.IRpcAgent/default"
}
Dans cet exemple, les agents SDV DT et RPC sont configurés pour la surveillance des plantages, et le rapport sur l'état de la VM est configuré pour être publié toutes les 100 ms.
Configuration par pack de services
La surveillance de l'état des instances de lot de services est facultative. Pour l'activer, stockez le fichier de configuration de l'état de santé dans l'APEX de votre bundle de services et définissez un chemin d'accès dans le champ health_config_path de sdv_service_bundle_metadata dans sdv_service_bundles_manifest.textproto. Pour en savoir plus sur les fichiers manifestes des offres groupées de services, consultez Métadonnées des offres groupées de services.
Le fichier de configuration de l'état de santé est un fichier textproto du type suivant :
message ServiceBundleHealthConfiguration {
// Required: An empty ServiceBundleHealthConfiguration is equivalent to no
// implicit health monitoring or QoS monitoring configured.
//
// Key should contain the instance name that the `InstanceConfiguration` applies to.
map<string, InstanceConfiguration> instance_config = 1;
}
Pour chaque instance, vous pouvez spécifier à la fois la configuration du signal de vie et la configuration de la qualité de service :
// Service bundle *instance* configuration.
message InstanceConfiguration {
// Optional.
//
// Instance health monitoring configuration. Monitors instance
// general health. Well suited for bundles executing periodic tasks.
optional HealthConfiguration health_config = 1;
// Optional.
//
// Map defining the QoS monitoring profile of the instance.
// The key (string) is the topic name of the specific QoS heartbeat
// publication. Choose a meaningful topic name for
// expressive HM reporting.
//
// Only one publisher should publish on this topic. The HM
// agent ignores all publishers except the first one registered
// by the service bundle instance configured for QoS monitoring.
map<string, QosMonitoringConfiguration> qos_config = 2;
}
Pour en savoir plus sur la configuration par fonctionnalité, consultez Surveillance des pulsations de vie et Surveillance de la qualité de service.
Écouter la sortie HM
Vous pouvez écouter le HM via des rapports périodiques ou une API RPC.
Rapport sur l'état des VM
La surveillance de l'état génère un rapport périodique à haute fréquence sur l'état de santé des VM, qui fournit des informations concises sur l'état de santé des entités surveillées.
La syntaxe de type de VmHealth est définie dans //system/software_defined_vehicle/health_monitor/catalog/health_topic.proto :
message VmHealth {
// Required.
// Describes if all monitored service bundles are healthy and report heartbeats on time.
bool all_monitored_service_bundles_healthy = 1;
// Required.
// Describes if all service bundles which should be running on the VM are alive.
bool all_service_bundles_alive = 2;
// Required.
// Indicates if QoS requirements for all service bundles which should be running
// on the VM are satisfied.
bool qos_violations_detected = 3;
}
Un bundle de services d'écouteur HM défini par l'OEM doit écouter les rapports VMHealth et prendre les mesures appropriées en fonction de l'architecture système complète.
Voici quelques actions possibles :
- Exécutez des routines de diagnostic sur la VM.
- Redémarrez la VM.
- Exécutez une campagne de télémétrie pour déterminer la cause.
- Mettez à jour le système ou arrêtez une mise à jour si le système fonctionne mal.
API RPC HM
Le rapport sur l'état des VM est une publication optimisée pour la fréquence et la vitesse de transmission. Il fournit des informations générales sur l'état du système.
L'API RPC HM permet au récepteur HM d'obtenir des informations détaillées sur la source des cas de non-respect des règles de santé. L'interface est définie dans //system/software_defined_vehicle/health_monitor/catalog/health_monitor_service.proto.
L'interface est reproduite ici pour plus de commodité :
// RPC Interface of the VM Health Monitor Agent for querying details about the current VM
// health.
//
// An OEM-defined service bundle typically monitors the overall health of the SDV instance by listening to
// high-frequency `VMHealth` publication. If violations are detected, this RPC interface can
// be used to retrieve detailed information about the malfunctioning component.
service HealthMonitorService {
// Returns the list of running SDV service bundles that were created or started
// by the orchestrator on this VM.
rpc ListAllServiceBundles(ListAllServiceBundlesRequest) returns (ListAllServiceBundlesResponse) {}
// Returns the list of crashed SDV service bundles.
rpc ListCrashingServiceBundles(ListCrashingServiceBundlesRequest)
returns (ListCrashingServiceBundlesResponse) {}
// Returns the list of recovering SDV service bundles.
rpc ListRecoveringServiceBundles(ListRecoveringServiceBundlesRequest)
returns (ListRecoveringServiceBundlesResponse) {}
// Returns the list of monitored SDV service bundles, which registered for reporting
// aliveness heartbeats but failed to report heartbeats on time.
rpc ListUnhealthyMonitoredServiceBundles(ListUnhealthyMonitoredServiceBundlesRequest)
returns (ListUnhealthyMonitoredServiceBundlesResponse) {}
// Returns a list of QoS monitoring violations detected.
// Provides a snapshot of the current system state.
rpc ListQosViolations(ListQosViolationsRequest)
returns (ListQosViolationsResponse) {}
}
Description détaillée des fonctionnalités
Cette section décrit plus en détail différents aspects de la gestion des identités.
Surveillance des pulsations de vie
Lorsque la surveillance de l'activité est configurée pour une instance de bundle de services, le HM s'attend à ce que l'instance publie des pulsations périodiques pour prouver que la logique métier fonctionne correctement. Cette surveillance est particulièrement adaptée aux instances de bundle de services qui effectuent des tâches périodiques. De plus, les bundles utilisant des runtimes asynchrones peuvent utiliser la surveillance de l'activité pour prouver que le pool de threads n'est pas épuisé.
Figure 1. Flux de surveillance de l'état de l'instance HM.
Configuration
Pour activer les signaux de vie sur une instance de bundle de services, ajoutez une instance de HealthConfiguration au champ health_config dans la configuration du bundle.
Une configuration de signal de vie définit un ensemble prédéterminé de paramètres qui établissent les critères d'évaluation du signal de vie périodique d'un service. Si les caractéristiques du signal de présence du service s'écartent de ces paramètres, le signal de présence est classé comme retardé et le bundle de services correspondant comme non opérationnel, ce qui peut indiquer un état opérationnel non optimal.
Un bundle de services est considéré comme opérationnel lorsqu'il envoie des signaux de présence à temps, conformément à sa configuration d'état. En cas de plantage ou de charge système élevée, il est possible qu'un signal de présence soit manquant ou retardé, ce qui peut entraîner le marquage du bundle de services comme non opérationnel. Dans ce cas, une infraction s'affiche dans le rapport VmHealth.
Les développeurs de groupes de services doivent définir la configuration de l'état d'un groupe de services dans les métadonnées APEX correspondantes. La configuration de l'état définit les critères suivants :
Délai initial maximal autorisé entre le démarrage du service et la première détection du signal de présence.
Période pendant laquelle le bundle de services SDV exécute la logique métier, qui correspond à la périodicité de publication d'un signal de présence de service.
Nombre de périodes manquées avant que le HM considère que le bundle de services n'est pas opérationnel.
Le temps d'exécution correspond au temps dont un bundle de services SDV a besoin pour exécuter sa logique métier avant de pouvoir publier un signal de présence de service.
Le bundle de services génère un cas de non-respect de l'état de santé si le signal de présence du service est retardé. Il existe deux cas en fonction de l'heure de l'observation de l'état de santé :
Cas 1 : Le signal de présence initial n'a pas été reçu. Si le délai initial autorisé est dépassé entre le début du bundle de services et le moment de l'observation, le bundle de services est considéré comme non opérationnel.
Cas de figure 2 : Des pulsations ont déjà été reçues. Si un seuil s'est écoulé entre le dernier signal de présence et l'heure d'observation, le bundle de services est considéré comme non opérationnel. Ce seuil est calculé en additionnant la période de référence (multipliée par le nombre de périodes) et la durée de la tâche.
Le format de configuration de l'état est défini dans //system/software_defined_vehicle/health_monitor/catalog/health_config.proto :
package com.android.sdv.health;
// Service Bundle's configuration for health monitoring.
message HealthConfiguration {
// Required.
// Initial delay in milliseconds is the time between the service starts and its first heartbeat.
optional uint64 initial_delay_ms = 2;
// Required.
// Period of reporting a heartbeat in milliseconds which corresponds to the periodicity of
// executing a business logic by the SDV service. This value should be larger than 0.
optional uint64 period_ms = 3;
// Required.
// The number of periods missing a heartbeat before the Health Monitor should consider the
// service as unhealthy. This value should be larger than 0.
optional uint64 num_periods = 4;
// Required.
// Duration of the business logic the SDV service bundle executes in milliseconds.
optional uint64 task_duration_ms = 5;
}
Considérations sur le temps d'exécution
Cette section fournit des conseils pour publier des pulsations de vie et s'inscrire correctement à la surveillance.
Publier des pulsations de vie
Une instance de bundle de services génère un message service heartbeat qui inclut un code temporel. Générez régulièrement le message, généralement juste après l'exécution de la logique métier principale. Le signal de présence du service indique que le bundle de services est actif.
L'objet d'instance de bundle à surveiller doit créer un éditeur de type ServiceHeartbeat, disponible dans la bibliothèque libhealth_api :
message ServiceHeartbeat {
// Required.
// The timestamp.
.google.protobuf.Timestamp timestamp = 1;
}
Choisissez le thème de la publication de manière arbitraire. L'agent HM utilise la découverte par type de message pour détecter la publication.
Lorsque vous configurez la surveillance de l'activité via la configuration de l'état liée au fichier manifeste du bundle de services correspondant, l'agent HM s'attend à ce que les battements de cœur soient publiés dès que l'instance a terminé sa routine on_start. Nous vous recommandons de limiter la durée de on_start pour éviter de bloquer le démarrage du système. Publiez donc les signaux de présence dans une tâche asynchrone démarrée dans on_start.
Les développeurs de bundles peuvent personnaliser le moment où le premier signal de présence est attendu à l'aide de l'entrée de configuration initial_delay_ms.
L'instance du bundle doit continuer à publier des signaux de présence jusqu'à ce qu'elle soit arrêtée. Une instance est considérée comme arrêtée lorsque sa routine on_stop est terminée.
Cas d'utilisation spécial : s'inscrire explicitement à la surveillance de la fréquence cardiaque
Le comportement décrit dans Surveillance des battements de cœur de l'état actif, où les battements de cœur sont attendus entre on_start et on_stop, est appelé surveillance implicite de l'état actif. Il s'agit de la méthode recommandée pour utiliser la fonctionnalité : elle simplifie la logique métier du bundle et garantit qu'il est toujours surveillé.
Toutefois, dans certains cas d'utilisation, la période de surveillance par défaut peut être une restriction :
- Une instance de bundle de services contient une logique métier périodique dans un intervalle de temps non lié aux événements
startetstop. La surveillance de l'état actif peut n'être nécessaire que pendant cette période personnalisée. - La HM suit précisément les HBs pendant les périodes de suspension et de reprise. Par conséquent, le bundle peut continuer à être surveillé après
on_stop. - Il est possible que les agents OEM personnalisés ne soient pas implémentés en tant que bundles de services. Par conséquent, ils ne peuvent pas bénéficier de la surveillance d'activité implicite. Toutefois, ils peuvent toujours nécessiter une surveillance de l'état.
Dans ce cas, le HM vous permet de contourner l'enregistrement implicite pour la surveillance de l'état actif en faveur de l'enregistrement explicite. Pour utiliser l'enregistrement explicite, une instance de bundle doit désactiver l'enregistrement implicite en n'incluant pas d'entrée de type HealthConfiguration pour l'instance spécifique dans le fichier manifeste du bundle. Ensuite, lors de l'exécution, l'instance de bundle doit utiliser l'API RPC définie dans //system/software_defined_vehicle/health_monitor/catalog/health_monitor_registration_service.proto pour s'enregistrer et se désenregistrer manuellement de la surveillance. Les pulsations publiées sont attendues dès que l'appel RPC d'enregistrement réussit.
Pour obtenir un exemple d'implémentation, consultez //system/software_defined_vehicle/samples/health/stable/health_monitored_service_bundle/.
Surveillance de la qualité de service
La qualité de service (QoS) est une mesure de la communication. Le HM vérifie si le message envoyé met trop de temps à transiter ou, dans le cas d'une communication périodique, si les messages ne sont pas reçus à la fréquence choisie.
SDV propose plusieurs variantes de communication Pub/Sub et RPC. Le dénominateur commun est que tous les schémas de communication contiennent au moins un écouteur. Pour que le HM surveille la communication, cette instance de bundle de service d'écoute doit publier des pulsations QoS spéciales chaque fois qu'elle reçoit un message intéressant.
Configuration
Pour activer la surveillance de la qualité de service d'une communication, commencez par identifier l'écouteur de communication qui publiera le signal de qualité de service. Ensuite, pour l'instance de bundle de services identifiée, ajoutez un ou plusieurs mappages de sujets à QosMonitoringConfiguration dans le champ qos_config. Pour en savoir plus, consultez Configuration des bundles par service.
topic est une chaîne qui définit le sujet de publication où le HM attend des HB QoS au moment de l'exécution. Une instance de bundle d'écoute peut participer à plusieurs communications et signaler des HB de qualité de service sur plusieurs sujets.
Les thèmes doivent être descriptifs, car ils sont renvoyés au bundle de services d'écouteur HM si des violations de la qualité de service sont détectées au moment de l'exécution.
Le type QosMonitoringConfiguration est défini dans //system/software_defined_vehicle/health_monitor/catalog/health_config.proto :
message QosMonitoringConfiguration {
// Optional - If absent, heartbeat frequency monitoring is disabled for this SB.
//
// The maximum allowable interval between consecutive heartbeats (in milliseconds).
// A QoS frequency violation is triggered if the time elapsed between
// two heartbeats exceeds this threshold.
optional uint64 qos_period_threshold_ms = 1;
// Optional - If absent, heartbeat latency monitoring is disabled for this SB.
//
// The maximum allowable interval between data publication and data processing timestamps (in milliseconds).
// A QoS latency violation is triggered if the time elapsed between
// data publication and data processing timestamps exceeds this threshold.
optional uint64 qos_latency_threshold_ms = 2;
}
Pour les cas d'utilisation par défaut, appliquez les deux types de surveillance de la qualité de service. Une valeur qos_latency_threshold_ms de 30 est raisonnable pour la communication Pub/Sub dans la VM sous des charges système normales.
Considérations sur le temps d'exécution
Comme pour la surveillance des battements de cœur de l'état de vie, le bundle d'écoute de la communication est censé publier un type de battement de cœur. Dans ce cas, un HB QoS doit être publié chaque fois que des messages intéressants sont reçus, et non à la fin de l'exécution de la logique métier.
Un QoS HB est de type QosHeartbeat, défini dans //system/software_defined_vehicle/health_monitor/catalog/qos_heartbeat.proto :
message QosHeartbeat {
option (.sdv.vsidl.v1.publication) = {
message_count: 2
model: SINGLE_PUB
};
// Required.
// Current timestamp at heartbeat transmission. The heartbeat should be sent
// immediately after the listener receives the related QoS-monitored message.
.google.protobuf.Timestamp timestamp = 1;
// Required.
// Timestamp corresponding to the creation time of the underlying data. This
// implies that, in addition to the data of interest, the monitored message includes
// a data creation timestamp field. The listener is responsible for routing this
// timestamp to the QosHeartbeat upon receiving a QoS-monitored message.
.google.protobuf.Timestamp data_timestamp = 2;
}
Le moment où la publication QoS HB est enregistrée et désenregistrée est essentiel pour une surveillance précise. Le HM attend des HB de QoS entre ces deux événements. Le bundle d'écoute des messages doit enregistrer la publication QoS HB lorsque la communication surveillée est enregistrée auprès de la pile de communication SDV. Pour ce faire, le HM peut utiliser l'API Availability. Pour en savoir plus, consultez Déterminer la disponibilité des services.
Surveillance de la récupération des packs de services
La récupération des instances de bundle de services est configurée dans les fichiers de configuration de l'agent d'orchestration. Pour en savoir plus sur ce sujet, consultez Packs de services. Le sous-système HM observe passivement le processus de récupération. Lorsqu'un échec de récupération d'une instance de bundle est détecté, une infraction est ajoutée au rapport VMHealth. Contrairement au reste des fonctionnalités de surveillance de HM, la surveillance de la récupération est obligatoire et non configurable.
Les plantages des instances de bundle de services qui ne sont pas configurées pour la récupération génèrent un non-respect de l'état de santé lors de leur premier plantage.
La récupération des instances de bundle de services est conçue pour s'intégrer à la surveillance de l'état de fonctionnement par signaux de présence. Le système HM est plus tolérant lorsqu'il évalue les battements de cœur lorsqu'il détecte que le bundle est en cours de récupération. En pratique, cette tolérance signifie que les bundles de services n'ont pas besoin d'effectuer d'étapes supplémentaires de désenregistrement ou d'enregistrement de la surveillance en cas de plantage.
Surveillance des plantages d'agent
Le HM détecte les plantages potentiels des agents SDV à l'aide du mécanisme de binder linkToDeath.
Vous pouvez configurer la surveillance des plantages dans la configuration de l'état de la VM (voir Configuration par instance SDV (VM)), en particulier le champ répété monitored_agent. Ce champ doit contenir des entrées de type BinderServiceAgent :
message BinderServiceAgent {
// agent_names must be unique across configuration
// used for HM internal agent identification, and naming entries in HM dumpsys report
string agent_name = 1;
// Binder interface name/identifier, e.g: "google.sdv.data_tunnel.IAgentService/default"
// HM Agent should have appropriate permissions to find the binder interface
// see also `sdv_crash_monitored_service` selinux attribute
string binder_interface_name = 2;
}
Les agents personnalisés peuvent également être surveillés si l'agent expose une interface de liaison. Pour surveiller un agent personnalisé, accordez les autorisations HM SELinux pour écouter l'interface Binder appropriée.
La propriété système ro.boot.sdv.health_monitor.agent_startup_timeout_sec peut remplacer la durée pendant laquelle le HM attend que les agents enregistrent leurs interfaces de binder une fois le HM démarré. Sauf si les agents personnalisés l'exigent, la valeur par défaut de trois secondes est appropriée.
Guides du développeur pour les packs de services
Cette section fournit des guides détaillés sur l'utilisation des fonctionnalités HM à partir de forfaits de services, contrairement au traitement théorique des sections précédentes. L'échantillon de référence à jour sur lequel ces guides sont basés est l'échantillon qos_monitoring. Suivez l'exemple de //system/software_defined_vehicle/samples/health/stable/qos_monitoring/README pour une expérience pratique.
Ajouter la surveillance des pulsations de vie à un bundle de services
Cette méthode est la plus directe pour activer la surveillance de l'état d'un bundle de services :
Définissez une instance de
ServiceBundleHealthConfigurationpour les instances de bundle dans un fichier nomméhealth_configuration.textproto:# health_bundle_configuration.textproto instance_config { key: "instance1" value: { health_config { initial_delay_ms: 1000 period_ms: 500 num_periods: 2 task_duration_ms: 200 } # qos_config entries irrelevant for this dev guide qos_config { ... } } }Ajoutez le fichier de configuration au bundle de service APEX. Dans un
Android.bp:apex { name: "com.android.sdv.sample.oem.health.qos_monitoring", // ... prebuilts: [ // ... "com.android.sdv.sample.oem.health.qos_monitoring.health_config", ], } prebuilt_etc { name: "com.android.sdv.sample.oem.health.qos_monitoring.health_config", src: "health_configuration.textproto", filename: "health.textproto", // ... // Reduce prebuilt visibility to avoid adding it in another APEX. visibility: ["//system/software_defined_vehicle/samples/health/qos_monitoring/apex"], }Stockez la configuration de l'état dans l'APEX et définissez
health_config_pathdans le fichier manifeste :# sdv_service_bundles_manifest.textproto sdv_service_bundle_metadata { ... health_config_path: "etc/config/health_configuration.textproto" }Dans la définition VSIDL, assurez-vous que le bundle publie
com.android.sdv.health.ServiceHeartbeat:sdv_service_bundle { name: "SampleBundle" publisher { message: "com.android.sdv.health.ServiceHeartbeat" topic: "arbitrary-topic" capacity: 2 } }Ajoutez des autorisations SDV au bundle pour qu'il soit autorisé à publier des HBs :
publisher { type: "com.android.sdv.health.ServiceHeartbeat" }Publiez régulièrement des pulsations de service dans le code, en commençant par
on_start:// ... fn on_start(&mut self) { // ... runtime.spawn(business_logic(self.context)) } async fn business_logic(context: ContextRef) -> SdvResult<()>{ // register HB publication let mw_comms = SdvComms { context }; let aliveness_hb_pub = create_publisher::<PublisherDescriptor<ServiceHeartbeat>>( &mw_comms, PublisherDescriptors::<ServiceHeartbeat>::ARBITRARY_TOPIC, ) .await?; loop{ // do business logic // ... // publish hb aliveness_hb_pub.publish(&ServiceHeartbeat { timestamp: MessageField(Some(Box::new(now.into()))), ..Default::default() })?; } }
Cas d'utilisation spécial : enregistrement explicite
Pour les cas d'utilisation plus spécifiques, où le bundle a besoin d'une surveillance HB pour les cycles de vie personnalisés (par exemple, une surveillance qui commence plus tôt ou se termine plus tard que l'état STARTED standard), vous pouvez utiliser la méthode d'enregistrement explicite :
Dans la définition VSIDL, ajoutez un client
com.android.sdv.health.HealthMonitorRegistrationService:sdv_service_bundle { # ... client { service: "com.android.sdv.health.HealthMonitorRegistrationService" channel: "com-android-sdv-health-health-monitor-registration-service" } }Ajoutez l'autorisation SDV pour utiliser le RPC d'enregistrement HB d'activité :
# ... client { service: "com.android.sdv.health.HealthMonitorRegistrationService" channel: "com-android-sdv-health-health-monitor-registration-service" }Enregistrez-vous auprès du HM via RPC, par exemple dans
on_startounew:let rpc_client = Self::new_client(comms).await?; let _ = rpc_client .RegisterConfiguration(&RegisterConfigurationRequest { config: Some(HealthConfiguration{ initial_delay_ms: 100, period_ms: 200, num_periods: 3, task_duration_ms: 40, special_fields: protobuf::SpecialFields::default(), }).into(), ..Default::default() }) .await .unwrap();Publiez les HBs.
Désinscrivez-vous de la surveillance lorsque vous n'en avez plus besoin :
let _ = rpc_client .UnregisterConfiguration(&UnregisterConfigurationRequest { ..Default::default() }) .await .unwrap();
Ajouter la surveillance de la qualité de service à la communication
Vérifiez que l'instance du bundle de services est abonnée à un sujet nommé
fog-light-statusdans le catalogue VSIDL :subscriber { message: "QosMonitoredFogLightStatus" topic: "left-fog-light-status" }Le format du message est le suivant :
package com.android.sdv.sample.oem.health.qos_monitoring; import "google/protobuf/timestamp.proto"; message QosMonitoredFogLightStatus { // arbitrary fields related to business logic int32 status = 1; // In SDV1.0, a qos monitored message should include a timestamp field .google.protobuf.Timestamp timestamp = 2; }Définissez une instance de
ServiceBundleHealthConfigurationpour les instances de bundle dans un fichierhealth_configuration.textprotoqui inclut la surveillance de la qualité de service :# health_bundle_configuration.textproto instance_config { key: "instance1" value: { # aliveness HB monitoring config irrelevant for this dev guide health_config { ... } qos_config { key: "qos-hb-right-fog-light-status" value { qos_period_threshold_ms: 100 qos_latency_threshold_ms: 50 } } } }Le sujet choisi dans le champ
keymontre que les HB de QoS seront publiés sur ce sujet, ce qui permet de surveiller un sujet appeléfog-light-status.Ajoutez le fichier de configuration au bundle de service APEX. Dans un
Android.bp:apex { name: "com.android.sdv.sample.oem.health.qos_monitoring", // ... prebuilts: [ // ... "com.android.sdv.sample.oem.health.qos_monitoring.health_config", ], } prebuilt_etc { name: "com.android.sdv.sample.oem.health.qos_monitoring.health_config", src: "health_configuration.textproto", filename: "health.textproto", // ... // Reduce prebuilt visibility to avoid adding it in another APEX. visibility: ["//system/software_defined_vehicle/samples/health/qos_monitoring/apex"], }Stockez la configuration de l'état dans l'APEX et définissez
health_config_pathdans le fichier manifeste :# sdv_service_bundles_manifest.textproto sdv_service_bundle_metadata { ... health_config_path: "etc/config/health_configuration.textproto" }Dans votre définition VSIDL, assurez-vous que le bundle est un éditeur de
com.android.sdv.health.QosHeartbeat:sdv_service_bundle { name: "SampleBundle" publisher { message: "com.android.sdv.health.QosHeartbeat" topic: "qos-hb-right-fog-light-status" capacity: 2 } }Ajoutez des autorisations SDV au bundle afin qu'il soit autorisé à publier des HB de qualité de service :
publisher { message: "com.android.sdv.health.QosHeartbeat" topic: "qos-hb-right-fog-light-status" }N'enregistrez la publication QoS HB que lorsque la communication surveillée est enregistrée. Utilisez l'API Availability depuis
libsdv_mw_clientlib:// Wait for monitored communication to be available let comms = SdvComms{context}; let registration_stream = create_registration_event_stream( &comms, SubscriberDescriptors::<QosMonitoredFogLightStatus>::LEFT_FOG_LIGHT_STATUS, ).await?; let mut registration_stream = Box::pin(registration_stream.filter(|e|e==Availability::Available)); registration_stream.next().await; // only when available, create QoS HB publication: let qos_hb_pub = create_publisher( &comms, PublisherDescriptors::<QosHeartbeat>::QOS_HB_LEFT_FOG_LIGHT_STATUS, ).await?; // ...Publier des battements de cœur QoS chaque fois qu'un message est reçu :
// ... use tap::Pipe; fn flatten_mw<T: Send>( s: impl Stream<Item = SdvResult<Vec<T>>> + Send + Unpin, ) -> impl Stream<Item = SdvResult<T>> + Send + Unpin { s.flat_map(|v| match v { Ok(v) => v.into_iter().map(Ok).pipe(stream::iter).left_stream(), Err(err) => Err(err).pipe(future::ready).pipe(stream::once).right_stream(), }) } { // ... let data_stream = create_observer( &comms, SubscriberDescriptors::<QosMonitoredFogLightStatus>::LEFT_FOG_LIGHT_STATUS, SubscribeOptions::default() ) .pipe(flatten_mw) .await?; while let Some(data) = data_stream.next().await { // publish QoS HB. Note how data.timestamp is used to populate the field qos_hb_pub.publish( &QosHeartbeat { timestamp: SystemTime::now(), data_timestamp: data.timestamp, ..Default::default() } ) // use data // ... } }Pour arrêter la surveillance de la qualité de service, supprimez l'objet d'éditeur :
// ... drop(qos_hb_pub);
Déboguer la surveillance de l'état
Pour le débogage et la présentation générale du système, utilisez l'outil dumpsys pour surveiller l'état de la VM :
adb shell dumpsys com.google.sdv.ISdvAgent/hm
Le rapport détaille la configuration des rapports sur l'état de santé des VM, la configuration des bundles et l'état de surveillance. Voici un exemple de ce type de rapport :
AGENT NAME: SDV Agent dump - Health Monitor
AGENT FQIN: instance1:com.android.sdv.health.HealthMonitorServiceBundle/instance1
AGENT STATE: Started
----------------
----------------
INTERNAL STATE REPORTERS:
*NAME: VM health report period:
*REPORT:
100----------------
*NAME: Recovery monitor manager
*REPORT:
HEARTBEAT MONITORING:
NO ACTIVE MONITORS
QOS MONITORING:
NO ACTIVE MONITORS
RECOVERY MONITORING:
a. Agent monitoring:
MONITOR 0:
ID: Agent: sdv_vsidl_provider_agent
linked_binder: com.google.sdv.ISdvAgent/vsidl_provider
alive: true
MONITOR 1:
ID: Agent: sdv_someip_broker
linked_binder: com.google.sdv.ISdvAgent/someip_broker
alive: false
b. SB monitoring:
MONITOR 0:
ID: FQIN: instance1:com.android.sdv.test.orchestrator.OrchSampleInitialPowerState/sample-initial-power-state
Recovery State: Normal
Lifecycle State: Started
Health Status: Healthy
MONITOR 1:
ID: FQIN: instance1:com.android.sdv.sample.apex.provider.Provider/sample-provider-v1
Recovery State: Normal
Lifecycle State: Started
Health Status: Healthy
MONITOR 2:
ID: FQIN: instance1:com.sdv.google.display_safety.HarSdvVehicleDataPublisher/instance-1
Recovery State: Normal
Lifecycle State: Started
Health Status: Healthy
----------------
*NAME: Health monitor
*REPORT:
CURR TIMESTAMP(ns): 1775543863756836167
INTERNAL STATE:
background_thread running: true
should_run: true
----------------