Мониторинг здоровья

Монитор состояния (Health Monitor, HM) — это агент SDV, который запускается на каждой виртуальной машине (ВМ) для отслеживания состояния пакетов служб, определения состояния ВМ и периодического создания отчета о состоянии ВМ.

Определяемые производителем пакеты услуг должны отслеживать различные сигналы состояния, сообщаемые модулем мониторинга состояния (HM), и на основе этих данных выполнять действия по восстановлению. Например, экземпляр SDV с аварийно завершающимися пакетами услуг может потребовать перезапуска или обновления.

Вы можете настроить агент HM для отслеживания следующих параметров:

  • Мониторинг состояния работоспособности объектов, выполняющих периодические задачи, осуществляется путем отслеживания сигналов подтверждения работоспособности. Этот мониторинг может быть настроен как для экземпляров пакетов услуг, так и для пользовательских OEM-агентов.
    • Состояние восстановления экземпляров пакетов служб. В SDV 2.0 можно настроить автоматический перезапуск пакетов служб при сбоях. HM предоставляет сигналы для мониторинга этого процесса восстановления.
    • Качество связи
  • Активность агентов по обслуживанию клиентов SDV и OEM

Для справки, полный каталог VSIDL, включая определения протоколов, доступен по адресу //system/software_defined_vehicle/health_monitor/catalog/health_monitor.vsidl .

Терминология

Эти термины используются на данной странице.

живое сердцебиение (HB)
Сообщение, сгенерированное пакетом служб, указывающее на его активность. Сообщение содержит метку времени, показывающую, когда оно было сгенерировано. Для получения дополнительной информации см. раздел «Публикация сигналов подтверждения активности» .

пульс качества обслуживания (QoS)
SDV поддерживает несколько моделей связи типа Pub/Sub и удаленного вызова процедур (RPC). Экземпляр пакета служб, прослушивающий обмен данными, может публиковать сигналы подтверждения качества обслуживания (QoS), что позволяет агенту HM обнаруживать нарушения QoS. Для получения дополнительной информации см. раздел «Мониторинг QoS» .

мониторинг восстановления пакета услуг
Экземпляры пакетов служб SDV можно настроить на перезапуск в случае сбоя. Восстановление экземпляра может быть либо успешным, либо неудачным. HM отслеживает состояние восстановления экземпляра пакета служб и сообщает о сбоях восстановления в рамках отчета о состоянии виртуальной машины. Для получения дополнительной информации см. раздел «Мониторинг восстановления пакетов служб» .

мониторинг сбоев агентов
В отличие от экземпляров пакетов служб, агенты SDV имеют решающее значение для корректной работы системы. Они не настраиваются для восстановления и поэтому никогда не должны давать сбои. HM отслеживает работу агентов SDV и сообщает о сбоях в рамках отчета о состоянии виртуальной машины. Мониторинг пользовательских агентов OEM возможен. Для получения дополнительной информации см. раздел «Мониторинг сбоев агентов» .

Отчет о состоянии VM
A message generated by the HM to indicate the health of the VM. For more information, see VM health report .

Работа с подсистемой HM

Для использования функций HM OEM-реализации необходимо следующее:

  • Настройте систему мониторинга состояния здоровья, предоставив конфигурационные файлы, как описано в разделе «Настройка системы мониторинга состояния здоровья» .
  • Используйте пакет сервисов HM Listener, определенный производителем оборудования, чтобы прослушивать выходной сигнал HM и предпринимать соответствующие действия.
  • Разрабатывайте пакеты сервисов, которые активно публикуют сигналы в соответствии с их конфигурацией состояния работоспособности. Эта публикация позволяет HM оценивать свое состояние работоспособности. Для получения дополнительной информации см. руководства по разработке пакетов сервисов .

Настройте систему HM.

Любая конфигурация, связанная с HM, находится в одном из следующих типов конфигурации:

  • Глобальная конфигурация состояния виртуальной машины для каждого отдельного виртуального устройства.
  • Конфигурация состояния пакета услуг, определяющая параметры состояния для всех экземпляров пакета.

