Sağlık durumu izleme

Durum İzleyici (HM), hizmet paketlerinin durumunu izlemek, sanal makinenin durumunu belirlemek ve düzenli olarak sanal makine durum raporu oluşturmak için her sanal makinede (VM) çalışan bir SDV aracısıdır.

OEM tarafından tanımlanan hizmet paketleri, HM tarafından bildirilen çeşitli sağlık sinyallerini dinlemeli ve verilere göre kurtarma işlemleri gerçekleştirmelidir. Örneğin, kilitlenen hizmet paketleri içeren bir SDV örneğinin yeniden başlatılması veya güncellenmesi gerekebilir.

HM aracısını aşağıdakileri izleyecek şekilde yapılandırabilirsiniz:

• Periyodik görevleri gerçekleştiren varlıkların canlılık durumunu, canlılık sinyallerini izleyerek kontrol eder. Bu izleme, hem hizmet paketi örnekleri hem de özel OEM temsilcileri için yapılandırılabilir.
  • Hizmet paketi örneklerinin kurtarma durumu. Hizmet paketlerini, kilitlendiklerinde otomatik olarak yeniden başlatılacak şekilde yapılandırabilirsiniz. HM, bu kurtarma sürecini izlemek için sinyaller sağlar.
  • İletişim HK'si
• SDV ve OEM özel temsilcilerinin etkinliği

Referans olarak, proto tanımları da dahil olmak üzere VSIDL kataloğunun tamamını //system/software_defined_vehicle/health_monitor/catalog/health_monitor.vsidl adresinde bulabilirsiniz.

Terminoloji

Bu terimler bu sayfada kullanılmaktadır.

HM alt sistemiyle çalışma

HM özelliklerini kullanmak için OEM uygulamasının şunları yapması gerekir:

• HM sistemini yapılandırma bölümünde ayrıntılı olarak açıklandığı şekilde yapılandırma dosyaları sağlayarak durum izleme sistemini yapılandırın.
• HM çıkışını dinlemek ve uygun işlemi yapmak için OEM tarafından tanımlanan bir HM işleyici hizmet paketi kullanın.
• Sağlık yapılandırmalarına göre aktif olarak sinyal yayınlayan hizmet paketleri geliştirin. Bu yayın, HM'nin sağlık durumunu değerlendirmesine olanak tanır. Daha fazla bilgi için Hizmet paketi geliştirici kılavuzları'na bakın.

HM sistemini yapılandırma

HM ile ilgili tüm yapılandırmalar aşağıdaki yapılandırma türlerinden birinde bulunur:

• Sanal makine başına genel bir sağlık yapılandırması
• Hizmet paketi başına durum yapılandırması, paketin tüm örnekleri için durum parametrelerini tanımlar.

Sanal makine başına durum yapılandırması

Çalışma zamanında HM aracısı, sanal makine genelinde bir durum yapılandırması bekler. Bu, //system/software_defined_vehicle/health_monitor/catalog/health_monitoring_config.proto konumunda tanımlanan VMHealth türünde bir textproto dosyasıdır (.textproto uzantılı). Sanal makine sağlığı yapılandırması, önyükleme zamanı sistem özelliği androidboot.sdv.health_monitor.config_path kullanılarak belirtilen yolda bulunmalıdır. Alternatif olarak, persist.sdv.health_monitor.config_path sistem özelliğini özel bir yola ayarlayarak bunu çalışma zamanında dinamik olarak yapılandırabilirsiniz. persist.* ayarı, androidboot.* ayarına göre önceliklidir. Yeni yapılandırmanın geçerli olması için cihazı yeniden başlatmanız gerekir.

Sanal makine durumu yapılandırması, aşağıdakileri ayarlamanıza olanak tanır:

• period_ms üzerinden sanal makine sağlık raporunun periyodikliği. Bu ayar, sağlık ihlallerinin tespit edildiğini daha hızlı bildirme ile HM alt sisteminin performansı arasında bir denge sağlar. 100 ms değerini kullanmanızı öneririz.

