Method, apparatus, device and computer readable storage medium for checking a service

Abstract

Embodiments of the present disclosure relate to methods, apparatuses, devices and computer readable storage media for checking services. A method for checking services comprises: obtaining historical data associated with a set of historical requests for a service in a first time period; determining, based on the historical data, a checking policy for the service in a second time period, the checking policy indicating at least a checking time for checking the service; and causing a check to be performed based on the checking policy. In the present disclosure, the checking policy for the service in a subsequent time period is determined based on the historical data associated with the historical requests for the service, so that the checking policy is adaptively adjusted to proactively detect the health status of the service.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure relate to the field of computers, and more specifically, to methods, apparatuses, devices and computer-readable storage media for checking a service. BACKGROUND

[0002] With the continuous development of the Internet of Vehicles, a Telematics Service Provider (TSP) platform usually relies on many external content providers or service providers, which may exist the case of unstable downstream services. Even if a Service Level Agreement (SLA) is signed with the service provider, it cannot guarantee that the service provided by the service provider will not be problematic.

[0003] Currently, the conventional solution for checking a service is so-called timing heartbeat detection, i.e., to detect the health status of the service at a predetermined time interval. Generally, the frequency of use of different services by users is not the same, so it is difficult for the conventional solution to accurately detect the health status of the service in advance. SUMMARY

[0004] According to an example embodiment of the present disclosure, a solution for checking a service is provided. The solution determines a checking policy for the service in a subsequent time period based on historical data associated with historical requests for the service, thereby realizing adaptive adjustment of the checking policy to detect the health status of the service in advance.

[0005] In a first aspect of the present disclosure, a method for checking a service is provided. The method comprises: obtaining historical data associated with a set of historical requests for the service in a first time period; determining, based on the historical data, a checking policy for the service in a second time period, the checking policy indicating at least a checking time for checking the service; and causing the checking to be performed based on the checking policy.

[0006] In some embodiments, the historical data indicates a set of request times associated with the set of historical requests, and determining the checking policy comprises: dividing the set of historical requests into a plurality of historical request subsets based on a time distribution of the set of request times; determining a checking frequency for checking the service based on the plurality of historical request subsets; and determining the checking time for checking the service based on the checking frequency.

[0007] In some embodiments, determining the checking time comprises: determining, based on the set of request times, a first historical request that is earliest in each of the plurality of historical request subsets; and determining the checking time based on the checking frequency and a first request time associated with the first historical request.

[0008] In some embodiments, the method further includes performing the checking for the service by: sending a probe packet to a remote device associated with the service; and determining availability of the service based on a response result associated with the probe packet.

[0009] In some embodiments, the service is a target service, and the method further includes determining the target service from a set of candidate services based on provisioning state data associated with provisioning states of the set of candidate services, the provisioning state of the target service indicating that the target service has been provisioned.

[0010] In some embodiments, other candidate services in the set of candidate services except the target service are non-target services, and the method further includes causing the checking for the non-target services to be performed based on a predetermined first checking policy.

[0011] In some embodiments, the method further includes providing warning information in response to the service exception.

[0012] In a second aspect of the present disclosure, an apparatus for checking a service is provided. The apparatus includes: a historical data obtaining module configured to obtain historical data associated with a set of historical requests for the service in a first time period; a checking policy determining module configured to determine a checking policy for the service in a second time period based on the historical data, the checking policy indicating at least a checking time for checking the service; and a first control module configured to cause the checking to be performed based on the checking policy.

[0013] In some embodiments, the historical data indicates a set of request times associated with the set of historical requests, and the checking policy determining module includes: a historical request dividing module configured to divide the set of historical requests into a plurality of historical request subsets based on a time distribution of the set of request times; a checking frequency determining module configured to determine a checking frequency for checking the service based on the plurality of historical request subsets; and a first checking time determining module configured to determine the checking time for checking the service based on the checking frequency.

[0014] In some embodiments, the first checking time determining module includes: a first historical request determining module configured to determine a first historical request in each of the plurality of historical request subsets based on the set of request times; and a second checking time determining module configured to determine the checking time based on the checking frequency and a first request time associated with the first historical request.

[0015] In some embodiments, the apparatus further includes a probe packet sending module configured to send a probe packet to a remote device associated with the service; and an availability determining module configured to determine the availability of the service based on a response result associated with the probe packet.