Конфигурация состояния виртуальной машины для каждой отдельной виртуальной машины

At run time, the HM agent expects a VM-wide health configuration: this is a textproto file (with a .textproto extension) of type VMHealth defined at //system/software_defined_vehicle/health_monitor/catalog/health_monitoring_config.proto . The VM Health configuration should be located at the path specified using boot time system property androidboot.sdv.health_monitor.config_path . Alternatively, you can configure this dynamically at run time by setting the persist.sdv.health_monitor.config_path system property to a custom path. The persist.* setting takes precedence over the androidboot.* setting. You must reboot the device for the new configuration to take effect.

В настройках состояния виртуальной машины можно задать следующие параметры:

  • Периодичность отправки отчета о состоянии виртуальной машины регулируется параметром period_ms . Его установка представляет собой компромисс между более быстрой передачей сигналов об обнаружении нарушений работоспособности и производительностью подсистемы мониторинга состояния. Мы рекомендуем значение 100 мс.

  • Какие агенты подлежат мониторингу на предмет сбоев (см. Мониторинг сбоев агентов ).

Примеры конфигурационных файлов находятся в папке //system/software_defined_vehicle/health_monitor/src/prod_configs/ . Вот пример конфигурационного файла:

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"
}

В этом примере агенты SDV DT и RPC настроены на мониторинг сбоев, а отчет о состоянии виртуальной машины настроен на публикацию каждые 100 мс.

Конфигурация для каждого пакета услуг

Мониторинг состояния экземпляров пакетов служб является необязательным. Чтобы включить его, сохраните файл конфигурации состояния в APEX-файле вашего пакета служб и укажите путь к нему в поле health_config_path объекта sdv_service_bundle_metadata в sdv_service_bundles_manifest.textproto . Дополнительную информацию о манифестах пакетов служб см. в разделе «Метаданные пакетов служб» .

Файл конфигурации системы здравоохранения представляет собой текстовый файл следующего типа:

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;
}

Для каждого экземпляра можно указать как конфигурацию проверки работоспособности (aliveness heartbeat), так и конфигурацию 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;
}

Для получения дополнительной информации о настройке отдельных функций см. разделы «Мониторинг сигналов работоспособности» и «Мониторинг качества обслуживания» .

Прослушайте выходной сигнал HM.

Вы можете прослушивать HM либо через периодические отчеты, либо через RPC API.

Отчет о состоянии VM

Система мониторинга состояния генерирует периодические отчеты о состоянии виртуальных машин с высокой частотой, предоставляя краткую информацию о состоянии отслеживаемых объектов.

Синтаксис типов VmHealth определен в файле //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;
}

Пакет служб прослушивания HM, определяемый производителем оборудования, должен отслеживать отчеты VMHealth и предпринимать соответствующие действия в зависимости от общей архитектуры системы. Возможные действия включают следующее:

  • Запустите диагностические процедуры на виртуальной машине.
  • Перезапустите виртуальную машину.
  • Проведите кампанию по сбору телеметрии, чтобы определить причину.
  • Обновите систему или остановите обновление, если система работает некорректно.

HM RPC API

Отчет о состоянии виртуальной машины — это документ, оптимизированный для частоты и скорости передачи данных, предоставляющий общую информацию о состоянии системы.

API RPC для мониторинга состояния здоровья (HM) позволяет слушателю HM получать подробную информацию об источнике нарушений работоспособности. Интерфейс определен в файле //system/software_defined_vehicle/health_monitor/catalog/health_monitor_service.proto . Для удобства интерфейс приведен здесь:

// 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) {}
}

Подробное описание характеристик

В этом разделе более подробно описаны различные аспекты HM.

Мониторинг сердцебиения и активности