• Hangi temsilcilerin kilitlenme açısından izleneceği (Temsilci kilitlenme izleme bölümüne bakın).

Yapılandırma dosyası örnekleri //system/software_defined_vehicle/health_monitor/src/prod_configs/ dizininde bulunur. Örnek bir yapılandırma dosyası:

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

Bu örnekte SDV DT ve RPC aracıları kilitlenme izleme için yapılandırılmıştır ve sanal makine sağlık raporu her 100 ms'de bir yayınlanacak şekilde yapılandırılmıştır.

Hizmet paketi yapılandırması başına

Hizmet paketi örneklerinin durumunu izlemek isteğe bağlıdır. Etkinleştirmek için sağlık yapılandırma dosyasını hizmet paketinizin APEX'inde depolayın ve sdv_service_bundles_manifest.textproto içindeki sdv_service_bundle_metadata öğesinin health_config_path alanında bu dosyanın yolunu tanımlayın. Hizmet paketi manifestleri hakkında daha fazla bilgi için Hizmet paketi meta verileri başlıklı makaleyi inceleyin.

Durum yapılandırma dosyası, aşağıdaki türde bir textproto dosyasıdır:

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

Her örnek için hem canlılık sinyali yapılandırmasını hem de QoS yapılandırmasını belirtebilirsiniz:

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

Özelliğe göre yapılandırma hakkında daha fazla bilgi için Canlılık sinyallerini izleme ve HK izleme başlıklı makaleleri inceleyin.

HM çıkışını dinleme

HM'yi periyodik raporlar veya RPC API aracılığıyla dinleyebilirsiniz.

Sanal makine sağlık raporu

Durum izleme, izlenen varlıkların durum durumu hakkında kısa bilgiler sağlayan yüksek frekanslı periyodik bir sanal makine durum raporu oluşturur.

VmHealth türünün söz dizimi //system/software_defined_vehicle/health_monitor/catalog/health_topic.proto içinde tanımlanır:

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

OEM tarafından tanımlanan bir HM dinleyici hizmeti paketi, VMHealth raporlarını dinlemeli ve tüm sistem mimarisine bağlı olarak uygun işlemi yapmalıdır. Yapabileceğiniz işlemler şunlardır:

• Sanal makinede teşhis rutinlerini çalıştırın.
• Sanal makineyi yeniden başlatın.
• Nedeni belirlemek için bir telemetri kampanyası yayınlayın.
• Sistemi güncelleyin veya sistem düzgün çalışmıyorsa güncellemeyi durdurun.

HM RPC API

Sanal makine sağlık raporu, sıklık ve aktarım hızı için optimize edilmiş bir yayındır ve sistemin sağlık durumu hakkında genel bilgiler sağlar.

HM RPC API, HM dinleyicisinin sağlık ihlallerinin kaynağı hakkında ayrıntılı bilgi edinmesini sağlar. Arayüz, //system/software_defined_vehicle/health_monitor/catalog/health_monitor_service.proto içinde tanımlanır. Arayüz, kolaylık sağlamak için burada yeniden oluşturulmuştur:

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

Özelliklerin ayrıntılı açıklaması

Bu bölümde, HM'nin çeşitli yönleri daha ayrıntılı olarak açıklanmaktadır.

Canlılık sinyallerini izleme

Bir hizmet paketi örneği için canlılık izleme yapılandırıldığında HM, iş mantığının doğru şekilde çalıştığını kanıtlamak için örneğin düzenli olarak sinyal yayınlamasını bekler. Bu izleme, periyodik görevler gerçekleştiren hizmet paketi örnekleri için en uygun seçenektir. Ayrıca, eşzamansız çalışma zamanlarını kullanan paketler, iş parçacığı havuzunun tükenmediğini kanıtlamak için canlılık izlemeyi kullanabilir.

Şekil 1. HM canlılık izleme akışı.

Yapılandırma

