File transfer protocol server state detection method, device, equipment, medium and program product

Abstract

The invention provides a file transfer protocol server state detection method which can be applied to the technical field of cloud computing. The method comprises the steps of sending a connection request to a server based on a preset detection time interval, and responding to establishment of connection with the server within a connection time threshold to obtain a first result; sending an identity authentication request to the server, and obtaining a second result in response to receiving an authentication success state code corresponding to identity authentication success; sending a command request to the server, and responding to a command response state code corresponding to the command request received in a response time threshold to obtain a third result; and based on the first result, the second result and the third result, determining that the server state is a normal state. The invention further provides a file transfer protocol server state detection device and equipment, a storage medium and a program product.

Description

Technical Field

[0001] This application relates to the field of cloud computing, and more specifically to a method, apparatus, device, medium, and program product for detecting the status of a file transfer protocol server. Background Technology

[0002] In the daily operation and maintenance of internet applications, server status monitoring is a core component in ensuring the continuity and availability of business services. Its core objective is to detect server anomalies in real time and issue timely warnings to avoid business losses due to service interruptions or performance degradation. Currently, mainstream server status monitoring methods in the industry mainly include Hypertext Transfer Protocol (HTTP) detection and Internet Control Message Protocol (ICMP) packet inter-network probing. These general monitoring solutions have been widely used in scenarios such as World Wide Web service availability verification and network connectivity testing, and can meet the monitoring needs of routine businesses for basic service status.

[0003] However, in core business scenarios such as large-scale file distribution, critical data backup, and automated script interaction, business processes heavily rely on the stable operation of the File Transfer Protocol (FTP). The aforementioned general detection methods are difficult to match the unique characteristics of FTP and the in-depth monitoring needs of business scenarios.

[0004] First, there is a clear protocol mismatch issue. HTTP detection is based on the HTTP protocol stack and cannot effectively simulate the complete interaction process unique to the FTP protocol, including key steps such as connection establishment, user authentication, and data channel negotiation. ICMP packet inter-network probes can only verify the reachability of the server's network layer. Even if the detection results show network connectivity, it does not mean that the FTP service itself is available. The server may have problems such as FTP service process crashes or protocol ports being incorrectly occupied, which will prevent the actual file transfer business from proceeding normally.

[0005] Secondly, existing general detection methods mostly remain at the level of network connectivity verification or simple connection establishment, making it difficult to detect deep-seated problems in the operation of FTP services. For example, there are hidden dangers such as severe service response delays, failure to establish data channels, and abnormal execution of specific FTP commands (such as upload, download, and directory switching commands). Although these do not affect the establishment of basic connections, they will directly cause file transfer functions to fail. Such deep-seated anomalies that affect actual business operations cannot be effectively identified by existing technologies.

[0006] Finally, existing technologies lack FTP context awareness capabilities. The operational status of FTP services is greatly affected by factors such as network fluctuations and instantaneous server load. The response characteristics of FTP services also differ under different business scenarios. However, existing detection methods mostly use fixed thresholds for anomaly judgment, which cannot make intelligent threshold adjustments based on the historical operation behavior of FTP services. This can easily lead to false alarms and interfere with normal operation and maintenance. Summary of the Invention

[0007] In view of the above problems, this application provides a method, apparatus, device, medium and program product for status detection of file transfer protocol servers.

[0008] According to a first aspect of this application, a method for detecting the status of a file transfer protocol server is provided, comprising: sending a connection request to a server based on a preset detection time interval, and obtaining a first result upon receiving a connection with the server within a connection time threshold, wherein the connection time threshold is set based on historical connection times within a preset time and a preset connection threshold; sending an authentication request to the server, and obtaining a second result upon receiving an authentication success status code corresponding to successful authentication; sending a command request to the server, and obtaining a third result upon receiving a command response status code corresponding to the command request within a response time threshold, wherein the response time threshold is set based on historical command response times within a preset time and a preset response threshold; and determining that the server status is normal based on the first result, the second result, and the third result.

[0009] According to an embodiment of this application, a connection time threshold is set based on historical connection times within a preset time period and a preset connection threshold, including: obtaining a first connection threshold based on the historical average connection time and a preset connection coefficient, wherein the preset connection coefficient is greater than 1 and less than or equal to 2; obtaining a second connection threshold based on the nth percentile after sorting historical connection times from smallest to largest, wherein n is greater than 50 and less than 100; and setting the connection time threshold based on the maximum value among the first connection threshold, the second connection threshold, and the preset connection threshold.

[0010] According to an embodiment of this application, a response time threshold is set based on historical command response times within a preset time period and a preset response threshold, including: obtaining a first response threshold based on the historical average command response time and a preset response coefficient, wherein the preset response coefficient is greater than 1 and less than or equal to 2; obtaining a second response threshold based on the m percentile after sorting historical command response times from smallest to largest, wherein m is greater than 50 and less than 100; and setting the response time threshold based on the maximum value among the first response threshold, the second response threshold, and the preset response threshold.

[0011] According to an embodiment of this application, after sending a connection request to the server, the method further includes: in response to the failure to establish a connection with the server, determining that the server connection is abnormal and triggering a connection abnormality alarm; or, in response to the time taken to establish a connection with the server exceeding a connection time threshold, determining that the server connection is abnormal and triggering a connection abnormality alarm.

[0012] According to an embodiment of this application, after sending an authentication request to the server, the method further includes: in response to receiving an authentication error status code corresponding to an authentication error, determining that the server authentication is abnormal and triggering an authentication error alarm; or, in response to the absence of an authentication success status code or an authentication error status code, determining that the server authentication is abnormal and triggering an authentication error alarm.