Когда для экземпляра пакета служб настроен мониторинг работоспособности, HM ожидает, что экземпляр будет периодически отправлять сигналы подтверждения корректной работы бизнес-логики. Этот мониторинг лучше всего подходит для экземпляров пакетов служб, выполняющих периодические задачи. Кроме того, пакеты, использующие асинхронные среды выполнения, могут использовать мониторинг работоспособности для подтверждения того, что пул потоков не исчерпан.

Поток мониторинга жизнеспособности HM

Рисунок 1. Схема мониторинга жизнеспособности HM.

Конфигурация

Чтобы включить проверку работоспособности (alvives HB) для экземпляра пакета служб, добавьте экземпляр HealthConfiguration в поле health_config в конфигурации пакета .

Конфигурация пульсации определяет заранее заданный набор параметров, которые устанавливают критерии для оценки периодического сигнала пульсации сервиса. Если характеристики пульсации сервиса отклоняются от этих параметров, пульсация классифицируется как запаздывающая, а соответствующий пакет сервисов — как неисправный, что может указывать на неоптимальное рабочее состояние.

Пакет служб считается работоспособным, если он своевременно отправляет сигналы подтверждения работоспособности в соответствии со своей конфигурацией состояния. В случае сбоя или высокой системной нагрузки сигнал подтверждения работоспособности может отсутствовать или поступать с задержкой, что приведет к тому, что пакет служб будет помечен как неработоспособный. В этом случае в отчете VmHealth появится сообщение о нарушении.

Разработчики пакетов сервисов должны определить конфигурацию работоспособности пакета сервисов в соответствующих метаданных APEX. Конфигурация работоспособности определяет следующие критерии:

  • Максимально допустимая начальная задержка между запуском сервиса и первым обнаружением сердцебиения.

  • Период, в течение которого пакет сервисов SDV выполняет бизнес-логику, соответствующий периодичности публикации сигнала активности сервиса.

  • Количество менструаций, которые должны быть пропущены, прежде чем госпожа сочтет комплекс услуг вредным для здоровья.

  • Время выполнения — это время, необходимое пакету сервисов SDV для выполнения своей бизнес-логики, прежде чем он сможет опубликовать сигнал подтверждения работоспособности сервиса.

Если сигнал подтверждения работоспособности сервиса поступает с задержкой, это приводит к нарушению работоспособности. В зависимости от времени наблюдения за состоянием работоспособности возможны два случая:

  • Случай 1: Первоначальный сигнал активности не был получен. Если между началом работы пакета услуг и моментом наблюдения прошло больше допустимой начальной задержки, чем указано, пакет услуг считается неисправным.

  • Случай 2: Сигналы активности уже были получены. Если между последним сигналом активности и временем наблюдения прошло определенное пороговое значение, пакет услуг считается неработоспособным. Это пороговое значение рассчитывается как сумма периода отчетности (умноженная на количество периодов) и продолжительности задачи.

Формат конфигурации состояния здоровья определен в //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;
}

Вопросы, связанные со временем выполнения.

В этом разделе представлены рекомендации по публикации данных о состоянии здоровья и правильной регистрации для мониторинга.

Публикуйте пульсирующие ритмы жизни

Экземпляр пакета служб генерирует сообщение о состоянии службы , содержащее метку времени. Это сообщение обычно генерируется сразу после выполнения основной бизнес-логики. Сообщение о состоянии службы указывает на то, что пакет служб активен.

Для мониторинга экземпляра пакета необходимо создать издателя типа ServiceHeartbeat , который доступен в библиотеке libhealth_api :

 message ServiceHeartbeat {
   // Required.
   // The timestamp.
   .google.protobuf.Timestamp timestamp = 1;
 }

Тему публикации выбирается произвольно. Агент HM использует поиск по типу сообщения для обнаружения публикации.