Bir hizmet paketi örneğinde canlılık HB'sini etkinleştirmek için paket yapılandırmasındaki health_config alanına bir HealthConfiguration örneği ekleyin.

Canlılık sinyali yapılandırması, bir hizmetin periyodik sinyalini değerlendirme ölçütlerini belirleyen önceden tanımlanmış bir parametre kümesini tanımlar. Hizmet sinyalinin özellikleri bu parametrelerden saparsa sinyal gecikmeli olarak sınıflandırılır ve ilgili hizmet paketi sağlıksız olarak değerlendirilir. Bu durum, optimum olmayan bir çalışma durumuna işaret edebilir.

Bir hizmet paketi, durum yapılandırmasına göre zamanında sinyal bildiriyorsa sağlıklı kabul edilir. Kilitlenme veya yüksek sistem yükü durumunda sinyal eksik ya da gecikmeli olabilir. Bu da hizmet paketinin sağlıksız olarak işaretlenmesine neden olur. Bu durumda, VmHealth raporunda bir ihlal görünür.

Hizmet paketi geliştiricileri, hizmet paketinin sağlık yapılandırmasını ilgili APEX meta verilerinde tanımlamalıdır. Durum yapılandırması şu ölçütleri tanımlar:

• Hizmetin başlatılması ile ilk sinyal algılama arasında izin verilen maksimum başlangıç gecikmesi.

• SDV hizmet paketinin iş mantığını yürüttüğü süre. Bu süre, hizmet sinyalinin yayınlanma sıklığına karşılık gelir.

• HM'nin hizmet paketini sağlıksız olarak değerlendirmesi için kaç dönemin kaçırılması gerektiği.

• Yürütme süresi, bir SDV hizmet paketinin hizmet sinyali yayınlayabilmesi için iş mantığını gerçekleştirmesi gereken süredir.

Hizmet paketi, hizmet sinyalinin gecikmesi durumunda bir sağlık ihlali oluşturur. Sağlık gözleminin zamanına göre iki durum vardır:

• 1. durum: İlk sinyal alınmadı. Hizmet paketinin başlangıcı ile gözlem zamanı arasında izin verilen ilk gecikmeden daha fazla süre geçtiyse hizmet paketi sağlıksız olarak kabul edilir.

• 2. durum: Sinyaller zaten alınmıştır. Son sinyal ile gözlem zamanı arasında bir eşik süresi geçtiyse hizmet paketi sağlıksız olarak kabul edilir. Bu eşik, raporlama döneminin (dönem sayısıyla çarpılır) ve görevin süresinin toplamı olarak hesaplanır.

Sağlık yapılandırması biçimi //system/software_defined_vehicle/health_monitor/catalog/health_config.proto içinde tanımlanır:

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

Çalışma zamanıyla ilgili dikkat edilmesi gereken noktalar

Bu bölümde, canlılık sinyallerini yayınlama ve izleme için doğru şekilde kaydolma hakkında bilgi verilmektedir.

Canlılık sinyallerini yayınlama

Hizmet paketi örneği, zaman damgası içeren bir hizmet sinyali mesajı oluşturur. Mesajı düzenli olarak, genellikle ana işletme mantığı yürütüldükten hemen sonra oluşturun. Hizmet sinyali, hizmet paketinin etkin olduğunu gösterir.

İzlenecek paket örneği nesnesinin, libhealth_api kitaplığında bulunan ServiceHeartbeat türünde bir yayıncı oluşturması gerekir:

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

Yayın konusunu rastgele seçin. HM aracısı, yayını algılamak için mesaj türüne göre keşif yöntemini kullanır.

Canlılık izleme, ilgili hizmet paketi manifestinde bağlantısı verilen durum yapılandırması aracılığıyla yapılandırılırken HM aracısı, örnek on_start rutinini tamamlar tamamlamaz HB'lerin yayınlanmasını bekler. Sistem başlatma işleminin engellenmemesi için on_start yöntemini kısa tutmanızı öneririz. Bu nedenle, sinyalleri on_start yönteminde başlatılan eşzamansız bir görevde yayınlayın.