[0016] In some embodiments, the service is a target service, and the apparatus further includes a target service determining module configured to determine the target service from a group of candidate services based on activation state data associated with activation states of the group of candidate services, the activation state of the target service indicating that the target service has been activated.

[0017] In some embodiments, other candidate services in the group of candidate services except the target service are non-target services, and the apparatus further includes a second control module configured to cause the checking for the non-target services to be performed based on a predetermined first checking policy.

[0018] In some embodiments, the apparatus further includes a warning information providing module configured to provide warning information in response to the service exception.

[0019] In a third aspect of the present disclosure, there is provided an apparatus for checking a service, comprising: at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions, when executed by the at least one processing unit, causing the apparatus to perform the method according to the first aspect of the present disclosure.

[0020] In a fourth aspect of the present disclosure, there is provided a computer-readable storage medium having stored thereon a computer program which, when executed by an apparatus, causes the apparatus to perform the method according to the first aspect of the present disclosure.

[0021] It can be seen from the above description that, according to the scheme for checking a service of embodiments of the present disclosure, a checking policy for a service in a subsequent time period is determined based on historical data associated with historical requests for the service. Compared with a conventional timing heartbeat check, by considering historical request data to dynamically determine a checking policy, the checking policy can be adaptively adjusted to detect the health status of the service in advance, so that the entire checking mechanism is more efficient and accurate, thereby guaranteeing good user experience and driving comfort.

[0022] It should be understood that the content described in the summary section is not intended to define key or important features of the embodiments of the present disclosure, nor to limit the scope of the present disclosure. Other features of the present disclosure will become apparent through the following description. BRIEF DESCRIPTION OF DRAWINGS

[0023] The above-described and other features, advantages, and aspects of the present disclosure will become more apparent as various embodiments of the present disclosure are described in greater detail below. Like reference numerals can refer to like elements throughout the description of the drawings. The drawings of the present disclosure are schematic representations for purposes of the explanation of certain embodiments thereof and are not intended to limit the scope of the present disclosure, unless otherwise specified herein.

[0024] Figure 1 a block diagram illustrating an example environment, in accordance with some embodiments of the present disclosure is shown;

[0025] Figure 2 a flow diagram illustrating a method for checking a service, in accordance with some embodiments of the present disclosure is shown;

[0026] Figure 3 a flow diagram illustrating a method for determining a checking policy, in accordance with some embodiments of the present disclosure is shown;

[0027] Figure 4 a block diagram illustrating an example apparatus for checking a service, in accordance with some embodiments of the present disclosure is shown; and

[0028] Figure 5 a schematic block diagram illustrating an example device that can be used to implement some embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0029] Embodiments of the present disclosure will be described below in greater detail with reference to the accompanying drawings. While certain embodiments of the present disclosure are shown in the drawings, it is understood that the present disclosure can be embodied in various forms and should not be interpreted as being limited to the embodiments set forth herein, but rather the embodiments are provided so as to more thoroughly and completely understand the present disclosure. It is understood that the drawings and embodiments of the present disclosure are for exemplary purposes only and are not intended to limit the scope of the present disclosure.

[0030] In the description of embodiments of the present disclosure, the term “includes” and its variants are to be read as open-ended terms that mean “comprises.” The term “based on” is to be interpreted as “based, at least in part, on.” The term “one embodiment” or “the embodiment” are to be interpreted as “at least one embodiment.” The terms “first,” “second,” etc. can refer to different or the same objects. Other explicit or implicit definitions can also be included below.

[0031] As described above, for a conventional TSP platform, there is usually a case of instability of downstream services. If service exceptions cannot be discovered in time, it will greatly affect the user's use experience and reduce the user's driving comfort. Known solutions usually detect the health status of services at predetermined time intervals. However, since the usage frequency of different services is often not the same and can change over time, it is difficult for such solutions to accurately detect the health status of services in advance.

[0032] Embodiments of this disclosure provide a scheme for inspecting services to address one or more of the aforementioned problems and other potential issues. In this disclosure, an inspection strategy for the service is determined based on historical data associated with historical requests for the service over subsequent time periods. Compared to conventional periodic heartbeat checks, dynamically determining the inspection strategy by considering historical request data allows for adaptive adjustment of the strategy to proactively detect the health status of the service, making the entire inspection mechanism more efficient and accurate, thereby ensuring a good user experience and driving comfort.

