El Monitor de estado (HM) es un agente de SDV que se ejecuta en cada máquina virtual (VM) para hacer un seguimiento del estado de los paquetes de servicios, determinar el estado de la VM y generar periódicamente un informe de estado de la VM.
Los paquetes de servicios definidos por el OEM deben detectar los diversos indicadores de estado que informa el HM y, según los datos, realizar acciones de recuperación. Por ejemplo, es posible que se deba reiniciar o actualizar una instancia de SDV con paquetes de servicios que fallan.
Puedes configurar el agente de HM para hacer un seguimiento de lo siguiente:
- Estado de actividad de las entidades que realizan tareas periódicas, a través de la supervisión de las señales de monitoreo de funcionamiento. Esta supervisión se puede configurar para las instancias de paquetes de servicios y los agentes OEM personalizados.
- Es el estado de recuperación de las instancias del paquete de servicios. En SDV 2.0, puedes configurar paquetes de servicios para que se reinicien automáticamente cuando se bloqueen. El HM proporciona indicadores para supervisar este proceso de recuperación.
- QoS de comunicación
- Disponibilidad de los agentes personalizados del OEM y del SDV
Como referencia, el catálogo completo de VSIDL, incluidas las definiciones de .proto, está disponible en //system/software_defined_vehicle/health_monitor/catalog/health_monitor.vsidl.
Terminología
Estos términos se usan en esta página.
Trabaja con el subsistema HM
Para usar las funciones de HM, la implementación del OEM debe hacer lo siguiente:
- Para configurar el sistema de supervisión del estado, proporciona archivos de configuración como se detalla en Configura el sistema de HM.
- Usa un paquete de servicios de HM Listener definido por el OEM para escuchar la salida de HM y tomar las medidas adecuadas.
- Desarrolla paquetes de servicios que publiquen activamente indicadores, según su configuración de estado. Esta publicación permite que el HM evalúe su estado de salud. Para obtener más información, consulta las guías para desarrolladores de paquetes de servicios.
Configura el sistema de HM
Cualquier configuración relacionada con HM reside en uno de estos tipos de configuración:
- Es una configuración de estado global por VM.
- Es una configuración de estado del paquete por servicio que define los parámetros de estado para todas las instancias del paquete.
Configuración de estado por VM
En el tiempo de ejecución, el agente de HM espera una configuración de estado para toda la VM: se trata de un archivo textproto (con una extensión .textproto) de tipo VMHealth definido en //system/software_defined_vehicle/health_monitor/catalog/health_monitoring_config.proto.
La configuración de VM Health debe ubicarse en la ruta de acceso especificada con la propiedad del sistema androidboot.sdv.health_monitor.config_path del tiempo de arranque.
Como alternativa, puedes configurar esto de forma dinámica en el tiempo de ejecución estableciendo la propiedad del sistema persist.sdv.health_monitor.config_path en una ruta de acceso personalizada. El parámetro de configuración persist.* tiene prioridad sobre el parámetro de configuración androidboot.*. Deberás reiniciar el dispositivo para que se aplique la configuración nueva.
La configuración del estado de la VM te permite establecer lo siguiente:
Es la periodicidad del informe de estado de la VM a través de
period_ms. Establecerlo implica una compensación entre una señalización más rápida de que se detectaron incumplimientos de estado y el rendimiento del subsistema de HM. Recomendamos un valor de 100 ms.Qué agentes se deben supervisar en caso de fallas (consulta Supervisión de fallas del agente)
En //system/software_defined_vehicle/health_monitor/src/prod_configs/, se encuentran ejemplos de archivos de configuración. A continuación, se muestra un ejemplo de un archivo de configuración:
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"
}
En este ejemplo, los agentes de SDV DT y RPC están configurados para la supervisión de fallas, y el informe de estado de la VM está configurado para publicarse cada 100 ms.
Configuración por paquete de servicio
La supervisión del estado de las instancias de paquetes de servicios es opcional. Para habilitar la función, almacena el archivo de configuración de estado en el APEX de tu paquete de servicio y define una ruta de acceso a él en el campo health_config_path de sdv_service_bundle_metadata en sdv_service_bundles_manifest.textproto. Para obtener más información sobre los manifiestos de paquetes de servicios, consulta Metadatos de paquetes de servicios.
El archivo de configuración de estado es un archivo textproto del siguiente tipo:
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;
}
Para cada instancia, puedes especificar la configuración de latidos de actividad y la configuración de QoS:
// 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;
}
Para obtener más información sobre la configuración por función, consulta Supervisión de latidos de actividad y Supervisión de QoS.
Cómo escuchar el resultado de HM
Puedes escuchar el HM a través de informes periódicos o una API de RPC.
Informe de estado de la VM
El monitoreo del estado genera un informe periódico de alta frecuencia sobre el estado de la VM, que proporciona información concisa sobre el estado de las entidades supervisadas.
La sintaxis del tipo de VmHealth se define en //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 paquete de servicios de escucha de HM definido por el OEM debe escuchar los informes de VMHealth y tomar las medidas adecuadas según la arquitectura completa del sistema.
Entre las acciones posibles, se incluyen las siguientes:
- Ejecuta rutinas de diagnóstico en la VM.
- Reinicia la VM.
- Ejecuta una campaña de telemetría para determinar la causa.
- Actualizar el sistema o detener una actualización si el sistema no funciona correctamente
API de RPC de HM
El informe de estado de la VM es una publicación optimizada para la frecuencia y la velocidad de transmisión, que proporciona información general sobre el estado del sistema.
La API de RPC de HM permite que el objeto de escucha de HM obtenga información detallada sobre la fuente de los incumplimientos de salud. La interfaz se define en //system/software_defined_vehicle/health_monitor/catalog/health_monitor_service.proto.
La interfaz se reproduce aquí para mayor comodidad:
// 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) {}
}
Descripción detallada de las funciones
En esta sección, se describen varios aspectos del HM con más detalle.
Supervisión de latidos de actividad
Cuando se configura la supervisión de actividad para una instancia de paquete de servicios, el HM espera que la instancia publique latidos periódicos para demostrar que la lógica de negocios funciona correctamente. Esta supervisión es más adecuada para las instancias de paquetes de servicios que realizan tareas periódicas. Además, los paquetes que usan tiempos de ejecución asíncronos pueden usar la supervisión de actividad para demostrar que el conjunto de subprocesos no está agotado.
Figura 1: Es el flujo de supervisión de la actividad de HM.
Configuración
Para habilitar el HB de actividad en una instancia de paquete de servicio, agrega una instancia de HealthConfiguration al campo health_config en la configuración del paquete.
Una configuración de latido de actividad define un conjunto predeterminado de parámetros que establecen los criterios para evaluar la señal de latido periódica de un servicio. Si las características del latido del servicio se desvían de estos parámetros, el latido se clasifica como retrasado y el paquete de servicios correspondiente como en mal estado, lo que podría indicar un estado operativo no óptimo.
Se considera que un paquete de servicios está en buen estado cuando informa latidos a tiempo según su configuración de estado. En caso de una falla o una carga alta del sistema, es posible que falte o se retrase un latido, lo que hará que el paquete de servicios se marque como en mal estado. En este caso, aparece un incumplimiento en el informe VmHealth.
Los desarrolladores de paquetes de servicios deben definir la configuración de estado de un paquete de servicios en los metadatos de APEX correspondientes. La configuración de estado define los siguientes criterios:
Es la demora inicial máxima permitida entre el inicio del servicio y la primera detección de latido.
Es el período durante el cual el paquete de servicios de SDV ejecuta la lógica empresarial, lo que corresponde a la periodicidad de publicación de un latido del servicio.
Es la cantidad de períodos que se deben omitir antes de que el HM considere que el paquete de servicios no está en buen estado.
El tiempo de ejecución es el tiempo que necesita un paquete de servicios de SDV para ejecutar su lógica empresarial antes de poder publicar un latido del servicio.
El paquete de servicios genera un incumplimiento de estado si se retrasa el latido del servicio. Existen dos casos según el momento de la observación del estado:
Caso 1: No se recibió el latido inicial. Si transcurrió más del retraso inicial permitido entre el inicio del paquete de servicios y el momento de la observación, se considera que el paquete de servicios no está en buen estado.
Caso 2: Ya se recibieron los latidos. Si transcurrió un umbral entre el último latido y el momento de la observación, se considera que el paquete de servicios no está en buen estado. Este umbral se calcula como la suma del período del informe (multiplicado por la cantidad de períodos) y la duración de la tarea.
El formato de configuración de estado se define en //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;
}
Consideraciones sobre el tiempo de ejecución
En esta sección, se brinda orientación para publicar latidos de actividad y registrarse correctamente para la supervisión.
Publica señales de monitoreo de funcionamiento
Una instancia de paquete de servicio genera un mensaje de latido del servicio que incluye una marca de tiempo. Genera el mensaje de forma rutinaria, por lo general, inmediatamente después de que se ejecuta la lógica empresarial principal. El latido del servicio indica que el paquete de servicio está activo.
El objeto de instancia del paquete que se supervisará debe crear un publicador del tipo ServiceHeartbeat, que está disponible en la biblioteca libhealth_api:
message ServiceHeartbeat {
// Required.
// The timestamp.
.google.protobuf.Timestamp timestamp = 1;
}
Elegir el tema de la publicación de forma arbitraria El agente de HM usa el descubrimiento por tipo de mensaje para detectar la publicación.
Cuando se configura la supervisión de actividad a través de la configuración de estado vinculada en el manifiesto del paquete de servicio correspondiente, el agente de HM espera que se publiquen los HB en cuanto la instancia finalice su rutina de on_start. Recomendamos que on_start sea breve para evitar bloquear el inicio del sistema, por lo que debes publicar latidos en una tarea asíncrona que se inicie en on_start.
Los desarrolladores de paquetes pueden personalizar el momento en que se espera el primer latido con la entrada de configuración initial_delay_ms.
La instancia del paquete debe seguir publicando latidos hasta que se detenga. Una instancia se considera detenida cuando finaliza su rutina on_stop.
Caso de uso especial: Registrarse de forma explícita para la supervisión de latidos
El comportamiento que se describe en Supervisión de latidos de actividad, en el que se esperan latidos entre on_start y on_stop, se denomina supervisión implícita de actividad. Esta es la forma recomendada de usar la función: simplifica la lógica empresarial del paquete y garantiza que siempre se supervise.
Sin embargo, es posible que existan algunos casos de uso en los que el período de supervisión predeterminado sea una restricción:
- Una instancia de paquete de servicios contiene lógica empresarial que es periódica en un intervalo de tiempo no vinculado a los eventos
startystop. Es posible que la supervisión de la actividad solo sea necesaria en este período personalizado. - El HM hace un seguimiento preciso de los HBs durante los períodos de suspensión y reanudación. Por lo tanto, es posible que el paquete quiera seguir supervisándose después de
on_stop. - Es posible que los agentes personalizados del OEM no se implementen como paquetes de servicios. Por lo tanto, no pueden beneficiarse de la supervisión implícita de la actividad. Sin embargo, es posible que aún requieran supervisión de actividad.
En estos casos, el HM te permite omitir el registro implícito para la supervisión de la actividad a favor del registro explícito. Para usar el registro explícito, una instancia de paquete debe inhabilitar el registro implícito. Para ello, no debe incluir una entrada de tipo HealthConfiguration para la instancia en particular en el manifiesto del paquete. Luego, en el tiempo de ejecución, la instancia del paquete debe usar la API de RPC definida en //system/software_defined_vehicle/health_monitor/catalog/health_monitor_registration_service.proto para registrarse y anular el registro de la supervisión de forma manual. Se espera que se publiquen latidos tan pronto como se complete correctamente la llamada a RPC de registro.
Para ver un ejemplo de implementación, consulta //system/software_defined_vehicle/samples/health/stable/health_monitored_service_bundle/.
Supervisión de la QoS
La calidad de servicio (QoS) es una medición de la comunicación. El HM supervisa si el mensaje enviado tarda demasiado en llegar o, en el caso de la comunicación periódica, si los mensajes no se reciben con la frecuencia elegida.
El SDV proporciona varias versiones de comunicación de Pub/Sub y RPC. El denominador común es que todos los esquemas de comunicación contienen al menos un receptor. Para que el HM supervise la comunicación, esta instancia del paquete de servicio de escucha debe publicar latidos especiales de QoS cada vez que reciba un mensaje de interés.
Configuración
Para habilitar la supervisión de la QoS de una comunicación, primero identifica el objeto de escucha de la comunicación que publicará el latido de la QoS. Luego, para la instancia del paquete de servicios identificada, agrega una o más asignaciones de temas a QosMonitoringConfiguration en el campo qos_config. Para obtener más información, consulta Configuración de paquetes por servicio.
El tema es una cadena que define el tema de publicación en el que el HM espera los latidos de QoS en el tiempo de ejecución. Una instancia de paquete de escucha puede participar en varias comunicaciones y puede informar latidos de QoS sobre varios temas.
Los temas deben ser descriptivos, ya que se informan al paquete de servicios del agente de escucha de HM si se detectan incumplimientos de la QoS durante el tiempo de ejecución.
El tipo QosMonitoringConfiguration se define en //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;
}
Para los casos de uso predeterminados, aplica ambos tipos de supervisión de QoS. Un valor de qos_latency_threshold_ms de 30 es razonable para la comunicación de Pub/Sub en la VM con cargas normales del sistema.
Consideraciones sobre el tiempo de ejecución
Al igual que con la supervisión de latidos de actividad, se espera que el paquete de escucha de comunicación publique un tipo de latido. En este caso, se debe publicar un HB de QoS cada vez que se reciban mensajes de interés, en lugar de al final de la ejecución de la lógica empresarial.
Un HB de QoS es de tipo QosHeartbeat, definido en //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;
}
El momento del registro y la anulación del registro de la publicación de HB de QoS es fundamental para una supervisión precisa. El HM espera HB de QoS entre estos dos eventos. El paquete de escucha de mensajes debe registrar la publicación de HB de QoS cuando la comunicación supervisada se registra con la pila de comunicación del SDV. El HM puede usar la API de disponibilidad para hacerlo. Para obtener más información, consulta Cómo determinar la disponibilidad del servicio.
Supervisión de la recuperación del paquete de servicios
La recuperación de instancias de paquetes de servicios se configura como parte de los archivos de configuración del agente de organización. Para obtener un tratamiento completo del tema, consulta Paquetes de servicios. El subsistema HM observa de forma pasiva el proceso de recuperación. Cuando se detecta un error en la recuperación de una instancia de paquete, se agrega un incumplimiento al informe de VMHealth. A diferencia del resto de las capacidades de supervisión de HM, la supervisión de la recuperación es obligatoria y no se puede configurar.
Las fallas de las instancias de paquetes de servicios que no están configuradas para la recuperación generan un incumplimiento de estado en su primera falla.
La recuperación de instancias de paquetes de servicios está diseñada para integrarse con la supervisión de actividad de latidos. El sistema de HM es más indulgente cuando evalúa los latidos del corazón si detecta que el paquete se está recuperando. En la práctica, esta flexibilidad significa que los paquetes de servicios no necesitan realizar ningún paso adicional de registro o anulación del registro de la supervisión si fallan.
Supervisión de fallas del agente
El HM detecta posibles fallas de los agentes de SDV con el mecanismo de linkToDeath de Binder.
Puedes configurar la supervisión de fallas como parte de la configuración de estado de la VM (consulta Configuración por instancia de SDV (VM)), específicamente el campo repetido monitored_agent. Este campo debe contener entradas del tipo 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;
}
También se pueden supervisar los agentes personalizados si exponen una interfaz de vinculador. Para supervisar un agente personalizado, otorga los permisos de SELinux de HM para escuchar la interfaz del binder adecuada.
La propiedad del sistema ro.boot.sdv.health_monitor.agent_startup_timeout_sec puede anular el tiempo que el HM espera a que los agentes registren sus interfaces de Binder una vez que se inicia el HM. A menos que los agentes personalizados lo requieran, el valor predeterminado de tres segundos es adecuado.
Guías para desarrolladores de paquetes de servicios
En esta sección, se proporcionan guías paso a paso para usar las funciones de HM de los paquetes de servicios, a diferencia del tratamiento teórico de las secciones anteriores. La muestra de referencia actualizada en la que se basan estas guías es la muestra qos_monitoring. Sigue el ejemplo de //system/software_defined_vehicle/samples/health/stable/qos_monitoring/README para obtener una experiencia práctica.
Agrega la supervisión de latidos de actividad a un paquete de servicios
Este método es la forma más directa de habilitar la supervisión del estado de un paquete de servicios:
Define una instancia de
ServiceBundleHealthConfigurationpara las instancias del paquete en un archivo llamadohealth_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 { ... } } }Agrega el archivo de configuración al APEX del paquete de servicio. En 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"], }Almacena la configuración de estado en el APEX y establece
health_config_pathen el manifiesto:# sdv_service_bundles_manifest.textproto sdv_service_bundle_metadata { ... health_config_path: "etc/config/health_configuration.textproto" }En la definición de VSIDL, asegúrate de que el paquete publique
com.android.sdv.health.ServiceHeartbeat:sdv_service_bundle { name: "SampleBundle" publisher { message: "com.android.sdv.health.ServiceHeartbeat" topic: "arbitrary-topic" capacity: 2 } }Agrega permisos de SDV al paquete para que este esté autorizado a publicar HB:
publisher { type: "com.android.sdv.health.ServiceHeartbeat" }Publica latidos del servicio periódicamente en el código, a partir de
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() })?; } }
Caso de uso especial: Registro explícito
Para casos de uso más especiales, en los que el paquete necesita supervisión de HB para ciclos de vida personalizados (por ejemplo, supervisión que comienza antes o termina después del estado STARTED estándar), puedes usar el método de registro explícito:
En la definición de VSIDL, agrega un cliente
com.android.sdv.health.HealthMonitorRegistrationService:sdv_service_bundle { # ... client { service: "com.android.sdv.health.HealthMonitorRegistrationService" channel: "com-android-sdv-health-health-monitor-registration-service" } }Agrega permiso de SDV para usar el RPC de registro de HB de actividad:
# ... client { service: "com.android.sdv.health.HealthMonitorRegistrationService" channel: "com-android-sdv-health-health-monitor-registration-service" }Regístrate en el HM a través de RPC, por ejemplo, en
on_startonew: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();Publicar HBs
Cancela el registro del monitoreo cuando ya no sea necesario:
let _ = rpc_client .UnregisterConfiguration(&UnregisterConfigurationRequest { ..Default::default() }) .await .unwrap();
Agrega supervisión de QoS a la comunicación
Verifica que la instancia del paquete de servicios sea suscriptora de un tema llamado
fog-light-statusen el catálogo de VSIDL:subscriber { message: "QosMonitoredFogLightStatus" topic: "left-fog-light-status" }El formato del mensaje es el siguiente:
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; }Define una instancia de
ServiceBundleHealthConfigurationpara las instancias del paquete en un archivohealth_configuration.textprotoque incluya la supervisión de la QoS:# 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 } } } }El tema elegido en el campo
keyilustra que los latidos del QoS se publicarán en este tema, lo que permitirá supervisar un tema llamadofog-light-status.Agrega el archivo de configuración al APEX del paquete de servicio. En 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"], }Almacena la configuración de estado en el APEX y establece
health_config_pathen el manifiesto:# sdv_service_bundles_manifest.textproto sdv_service_bundle_metadata { ... health_config_path: "etc/config/health_configuration.textproto" }En la definición de VSIDL, asegúrate de que el paquete sea un publicador 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 } }Agrega permisos de SDV al paquete para que este esté autorizado a publicar latidos de QoS:
publisher { message: "com.android.sdv.health.QosHeartbeat" topic: "qos-hb-right-fog-light-status" }Registra la publicación de HB de QoS solo cuando se registre la comunicación supervisada. Usa la API de disponibilidad desde
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?; // ...Publica HBs de QoS cada vez que se recibe un mensaje:
// ... 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 // ... } }Para detener la supervisión de la QoS, descarta el objeto de publicador:
// ... drop(qos_hb_pub);
Depura la supervisión del estado
Para fines de depuración y descripción general del sistema, usa la herramienta dumpsys para supervisar el estado de supervisión del estado de la VM:
adb shell dumpsys com.google.sdv.ISdvAgent/hm
En el informe, se detallan la configuración de informes de estado de la VM, la configuración del paquete y el estado de supervisión. A continuación, se muestra un ejemplo de este tipo de informe:
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
----------------