При настройке мониторинга работоспособности через конфигурацию состояния, указанную в манифесте соответствующего пакета служб, агент мониторинга работоспособности ожидает публикации сигналов подтверждения работоспособности сразу после завершения процедуры on_start экземпляра. Мы рекомендуем делать on_start короткой, чтобы избежать блокировки запуска системы, поэтому публикуйте сигналы подтверждения работоспособности в асинхронной задаче, запускаемой в on_start .

Разработчики пакетов могут настроить время, когда ожидается первый сигнал подтверждения активности, используя параметр конфигурации initial_delay_ms .

Экземпляр пакета должен продолжать публиковать сигналы подтверждения активности до тех пор, пока его не остановят. Экземпляр считается остановленным, когда завершается его процедура on_stop .

Особый сценарий использования: явная регистрация для мониторинга сердцебиения.

Поведение, описанное в разделе «Мониторинг пульсации активности» , где пульсация ожидается между on_start и on_stop , называется неявным мониторингом активности . Это рекомендуемый способ использования данной функции: он упрощает бизнес-логику пакета и гарантирует, что пакет всегда находится под наблюдением.

Однако в некоторых случаях период мониторинга по умолчанию может быть ограничением:

  • Экземпляр пакета сервисов содержит бизнес-логику, которая выполняется периодически в течение временного интервала, не связанного с событиями start и stop . Мониторинг работоспособности может потребоваться только в течение этого заданного периода.
  • The HM accurately tracks HBs across suspend and resume periods. Therefore, the bundle might want to continue being monitored post on_stop .
  • Пользовательские OEM-агенты могут не быть реализованы в виде пакетов услуг. Следовательно, они не могут воспользоваться преимуществами неявного мониторинга активности. Однако мониторинг активности им всё ещё может потребоваться.

For these cases, the HM lets you bypass implicit registration to aliveness monitoring in favor of explicit registration . To use explicit registration, a bundle instance must opt out of implicit registration by not including an entry of type HealthConfiguration for the particular instance in the bundle's manifest. Then, at run time, the bundle instance should use the RPC API defined in //system/software_defined_vehicle/health_monitor/catalog/health_monitor_registration_service.proto to manually register and deregister from monitoring. Published heartbeats are expected as soon as the registration RPC call succeeds.

Пример реализации можно посмотреть по адресу //system/software_defined_vehicle/samples/health/stable/health_monitored_service_bundle/ .

мониторинг качества обслуживания

Качество обслуживания (QoS) — это показатель качества связи. HM отслеживает, не тратит ли отправленное сообщение слишком много времени на передачу, или, в случае периодической связи, не принимаются ли сообщения с выбранной частотой.

SDV предоставляет несколько вариантов обмена данными по протоколам Pub/Sub и RPC. Общим знаменателем является то, что все схемы обмена данными содержат как минимум одного слушателя. Для того чтобы HM мог отслеживать обмен данными, этот экземпляр пакета служб, осуществляющих прослушивание, должен публиковать специальные сигналы QoS всякий раз, когда он получает сообщение, представляющее интерес.

Конфигурация

Чтобы включить мониторинг QoS для связи, сначала определите слушатель связи, который будет публиковать сигналы подтверждения QoS. Затем для указанного экземпляра пакета служб добавьте одну или несколько тем в сопоставления QosMonitoringConfiguration в поле qos_config . Дополнительную информацию см. в разделе «Конфигурация для каждого пакета служб» .

Тема представляет собой строку, определяющую тему публикации, в которой HM ожидает сообщений QoS HB во время выполнения. Экземпляр пакета прослушивания может участвовать в нескольких коммуникациях и сообщать о сообщениях QoS HB по нескольким темам.

Темы должны быть описательными, поскольку информация о нарушениях QoS во время выполнения передается в пакет службы прослушивания HM.

Тип QosMonitoringConfiguration определен в //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;
}

Для стандартных сценариев использования следует применять оба типа мониторинга QoS. Значение qos_latency_threshold_ms равное 30 является разумным для внутривиртуальной связи по протоколу Pub/Sub при нормальной системной нагрузке.

Вопросы, связанные со временем выполнения.