[0033] The following description will continue with reference to the accompanying drawings, which will provide some exemplary embodiments of this disclosure.

[0034] Figure 1 A block diagram of an example environment according to some embodiments of the present disclosure is shown. Figure 1 As shown, the example environment 100 can generally include vehicles 110, users 120, and service providers 170.

[0035] like Figure 1 As shown, user 120 can be carried by vehicle 110, and can be, for example, the driver or passenger of vehicle 110. Although in Figure 1 In this embodiment, user 120 is shown as the driver of a vehicle, but vehicle 110 may also include any suitable type of motor vehicle or non-motor vehicle, examples of which include, but are not limited to, cars, sedans, trucks, buses, electric vehicles, motorcycles, etc. However, it should be understood that a vehicle is merely one example of vehicle 110. Embodiments of this disclosure are equally applicable to other vehicles 110 besides vehicles, such as boats, trains, etc. In some embodiments, user 120 may also be other occupants of vehicle 110. It should be understood that... Figure 1 The environment 100 shown is merely exemplary, and the scheme for inspecting services according to embodiments of this disclosure can also be applied to other suitable environments. The scope of this disclosure is not limited in this respect.

[0036] like Figure 1As shown, the vehicle 110 has a center console 140 with a touch screen. The user 120 can use services provided by the service provider 170, for example, by operating the touch screen. In the context of the present disclosure, the service provider 170 represents a provider of Internet service content, application services, and the like. Examples of the service provider 170 include, but are not limited to, a music content provider, a weather information provider, a navigation service provider, and a violation query service provider, among others. The scope of the present disclosure is not limited in this respect. The user 120 can initiate a request 150 to the service provider 170 by operating the center console 140, and can receive data 160 from the service provider 170. It should be appreciated that the user 120 can also use services provided by the service provider 170 with the aid of a device such as a mobile phone, a personal digital assistant, and the like. The scope of the present disclosure is not limited in this respect.

[0037] Figure 2 A flowchart of a method 200 for inspecting a service according to some embodiments of the present disclosure is shown. For example, the method 200 can be performed by the electronic device 130 as shown. In some embodiments, the electronic device 130 can be a device having a computing function such as an electronic control unit, a personal computer, a workstation, a server, and the like. It should be appreciated that, although the electronic device 130 is shown to be located within the vehicle 110 in Figure 1 Figure 1 It should be appreciated that the method 200 can also include additional blocks not shown, and / or the blocks shown can be omitted. The scope of the present disclosure is not limited in this respect.

[0038] At block 202, the electronic device 130 obtains historical data associated with a set of historical requests for the service over a first time period.

[0039] In some embodiments, the electronic device 130 can be communicatively coupled to a recording device (not shown) for recording request data associated with the request 150 for the service, for example. The recording device can be located within the vehicle 110, for example. The scope of the present disclosure is not limited in this respect. Figure 1 ​For example, after the user 120 opens the service, the user 120 uses the application corresponding to the service, and triggers the request 150 for the service, the recording device can record the timestamp corresponding to the corresponding request 150, the data amount, and the like. The electronic device 130 can obtain the historical data associated with the set of historical requests for the service in the first time period from the recording device by sending a request to the recording device. In some embodiments, the electronic device 130 itself can also be configured to record the request data for the service to obtain the historical data. It should be understood that the data associated with the historical requests can also be recorded and provided by any other suitable device, and the electronic device 130 can obtain the historical data from the device, and the scope of the present disclosure is not limited in this respect.

[0040] In some embodiments, the first time period is a past period of time, and can have a predetermined length of time. The first time period is, for example, the most recent day, the most recent week, the most recent 30 days, or the most recent natural month, and the like. In some embodiments, the first time period can be selected and set by the user 120. The scope of the present disclosure is not limited in this respect.

[0041] In some embodiments, the historical data obtained by the electronic device 130 can include timestamp information of the set of historical requests in the first time period, to indicate a set of request instants associated with the set of historical requests. It should be noted that in the context of the present disclosure, the request instant only contains specific time information, and does not contain date information. For example, the timestamp information of 19:22 on September 2 corresponds to the request instant of 19:22, and the timestamp information of 19:22 on September 11 also corresponds to the request instant of 19:22. In some embodiments, the historical data obtained by the electronic device 130 can also include success information or failure information of the historical requests. It should be understood that the historical data obtained by the electronic device 130 can also include any other suitable information, and the scope of the present disclosure is not limited in this respect.