Paket geliştiricileri, initial_delay_ms yapılandırma girişini kullanarak ilk sinyalin beklendiği zamanı özelleştirebilir.

Paket örneği, durdurulana kadar sinyal yayınlamaya devam etmelidir. on_stop rutini tamamlandığında örnek durdurulmuş kabul edilir.

Özel kullanım alanı: Sinyal izlemeye açıkça kaydolma

Canlılık sinyallerini izleme bölümünde açıklanan ve on_start ile on_stop arasında sinyal beklenen davranışa dolaylı canlılık izleme adı verilir. Bu, özelliği kullanmanın önerilen yoludur: Paketin iş mantığını basitleştirir ve paketin her zaman izlenmesini sağlar.

Ancak varsayılan izleme süresinin kısıtlama oluşturduğu bazı kullanım alanları olabilir:

• Hizmet paketi örneği, start ve stop etkinliklerine bağlı olmayan bir zaman aralığında periyodik olan iş mantığı içeriyor. Canlılık izleme yalnızca bu özel dönemde gerekli olabilir.
• HM, askıya alma ve devam ettirme dönemleri boyunca HB'leri doğru şekilde izler. Bu nedenle, paketin on_stop tarihinden sonra da izlenmeye devam etmesi gerekebilir.
• Özel OEM temsilcileri, hizmet paketleri olarak uygulanmayabilir. Bu nedenle, dolaylı canlılık izleme özelliğinden yararlanamazlar. Ancak yine de canlılık izleme gerekebilir.

Bu gibi durumlarda HM, açık kayıt lehine canlılık izlemeye yönelik örtük kaydı atlamanıza olanak tanır. Açık tescili kullanmak için paket örneği, paketin manifest dosyasında belirli örnek için HealthConfiguration türünde bir giriş eklemeyerek dolaylı tescili devre dışı bırakmalıdır. Ardından, çalışma zamanında paket örneği, izlemeye manuel olarak kaydolmak ve kaydı iptal etmek için //system/software_defined_vehicle/health_monitor/catalog/health_monitor_registration_service.proto içinde tanımlanan RPC API'yi kullanmalıdır. Kayıt RPC çağrısı başarılı olur olmaz sinyallerin yayınlanması beklenir.

Örnek bir uygulama için //system/software_defined_vehicle/samples/health/stable/health_monitored_service_bundle/ sayfasına bakın.

HK izleme

Hizmet Kalitesi (HK), iletişimin ölçümüdür. HM, gönderilen mesajın aktarımda çok fazla zaman harcayıp harcamadığını veya periyodik iletişim durumunda mesajların seçilen sıklıkta alınıp alınmadığını izler.

SDV, Pub/Sub ve RPC iletişiminin çeşitli türlerini sunar. Tüm iletişim şemalarının ortak paydası, en az bir dinleyici içermeleridir. HM'nin iletişimi izlemesi için bu dinleme hizmeti paketi örneği, ilgilenilen bir mesaj aldığında özel QoS sinyalleri yayınlamalıdır.

Yapılandırma

Bir iletişimin QoS izlemesini etkinleştirmek için önce QoS sinyalini yayınlayacak iletişim dinleyicisini tanımlayın. Ardından, tanımlanan hizmet paketi örneği için qos_config alanına bir veya daha fazla konu-QosMonitoringConfiguration eşlemesi ekleyin. Daha fazla bilgi için Hizmet paketi başına yapılandırma bölümünü inceleyin.

Konu, HM'nin çalışma zamanında QoS HB'leri beklediği yayın konusunu tanımlayan bir dizedir. Dinleme paketi örneği, birden fazla iletişime katılabilir ve birden fazla konuda QoS HB'leri bildirebilir.

Çalışma zamanında QoS ihlalleri tespit edilirse HM dinleyici hizmet paketine geri bildirildikleri için konular açıklayıcı olmalıdır.