Подобно мониторингу активности (HB), ожидается, что пакет прослушивания связи будет публиковать своего рода «пульс». В этом случае QoS-пульс должен публиковаться всякий раз, когда получены интересующие сообщения, а не по завершении выполнения бизнес-логики.

Объект QoS HB имеет тип QosHeartbeat , определенный в //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;
}

Время регистрации и отмены регистрации публикации QoS HB имеет решающее значение для точного мониторинга. HM ожидает появления сообщений QoS HB в промежутке между этими двумя событиями. Пакет прослушивания сообщений должен зарегистрировать публикацию QoS HB, когда отслеживаемая связь зарегистрирована в стеке связи SDV. HM может использовать API доступности для этого. Для получения дополнительной информации см. раздел «Определение доступности сервиса» .

мониторинг восстановления пакета услуг

Восстановление экземпляров пакетов служб настраивается в рамках конфигурационных файлов агента оркестрации. Подробное описание этой темы см. в разделе «Пакеты служб» . Подсистема HM пассивно наблюдает за процессом восстановления. При обнаружении сбоя восстановления экземпляра пакета в отчет VMHealth добавляется запись о нарушении. В отличие от остальных возможностей мониторинга HM, мониторинг восстановления является обязательным и не подлежит настройке.

Сбои экземпляров пакетов служб, не настроенных для восстановления, приводят к нарушению работоспособности при первом же сбое.

Восстановление экземпляра пакета служб разработано для интеграции с мониторингом активности пульса. Система мониторинга активности пульса более лояльна при оценке пульса, когда обнаруживает, что пакет восстанавливается. На практике эта лояльность означает, что пакетам служб не нужно выполнять никаких дополнительных шагов по отмене или регистрации мониторинга в случае сбоя.

Мониторинг сбоев агентов

Система HM обнаруживает потенциальные сбои агентов SDV с помощью механизма linkToDeath в блоке binder.

Вы можете настроить мониторинг сбоев в рамках конфигурации состояния виртуальной машины (см. Конфигурация для каждого экземпляра SDV (виртуальной машины) ), в частности, в поле monitored_agent repeated. Это поле должно содержать записи типа 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;
}

Пользовательские агенты также можно отслеживать, если агент предоставляет интерфейс привязки. Для отслеживания пользовательского агента предоставьте HM SELinux разрешения на прослушивание соответствующего интерфейса привязки.

Системное свойство ro.boot.sdv.health_monitor.agent_startup_timeout_sec может переопределять время ожидания HM регистрации агентами своих интерфейсов привязки после запуска HM. Если это не требуется пользовательскими агентами, значение по умолчанию, равное трем секундам, является подходящим.

Руководства разработчика пакетов сервисов

В этом разделе представлены пошаговые инструкции по использованию функций мониторинга здоровья (HM) из пакетов сервисов, в отличие от теоретического рассмотрения в предыдущих разделах. Актуальным эталонным примером, на котором основаны эти инструкции, является пример qos_monitoring . Для получения практического опыта следуйте инструкциям в файле //system/software_defined_vehicle/samples/health/stable/qos_monitoring/README этого примера.

Добавьте мониторинг сердцебиения для оценки жизнеспособности в пакет услуг.

Этот метод является наиболее прямым способом включения мониторинга состояния пакета услуг:

  1. Define an instance of ServiceBundleHealthConfiguration for the bundle instances in a file named 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 { ... }

  }
}

  2. Добавьте файл конфигурации в пакет служб APEX. В файле 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"],
}

  3. Сохраните конфигурацию работоспособности в APEX и укажите health_config_path в манифесте: 

    # sdv_service_bundles_manifest.textproto