[0042] In block 204, the electronic device 130 determines, based on the historical data, a checking policy for the service in a second time period, the checking policy indicating at least a checking time for checking the service. In some embodiments, the second time period is a future period of time, and can have a predetermined length of time. The second time period is, for example, a future day, a future week, a future 30 days, and the like. In some embodiments, the second time period can be selected and set by the user 120. The scope of the present disclosure is not limited in this respect.

[0043] In some embodiments, the electronic device 130 can determine the checking policy based on the time distribution of the obtained historical data. This will be described below in conjunction with FIG. 3. Figure 3Further details are described in further detail.

[0044] In some embodiments, over time, the electronic device 130 can determine the inspection policy corresponding thereto based on the obtained updated historical data, so as to update the inspection policy. In this way, the method according to the present disclosure can achieve dynamically determining the inspection policy, so as to adaptively adjust the inspection policy, so that the entire inspection mechanism is more efficient and accurate, thereby guaranteeing good user experience and driving comfort.

[0045] In some embodiments, for different services, the electronic device 130 can determine the inspection policy for the corresponding service based on the historical data associated with the corresponding service. In this way, the method according to the present disclosure can provide personalized inspection policies for different services, and support inspection requirements with greater flexibility.

[0046] At block 206, the electronic device 130 causes the inspection to be performed based on the inspection policy. In some embodiments, the electronic device 130 itself can perform the inspection for the service based on the determined inspection policy.

[0047] In some embodiments, the electronic device 130 can start and execute a scheduled task for performing the inspection based on the determined inspection policy. In the context of the present disclosure, the scheduled task represents a persistent periodic task. For example, the electronic device 130 can start and execute a scheduled task for performing the inspection for the navigation service at 7 am every day based on the inspection policy. In some embodiments, the electronic device 130 can update the scheduled task in real time as the inspection policy is updated, to ensure that the inspection is always performed based on the latest inspection policy. It should be understood that the electronic device 130 can also perform the inspection based on the inspection policy in any other suitable manner, and the scope of the present disclosure is not limited in this respect.

[0048] In some embodiments, the electronic device 130 can send a probe packet to a remote device (e.g., a server of the service provider 170) associated with the service. The electronic device 130 can determine the availability of the service based on a response result associated with the probe packet. In one example, the electronic device 130 receives information indicating that the service is available from the remote device after sending the probe packet. In this case, the electronic device 130 can determine that the service is available. In another example, the electronic device 130 receives information indicating that the service is busy from the remote device after sending the probe packet. In this case, the electronic device 130 can determine that the service is temporarily unavailable, and can resend the probe packet to the remote device after a certain time (e.g., 60 seconds). In yet another example, the electronic device 130 does not receive feedback information from the remote device within a predetermined time period (e.g., 45 seconds) after sending the probe packet. In this case, the electronic device 130 can determine that the service is abnormal. In this way, the electronic device 130 can effectively check the availability of the service so as to ensure that the service is available when the user 120 uses the service as much as possible, thereby improving the user experience and driving comfort. In some embodiments, the electronic device 130 can perform the check for the service by means of a Telnet command based on a domain name and a port, a Ping command based on an IP, a Call command based on a specific function of the service, or a combination thereof. It should be understood that the electronic device 130 can also perform the check for the service by means of any other suitable command, and the scope of the present disclosure is not limited in this respect.

[0049] In some embodiments, the electronic device 130 can provide warning information in response to the service being abnormal. In one example, the electronic device 130 can send warning information prompting the service being abnormal to the TSP, so that the TSP can take a quick reaction mechanism, troubleshoot the source of the fault, and take measures in time to restore the service as soon as possible. In another example, the electronic device 130 can send warning information prompting the service being abnormal to the service provider 170, so that the service provider 170 can be informed in time that the user 120 cannot receive its service or content, and take corresponding measures. It should be understood that the electronic device 130 can also provide warning information to any other relevant object, and the scope of the present disclosure is not limited in this respect. In this way, after discovering that the service is abnormal, the relevant parties can be informed in time to take effective measures to restore the service as soon as possible, thereby reducing or even avoiding the impact on the user 120 using the service. Thus, the user experience can be further guaranteed, and the driving comfort can be improved.