[0013] According to an embodiment of this application, after sending a command request to the server, the method further includes: determining that the server service is abnormal and triggering a runtime abnormality alarm in response to a missing command response status code; or determining that the server service is abnormal and triggering a runtime abnormality alarm in response to a time taken to receive the command response status code exceeding a response time threshold; or determining that the server service is abnormal and triggering a runtime abnormality alarm in response to receiving an error status code in the command response.

[0014] According to an embodiment of this application, after receiving the command response error status code, the method further includes: locating the faulty node based on the command response error status code and the command request; and obtaining the root cause of the runtime exception based on the stack information of the faulty node and the command request.

[0015] A second aspect of this application provides a file transfer protocol server status detection device, comprising: a connection module, configured to send a connection request to a server based on a preset detection time interval, and to obtain a first result upon establishing a connection with the server within a connection time threshold, wherein the connection time threshold is set based on historical connection times within a preset time and a preset connection threshold; an authentication module, configured to send an authentication request to the server, and to obtain a second result upon receiving an authentication success status code corresponding to successful authentication; a command module, configured to send a command request to the server, and to obtain a third result upon receiving a command response status code corresponding to the command request within a response time threshold, wherein the response time threshold is set based on historical command response times within a preset time and a preset response threshold; and a detection module, configured to determine that the server status is normal based on the first result, the second result, and the third result.

[0016] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0017] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0018] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0019] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0020] Figure 1 The illustration schematically depicts an application scenario of a file transfer protocol server status detection method, apparatus, device, medium, and program product according to embodiments of this application.

[0021] Figure 2 A flowchart illustrating a file transfer protocol server status detection method according to an embodiment of this application is shown schematically.

[0022] Figure 3 A flowchart illustrating the setting of a connection time threshold according to an embodiment of this application is shown schematically;

[0023] Figure 4 A flowchart illustrating the setting of a response time threshold according to an embodiment of this application is shown schematically;

[0024] Figure 5 This schematically illustrates a flowchart following the receipt of a command response error status code according to an embodiment of this application;

[0025] Figure 6 This schematically illustrates a structural block diagram of a file transfer protocol server status detection device according to an embodiment of this application; and

[0026] Figure 7 A block diagram schematically illustrates an electronic device suitable for implementing a file transfer protocol server status detection method according to an embodiment of this application. Detailed Implementation

[0027] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0028] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0029] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0030] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0031] In related technologies, server status detection is the core of ensuring business continuity and availability in the daily operation and maintenance of Internet applications. Mainstream HTTP, ICMP and other common detection methods can meet the routine basic monitoring needs. However, in core business scenarios such as large-scale file distribution and data backup that rely on the FTP protocol, these methods have limitations such as protocol mismatch, difficulty in detecting deep service problems, and lack of FTP context awareness, and cannot match the FTP-specific characteristics and deep monitoring needs.

[0032] This application provides a file transfer protocol server status detection method, comprising: sending a connection request to a server based on a preset detection time interval, and obtaining a first result upon receiving a connection with the server within a connection time threshold, wherein the connection time threshold is set based on historical connection times within a preset time and a preset connection threshold; sending an authentication request to the server, and obtaining a second result upon receiving an authentication success status code corresponding to successful authentication; sending a command request to the server, and obtaining a third result upon receiving a command response status code corresponding to the command request within a response time threshold, wherein the response time threshold is set based on historical command response times within a preset time and a preset response threshold; and determining that the server status is normal based on the first result, the second result, and the third result.

[0033] According to the embodiments of this application, by sequentially performing full-process verification of FTP-specific connection establishment, authentication, and command interaction, the normal state of the server is determined by comprehensively considering the three types of verification results. This accurately simulates core interactive links such as FTP control connection and authentication, effectively verifying the availability of the FTP service itself, rather than just focusing on network layer reachability. The method provided by this application covers key links of connection, authentication, and command processing, and can identify deep-seated hidden dangers such as service response delays and command execution anomalies, ensuring that the detection results are strongly correlated with the availability of actual file transfer services. In addition, the connection time threshold and response time threshold are dynamically configured based on historical operating data and preset thresholds, thereby adapting to network fluctuations, instantaneous changes in server load, and response characteristics of different business scenarios, avoiding false alarms caused by fixed thresholds, and reducing operational interference.

[0034] Figure 1 The illustration shows an application scenario of the file transfer protocol server status detection method according to an embodiment of this application.

[0035] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0036] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0037] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0038] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0039] It should be noted that the file transfer protocol server status detection method provided in this application embodiment can generally be executed by server 105. Correspondingly, the file transfer protocol server status detection device provided in this application embodiment can generally be located in server 105. The file transfer protocol server status detection method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the file transfer protocol server status detection device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0040] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0041] The following will be based on Figure 1 The described scene, through Figures 2-5 A file transfer protocol server status detection method according to embodiments of this application will be described in detail.

[0042] Figure 2 A flowchart illustrating a file transfer protocol server status detection method according to an embodiment of this application is shown.

[0043] like Figure 2 As shown, the file transfer protocol server status detection in this embodiment includes operations S210 to S240.

[0044] In operation S210, a connection request is sent to the server based on a preset detection time interval. In response, a connection is established with the server within the connection time threshold, and a first result is obtained.

[0045] According to embodiments of this application, connection requests are sent to at least one server simultaneously. In one optional embodiment, concurrent scheduling can be implemented using a thread pool. Specifically, the thread pool selects one or more targets from the list of servers to be detected simultaneously, allocates an idle thread to each target, and allows each thread to independently call the connection interface (standard control port 21 as defined by the FTP protocol) to synchronously establish a Transmission Control Protocol (TCP) connection with the server. Each thread executes in parallel without blocking the others. In another optional embodiment, an event loop mechanism can be used, whereby all connection requests from servers to be detected are registered as non-blocking I / O events at once. Connection initiation operations are triggered simultaneously through multiplexing, allowing other requests to be processed without waiting for a single connection to complete.