sdv_service_bundle_metadata {
  ...
  health_config_path: "etc/config/health_configuration.textproto"
}

  4. В определении VSIDL убедитесь, что пакет публикует com.android.sdv.health.ServiceHeartbeat : 

    sdv_service_bundle {
  name: "SampleBundle"
  publisher {
    message: "com.android.sdv.health.ServiceHeartbeat"
    topic: "arbitrary-topic"
    capacity: 2
  }
}

  5. Добавьте в пакет разрешения SDV, чтобы пакет имел право публиковать HB-файлы: 

      publisher {
    type: "com.android.sdv.health.ServiceHeartbeat"
  }

  6. Периодически публикуйте сигналы подтверждения работоспособности сервиса в коде, начиная с 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()
    })?;
  }
}

Особый вариант использования: Явная регистрация

Для более специфических случаев использования, когда пакету требуется мониторинг HB для пользовательских жизненных циклов (например, мониторинг, начинающийся раньше или заканчивающийся позже стандартного состояния STARTED ), можно использовать явный метод регистрации:

  1. В определение VSIDL добавьте клиент com.android.sdv.health.HealthMonitorRegistrationService : 

    sdv_service_bundle {
  # ...
  client {
    service: "com.android.sdv.health.HealthMonitorRegistrationService"
    channel: "com-android-sdv-health-health-monitor-registration-service"
  }
}

  2. Добавить разрешение SDV для использования RPC регистрации HB для проверки жизнеспособности: 

      # ...
  client {
    service: "com.android.sdv.health.HealthMonitorRegistrationService"
    channel: "com-android-sdv-health-health-monitor-registration-service"
  }

  3. Зарегистрируйтесь в HM через RPC, например, в on_start или new : 

    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();

  4. Опубликуйте HBs.

  5. Отмените регистрацию в системе мониторинга, когда она больше не требуется: 

    let _ = rpc_client
  .UnregisterConfiguration(&UnregisterConfigurationRequest { ..Default::default() })
  .await
  .unwrap();

Добавьте мониторинг качества обслуживания (QoS) в систему связи.

  1. Убедитесь, что экземпляр пакета служб является подписчиком темы с именем fog-light-status в каталоге VSIDL: 

    subscriber {
  message: "QosMonitoredFogLightStatus"
  topic: "left-fog-light-status"
}

    Формат сообщения следующий: 

    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;
}

  2. Определите экземпляр ServiceBundleHealthConfiguration для экземпляров пакетов в файле health_configuration.textproto , который включает мониторинг 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 }
    }
  }
}

    Выбранная в key поле тема указывает на то, что сообщения QoS HB будут публиковаться по этой теме, что позволит осуществлять мониторинг темы под названием fog-light-status .

  3. Добавьте файл конфигурации в пакет служб APEX. В файле 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"],
}

  4. Сохраните конфигурацию работоспособности в APEX и укажите health_config_path в манифесте: 

    # sdv_service_bundles_manifest.textproto
sdv_service_bundle_metadata {
  ...
  health_config_path: "etc/config/health_configuration.textproto"
}

  5. В определении VSIDL убедитесь, что пакет является издателем 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
  }
}

  6. Добавьте в пакет разрешения SDV, чтобы пакет имел право публиковать QoS HB: 

    publisher { message: "com.android.sdv.health.QosHeartbeat" topic: "qos-hb-right-fog-light-status" }

  7. Регистрируйте публикацию QoS HB только тогда, когда отслеживаемое соединение зарегистрировано. Используйте API доступности из 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?;

// ...

  8. Публиковать QoS-контроллеры каждый раз при получении сообщения: 

    // ...
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
    // ...
  }
}

  9. Чтобы остановить мониторинг QoS, удалите объект издателя: 

    // ...
drop(qos_hb_pub);

Мониторинг состояния отладки

Для отладки и обзора системы используйте инструмент dumpsys для мониторинга состояния работоспособности виртуальной машины: 

adb shell dumpsys com.google.sdv.ISdvAgent/hm

В отчете подробно описывается конфигурация системы отчетности о состоянии виртуальных машин, конфигурация пакетов и состояние мониторинга. Ниже приведен пример такого отчета: 

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

----------------