[0050] In some embodiments, the electronic device 130 can be communicatively coupled to a checking device (e.g., a server of the service provider 170) for performing the check Figure 1(Not shown in the image). Electronic device 130 can provide the determined inspection strategy to the inspection equipment via wired or wireless transmission. Electronic device 130 can further control the inspection equipment to perform inspections on the service. It should be understood that inspections can also be performed based on the inspection strategy in any other suitable manner, and the scope of this disclosure is not limited in this respect.

[0051] In some embodiments, the electronic device 130 may also acquire activation status data associated with the activation status of a set of candidate services. The activation status data indicates whether each candidate service has been activated. In this disclosure, if a service is activated by user 120 and then deactivated by user 120, the activation status of that service will indicate that the service has not yet been activated. The electronic device 130 may determine a target service from a set of candidate services based on the activation status data, the activation status of which indicates that the target service has been activated. For the determined target service, the electronic device 130 may execute the service inspection method according to this disclosure to determine an inspection strategy and perform an inspection of the target service.

[0052] In some embodiments, electronic device 130 can identify candidate services other than the target service from a set of candidate services as non-target services. Electronic device 130 can perform checks on non-target services based on a pre-determined first check strategy. In some embodiments, the first check strategy can be a regular timed heartbeat check, i.e., probing the service status at predetermined time intervals (e.g., one hour). In some embodiments, the first check strategy for non-target services can also be pre-determined by user 120. It should be understood that the first check strategy can also be any other suitable check strategy, and the scope of this disclosure is not limited in this respect. Electronic device 130 can perform checks on non-target services based on the first check strategy in a manner similar to that described above in conjunction with the check strategy, which will not be repeated here. In this way, the method according to this disclosure can provide personalized check strategies for different services and support check needs with greater flexibility, making the entire check mechanism more efficient and accurate, thereby ensuring a good user experience and driving comfort.

[0053] Figure 3 A flowchart of a method 300 for determining an inspection strategy according to some embodiments of the present disclosure is shown. For example, method 300 may be as follows: Figure 2 An example implementation of the box 202 shown. In some embodiments, method 300 may be provided by, for example... Figure 1 The illustrated electronic device 130 performs this action. It should be understood that method 300 may also include additional boxes not shown and / or the boxes shown may be omitted, and the scope of this disclosure is not limited in this respect.

[0054] At block 302, the electronic device 130 divides a set of historical requests into a plurality of historical request subsets based on a time distribution of a set of request instants. In some embodiments, the electronic device 130 can obtain the time distribution of the set of request instants by marking the request instants of the historical requests on a time axis. As described above, the request instants only contain specific time information, but not date information. Therefore, in the case that the length of the first time period is greater than 24 hours, for example, the first time period is a week or a month, the request instants corresponding to the historical requests in different dates will be located on the same 24-hour time axis. In this way, the usage behavior of the user 120 in different dates can be considered comprehensively. Based on the time distribution, the electronic device 130 can cluster the plurality of historical requests so as to divide the plurality of historical requests into the plurality of historical request subsets.

[0055] In some embodiments, the electronic device 130 can cluster the plurality of historical requests based on a predetermined time threshold. Illustratively, if the time interval of two adjacent request instants on the time axis is less than or equal to the predetermined time threshold, the electronic device 130 can divide the historical requests corresponding to the two adjacent request instants into the same historical request subset; if the time interval of two adjacent request instants on the time axis is greater than the predetermined time threshold, the electronic device 130 can divide the historical requests corresponding to the two adjacent request instants into two different historical request subsets.

[0056] In one example, a set of request instants corresponding to a set of historical requests for the information service in the first time period is {9:12, 9:52, 10:58, 11:38, 12:15}. Taking 1 hour as the predetermined time threshold, since the time interval between 9:12 and 9:52 is less than 1 hour, the historical requests corresponding to the two request instants can be divided into the same historical request subset; the time interval between 9:52 and 10:58 is greater than 1 hour, so the historical requests corresponding to the two request instants are divided into two different historical request subsets; the time interval between 10:58 and 11:38 is less than 1 hour, so the historical requests corresponding to the two request instants can be divided into the same historical request subset; and the time interval between 11:38 and 12:15 is less than 1 hour, so the historical requests corresponding to the two request instants can be divided into the same historical request subset. In this way, the set of historical requests is divided into two historical request subsets. The request instant sets corresponding to the two historical request subsets are {9:12, 9:52} and {10:58, 11:38, 12:15}, respectively.