[0046] According to embodiments of this application, a detection time interval is preset for each server. The detection time intervals for different servers can be the same or different. For example, assuming the detection time interval is set to 2 seconds for the first server and 1 second for the second server, a connection request can be sent to the first server every 2 seconds after the first server starts running, and a connection request can be sent to the second server every 1 second after the second server starts running. Alternatively, assuming the preset detection time interval for each server is 2 seconds, a connection request can be sent to each server every 2 seconds after the first server starts running.

[0047] According to an embodiment of this application, a first timestamp of sending a connection request to the server is recorded. This is used to calculate the time required to establish a connection with the server in subsequent steps. .

[0048] In one optional embodiment, a first result is obtained in response to establishing a connection with the server within a connection time threshold. Specifically, a second timestamp indicating successful connection is recorded. Second timestamp With first timestamp The difference between them is the time taken to establish the connection. If the time taken to establish a connection If the connection time is less than or equal to the preset connection time threshold, a first result is generated. The first result includes: a result type marked as "connection normal" and the time taken to establish the connection. Second timestamp This initial result will serve as a prerequisite for sending subsequent authentication requests to the server, and will also include the time required to establish the connection. It will be written to the historical connection time database in real time, used to dynamically update the connection time threshold, forming the basic data support for threshold self-optimization.

[0049] In another optional embodiment, in response to the time taken to establish a connection with the server exceeding a connection time threshold, a server connection abnormality is determined, and a connection abnormality alarm is triggered. Specifically, if the time taken to establish a connection exceeds a connection time threshold... If the connection time exceeds the preset threshold, a server connection is considered abnormal. At this point, the system will record key information: target server address, FTP control port, and connection establishment time. The current connection time threshold and anomaly type are marked as "Connection Timeout". The alarm message clearly states "Connection timeout exceeded" and includes a preliminary cause (e.g., "Possible causes: network link congestion, high server CPU / memory load, slow FTP service process response"). Furthermore, this timeout record is written to the historical connection time database in real time for subsequent dynamic adjustment of the connection time threshold. It also provides maintenance personnel with traceability data on connection performance degradation, helping to pinpoint whether the problem originates at the network level or within the server itself.

[0050] In another optional embodiment, in response to a failure to establish a connection with the server, a server connection anomaly is determined, and a connection anomaly alarm is triggered. A failure to establish a connection with the server includes: receiving a connection rejection flag from the server, indicating that the server actively refuses to establish a connection; or receiving network layer unreachable feedback, causing the connection request to fail to reach the server. In this case, the system directly marks "server connection anomaly" and simultaneously triggers a connection anomaly alarm. The alarm information includes the target server address, FTP control port, connection failure timestamp, failure type (e.g., "server actively refuses," "network unreachable"), and preliminary fault attribution (e.g., "possible causes: FTP service not started, port occupied, network link interrupted"). Simultaneously, the connection failure record (including failure type, time consumption, and environmental parameters) is written to the anomaly log database, providing data support for subsequent fault tracing and connection time threshold optimization, ensuring that maintenance personnel can quickly locate the core scenario of the connection failure.

[0051] According to the embodiments of this application, after sending a connection request to the server, the system accurately identifies two scenarios: "connection failure" and "connection timeout," determines server connection anomalies in real time, and triggers corresponding alarms. This quickly captures faults or performance degradation issues at the FTP service connection level, laying a solid foundation for subsequent core detection processes such as identity authentication and command interaction. It effectively avoids the risk of business interruption due to failure to handle connection anomalies in a timely manner, and improves the timeliness and reliability of FTP service connection status monitoring.

[0052] In operation S220, an authentication request is sent to the server. In response, an authentication success status code corresponding to successful authentication is received, and a second result is obtained.

[0053] In one optional implementation, after successfully establishing a connection with the server, a simulated authentication process is initiated immediately. Specifically, a username command is first sent to the server through this connection. After receiving a password request response from the server, a password command is then sent. The authentication response data returned by the server is received in real time, and the status code in the response is parsed according to the FTP protocol standard. For example, if a "2xx" success status code is parsed, authentication is considered successful, and a second result is generated. The second result includes: a result type marked "authentication successful," along with key data such as the target server address, the authenticated username, the authentication success status code, the actual authentication time, and the success timestamp. This result serves as a prerequisite for subsequently sending FTP command requests to the server. Simultaneously, the actual authentication time and success records are written to the historical authentication database in real time, providing fundamental data support for analyzing the stability of the FTP service authentication process.

[0054] In another optional implementation, in response to receiving an authentication error status code corresponding to an authentication error, the system determines that the server authentication is abnormal and triggers an authentication error alarm. Specifically, it listens to the authentication response data returned by the server and parses the status code in the response according to the FTP protocol standard. If a "5xx" type authentication error status code is parsed, such as "530" (username or password error), "532" (account permissions required to store files), or "501" (invalid authentication parameters), which clearly indicates authentication failure, the system immediately determines that the server authentication is abnormal. The system will synchronously record key information: the target server address, the username participating in the authentication, the specific authentication error status code and its corresponding meaning, and the timestamp of the abnormality, and then trigger an authentication error alarm. The alarm information includes the core reason for the authentication failure (such as "username and password do not match" or "invalid authentication parameters"), along with preliminary troubleshooting suggestions (such as "check the validity of authentication credentials" and "confirm FTP account permission configuration"), and writes the details of this authentication abnormality to the operation and maintenance log database, providing complete data support for subsequent fault tracing and helping operation and maintenance personnel quickly locate and handle authentication-level faults.