QosMonitoringConfiguration türü, //system/software_defined_vehicle/health_monitor/catalog/health_config.proto içinde tanımlanır:

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

Varsayılan kullanım alanları için her iki HK izleme türünü de zorunlu kılın. Normal sistem yükleri altında, sanal makine içi Pub/Sub iletişimi için qos_latency_threshold_ms/30 makul bir değerdir.

Çalışma zamanıyla ilgili dikkat edilmesi gereken noktalar

Canlılık HB izlemeye benzer şekilde, iletişim dinleme paketinin bir tür sinyal yayınlaması beklenir. Bu durumda, iş mantığı yürütme işleminin sonunda değil, ilgili mesajlar alındığında bir QoS HB yayınlanmalıdır.

HK HB, //system/software_defined_vehicle/health_monitor/catalog/qos_heartbeat.proto içinde tanımlanan QosHeartbeat türündedir:

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

Doğru izleme için QoS HB yayınının kaydedilme ve kaydının silinme zamanı çok önemlidir. HM, bu iki etkinlik arasında QoS HB'leri bekler. Mesaj dinleme paketi, izlenen iletişim SDV iletişim yığınına kaydedildiğinde QoS HB yayınını kaydetmelidir. HM, bu işlem için müsaitlik durumu API'sini kullanabilir. Daha fazla bilgi için Hizmet kullanılabilirliğini belirleme başlıklı makaleyi inceleyin.

Hizmet paketi kurtarma izleme

Hizmet paketi örneklerinin kurtarılması, düzenleme aracısı yapılandırma dosyalarının bir parçası olarak yapılandırılır. Konuyla ilgili ayrıntılı bilgi için Hizmet paketleri başlıklı makaleyi inceleyin. HM alt sistemi, kurtarma sürecini pasif olarak gözlemler. Bir paket örneğinin kurtarılamadığı tespit edildiğinde VMHealth raporuna bir ihlal eklenir. HM izleme özelliklerinin geri kalanının aksine, kurtarma izleme zorunludur ve yapılandırılamaz.

Kurtarma için yapılandırılmamış hizmet paketi örneklerinin kilitlenmesi, ilk kilitlenmede sağlık ihlali oluşturur.

Hizmet paketi örneği kurtarma, sinyal canlılık izleme ile entegre olacak şekilde tasarlanmıştır. HM sistemi, paketin kurtarıldığını algıladığında kalp atışlarını değerlendirirken daha esnek davranır. Uygulamada bu esneklik, hizmet paketlerinin kilitlenmeleri durumunda ek izleme kaydı iptali veya kayıt adımları uygulaması gerekmediği anlamına gelir.

Temsilci kilitlenmelerini izleme

HM, bağlayıcı linkToDeath mekanizmasını kullanarak SDV temsilcilerinin olası kilitlenmelerini algılar.

Kilitlenme izlemeyi, sanal makine durumu yapılandırmasının bir parçası olarak (SDV örneği (sanal makine) başına yapılandırma bölümüne bakın), özellikle de monitored_agent yinelenen alanında yapılandırabilirsiniz. Bu alan, BinderServiceAgent türünde girişler içermelidir:

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

Özel temsilciler, bir bağlayıcı arayüzü sunuyorsa izlenebilir. Özel bir aracıyı izlemek için HM SELinux'a uygun bağlayıcı arayüzünü dinleme izinlerini verin.

ro.boot.sdv.health_monitor.agent_startup_timeout_sec sistem özelliği, HM başlatıldıktan sonra HM'nin, aracıların bağlayıcı arayüzlerini kaydetmesi için ne kadar bekleyeceğini geçersiz kılabilir. Özel temsilciler tarafından gerekli kılınmadığı sürece varsayılan üç saniye uygundur.

Hizmet paketi geliştirici kılavuzları