[0057] It should be appreciated that the predetermined time threshold can also be any other suitable value, and that the historical requests can also be partitioned in any other suitable manner, the scope of the disclosure not being limited in this respect.

[0058] At block 304, the electronic device 130 determines a check frequency for checking the service based on the plurality of historical request subsets. In some embodiments, the electronic device 130 can determine a single-day expected usage frequency based on the number of historical request subsets. For example, when there are 3 historical request subsets, the single-day expected usage frequency is 3 times a day.

[0059] In some embodiments, the electronic device 130 can determine the check frequency for checking the service according to the single-day expected usage frequency. The electronic device 130, for example, can determine the check frequency to be the same as the single-day expected usage frequency. For example, the electronic device 130 determines that the single-day expected usage frequency of the user 120 for the music service is 2 times a day, the electronic device 130 can set the check frequency for checking the music service to be 2 times a day. It should be appreciated that the check frequency can also be determined in any other suitable manner, the scope of the disclosure not being limited in this respect.

[0060] At block 306, the electronic device 130 determines a check time for checking the service based on the check frequency. In some embodiments, the electronic device 130 can determine, based on the set of request times, a first historical request that is the earliest in each of the plurality of historical request subsets. For example, if the historical requests in one of the historical request subsets correspond to request times that are distributed between 9:20 and 10:12, the electronic device 130 can determine the historical request that corresponds to 9:20 as the first historical request.

[0061] In some embodiments, the electronic device 130 can determine the check time based on the check frequency and a first request time associated with the first historical request. In some embodiments, the electronic device 130 can set the check time to be a predetermined time length, e.g., 15 minutes, earlier than the first request time. In one example, the plurality of historical requests for the music service are distributed between 8:10 and 8:50 and between 18:20 and 19:10 each day, the electronic device 130 can partition the historical requests into two different historical request subsets. The electronic device 130 can determine the first request times corresponding to the earliest first historical requests for the two historical request subsets, i.e., 8:10 and 18:20, respectively. The electronic device 130 can set the check frequency to be twice a day, and set the check time for the music service to be 7:55 and 18:05 each day based on the first request times.

[0062] By setting the check time slightly earlier than the first request time, on the one hand, the time when the user 120 uses the corresponding service can be predicted based on the historical data, so that the service is checked before the user 120 uses the corresponding service, and on the other hand, a certain processing time is reserved for the case where the service is abnormal, so as to ensure that the service is restored to be available when the user 120 uses the service as much as possible, thereby ensuring good user experience.

[0063] From the above description in combination with Figures 1 to 3 the drawings, it can be seen that the method for checking a service according to the present disclosure can determine a check strategy for the service in a subsequent time period based on historical data associated with historical requests for the service. Compared with the conventional timing heartbeat check, by considering the historical request data to dynamically determine the check strategy, the check strategy can be adaptively configured to detect the health status of the service in advance, so that the entire checking mechanism is more efficient and accurate, thereby ensuring good user experience and driving comfort.

[0064] In the foregoing, an example implementation of the method according to the present disclosure has been described in detail with reference to Figures 1 to 3 In the following, an implementation of a corresponding apparatus will be described.

[0065] Figure 4 A block diagram of an example apparatus 400 for checking a service according to some embodiments of the present disclosure is shown. The apparatus 400 may, for example, be used to implement an electronic device as shown in Figure 1 The apparatus 400 can include a historical data obtaining module 402 configured to obtain historical data associated with a set of historical requests for a service in a first time period. The apparatus 400 can also include a check strategy determining module 404 configured to determine, based on the historical data, a check strategy for the service in a second time period, the check strategy indicating at least a check time for checking the service. In addition, the apparatus 400 can also include a first control module 406 configured to cause the checking to be performed based on the check strategy.

[0066] In some embodiments, the historical data indicates a set of request times associated with the set of historical requests, and the check strategy determining module 404 includes: a historical request dividing module configured to divide the set of historical requests into a plurality of historical request subsets based on a time distribution of the set of request times; a check frequency determining module configured to determine, based on the plurality of historical request subsets, a check frequency for checking the service; and a first check time determining module configured to determine, based on the check frequency, the check time for checking the service.