[0055] In another optional implementation, in response to the absence of a successful authentication status code or an error authentication status code, a server authentication anomaly is determined, triggering an authentication anomaly alarm. Specifically, if no explicit authentication status code is detected, or the parsed response data does not contain a status code conforming to the FTP protocol standard, or the response data format is abnormal and the status code cannot be recognized, it is determined as "missing successful authentication status code or missing error authentication status code". At this time, the system will mark the server authentication as abnormal, record the target server address, authentication username, anomaly type (such as "no valid status code in authentication response", "abnormal response format", "no status code received after timeout"), timestamp of the anomaly occurrence, and actual waiting time, and then trigger an authentication anomaly alarm. The alarm information is marked "missing authentication response status code" and includes a preliminary attribution (such as "possible causes: network link interruption leading to response loss, FTP server authentication module failure, server returning a non-standard response format"). At the same time, the complete details of this anomaly are written to the operation and maintenance log database to provide data support for subsequent troubleshooting of server authentication process failures and network transmission stability issues, ensuring timely detection of potential anomalies at the authentication interaction level.

[0056] According to the embodiments of this application, after sending an authentication request to the server, by comprehensively covering two scenarios, namely "receiving an authentication error status code" and "authentication successful or missing error status code", the server authentication anomaly can be accurately determined in real time and the corresponding alarm can be triggered. This effectively captures various authentication-level hidden dangers such as incorrect authentication credentials, server authentication module failure, and response loss, ensuring that anomalies in the FTP service authentication process can be detected and handled in a timely manner, improving the comprehensiveness and reliability of authentication status monitoring, and laying a solid foundation for subsequent core processes such as command interaction.

[0057] In operation S230, a command request is sent to the server. In response, a command response status code corresponding to the command request is received within the response time threshold, and a third result is obtained.

[0058] According to embodiments of this application, a low-overhead, high-determinism command request is sent to the server, and a third timestamp of the command request being sent to the server is recorded. Low-overhead commands consume minimal server resources, have simple execution logic, require no complex calculations or data processing, and do not involve resource-intensive operations such as large file transfers, directory modifications, or permission changes. They only trigger basic response interactions. For example, with a NOOP command, the server only needs to return "200 NOOP ok" after receiving it, with no additional resource consumption. High-deterministic commands provide predictable and easily parsed response results. The response format strictly adheres to protocol specifications, with fixed status codes and a uniform return content structure, avoiding ambiguous or variable results. Furthermore, the criteria for success or failure are clear and unambiguous. For instance, a successful SYST command will always return "215 System type: XXX" (e.g., "215 Systemtype: UNIX Type: L8"), with a fixed status code of 215. Failure returns a clear error code (e.g., "502 Command not implemented"), with unambiguous judgment criteria.

[0059] In one optional embodiment, a third result is obtained in response to receiving a command response status code corresponding to the command request within a response time threshold. Specifically, the system continuously monitors server feedback, parses the response data according to the FTP protocol standard, and confirms that the parsed status code corresponds to the sent command request. For example, if a NOOP command is sent, a corresponding success status code of 200 is received; or if a SYST command is sent, a corresponding success status code of 215 is received. Simultaneously, a fourth timestamp of the received command response status code is recorded. Fourth timestamp With third timestamp The difference between them is the command response time. If the command response time If the response time is less than or equal to the preset response time threshold, a third result is generated. The third result includes: a result type marked as "command response normal," along with data such as the target server address, the type of command sent, the corresponding response status code, the actual response time, and a success timestamp. This result is used to verify the server's command processing capabilities and connection stability. Simultaneously, the actual response time is written to the historical command response database, providing data support for dynamically optimizing the response time threshold and analyzing the stability of the core FTP service functions.

[0060] In another alternative embodiment, the time taken to receive the command response status code, i.e., the command response time. If the response time threshold is exceeded, a server service malfunction is identified, and a runtime exception alarm is triggered. If the command response time... If the response time exceeds the preset threshold, it is directly judged as "server service abnormality". The system immediately records key information, such as the target server address, the type of command sent, the actual response time, the current response time threshold, and the abnormality type marked as "command response timeout", and then triggers a runtime abnormality alarm. The alarm message is marked "command response time exceeds threshold" and includes a preliminary cause (such as "possible causes: network link congestion, server overload, slow FTP service process processing"). In addition, this timeout record is written to the historical command response database in real time, which not only provides data support for subsequent dynamic optimization of the response time threshold, but also provides a complete basis for operation and maintenance personnel to trace the server performance degradation trend and locate the core failure point.

[0061] In another optional embodiment, in response to a missing command response status code, a server service anomaly is determined, triggering an operational anomaly alarm. Specifically, if no feedback data is received from the server, or if a data packet is received from the server but no FTP protocol standard status code is found after parsing, or if the response data format is disordered or fields are incomplete, making it impossible to extract a valid status code, it is determined as "missing command response status code". At this time, the system marks the server service as abnormal, records the target server address, the type of command sent, the anomaly type (no response / no valid status code / format error), the anomaly timestamp, and the actual waiting time, and then triggers an operational anomaly alarm. The alarm information is marked "missing command response status code", and a preliminary cause is attributed (such as FTP service process crash, network link interruption, server configuration anomaly). At the same time, the anomaly details are written to the operation and maintenance log database to provide data support for fault diagnosis and response time threshold optimization.

[0062] In another optional embodiment, in response to receiving a command response error status code, the system determines that the server service is abnormal and triggers a runtime anomaly alarm. For example, after sending the NOOP command, a "502" (command not implemented) or "550" (permission denied) error is received; after sending the SYST command, a "501" (invalid parameter) or "530" (not logged in, authentication status abnormality) error is received. At this time, the system directly marks "server service abnormality" and immediately records key information: the target server address, the type of command sent, the specific error status code and its corresponding meaning, and the timestamp of the anomaly occurrence, subsequently triggering a runtime anomaly alarm. The alarm information clearly indicates "command response error" and includes a preliminary attribution (such as "possible causes: incorrect server command permission configuration, FTP service not enabled, invalid command parameters, abnormal server file system"). Simultaneously, this error record is written to the historical command response database in real time, providing accurate data support for maintenance personnel to locate server command processing module failures and permission configuration problems, and also providing a reference for subsequent optimization and probing command selection.