Bu bölümde, önceki bölümlerdeki teorik anlatımın aksine, hizmet paketlerindeki HM özelliklerinin nasıl kullanılacağına dair adım adım açıklamalı kılavuzlar sunulmaktadır. Bu kılavuzların temel aldığı güncel referans örneği, qos_monitoring örneğidir. Pratik bir deneyim için örneğin //system/software_defined_vehicle/samples/health/stable/qos_monitoring/README bölümünü inceleyin.

Hizmet paketine canlılık sinyali izleme ekleme

Bu yöntem, bir hizmet paketi için durum izlemeyi etkinleştirmenin en doğrudan yoludur:

1. Paket örnekleri için health_configuration.textproto adlı dosyada ServiceBundleHealthConfiguration örneği tanımlayın:

   # 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. Yapılandırma dosyasını hizmet paketi APEX'e ekleyin. Android.bp içinde:

   
   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. Sağlık yapılandırmasını APEX'te depolayın ve manifest dosyasında health_config_path değerini ayarlayın:

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

4. VSIDL tanımında, paketin yayınlandığından emin olun com.android.sdv.health.ServiceHeartbeat:

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

5. Paketin HB yayınlama yetkisine sahip olması için pakete SDV izinleri ekleyin:

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

6. on_start tarihinden itibaren kodda hizmet sinyallerini düzenli olarak yayınlayın:

   // ...
   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()
       })?;
     }
   }
   

Özel kullanım alanı: Açık kayıt

Paketin özel yaşam döngüleri için HB izlemesi gerektirdiği daha özel kullanım alanlarında (örneğin, standart STARTED durumundan daha erken başlayan veya daha geç biten izleme) açık kayıt yöntemini kullanabilirsiniz:

1. VSIDL tanımına bir com.android.sdv.health.HealthMonitorRegistrationService istemcisi ekleyin:

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

2. Canlılık HB kaydı RPC'sini kullanmak için SDV izni ekleyin:

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

3. RPC üzerinden HM'ye kaydolun (ör. on_start veya 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. HB'leri yayınlayın.

5. Artık gerekmediğinde izleme kaydını iptal edin:

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

İletişime HK izleme ekleme

1. Hizmet paketi örneğinin, VSIDL kataloğunda fog-light-status adlı bir konunun abonesi olduğunu doğrulayın:

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

   Mesaj biçimi aşağıdaki gibidir:

   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;
   
     // A QoS-monitored message must include a timestamp field
     .google.protobuf.Timestamp timestamp = 2;
   }
   

2. QoS izleme içeren bir health_configuration.textproto dosyasındaki paket örnekleri için ServiceBundleHealthConfiguration örneği tanımlayın:

   # 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 alanında seçilen konu, QoS HB'lerin bu konuda yayınlanacağını gösterir. Bu sayede fog-light-status adlı bir konu izlenebilir.

3. Yapılandırma dosyasını hizmet paketi APEX'e ekleyin. Android.bp içinde:

   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. Sağlık yapılandırmasını APEX'te depolayın ve manifest dosyasında health_config_path değerini ayarlayın:

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

5. VSIDL tanımınızda, paketin com.android.sdv.health.QosHeartbeat yayıncısı olduğundan emin olun:

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

6. Paketin QoS HB'leri yayınlama yetkisine sahip olması için pakete SDV izinleri ekleyin:

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

7. QoS HB yayınını yalnızca izlenen iletişim kayıtlı olduğunda kaydedin. libsdv_mw_clientlib üzerinden müsaitlik durumu API'sini kullanın:

   // 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. Her mesaj alındığında QoS HB'leri yayınlama:

   // ...
   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. Hizmet kalitesi izlemeyi durdurmak için yayıncı nesnesini silin:

   // ...
   drop(qos_hb_pub);
   

Hata ayıklama sağlığını izleme

Hata ayıklama ve sisteme genel bakış için dumpsys aracını kullanarak sanal makinenin sistem durumu izleme durumunu izleyin:

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

Raporda sanal makine durumu raporlama yapılandırması, paket yapılandırması ve izleme durumu ayrıntılı olarak açıklanır. Aşağıda bu tür bir raporun örneği verilmiştir:

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

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