[0067] In some embodiments, the first check time determination module comprises: a first historical request determination module configured to determine, based on the set of request time instants, a first historical request that is earliest in each of the plurality of historical request subsets; and a second check time determination module configured to determine, based on the check frequency and a first request time instant associated with the first historical request, the check time.

[0068] In some embodiments, the apparatus 400 further comprises: a probe packet sending module configured to send a probe packet to a remote device associated with the service; and an availability determination module configured to determine the availability of the service based on a response result associated with the probe packet.

[0069] In some embodiments, the service described above is a target service, and the apparatus 400 further comprises: a target service determination module configured to determine, based on the activation state data associated with the set of candidate services, the target service from the set of candidate services, the activation state of the target service indicating that the target service has been activated.

[0070] In some embodiments, the other candidate services in the set of candidate services except the target service are non-target services, and the apparatus 400 further comprises: a second control module configured to cause the check for the non-target services to be performed based on the predetermined first check policy.

[0071] In some embodiments, the apparatus 400 further comprises: a warning information providing module configured to provide warning information in response to the service exception.

[0072] The modules and / or units included in the apparatus 400 can be implemented in various ways, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more units can be implemented using software and / or firmware, e.g., machine-executable instructions stored on a storage medium. In addition to or instead of machine-executable instructions, part or all of the units included in the apparatus 400 can be implemented at least partly in hardware logic components. As examples and not by way of limitation, hardware logic components can include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-chips (SOCs), complex programmable logic devices (CPLDs), etc.

[0073] Figure 4 The modules and / or units illustrated in FIG. 4 can be implemented as, included in, or hosted by hardware modules, software modules, firmware modules, or any combination thereof. In particular, in some embodiments, the procedures, methods, or processes described above can be implemented by hardware of a storage system or a host corresponding to the storage system or other computing devices independent of the storage system.

[0074] Figure 5 A schematic block diagram of an example device 500 that can be used to implement some embodiments of the present disclosure is shown. The device 500 can be used to implement an electronic device as shown. Figure 1 Figure 5 As shown, the device 500 includes a central processing unit (CPU) 501 that can perform various suitable actions and processes in accordance with computer program instructions stored in a read-only memory (ROM) 502 or computer program instructions loaded into a random access memory (RAM) 503 from a storage unit 508. Various programs and data used by the device 500, in addition to the computer program instructions, can also be stored in the RAM 503. The CPU 501, the ROM 502, and the RAM 503 are connected to each other by a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0075] A plurality of components in the device 500 are connected to the I / O interface 505, including: an input unit 506, such as a keyboard, a mouse, etc.; an output unit 507, such as various types of displays, speakers, etc.; a storage unit 508, such as a magnetic disk, a magneto-optical disk, etc.; and a communication unit 509, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 509 allows the device 500 to exchange information / data with other devices through a computer network, such as the Internet, and / or various telecommunication networks.

[0076] The processing unit 501 performs various methods and processes described above, such as the method 200. For example, in some embodiments, the method 200 can be implemented as a computer software program that is tangibly embodied in a machine-readable medium, such as the storage unit 508. In some embodiments, part or all of the computer program can be loaded and / or installed on the device 500 via the ROM 502 and / or the communication unit 509. When the computer program is loaded into the RAM 503 and executed by the CPU 501, one or more steps of the method 200 described above can be performed. Alternatively, in other embodiments, the CPU 501 can be configured to perform the method 200 by any other suitable means, such as by means of firmware.

[0077] The functionality described herein above can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, example types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.

[0078] ​Program code for carrying out methods of the present disclosure can be written in any combination of one or more programming languages. The program code can be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the program code, when executed by the processor or controller, causes the machine to perform the functions / acts specified in the flowcharts and / or block diagrams. The program code can be executed entirely on a machine, partially on a machine, partially on a machine and partially on a remote machine or entirely on a remote machine or server.