[0063] According to the embodiments of this application, after sending a command request to the server, by comprehensively covering three abnormal scenarios such as "missing command response status code", "command response time exceeding the limit", and "receiving command response error status code", it is possible to accurately determine server service abnormalities and trigger operational abnormality alarms, promptly capture various faults in the command processing stage, ensure the stability and reliability of FTP service command processing functions, and improve the comprehensiveness and timeliness of server operation status monitoring.

[0064] In operation S240, based on the first result, the second result, and the third result, the server status is determined to be normal.

[0065] According to the embodiments of this application, the first result confirms that a connection with the server was successfully established, and the actual connection time did not exceed the preset connection time threshold, with no connection failures, timeouts, or other anomalies, thus verifying the availability of the server's network connection layer. The second result confirms that after sending the authentication request, a successful FTP protocol standard authentication success status code was received, with no authentication errors or missing status codes, thus verifying the normal operation of the server's authentication process. The third result confirms that after sending a low-overhead, high-determinism command, a success status code corresponding to the command was received within the preset response time threshold, with no response timeouts, missing status codes, or command response errors, thus verifying the effectiveness of the server's command processing function. Therefore, considering that the first, second, and third results all meet the normal judgment conditions, the server status can be ultimately determined to be normal, and key data such as the server address, the time spent in each step, and the success status code are recorded synchronously to provide support for subsequent monitoring and analysis.

[0066] Figure 3 A flowchart illustrating the setting of a connection time threshold according to an embodiment of this application is shown.

[0067] like Figure 3 As shown, the setting of the connection time threshold in this embodiment includes operations S310 to S330.

[0068] In operation S310, a first connection threshold is obtained based on the historical average connection time and a preset connection coefficient, wherein the preset connection coefficient is greater than 1 and less than or equal to 2.

[0069] According to an embodiment of the present application, extract the valid historical connection records of the target server within a specified period (e.g., 30 days), only retain the records of successfully established connections, calculate the arithmetic mean of the actual connection time-consuming in these valid records, and denote it as the historical average connection time. Set a preset connection coefficient, which is greater than 1 and less than or equal to 2. Its function is to reserve a buffer space to adapt to scenarios such as network fluctuations and temporary server load changes. The coefficient selection needs to be combined with the actual scenario. For example, when the network environment is stable, it can take 1.2 - 1.5, and when the network fluctuations are large (such as cross-region detection), it can take 1.6 - 2.0. The commonly used default value is 1.5. Multiply the historical average connection time by the preset connection coefficient to obtain the first connection threshold. For example, if the historical average connection time is 100ms and the preset connection coefficient is 1.5, then the first connection threshold is 150ms. In this embodiment, regularly re-statistics the historical connection data, update the historical average connection time, and adjust the preset connection coefficient according to the server connection stability to ensure that the threshold always fits the actual operating conditions and avoid misjudgment.

[0070] In operation S320, obtain the second connection threshold based on the nth percentile after sorting the historical connection times from small to large, where n is greater than 50 and less than 100.

[0071] According to an embodiment of the present application, extract the connection success records of the target server within a specified period,剔除 invalid data such as connection failures and abnormal interruptions, and only retain the actual connection time-consuming data available for statistics. Arrange the filtered valid connection time-consuming data in ascending order to form a first ordered data sequence, and obtain the second connection threshold based on the nth percentile after sorting. The value range of the percentile n is 50 < n < 100. The larger the value of n, the stronger the fault tolerance. The value of n can be adjusted according to the server stability requirements, and usually takes 80 - 95. In this embodiment, n is 95, which means that only 5% of the normal connection time-consuming is allowed to exceed this threshold. Assuming there are 100 valid data, the 95th data is taken as the second connection threshold. In this embodiment, regularly re-collect the historical connection data, update the first ordered data sequence and recalculate the nth percentile. If the server operating environment changes (such as migrating the computer room, expanding capacity), an immediate update can be triggered to ensure that the threshold adapts to the new scenario.

[0072] In operation S330, set the connection time threshold based on the maximum value among the first connection threshold, the second connection threshold, and the preset connection threshold.

[0073] It should be noted that the Chinese text "剔除" in the translation of is a literal translation placeholder, and it should be replaced with the appropriate English expression according to the actual context. Here, "剔除" can be translated as "exclude" or "filter out", etc. The translation should be adjusted according to the specific requirements of the text.According to the embodiments of this application, the preset connection threshold is a fixed value set by the administrator based on actual business needs, server performance limits, compliance requirements, and other scenarios, without relying on historical connection data for calculation. Administrators can refer to the calculation results of the first and second connection thresholds, or combine factors such as cross-regional access needs, server peak load characteristics, and network link quality to directly set a specific value; there is no mandatory range restriction on the value, but it is necessary to avoid excessively wide values ​​leading to missed detections of abnormal connections and excessively strict values ​​leading to false detections of normal connections. Commonly used setting ranges are similar to the first and second connection thresholds. This threshold supports manual adjustment by the administrator as needed. When the server deployment environment changes, business traffic fluctuates, or the network architecture is upgraded, it can be updated immediately to adapt to new scenarios. Its core function is to provide a flexible manual configuration option for connection time determination, supplementing the applicable boundaries of the first two data-driven thresholds.

[0074] According to embodiments of this application, the maximum value among the first connection threshold, the second connection threshold, and the preset connection threshold is selected, and the selected maximum value is directly used as the connection time threshold to determine whether the server connection time is normal. When any of the thresholds is updated, the maximum value of the three values ​​needs to be recalculated, and the connection time threshold is updated synchronously to ensure that the judgment standard always adapts to the actual scenario.

