হেলথ মনিটর (HM) হলো একটি SDV এজেন্ট যা প্রতিটি ভার্চুয়াল মেশিনে (VM) সার্ভিস বান্ডেলের অবস্থা ট্র্যাক করতে, VM-এর স্বাস্থ্য নির্ধারণ করতে এবং পর্যায়ক্রমে একটি VM স্বাস্থ্য প্রতিবেদন তৈরি করতে চলে।
OEM-দ্বারা সংজ্ঞায়িত সার্ভিস বান্ডেলগুলোকে অবশ্যই HM দ্বারা রিপোর্ট করা বিভিন্ন হেলথ সিগন্যাল শুনতে হবে এবং সেই ডেটার উপর ভিত্তি করে পুনরুদ্ধারমূলক পদক্ষেপ গ্রহণ করতে হবে। উদাহরণস্বরূপ, ক্র্যাশ হওয়া সার্ভিস বান্ডেলসহ একটি SDV ইনস্ট্যান্সকে রিস্টার্ট বা আপডেট করার প্রয়োজন হতে পারে।
আপনি HM এজেন্টকে নিম্নলিখিত বিষয়গুলো ট্র্যাক করার জন্য কনফিগার করতে পারেন:
- পর্যায়ক্রমিক কাজ সম্পাদনকারী সত্তাগুলোর সজীবতার অবস্থা, তাদের সজীবতার হার্টবিট পর্যবেক্ষণের মাধ্যমে জানা যায়। এই পর্যবেক্ষণ ব্যবস্থাটি সার্ভিস বান্ডেল ইনস্ট্যান্স এবং কাস্টম OEM এজেন্ট উভয়ের জন্যই কনফিগার করা যেতে পারে।
- সার্ভিস বান্ডেল ইনস্ট্যান্সগুলোর পুনরুদ্ধার অবস্থা। SDV 2.0-তে, ক্র্যাশ করার সময় স্বয়ংক্রিয়ভাবে পুনরায় চালু হওয়ার জন্য আপনি সার্ভিস বান্ডেলগুলো কনফিগার করতে পারেন। HM এই পুনরুদ্ধার প্রক্রিয়াটি নিরীক্ষণের জন্য সিগন্যাল প্রদান করে।
- যোগাযোগের QoS
- এসডিভি এবং ওইএম কাস্টম এজেন্টদের সক্রিয়তা
তথ্যসূত্র হিসেবে, প্রোটো ডেফিনিশন সহ সম্পূর্ণ VSIDL ক্যাটালগটি //system/software_defined_vehicle/health_monitor/catalog/health_monitor.vsidl -এ পাওয়া যাবে।
পরিভাষা
এই পৃষ্ঠায় এই পরিভাষাগুলো ব্যবহৃত হয়েছে।
HM সাবসিস্টেমের সাথে কাজ করুন
HM বৈশিষ্ট্যগুলি ব্যবহার করার জন্য, একটি OEM বাস্তবায়নকে নিম্নলিখিত কাজগুলো করতে হবে:
- এইচএম সিস্টেম কনফিগার করুন-এ বিস্তারিতভাবে বর্ণিত কনফিগারেশন ফাইলগুলি প্রদান করে স্বাস্থ্য পর্যবেক্ষণ সিস্টেমটি কনফিগার করুন।
- HM আউটপুট শোনার জন্য এবং যথাযথ ব্যবস্থা গ্রহণের জন্য একটি OEM-নির্ধারিত HM Listener সার্ভিস বান্ডেল ব্যবহার করুন।
- সার্ভিস বান্ডেল তৈরি করুন যা তাদের হেলথ কনফিগারেশন অনুযায়ী সক্রিয়ভাবে সিগন্যাল প্রকাশ করে। এই প্রকাশনাটি 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এর মাধ্যমে ভিএম হেলথ রিপোর্টের পর্যায়কাল নির্ধারণ করা হয়। এটি নির্ধারণ করা হলো হেলথ ভায়োলেশন শনাক্ত হওয়ার দ্রুত সংকেত প্রদান এবং এইচএম সাবসিস্টেমের পারফরম্যান্সের মধ্যে একটি ভারসাম্য। আমরা ১০০ মিলিসেকেন্ডের একটি মান সুপারিশ করি।কোন এজেন্টগুলোকে ক্র্যাশ মনিটর করতে হবে ( এজেন্ট ক্র্যাশ মনিটরিং দেখুন)।
কনফিগারেশন ফাইলের উদাহরণ //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 এজেন্ট কনফিগার করা হয়েছে, এবং প্রতি ১০০ মিলিসেকেন্ডে VM স্বাস্থ্য প্রতিবেদন প্রকাশ করার জন্য কনফিগার করা হয়েছে।
প্রতি পরিষেবা বান্ডেল কনফিগারেশন
সার্ভিস বান্ডেল ইনস্ট্যান্সের স্বাস্থ্য পর্যবেক্ষণ ঐচ্ছিক। এটি চালু করতে, আপনার সার্ভিস বান্ডেলের APEX-এ স্বাস্থ্য কনফিগারেশন ফাইলটি সংরক্ষণ করুন এবং sdv_service_bundles_manifest.textproto এর sdv_service_bundle_metadata এর health_config_path ফিল্ডে এটির একটি পাথ নির্ধারণ করুন। সার্ভিস বান্ডেল ম্যানিফেস্ট সম্পর্কে আরও তথ্যের জন্য, সার্ভিস বান্ডেল মেটাডেটা দেখুন।
স্বাস্থ্য কনফিগারেশন ফাইলটি নিম্নলিখিত ধরণের একটি টেক্সটপ্রোটো ফাইল:
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;
}
প্রতিটি ইনস্ট্যান্সের জন্য, আপনি সজীবতা হার্টবিট কনফিগারেশন এবং 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;
}
প্রতিটি ফিচারের কনফিগারেশন সম্পর্কে আরও তথ্যের জন্য, অ্যালাইভনেস হার্টবিট মনিটরিং এবং কিউওএস মনিটরিং দেখুন।
এইচএম আউটপুট শুনুন
আপনি পর্যায়ক্রমিক প্রতিবেদন অথবা একটি RPC API-এর মাধ্যমে HM-এর কথা শুনতে পারেন।
ভিএম স্বাস্থ্য প্রতিবেদন
স্বাস্থ্য পর্যবেক্ষণ একটি উচ্চ-ফ্রিকোয়েন্সির পর্যায়ক্রমিক ভিএম স্বাস্থ্য প্রতিবেদন তৈরি করে, যা পর্যবেক্ষণাধীন সত্তাগুলোর স্বাস্থ্যগত অবস্থা সম্পর্কে সংক্ষিপ্ত তথ্য প্রদান করে।
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;
}
একটি OEM-সংজ্ঞায়িত HM লিসেনার সার্ভিস বান্ডেলের উচিত VMHealth রিপোর্ট শোনা এবং সম্পূর্ণ সিস্টেম আর্কিটেকচারের উপর নির্ভর করে যথাযথ ব্যবস্থা গ্রহণ করা। সম্ভাব্য ব্যবস্থাগুলোর মধ্যে নিম্নলিখিতগুলো অন্তর্ভুক্ত:
- ভিএম-এ ডায়াগনস্টিক রুটিনগুলো চালান।
- ভিএমটি পুনরায় চালু করুন।
- কারণ নির্ণয়ের জন্য একটি টেলিমেট্রি অভিযান চালান।
- সিস্টেমটি ত্রুটিপূর্ণ হলে তা আপডেট করুন অথবা আপডেট বন্ধ করুন।
এইচএম আরপিসি এপিআই
ভিএম হেলথ রিপোর্ট হলো ফ্রিকোয়েন্সি এবং ট্রান্সমিশন স্পিডের জন্য অপ্টিমাইজ করা একটি প্রকাশনা, যা সিস্টেমের স্বাস্থ্যগত অবস্থা সম্পর্কে বিস্তৃত তথ্য প্রদান করে।
HM RPC API, 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 আশা করে যে ইনস্ট্যান্সটি পর্যায়ক্রমিক হার্টবিট প্রকাশ করবে, যা প্রমাণ করবে যে বিজনেস লজিক সঠিকভাবে কাজ করছে। এই মনিটরিং সেইসব সার্ভিস বান্ডেল ইনস্ট্যান্সের জন্য সবচেয়ে উপযুক্ত, যেগুলো পর্যায়ক্রমিক কাজ সম্পাদন করে। এছাড়াও, অ্যাসিঙ্ক্রোনাস রানটাইম ব্যবহারকারী বান্ডেলগুলো থ্রেড পুল নিঃশেষ হয়ে যায়নি তা প্রমাণ করতে অ্যালাইভনেস মনিটরিং ব্যবহার করতে পারে।
চিত্র ১. এইচএম-এর সজীবতা পর্যবেক্ষণ প্রবাহ।
কনফিগারেশন
একটি সার্ভিস বান্ডেল ইনস্ট্যান্সে অ্যালাইভনেস এইচবি (HB) সক্রিয় করতে, বান্ডেল কনফিগারেশনের health_config ফিল্ডে HealthConfiguration এর একটি ইনস্ট্যান্স যোগ করুন।
একটি সচলতা হার্টবিট কনফিগারেশন পূর্বনির্ধারিত কিছু প্যারামিটার নির্ধারণ করে, যা একটি সার্ভিসের পর্যায়ক্রমিক হার্টবিট সিগন্যাল মূল্যায়নের মানদণ্ড স্থাপন করে। যদি সার্ভিস হার্টবিটের বৈশিষ্ট্যগুলো এই প্যারামিটারগুলো থেকে বিচ্যুত হয়, তবে হার্টবিটটিকে বিলম্বিত এবং সংশ্লিষ্ট সার্ভিস বান্ডেলটিকে অস্বাস্থ্যকর হিসেবে শ্রেণীবদ্ধ করা হয়, যা একটি অ-অনুকূল কার্যক্ষম অবস্থার ইঙ্গিত দিতে পারে।
একটি সার্ভিস বান্ডেলকে তখনই স্বাস্থ্যকর বলে মনে করা হয়, যখন এটি তার হেলথ কনফিগারেশন অনুযায়ী সময়মতো হার্টবিট রিপোর্ট করে। কোনো ক্র্যাশ বা উচ্চ সিস্টেম লোডের ক্ষেত্রে, হার্টবিট অনুপস্থিত থাকতে পারে বা বিলম্বিত হতে পারে, যার ফলে সার্ভিস বান্ডেলটিকে অস্বাস্থ্যকর হিসেবে চিহ্নিত করা হয়। এই ক্ষেত্রে, VmHealth রিপোর্টে একটি ভায়োলেশন দেখা যায়।
সার্ভিস বান্ডেল ডেভেলপারদের সংশ্লিষ্ট APEX মেটাডেটাতে একটি সার্ভিস বান্ডেলের হেলথ কনফিগারেশন নির্ধারণ করতে হবে। হেলথ কনফিগারেশন নিম্নলিখিত মানদণ্ডগুলো নির্ধারণ করে:
পরিষেবা শুরু এবং প্রথম হৃদস্পন্দন শনাক্তকরণের মধ্যে অনুমোদিত সর্বোচ্চ প্রাথমিক বিলম্ব।
যে সময়কালে SDV সার্ভিস বান্ডেল ব্যবসায়িক যুক্তি সম্পাদন করে, যা একটি সার্ভিস হার্টবিট প্রকাশের পর্যায়কালের সাথে সঙ্গতিপূর্ণ।
যতগুলো মেয়াদ বাদ পড়লে মহামান্য মন্ত্রী পরিষেবা প্যাকেজটিকে অস্বাস্থ্যকর বলে বিবেচনা করবেন।
এক্সিকিউশন টাইম হলো সেই সময়কাল, যা একটি SDV সার্ভিস বান্ডেলের সার্ভিস হার্টবিট প্রকাশ করার আগে তার বিজনেস লজিক সম্পাদন করতে প্রয়োজন হয়।
সার্ভিসের হার্টবিট বিলম্বিত হলে সার্ভিস বান্ডেলটি একটি হেলথ ভায়োলেশন তৈরি করে। হেলথ অবজারভেশনের সময়ের উপর ভিত্তি করে দুটি পরিস্থিতি রয়েছে:
কেস ১: প্রাথমিক হার্টবিট পাওয়া যায়নি। সার্ভিস বান্ডেল শুরু হওয়ার পর থেকে পর্যবেক্ষণের সময় পর্যন্ত যদি অনুমোদিত প্রাথমিক বিলম্বের চেয়ে বেশি সময় অতিবাহিত হয়, তবে সার্ভিস বান্ডেলটিকে অস্বাস্থ্যকর বলে গণ্য করা হয়।
কেস ২: ইতিমধ্যে হার্টবিট পাওয়া গেছে। যদি শেষ হার্টবিট এবং পর্যবেক্ষণের সময়ের মধ্যে একটি নির্দিষ্ট সীমা অতিবাহিত হয়ে যায়, তাহলে সার্ভিস বান্ডেলটিকে অস্বাস্থ্যকর বলে গণ্য করা হয়। এই সীমাটি রিপোর্টিং পিরিয়ড (পিরিয়ডের সংখ্যা দ্বারা গুণিত) এবং টাস্কের সময়কালের যোগফল হিসাবে গণনা করা হয়।
স্বাস্থ্য কনফিগারেশন ফরম্যাটটি //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 এজেন্ট বার্তার ধরন অনুযায়ী আবিষ্কার পদ্ধতি ব্যবহার করে প্রকাশনাটি শনাক্ত করে।
সংশ্লিষ্ট সার্ভিস বান্ডেল ম্যানিফেস্টে লিঙ্ক করা হেলথ কনফিগারেশনের মাধ্যমে অ্যালাইভনেস মনিটরিং কনফিগার করার সময়, HM এজেন্ট আশা করে যে ইনস্ট্যান্সটি তার on_start রুটিন শেষ করার সাথে সাথেই HB (হার্টবিট) প্রকাশিত হবে। সিস্টেম স্টার্টআপে বাধা এড়াতে আমরা on_start সময়কাল সংক্ষিপ্ত রাখার পরামর্শ দিই, তাই on_start এ শুরু করা একটি অ্যাসিঙ্ক্রোনাস টাস্কের মধ্যে হার্টবিটগুলো প্রকাশ করুন।
বান্ডেল ডেভেলপাররা initial_delay_ms কনফিগারেশন এন্ট্রি ব্যবহার করে প্রথম হার্টবিট কখন প্রত্যাশিত হবে, সেই সময়টি কাস্টমাইজ করতে পারেন।
বান্ডেল ইনস্ট্যান্সটি বন্ধ না করা পর্যন্ত হার্টবিট প্রকাশ করতে থাকবে। একটি ইনস্ট্যান্সকে বন্ধ বলে গণ্য করা হয় যখন তার on_stop রুটিনটি শেষ হয়।
বিশেষ ব্যবহার ক্ষেত্র: হৃদস্পন্দন পর্যবেক্ষণের জন্য স্পষ্টভাবে নিবন্ধন করুন
The behavior described in Aliveness heartbeats monitoring , where heartbeats are expected between on_start and on_stop , is called implicit aliveness monitoring . This is the recommended way to use the feature: it simplifies the bundle's business logic and ensures that the bundle is always monitored.
তবে, এমন কিছু ব্যবহারের ক্ষেত্র থাকতে পারে যেখানে পূর্বনির্ধারিত পর্যবেক্ষণ সময়কাল একটি সীমাবদ্ধতা হয়ে দাঁড়ায়:
- একটি সার্ভিস বান্ডেল ইনস্ট্যান্সে এমন বিজনেস লজিক থাকে যা
startএবংstopইভেন্টের সাথে সম্পর্কহীন একটি নির্দিষ্ট সময় অন্তর পর্যায়ক্রমিকভাবে ঘটে। শুধুমাত্র এই নির্দিষ্ট সময়কালেই এর সচলতা পর্যবেক্ষণের প্রয়োজন হতে পারে। - HM সাসপেন্ড এবং রিজুম সময়কাল জুড়ে HB-গুলোকে নির্ভুলভাবে ট্র্যাক করে। তাই,
on_stopপরেও বান্ডেলটির পর্যবেক্ষণ চালিয়ে যাওয়া প্রয়োজন হতে পারে। - কাস্টম OEM এজেন্টগুলো সার্ভিস বান্ডেল হিসেবে বাস্তবায়িত নাও হতে পারে। ফলে, তারা অন্তর্নিহিত অ্যালাইভনেস মনিটরিংয়ের সুবিধা নিতে পারে না। তবে, তাদের অ্যালাইভনেস মনিটরিংয়ের প্রয়োজন হতে পারে।
এইসব ক্ষেত্রে, HM আপনাকে সুস্পষ্ট রেজিস্ট্রেশনের জন্য ইমপ্লিসিট রেজিস্ট্রেশনকে বাইপাস করার সুযোগ দেয়। সুস্পষ্ট রেজিস্ট্রেশন ব্যবহার করার জন্য, একটি বান্ডেল ইনস্ট্যান্সকে তার ম্যানিফেস্টে নির্দিষ্ট ইনস্ট্যান্সটির জন্য HealthConfiguration টাইপের কোনো এন্ট্রি অন্তর্ভুক্ত না করে ইমপ্লিসিট রেজিস্ট্রেশন থেকে বেরিয়ে আসতে হবে। তারপর, রান টাইমে, বান্ডেল ইনস্ট্যান্সটিকে //system/software_defined_vehicle/health_monitor/catalog/health_monitor_registration_service.proto তে সংজ্ঞায়িত RPC API ব্যবহার করে মনিটরিং থেকে ম্যানুয়ালি রেজিস্টার এবং ডি-রেজিস্টার করতে হবে। রেজিস্ট্রেশন RPC কলটি সফল হওয়ার সাথে সাথেই প্রকাশিত হার্টবিট পাওয়া যাবে বলে আশা করা যায়।
For an example implementation, see //system/software_defined_vehicle/samples/health/stable/health_monitored_service_bundle/ .
QoS পর্যবেক্ষণ
কোয়ালিটি অফ সার্ভিস (QoS) হলো যোগাযোগের একটি পরিমাপ। HM পর্যবেক্ষণ করে যে প্রেরিত বার্তাটি পথে অতিরিক্ত সময় ব্যয় করছে কিনা, অথবা পর্যায়ক্রমিক যোগাযোগের ক্ষেত্রে, নির্বাচিত ফ্রিকোয়েন্সিতে বার্তাগুলো গৃহীত হচ্ছে কিনা।
SDV বিভিন্ন ধরনের পাব/সাব এবং আরপিসি কমিউনিকেশন প্রদান করে। এদের মধ্যে সাধারণ মিল হলো, সমস্ত কমিউনিকেশন স্কিমে অন্তত একটি লিসেনার থাকে। HM-এর কমিউনিকেশন মনিটর করার জন্য, এই লিসেনিং সার্ভিস বান্ডেল ইনস্ট্যান্সটিকে অবশ্যই বিশেষ QoS হার্টবিট পাবলিশ করতে হবে যখনই এটি কোনো গুরুত্বপূর্ণ মেসেজ গ্রহণ করে।
কনফিগারেশন
কোনো কমিউনিকেশনের QoS মনিটরিং চালু করতে, প্রথমে সেই কমিউনিকেশন লিসেনারটি শনাক্ত করুন যেটি QoS হার্টবিট প্রকাশ করবে। তারপর, শনাক্তকৃত সার্ভিস বান্ডেল ইনস্ট্যান্সটির জন্য, qos_config ফিল্ডের QosMonitoringConfiguration ম্যাপিং-এ এক বা একাধিক টপিক যোগ করুন। আরও তথ্যের জন্য, প্রতি-সার্ভিস বান্ডেল কনফিগারেশন দেখুন।
টপিক হলো একটি স্ট্রিং যা পাবলিকেশন টপিককে সংজ্ঞায়িত করে, যেখানে 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 হওয়া যুক্তিসঙ্গত।
রান টাইম বিবেচনা
অ্যালাইভনেস এইচবি মনিটরিং-এর মতোই, কমিউনিকেশন লিসেনিং বান্ডেল থেকেও এক ধরনের হার্টবিট প্রকাশ করার কথা। এক্ষেত্রে, বিজনেস লজিক এক্সিকিউশন শেষ হওয়ার পরিবর্তে, যখনই কোনো গুরুত্বপূর্ণ মেসেজ পাওয়া যাবে, তখনই একটি 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 প্রত্যাশা করে। যখন পর্যবেক্ষণাধীন যোগাযোগটি SDV কমিউনিকেশন স্ট্যাকে নিবন্ধিত হয়, তখন মেসেজ লিসেনিং বান্ডেলটির উচিত QoS HB পাবলিকেশনটি নিবন্ধন করা। এটি করার জন্য HM অ্যাভেইলেবিলিটি API ব্যবহার করতে পারে। আরও তথ্যের জন্য, ‘পরিষেবার প্রাপ্যতা নির্ধারণ’ দেখুন।
পরিষেবা বান্ডেল পুনরুদ্ধার পর্যবেক্ষণ
সার্ভিস বান্ডেল ইনস্ট্যান্সের পুনরুদ্ধার অর্কেস্ট্রেশন এজেন্ট কনফিগারেশন ফাইলের অংশ হিসেবে কনফিগার করা হয়। এই বিষয়ে বিস্তারিত আলোচনার জন্য, সার্ভিস বান্ডেলস দেখুন। HM সাবসিস্টেম নিষ্ক্রিয়ভাবে পুনরুদ্ধার প্রক্রিয়াটি পর্যবেক্ষণ করে। যখন কোনো বান্ডেল ইনস্ট্যান্স পুনরুদ্ধারে ব্যর্থতা শনাক্ত করা হয়, তখন VMHealth রিপোর্টে একটি ভায়োলেশন যোগ করা হয়। HM-এর অন্যান্য পর্যবেক্ষণ ক্ষমতার বিপরীতে, পুনরুদ্ধার পর্যবেক্ষণ বাধ্যতামূলক এবং এটি কনফিগারযোগ্য নয়।
যেসব সার্ভিস বান্ডেল ইনস্ট্যান্স রিকভারির জন্য কনফিগার করা নেই, সেগুলোর প্রথম ক্র্যাশেই একটি হেলথ ভায়োলেশন তৈরি হয়।
সার্ভিস বান্ডেল ইনস্ট্যান্স রিকভারি হার্টবিট অ্যালাইভনেস মনিটরিং-এর সাথে সমন্বিত করার জন্য ডিজাইন করা হয়েছে। বান্ডেলটি রিকভার হচ্ছে এমনটা শনাক্ত করলে, HM সিস্টেম হার্টবিট মূল্যায়নের ক্ষেত্রে আরও নমনীয় হয়। বাস্তবে, এই নমনীয়তার অর্থ হলো, সার্ভিস বান্ডেলগুলো ক্র্যাশ করলে সেগুলোকে কোনো অতিরিক্ত মনিটরিং ডি-রেজিস্ট্রেশন বা রেজিস্ট্রেশন পদক্ষেপ নিতে হয় না।
এজেন্ট ক্র্যাশ পর্যবেক্ষণ
HM, বাইন্ডার linkToDeath মেকানিজম ব্যবহার করে SDV এজেন্টদের সম্ভাব্য ক্র্যাশ শনাক্ত করে।
আপনি ভিএম হেলথ কনফিগারেশনের অংশ হিসেবে ক্র্যাশ মনিটরিং কনফিগার করতে পারেন (দেখুন প্রতি-এসডিভি ইনস্ট্যান্স (ভিএম) কনফিগারেশন ), বিশেষত monitored_agent রিপিটেড ফিল্ডের মাধ্যমে। এই ফিল্ডটিতে 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 ফিচারগুলি কীভাবে ব্যবহার করতে হয় তার ধাপে ধাপে নির্দেশিকা দেওয়া হয়েছে। এই নির্দেশিকাগুলি যে হালনাগাদ রেফারেন্স স্যাম্পলের উপর ভিত্তি করে তৈরি, সেটি হলো qos_monitoring স্যাম্পল। ব্যবহারিক অভিজ্ঞতার জন্য স্যাম্পলটির //system/software_defined_vehicle/samples/health/stable/qos_monitoring/README অনুসরণ করুন।
একটি পরিষেবা বান্ডেলে জীবন্ত হৃদস্পন্দন পর্যবেক্ষণ যোগ করুন
এই পদ্ধতিটি একটি সার্ভিস বান্ডেলের জন্য স্বাস্থ্য পর্যবেক্ষণ সক্রিয় করার সবচেয়ে সরাসরি উপায়:
health_configuration.textprotoনামের একটি ফাইলে বান্ডেল ইনস্ট্যান্সগুলোর জন্যServiceBundleHealthConfigurationএর একটি ইনস্ট্যান্স সংজ্ঞায়িত করুন:# 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 { ... } } }সার্ভিস বান্ডেল 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"], }APEX-এ হেলথ কনফিগারেশন সংরক্ষণ করুন এবং ম্যানিফেস্টে
health_config_pathসেট করুন:# sdv_service_bundles_manifest.textproto sdv_service_bundle_metadata { ... health_config_path: "etc/config/health_configuration.textproto" }VSIDL সংজ্ঞায়, নিশ্চিত করুন যে বান্ডেলটি
com.android.sdv.health.ServiceHeartbeatপ্রকাশ করে:sdv_service_bundle { name: "SampleBundle" publisher { message: "com.android.sdv.health.ServiceHeartbeat" topic: "arbitrary-topic" capacity: 2 } }বান্ডেলটিতে SDV অনুমতি যোগ করুন যাতে বান্ডেলটি HB প্রকাশ করার জন্য অনুমোদিত হয়:
publisher { type: "com.android.sdv.health.ServiceHeartbeat" }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 অবস্থার আগে শুরু হওয়া বা পরে শেষ হওয়া পর্যবেক্ষণ করা), সেখানে আপনি এক্সপ্লিসিট রেজিস্ট্রেশন পদ্ধতিটি ব্যবহার করতে পারেন:
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" } }জীবন্ততা এইচবি রেজিস্ট্রেশন আরপিসি ব্যবহারের জন্য এসডিভি অনুমতি যোগ করুন:
# ... client { service: "com.android.sdv.health.HealthMonitorRegistrationService" channel: "com-android-sdv-health-health-monitor-registration-service" }RPC-এর মাধ্যমে HM-এর সাথে নিবন্ধন করুন, উদাহরণস্বরূপ,
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();এইচবি প্রকাশ করুন।
প্রয়োজন ফুরিয়ে গেলে পর্যবেক্ষণ থেকে নিবন্ধন বাতিল করুন:
let _ = rpc_client .UnregisterConfiguration(&UnregisterConfigurationRequest { ..Default::default() }) .await .unwrap();
যোগাযোগে QoS মনিটরিং যোগ করুন
যাচাই করুন যে সার্ভিস বান্ডেল ইনস্ট্যান্সটি VSIDL ক্যাটালগে
fog-light-statusনামের একটি টপিকের সাবস্ক্রাইবার: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; }health_configuration.textprotoফাইলে QoS মনিটরিং অন্তর্ভুক্ত বান্ডেল ইনস্ট্যান্সগুলির জন্যServiceBundleHealthConfigurationএর একটি ইনস্ট্যান্স সংজ্ঞায়িত করুন:# 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নামক একটি টপিক মনিটর করা যাবে।সার্ভিস বান্ডেল 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"], }APEX-এ হেলথ কনফিগারেশন সংরক্ষণ করুন এবং ম্যানিফেস্টে
health_config_pathসেট করুন:# sdv_service_bundles_manifest.textproto sdv_service_bundle_metadata { ... health_config_path: "etc/config/health_configuration.textproto" }আপনার 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 } }বান্ডেলটিতে SDV অনুমতি যোগ করুন যাতে বান্ডেলটি QoS HB প্রকাশ করার জন্য অনুমোদিত হয়:
publisher { message: "com.android.sdv.health.QosHeartbeat" topic: "qos-hb-right-fog-light-status" }শুধুমাত্র যখন মনিটর করা কমিউনিকেশনটি রেজিস্টার করা হয়, তখনই QoS HB পাবলিকেশনটি রেজিস্টার করুন।
libsdv_mw_clientlibথেকে অ্যাভেইলেবিলিটি API ব্যবহার করুন:// 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?; // ...প্রতিবার বার্তা প্রাপ্ত হলে QoS HB প্রকাশ করুন:
// ... 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 // ... } }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
----------------