[0079] In the context of the present disclosure, a machine-readable medium can be a tangible medium that contains or stores program code for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium would include one or more lines of a system, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0080] Moreover, while operations can be depicted in a particular, serial order, this should not be understood as requiring or implying that such operations be performed in the particular order shown, or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing can be advantageous. Likewise, while specific implementations are discussed herein, these should not be understood to limit the scope of the disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in subcombination or as separate embodiments. Accordingly, the particular implementation described is merely exemplary in nature and is not intended to suggest any limitation as to the scope of the disclosure.

[0081] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A method for checking a service, comprising: obtaining historical data associated with a set of historical requests for the service in a first time period, wherein the set of historical requests are requests for the service of a vehicle previously; determining, based on the historical data, a checking policy for the service in a second time period, the checking policy indicating at least a checking time for checking the service, wherein the checking policy is adaptively adjusted; and causing the checking to be dynamically performed based on the checking policy. 2.The method of claim 1, wherein the historical data indicates a set of request time instants associated with the set of historical requests, and determining the checking policy comprises: dividing the set of historical requests into a plurality of subsets of historical requests based on a time distribution of the set of request time instants; determining a checking frequency for checking the service based on the plurality of subsets of historical requests; and determining the checking time for checking the service based on the checking frequency. 3.The method of claim 2, wherein determining the checking time comprises: determining a first historical request earliest in each of the plurality of subsets of historical requests based on the set of request time instants; and determining the checking time based on the checking frequency and a first request time instant associated with the first historical request. 4.The method of claim 1, further comprising performing the checking for the service by: sending a probe packet to a remote device associated with the service; and determining availability of the service based on a response result associated with the probe packet. 5.The method of claim 1, wherein the service is a target service, the method further comprising: determining the target service from a set of candidate services based on activation state data associated with activation states of the set of candidate services, the activation state of the target service indicating that the target service has been activated. 6.The method of claim 5, wherein other candidate services in the set of candidate services except the target service are non-target services, the method further comprising: causing the checking for the non-target services to be performed based on a predetermined first checking policy. 7.The method of any one of claims 1-6, further comprising: providing warning information in response to the service being abnormal. 8.An apparatus for checking a service, comprising: a historical data obtaining module configured to obtain historical data associated with a set of historical requests for the service in a first time period, wherein the set of historical requests are requests for the service of a vehicle previously; a checking policy determining module configured to determine, based on the historical data, a checking policy for the service in a second time period, the checking policy indicating at least a checking time for checking the service, wherein the checking policy is adaptively adjusted; and a first control module configured to cause the checking to be dynamically performed based on the checking policy. ​ ​ ​ ​ 9. The apparatus of claim 8, wherein the historical data indicates a set of request time instants associated with the set of historical requests, and the inspection policy determination module comprises: a historical request partitioning module configured to partition the set of historical requests into a plurality of historical request subsets based on a temporal distribution of the set of request time instants; an inspection frequency determination module configured to determine an inspection frequency for inspecting the service based on the plurality of historical request subsets; and a first inspection time determination module configured to determine the inspection time for inspecting the service based on the inspection frequency.

10. The apparatus of claim 9, wherein the first inspection time determination module comprises: a first historical request determination module configured to determine a first historical request that is earliest in each of the plurality of historical request subsets based on the set of request time instants; and a second inspection time determination module configured to determine the inspection time based on the inspection frequency and a first request time instant associated with the first historical request.

11. The apparatus of claim 8, further comprising: a probe packet sending module configured to send a probe packet to a remote device associated with the service; and an availability determination module configured to determine an availability of the service based on a response result associated with the probe packet.

12. The apparatus of claim 8, wherein the service is a target service, the apparatus further comprising: a target service determination module configured to determine the target service from a set of candidate services based on activation state data associated with activation states of the set of candidate services, the activation state of the target service indicating that the target service has been activated.

13. The apparatus of claim 12, wherein a candidate service other than the target service in the set of candidate services is a non-target service, the apparatus further comprising: a second control module configured to cause an inspection for the non-target service to be performed based on a predetermined first inspection policy.

14. The apparatus of any of claims 8 to 13, further comprising: a warning information providing module configured to provide warning information in response to the service being abnormal.

15. An apparatus for inspecting a service, comprising: at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions when executed by the at least one processing unit causing the apparatus to perform the method of any of claims 1 to 7.

16. A computer-readable storage medium having stored thereon a computer program which, when executed by an apparatus, causes the apparatus to perform the method of any of claims 1 to 7. ​ ​ ​ ​

Images