[0075] The first and second connection thresholds are obtained by using historical connection times within a preset time period. These are then compared with the preset connection thresholds configured by the administrator, and the maximum value among the three is taken as the connection time threshold. This approach not only relies on historical data to ensure the rationality and scenario adaptability of the thresholds, but also reserves buffer space through preset coefficients and percentile intervals. Furthermore, it provides a flexible adjustment dimension by using preset thresholds, effectively reducing connection judgment errors caused by network fluctuations and temporary changes in server load. This makes the server's judgment standard for controlling connection time more accurate and reliable.

[0076] Figure 4 A flowchart illustrating the setting of a response time threshold according to an embodiment of this application is shown.

[0077] like Figure 4 As shown, the setting of the response time threshold in this embodiment includes operations S410 to S430.

[0078] In operation S410, a first response threshold is obtained based on the historical average command response time and a preset response coefficient, where the preset response coefficient is greater than 1 and less than or equal to 2.

[0079] According to an embodiment of the present application, extract the valid successful response records of command requests within a specified period of the target server, and eliminate invalid data such as timeouts and error responses. Calculate the arithmetic mean of the command response times in these records, which is denoted as the historical average command response time. Set a preset response coefficient that is greater than 1 and less than or equal to 2. Its function is to cope with scenarios such as network fluctuations and temporary delays in server command processing, and reserve a fault tolerance buffer. The coefficient selection needs to be combined with the actual scenario. For example, when the network is stable and the server is load-balanced, take 1.2 - 1.5; when performing cross-regional detection or during the business peak period, take 1.6 - 2.0. The commonly used default value is 1.5. Multiply the historical average command response time by the preset response coefficient to obtain the first response threshold. For example, if the historical average command response time is 200 ms and the preset response coefficient is 1.4, then the first response threshold is 280 ms. In this embodiment, regularly re-collect historical command response data and update the historical average command response time. When the server operating environment changes (such as software upgrade or hardware expansion) or the network quality fluctuates, the preset response coefficient can be flexibly adjusted to avoid misjudgment.

[0080] In operation S420, obtain a second response threshold based on the m-th percentile after sorting the historical command response times from smallest to largest, where m is greater than 50 and less than 100.

[0081] According to an embodiment of the present application, extract the successful response records of command requests within a specified period of the target server, eliminate invalid data such as timeouts, error responses, and abnormal interruptions, and only retain the actual command response durations that can be statistically analyzed. Arrange the filtered valid response duration data in ascending order to form a second ordered data sequence, and obtain a second response threshold based on the m-th percentile after sorting. The value range of the percentile m is 50 < m < 100. The larger the value of m, the stronger the fault tolerance. The value of m can be flexibly adjusted according to the stability requirements of server command processing, and usually ranges from 80 - 95. In this embodiment, m is 95, which means that only 5% of the normal command response durations are allowed to exceed this threshold. Assuming there are 100 valid data, take the 95th data as the second response threshold. In this embodiment, regularly re-collect historical command response data, update the second ordered data sequence and recalculate the m-th percentile. If the server deployment environment changes (such as migrating nodes or upgrading the FTP service version), an immediate update can be triggered to ensure that the threshold adapts to the new operating scenario.

[0082] In operation S420, set a response time threshold based on the maximum value among the first response threshold, the second response threshold, and the preset response threshold.

[0083] According to the embodiments of this application, the preset response threshold is a fixed value set by the administrator based on actual business needs, server command processing performance limits, network link quality, and compliance requirements. It does not rely on historical command response data for calculation and is primarily used to determine whether command response time is normal. Administrators can refer to the calculation results of the first and second response thresholds, or combine factors such as cross-regional command interaction needs, command processing latency characteristics under peak server load, and the response speed requirements of critical businesses to directly set specific values. There are no mandatory range restrictions on the value, but it is necessary to avoid overly broad values ​​leading to missed abnormal responses and overly strict values ​​leading to misjudgments of normal responses. Commonly used setting ranges are similar to the first and second response thresholds. This threshold supports manual adjustment by the administrator as needed. When the server deployment environment changes, business traffic fluctuates, or the FTP service version is upgraded, it can be updated immediately to adapt to new scenarios. Its core function is to provide a flexible manual configuration option for command response time determination, supplementing the applicable boundaries of the first two data-driven thresholds and covering customized determination needs in special scenarios.

[0084] According to embodiments of this application, the maximum value among a first response threshold, a second response threshold, and a preset response threshold is selected, and the selected maximum value is directly used as the response time threshold to determine whether the command response time is normal. If any of the thresholds changes, the three values ​​must be immediately re-compared, and the response time threshold updated.

[0085] The first and second response thresholds are obtained by using historical command response times within a preset time period. These are then compared with the preset response thresholds configured by the administrator, and the maximum value among the three is taken as the response time threshold. This approach not only relies on historical data to ensure the adaptability of the thresholds to the actual operating scenarios of the server, but also reserves fault tolerance space to cope with network fluctuations and temporary load changes through preset response coefficients and percentile ranges. Furthermore, the preset response thresholds provide a customized adjustment dimension, effectively reducing the possibility of misjudgment in command response time determination, and making the criteria for determining whether a command response is normal more accurate, flexible, and reliable.

[0086] Figure 5 The flowchart illustrating the process following the receipt of a command response error status code according to an embodiment of this application is shown schematically.

[0087] like Figure 5 As shown, after receiving the command response error status code, this embodiment also includes operations S510 to S520.

[0088] When operating the S510, the faulty node is located based on the command response error status code and command request.

[0089] First, identify the type of command request sent and clarify the standard processing flow of the command on the server side. Taking the SYST command as an example, the command type is a system information query, and its core purpose is to obtain basic configurations such as the server operating system type and FTP service version. The processing flow is "receive command → syntax verification → login status verification → system information collection → response construction → return result". The core modules associated with this are "command parsing module", "authentication status verification module", "system information collection module" and "response message construction module".

[0090] Next, according to the FTP protocol specification, the meaning of the command response error status codes corresponding to the SYST command is parsed. For example, "501" indicates a command syntax error (such as carrying extra parameters or illegal character format); "530" indicates that the client is not logged in and the server prohibits anonymous users from calling the SYST command; "502" indicates that the server does not support the processing logic of the SYST command (the corresponding function has not been developed); "550" indicates that the logged-in user does not have permission to query system information; and "421" indicates that the server's core services are unavailable and cannot respond to commands.

[0091] Finally, the command response error status codes are matched one by one with the SYST command processing flow and associated modules to pinpoint the specific fault node. For example, if "501" is returned, the error occurs in the "syntax verification" stage, corresponding to the command parsing module (this module is responsible for verifying whether the command format conforms to the protocol specification; the fault may be due to abnormal syntax verification rules within the module); if "530" is returned, the error occurs in the "login status verification" stage, corresponding to the authentication status verification module (the module did not detect a valid login session, or anonymous access permissions are disabled); if "502" is returned, the error occurs in the "function routing after command reception" stage, corresponding to the command parsing module (this module has no SYST command processing logic mapping and is not associated with the system information collection function); if "550" is returned, the error occurs in the "permission judgment after login status verification" stage, corresponding to the authentication status verification module (the module has confirmed the login status, but the "query system information" permission item is not in the user permission list); if "421" is returned, the error runs through the entire command processing flow, corresponding to the server core service module (the core process is not running normally, causing all commands to be unreceived or unresponsive).

[0092] By precisely mapping the command flow, error code meanings, and associated modules, the specific functional nodes where exceptions occur during SYST command execution can be directly identified, providing a clear direction for subsequent root cause analysis.

[0093] When operating the S520, the root cause of the runtime exception is obtained based on the stack information of the faulty node and command request.

[0094] First, identify the core responsibilities of the faulty node (such as command parsing, permission verification, and system information collection), and sort out its normal function call path, dependent resources (system interfaces, configuration files, databases), and key rules (parameter formats, permission thresholds) to define the scope of analysis and avoid blindly checking stack information outside of module functions.

[0095] Next, the stack trace of the command request is analyzed to extract key exception clues. Specifically, the function that directly throws the error is captured from the stack trace to identify the specific code segment where the exception occurred; the function's input parameters, local variable states, and system / interface return codes are recorded; and the upper-level call relationships of the exception function are traced to clarify the complete flow path of command processing.

[0096] Next, the standard rules of the faulty node (such as the SYST command not allowing parameters) are compared with the actual data in the stack (such as parameters containing extra characters) to find the contradictions; then, based on the contradictions, the reasons why the normal logic failed are traced. For example, the root cause of parameters not conforming to the rules may be an error in the client command construction, and the root cause of the interface call returning permission denial may be insufficient process permissions.

[0097] Finally, identify the root cause type and categorize the reasons for the runtime anomaly into specific, repairable types such as incorrect parameters, improper permission configuration, missing dependent resources, and failure of underlying interfaces. Additionally, the root cause can be verified and deduced by reproducing the fault and checking configuration / resource status, eliminating secondary factors (such as network fluctuations and temporary load) to confirm that the root cause is the sole or core reason triggering the anomaly.

[0098] By accurately locating faulty nodes through error status codes and command requests, and then tracing the root cause of the operational anomaly by combining the stack information of the faulty node and the command request, a closed-loop analysis is formed from the triggering of the anomaly to the locking of the module, and then to the source location. This effectively avoids blind troubleshooting, significantly shortens the fault troubleshooting cycle, provides a clear basis for the accurate repair of the fault, and improves the efficiency and accuracy of handling server operational anomalies.

[0099] Based on the above-described file transfer protocol server status detection method, this application also provides a file transfer protocol server status detection device. The following will be combined with... Figure 6 The device is described in detail.

[0100] Figure 6 A schematic block diagram of a file transfer protocol server status detection device according to an embodiment of this application is shown.

[0101] like Figure 6 As shown, the file transfer protocol server status detection device 600 of this embodiment includes a connection module 610, an authentication module 620, a command module 630, and a detection module 640.

[0102] The connection module 610 is used to send a connection request to the server based on a preset detection time interval, and to establish a connection with the server within a connection time threshold to obtain a first result. The connection time threshold is set based on historical connection times within a preset time period and a preset connection threshold. In one embodiment, the connection module 610 can be used to perform the operation S210 described above, which will not be repeated here.

[0103] The authentication module 620 is used to send an authentication request to the server and, in response to receiving an authentication success status code corresponding to successful authentication, obtains a second result. In one embodiment, the authentication module 620 can be used to perform the operation S220 described above, which will not be repeated here.

[0104] Command module 630 is used to send a command request to the server, and in response to receiving a command response status code corresponding to the command request within a response time threshold, obtains a third result. The response time threshold is set based on historical command response times within a preset time period and a preset response threshold. In one embodiment, command module 630 can be used to execute the operation S230 described above, which will not be repeated here.

[0105] The detection module 640 is used to determine that the server status is normal based on the first result, the second result, and the third result. In one embodiment, the detection module 640 can be used to perform the operation S240 described above, which will not be repeated here.

[0106] The file transfer protocol server status detection device 600 in this embodiment further includes a connection time threshold module, used to set a connection time threshold based on historical connection times within a preset time and a preset connection threshold. In one embodiment, the connection time threshold module can be used to perform the operations S310 to S330 described above, which will not be repeated here.

[0107] The file transfer protocol server status detection device 600 in this embodiment further includes a response time threshold module, used to set a response time threshold based on historical command response times within a preset time and a preset response threshold. In one embodiment, the response time threshold module can be used to perform the operations S410 to S430 described above, which will not be repeated here.

[0108] According to embodiments of this application, any plurality of modules among the connection module 610, authentication module 620, command module 630, and detection module 640 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of the connection module 610, authentication module 620, command module 630, and detection module 640 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the connection module 610, authentication module 620, command module 630, and detection module 640 can be at least partially implemented as a computer program module, which, when run, can perform corresponding functions.

[0109] Figure 7 A block diagram schematically illustrates an electronic device suitable for implementing a file transfer protocol server status detection method according to an embodiment of this application.

[0110] like Figure 7 As shown, an electronic device 700 according to an embodiment of this application includes a processor 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage portion 708 into a random access memory (RAM) 703. The processor 701 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 701 may also include onboard memory for caching purposes. The processor 701 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0111] RAM 703 stores various programs and data required for the operation of electronic device 700. Processor 701, ROM 702, and RAM 703 are interconnected via bus 704. Processor 701 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 702 and / or RAM 703. It should be noted that the programs may also be stored in one or more memories other than ROM 702 and RAM 703. Processor 701 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0112] According to embodiments of this application, the electronic device 700 may further include an input / output (I / O) interface 705, which is also connected to a bus 704. The electronic device 700 may also include one or more of the following components connected to the input / output (I / O) interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the input / output (I / O) interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0113] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0114] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 702 and / or RAM 703 and / or one or more memories other than ROM 702 and RAM 703 described above.

[0115] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code enables the computer system to implement the file transfer protocol server status detection method provided in the embodiments of this application.

[0116] When the computer program is executed by the processor 701, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0117] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 709, and / or installed from a removable medium 711. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0118] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 709, and / or installed from the removable medium 711. When the computer program is executed by the processor 701, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0119] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0120] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0121] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A method for detecting the status of a file transfer protocol server, characterized in that, include: Based on a preset detection time interval, a connection request is sent to the server, and a connection is established with the server within a connection time threshold to obtain a first result. The connection time threshold is set based on historical connection times within a preset time and a preset connection threshold. Send an authentication request to the server, and in response to receiving an authentication success status code corresponding to successful authentication, obtain a second result; Send a command request to the server, and in response to receiving a command response status code corresponding to the command request within a response time threshold, obtain a third result, wherein the response time threshold is set based on historical command response times within a preset time and a preset response threshold. Based on the first result, the second result, and the third result, the server status is determined to be normal.

2. The file transfer protocol server status detection method according to claim 1, characterized in that, The connection time threshold is set based on historical connection times within a preset time period and a preset connection threshold, including: A first connection threshold is obtained based on the historical average connection time and a preset connection coefficient, wherein the preset connection coefficient is greater than 1 and less than or equal to 2. The second connection threshold is obtained based on the nth percentile after sorting the historical connection times from smallest to largest, where n is greater than 50 and less than 100. The connection time threshold is set based on the maximum value among the first connection threshold, the second connection threshold, and the preset connection threshold.

3. The file transfer protocol server status detection method according to claim 1, characterized in that, The response time threshold is set based on historical command response times within a preset time period and a preset response threshold, including: A first response threshold is obtained based on the historical average command response time and a preset response coefficient, wherein the preset response coefficient is greater than 1 and less than or equal to 2. The second response threshold is obtained by sorting the historical command response times from smallest to largest by the m percentile, where m is greater than 50 and less than 100. The response time threshold is set based on the maximum value among the first response threshold, the second response threshold, and the preset response threshold.

4. The file transfer protocol server status detection method according to claim 1, characterized in that, After sending a connection request to the server, it also includes: In response to the failure to establish a connection with the server, a server connection error is determined, and a connection error alarm is triggered; or, If the time taken to establish a connection with the server exceeds the connection time threshold, a server connection abnormality is determined, and a connection abnormality alarm is triggered.

5. The file transfer protocol server status detection method according to claim 1, characterized in that, After sending the authentication request to the server, the method further includes: Upon receiving an authentication error status code corresponding to an authentication error, the server determines that authentication is abnormal and triggers an authentication error alarm; or, In response to the absence of the authentication success status code or the authentication error status code, the server authentication is determined to be abnormal, and an authentication abnormality alarm is triggered.

6. The file transfer protocol server status detection method according to claim 1, characterized in that, After sending the command request to the server, the method further includes: In response to the missing command response status code, a server service abnormality is determined, and a runtime abnormality alarm is triggered; or, If the time taken to receive the command response status code exceeds the response time threshold, a server service abnormality is determined, and a runtime abnormality alarm is triggered; or, Upon receiving a command and receiving an error status code, the server service is determined to be abnormal, triggering a runtime exception alarm.

7. The file transfer protocol server status detection method according to claim 6, characterized in that, After receiving the command response error status code, it also includes: Based on the command response error status code and the command request, locate the faulty node; Based on the stack information of the faulty node and the command request, the root cause of the runtime exception is obtained.

8. A file transfer protocol server status detection device, characterized in that, The device includes: The connection module is used to send a connection request to the server based on a preset detection time interval, and to establish a connection with the server within a connection time threshold to obtain a first result, wherein the connection time threshold is set based on historical connection times within a preset time and a preset connection threshold. The authentication module is used to send an authentication request to the server and, in response to receiving an authentication success status code corresponding to successful authentication, obtain a second result. The command module is used to send a command request to the server, and in response to receiving a command response status code corresponding to the command request within a response time threshold, obtain a third result, wherein the response time threshold is set based on historical command response times within a preset time and a preset response threshold. The detection module is used to determine that the server status is normal based on the first result, the second result, and the third result.

9. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images