Full-link tracking agricultural monitoring system and method based on Prometheus and Grafana, medium, terminal and program product

Abstract

The invention provides a Prometheus and Grafana-based full-link tracking agricultural monitoring system, a Prometheus and Grafana-based full-link tracking agricultural monitoring method, a medium, a terminal and a program product, and the system comprises a burying point deployment module which is used for deploying corresponding Prometheus burying points in all links in a full-link data flow path from an agricultural equipment side to a user side; the data acquisition module is used for acquiring monitoring index data corresponding to each Prometheus burying point and equipment response data of the agricultural equipment end in response to the execution instruction; the equipment fault matching module is used for carrying out feature comparison on the collected equipment response data and a pre-constructed abnormal response feature library and generating an equipment fault event; and the visual alarm module is used for carrying out visual display on the acquired monitoring index data based on Grafana, and triggering an alarm based on a preset alarm rule according to the monitoring index data and the equipment fault event. According to the invention, fine-grained monitoring tracking of the whole link can be realized, and the accuracy of agricultural equipment fault type identification is improved.

Description

Technical Field

[0001] This application relates to the field of smart agriculture technology, and in particular to a full-link tracking agricultural monitoring system, method, medium, terminal and program product based on Prometheus and Grafana. Background Technology

[0002] With the rapid development of smart agriculture, agricultural irrigation monitoring systems based on IoT technology have become a core means to achieve precision irrigation, water conservation, and increased efficiency. However, in large-scale deployment scenarios, the access of massive amounts of irrigation equipment poses a severe challenge to the real-time performance, reliability, and intelligent operation and maintenance capabilities of existing monitoring systems.

[0003] At the level of equipment status monitoring and fault diagnosis, existing monitoring technologies can usually only detect the single dimension of "data reporting interruption", but cannot effectively distinguish between physical damage to equipment (such as valve jamming) and data link failure (such as MQTT broker message backlog). This forces maintenance personnel to carry a variety of professional testing equipment to the site for manual troubleshooting, with an average fault location time of more than 2 hours. This seriously affects the continuity of irrigation operations and the normal rotation of irrigation in farmland, and may even cause production accidents such as flooding or drought in farmland.

[0004] Furthermore, at the data processing level, existing systems mostly employ batch processing or near real-time architectures to handle the massive amounts of status data reported by devices and control commands issued by the business platform. This architecture inherently suffers from high latency bottlenecks, resulting in data acquisition by the business platform typically being delayed by more than 60 seconds, failing to meet the real-time requirements of precise irrigation. Moreover, existing systems lack fine-grained monitoring and performance indicator collection for key nodes such as Kafka message queue backlogs and Redis write blockages throughout the entire processing stage, from data access, parsing, cleaning to forwarding. This results in the business platform failing to issue automatic alerts even when data latency exceeds one minute.

[0005] Therefore, it is necessary to provide a full-link tracking agricultural monitoring system, method, medium, terminal, and program product based on Prometheus and Grafana to solve the above-mentioned problems in the prior art. Summary of the Invention

[0006] In view of the shortcomings of the prior art described above, the purpose of this application is to provide a full-link tracking agricultural monitoring system, method, medium, terminal and program product based on Prometheus and Grafana, to solve the technical problems of low efficiency in agricultural equipment diagnosis, poor real-time data processing and lack of fine-grained monitoring in the prior art.

[0007] To achieve the above and other related objectives, the first aspect of this application provides a full-link tracking agricultural monitoring system based on Prometheus and Grafana, comprising:

[0008] The event tracking module is used to deploy corresponding Prometheus event tracking points at each stage of the entire data flow path from agricultural equipment to user.

[0009] The data acquisition module is used to collect monitoring indicator data corresponding to each of the Prometheus embedding points, as well as device response data from the agricultural equipment terminal in response to the execution instructions;

[0010] The equipment fault matching module is used to compare the collected equipment response data with a pre-built abnormal response feature library and generate equipment fault events.

[0011] The visualization alarm module is used to visualize the collected monitoring indicator data based on Grafana, and to trigger alarms based on preset alarm rules according to the monitoring indicator data and the device failure events.

[0012] In some embodiments of the first aspect of this application, the tracking point deployment module includes: a first tracking point deployment unit, configured to deploy corresponding Prometheus tracking points at each stage from the agricultural equipment end to the data platform layer, in order to obtain monitoring indicator data for each Prometheus tracking point; a second tracking point deployment unit, configured to deploy corresponding Prometheus tracking points at each stage from the data processing layer to the storage layer, in order to obtain monitoring indicator data for each Prometheus tracking point; and a third tracking point deployment unit, configured to deploy corresponding Prometheus tracking points at each stage from the business layer to the user end, in order to obtain monitoring indicator data for each Prometheus tracking point.

[0013] In some embodiments of the first aspect of this application, the specific process of deploying corresponding Prometheus tracking points at each stage from the agricultural equipment end to the data platform layer to obtain monitoring indicator data for each Prometheus tracking point includes: embedding Prometheus tracking points at the agricultural equipment end stage to obtain LoRa air interface transmission latency indicators for monitoring the network status of the agricultural equipment end; embedding Prometheus tracking points at the gateway stage to obtain MQTT sending latency indicators for monitoring the network link quality from the agricultural equipment end to the cloud; embedding Prometheus tracking points at the Kafka cluster stage to obtain Kafka enqueue time indicators for monitoring the performance of the internal integration link from the MQTT broker to the Kafka cluster; and embedding Prometheus tracking points at the data parsing service stage to obtain consumption latency indicators for monitoring the consumption processing capability of the data parsing service.

[0014] In some embodiments of the first aspect of this application, the specific process of deploying corresponding Prometheus tracking points at each stage from the data processing layer to the storage layer to obtain monitoring metric data for each Prometheus tracking point includes: embedding Prometheus tracking points at the protocol parsing stage to obtain protocol parsing time metrics for monitoring the performance of the parsing service in deconstructing raw device data; embedding Prometheus tracking points at the data cleaning stage to obtain field processing latency metrics for monitoring the business logic performance of data cleaning and transformation; embedding Prometheus tracking points at the Redis caching stage to obtain write response time metrics for monitoring cache access performance; and embedding Prometheus tracking points at the PostgreSQL cluster stage to obtain SQL execution time metrics for monitoring database query and write performance.

[0015] In some embodiments of the first aspect of this application, the specific process of deploying corresponding Prometheus event points at various stages from the business layer to the user end to obtain monitoring metric data for each Prometheus event point includes: embedding Prometheus event points at the business API stage to obtain data assembly latency metrics, used to monitor the performance of the business API in acquiring data and assembling it into the final output returned to the front end; embedding Prometheus event points at the message queue stage to obtain queue backlog metrics, used to monitor the asynchronous processing capability of the business platform in issuing commands; embedding Prometheus event points at the business platform stage to obtain HTTP reception latency metrics, used to monitor the response speed of the interface between the user end and the business platform; and embedding Prometheus event points at the user end stage to obtain front-end rendering time metrics, used to monitor the rendering performance of the user interface.

[0016] In some embodiments of the first aspect of this application, the visual alarm module includes: a primary alarm unit for sending triggered alarm notifications to the user terminal for processing; and an advanced alarm unit for automatically executing emergency plans.

[0017] To achieve the above and other related objectives, a second aspect of this application provides a full-link tracking agricultural monitoring method based on Prometheus and Grafana, comprising:

[0018] Deploy corresponding Prometheus tracking points at each stage of the end-to-end data flow path from agricultural equipment to user;

[0019] Collect monitoring index data corresponding to each of the Prometheus embedding points, as well as device response data from agricultural equipment in response to execution commands;

[0020] The collected device response data is compared with a pre-built abnormal response feature library to generate device failure events;

[0021] The collected monitoring metrics data are visualized using Grafana, and alarms are triggered based on preset alarm rules according to the monitoring metrics data and the device failure events.

[0022] To achieve the above and other related objectives, a third aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method.

[0023] To achieve the above and other related objectives, a fourth aspect of this application provides a computer program product comprising computer program code that, when executed on a computer, causes the computer to implement the method.

[0024] To achieve the above and other related objectives, a fifth aspect of this application provides an electronic terminal, including a memory, a processor, and a computer program stored in the memory; the processor executes the computer program to implement the method.

[0025] As described above, the end-to-end tracking agricultural monitoring system, method, medium, terminal, and program products based on Prometheus and Grafana of this application have the following beneficial effects:

[0026] By deploying corresponding Prometheus tracking points at each stage of the end-to-end data flow path from agricultural equipment to the user, monitoring metric data corresponding to each Prometheus tracking point is collected. This data is then visualized using Grafana, enabling rapid location of latency fault nodes based on the monitoring metric data at each stage of the entire process. This achieves fine-grained monitoring and real-time data processing throughout the entire processing stage from data access to the user end. Simultaneously, by comparing the collected equipment response data with a pre-built abnormal response feature library, the system can accurately distinguish equipment fault types, improving the accuracy of equipment fault type identification. Furthermore, alarms are triggered based on preset alarm rules, guiding maintenance personnel to quickly take appropriate measures and reducing maintenance costs. Attached Figure Description

[0027] Figure 1 The diagram shown is a block diagram of an end-to-end tracking agricultural monitoring system based on Prometheus and Grafana, as described in one embodiment of this application.

[0028] Figure 2 The diagram shown is a block diagram of the embedding deployment module in one embodiment of this application.

[0029] Figure 3 The diagram shows the workflow of a full-link tracking agricultural monitoring system based on Prometheus and Grafana, as described in one embodiment of this application.

[0030] Figure 4 The diagram shown is a schematic of the root cause analysis process of a full-link tracking agricultural monitoring system based on Prometheus and Grafana in one embodiment of this application.

[0031] Figure 5 The diagram shown is a flowchart of an end-to-end tracking agricultural monitoring method based on Prometheus and Grafana, according to one embodiment of this application.

[0032] Figure 6 The diagram shown is a structural schematic of an electronic terminal according to an embodiment of this application. Detailed Implementation

[0033] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0034] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. For example, "first XX" and "second XX" are merely used to distinguish different XXs and do not limit their order. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0035] It should be noted that, in the embodiments of this application, the words "exemplary" or "for example" indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0036] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0037] Before providing a further detailed description of the present invention, the nouns and terms used in the embodiments of the present invention are explained, and the nouns and terms used in the embodiments of the present invention are subject to the following interpretations:

[0038] <1> Prometheus is an open-source service monitoring system and time-series database, primarily used to record and query the operating status and performance metrics of a system. It has a built-in, efficient time-series data storage function specifically designed to store timestamped metric data. By periodically pulling (pulling) the metric data of the monitored targets, it enables health monitoring and alerting of systems, services, and containers. It also provides the flexible query language PromQL, supporting real-time monitoring, aggregation, and analysis functions.

[0039] <2> Grafana is an open-source analytics and monitoring platform primarily used to visualize time-series data from various data sources, such as Prometheus, Zabbix, InfluxDB, and Elasticsearch. With Grafana, users can create real-time monitoring dashboards, analyze data, and send alerts.

[0040] <3> MQTT (Message Queuing Telemetry Transport) is a lightweight message transport protocol based on a publish / subscribe model. It is designed for remote devices and resource-constrained applications connected in low-bandwidth, high-latency, or unstable network environments.

[0041] <4> The MQTT broker (Message Queuing Telemetry Transport Broker) is the central hub in a publish / subscribe messaging system. It receives messages from publishers and distributes them to subscribers. It plays a crucial role in managing the communication flow between MQTT clients and ensuring reliable message delivery.

[0042] <5> LoRa (Long Range Radio) is a low-power local area network wireless standard designed to resolve the conflict between power consumption and transmission range limitations. Generally, low power consumption results in shorter transmission distances, while high power consumption results in longer transmission distances. By developing LoRa technology, the technical problem of achieving longer transmission distances than other wireless methods under the same power consumption conditions has been solved, thus achieving a balance between low power consumption and long range.

[0043] <6> Kafka is a distributed message streaming platform that supports multiple partitions and replicas and is based on Zookeeper. It is also an open-source message engine system based on the publish-subscribe pattern.

[0044] <7> Redis (Remote Dictionary Server) is an open-source, network-enabled, in-memory or persistent, log-structured key-value database written in ANSI C, and provides APIs for multiple languages.

[0045] <8> PostgreSQL (Postgres Structured Query Language) is a powerful, open-source client / server relational database management system.

[0046] <9> SQL (Structured Query Language) is a database language with multiple functions such as data manipulation and data definition. This language is interactive and can provide great convenience to users.

[0047] <10> API (Application Programming Interface): A set of predefined functions designed to provide applications and developers with the ability to access a set of routines based on certain software or hardware, without needing to access the source code or understand the details of the internal workings.

[0048] <11> HTTP (Hypertext Transfer Protocol) is a simple request-response protocol that typically runs on top of TCP. It specifies what messages a client might send to a server and what responses it might receive. The headers of the request and response messages are given in ASCII format, while the message content has a MIME-like format. It is an application layer protocol used for distributed, collaborative, and hypermedia information systems.

[0049] <12> The Prometheus Exporter is a tool used to collect and expose metric data. It can convert the running status of a system, service, or application into a format that Prometheus can recognize. It is an indispensable component of the Prometheus monitoring system and mainly provides monitoring data to Prometheus via the HTTP protocol.

[0050] <13> RabbitMQ is an open-source message queue middleware implemented based on the AMQP protocol. Its core functions are decoupling systems, asynchronous communication, and peak shaving. RabbitMQ receives and forwards messages, acting as a "communication bridge" between different components in a distributed system. It allows producer and consumer programs to interact asynchronously without direct association.

[0051] <14> ACK (Acknowledge character): In data communication, a transmission control character sent by the receiving station to the sending station indicates that the received data has been acknowledged as correct.

[0052] <15> Prometheus Alertmanager is a component of the Prometheus monitoring system used to process alarms generated by Prometheus. It is responsible for receiving, deduplicating, grouping, suppressing, and notifying alarms, and is the core part of the Prometheus alarm mechanism.

[0053] To facilitate understanding of the embodiments of this application, firstly, in conjunction with Figure 1 Detailed explanation. Figure 1 This diagram illustrates a block diagram of a Prometheus and Grafana-based end-to-end tracking agricultural monitoring system according to an embodiment of the present invention. The Prometheus and Grafana-based end-to-end tracking agricultural monitoring system 100 in this embodiment includes: a data point deployment module 101, a data acquisition module 102, an equipment fault matching module 103, and a visualization alarm module 104.

[0054] The tracking point deployment module 101 is used to deploy corresponding Prometheus tracking points at each stage of the entire data flow path from agricultural equipment to user.

[0055] Prometheus tracking points are embedded in each stage of data collection, parsing, storage, and forwarding to collect metrics such as HTTP request time, Kafka backlog, and Redis latency.

[0056] In some embodiments of this application, such as Figure 2 As shown, the event tracking deployment module 101 includes: a first event tracking deployment unit 1011, used to deploy corresponding Prometheus event tracking points at each stage from the agricultural equipment end to the data platform layer, in order to obtain monitoring indicator data of each Prometheus event tracking point; a second event tracking deployment unit 1012, used to deploy corresponding Prometheus event tracking points at each stage from the data processing layer to the storage layer, in order to obtain monitoring indicator data of each Prometheus event tracking point; and a third event tracking deployment unit 1013, used to deploy corresponding Prometheus event tracking points at each stage from the business layer to the user end, in order to obtain monitoring indicator data of each Prometheus event tracking point.

[0057] In this embodiment, the monitoring path covers every link from agricultural equipment to data platform layer, data processing layer, storage layer, business layer, and user terminal. When a problem occurs, maintenance personnel can trace the source along this complete link, quickly locate the fault node, and greatly improve management and monitoring efficiency.

[0058] In some embodiments of this application, such as Figure 3As shown, the process of deploying corresponding Prometheus tracking points at each stage from the agricultural equipment end to the data platform layer to obtain monitoring metric data for each Prometheus tracking point includes: embedding Prometheus tracking points at the agricultural equipment end to obtain LoRa air interface transmission latency metrics for monitoring the network status of the agricultural equipment end; embedding Prometheus tracking points at the gateway end to obtain MQTT sending latency metrics for monitoring the network link quality from the agricultural equipment end to the cloud; embedding Prometheus tracking points at the Kafka cluster end to obtain Kafka enqueue time metrics for monitoring the performance of the internal integration link from the MQTT broker end to the Kafka cluster; and embedding Prometheus tracking points at the data parsing service end to obtain consumption latency metrics for monitoring the consumption processing capacity of the data parsing service.

[0059] In this embodiment, Prometheus tracking points are deployed at each stage from the agricultural equipment to the data platform layer. This stage monitors the entire process of data generation from the IoT device to its processing within the data platform, ensuring the real-time performance and stability of data processing. Specifically, at the agricultural equipment end, the time taken for message data to be transmitted over the wireless spectrum is calculated. If the LoRa air interface transmission delay exceeds the first threshold of 1 second, it indicates a network anomaly at the agricultural equipment end, issuing a yellow alarm and requiring investigation of the device's signal network. The gateway timestamp in the message is recorded at the gateway, and the difference between this and the timestamp received by the agent is used to obtain the MQTT message publication time. If this exceeds the second threshold of 500 ms, it indicates network transmission delay, issuing a yellow alarm and requiring investigation of the carrier link or agent load. At the Kafka cluster, the time from receiving the message at the agent to successfully writing the message to the Kafka queue is calculated. If this exceeds the third threshold of 2 seconds, it indicates message enqueueing is blocked, issuing a red alarm and requiring investigation of the MQTT agent's backend connector or the network between it and the Kafka cluster. By monitoring the lag value of the Kafka consumer group to obtain the consumption latency metric, if the number of pending messages exceeds the fourth threshold of 1000, it indicates a bottleneck in data processing, issuing a red alert, which may be due to insufficient performance of the parsing service or complex parsing logic. For example, a Prometheus exporter can be deployed on the MQTT broker and Kafka cluster to expose the monitoring metrics.

[0060] In some embodiments of this application, such as Figure 3As shown, the deployment of corresponding Prometheus tracking points at each stage from the data processing layer to the storage layer to obtain monitoring metric data for each Prometheus tracking point includes the following specific processes: embedding Prometheus tracking points in the protocol parsing stage to obtain protocol parsing time metrics, used to monitor the performance of the parsing service in deconstructing raw device data; embedding Prometheus tracking points in the data cleaning stage to obtain field processing latency metrics, used to monitor the business logic performance of data cleaning and transformation; embedding Prometheus tracking points in the Redis caching stage to obtain write response time metrics, used to monitor cache access performance; and embedding Prometheus tracking points in the PostgreSQL cluster stage to obtain SQL execution time metrics, used to monitor database query and write performance.

[0061] In this embodiment, Prometheus tracking points are deployed at each stage from the data processing layer to the storage layer. This stage monitors the process of data processing, cleaning, caching, and persistence within the platform, ensuring data accuracy. Specifically, the Prometheus client library is used to record the time taken from receiving the raw message to completing parsing. If it exceeds the fifth threshold of 200ms, it indicates a protocol parsing timeout, issuing an orange alert, possibly due to abnormal data format or degraded parsing service performance. Similarly, the Prometheus client library is used to record the average time taken to process a single message or batch of data. If it exceeds the sixth threshold of 50% of the same type, it indicates a decrease in cleaning efficiency, issuing an orange alert. A Prometheus exporter is deployed in the Redis cache to obtain write response time metrics. If it exceeds the seventh threshold of 10ms, it indicates a cache write anomaly, issuing an immediate alert, requiring immediate inspection of Redis. A Prometheus exporter is deployed in the PostgreSQL cluster to obtain SQL execution time metrics. If it exceeds the eighth threshold of 100ms, it indicates a need for database query optimization, providing automatic suggestions and triggering database query optimization recommendations.

[0062] In some embodiments of this application, such as Figure 3As shown, the specific process of deploying corresponding Prometheus event tracking points at each stage from the business layer to the user end to obtain monitoring metric data for each Prometheus event tracking point includes: embedding Prometheus event tracking points at the business API stage to obtain data assembly latency metrics, used to monitor the performance of the business API in acquiring data and assembling it into the final response returned to the front end; embedding Prometheus event tracking points at the message queue stage to obtain queue backlog metrics, used to monitor the asynchronous processing capability of the business platform in issuing commands; embedding Prometheus event tracking points at the business platform stage to obtain HTTP reception latency metrics, used to monitor the response speed of the interface between the user end and the business platform; and embedding Prometheus event tracking points at the user end stage to obtain front-end rendering time metrics, used to monitor the rendering performance of the user interface.

[0063] In this embodiment, Prometheus tracking points are deployed at each stage from the business layer to the user end. This stage monitors business logic processing, command issuance, and the end-user experience to ensure a positive user experience. Specifically, Prometheus exporters are deployed at the business API and RabbitMQ message queue stages to obtain data assembly latency and queue backlog metrics, respectively. Middleware or interceptors are used in the business platform API service to record the time taken for each HTTP request, obtaining the HTTP reception latency metric. If the sum of the data assembly latency, queue backlog, and HTTP reception latency metrics exceeds the ninth threshold of 5 seconds, the current operation should be interrupted, implementing a forced circuit breaker to avoid erroneous business results. Frontend performance API data is collected and exposed to Prometheus to obtain the frontend rendering time metric. If it exceeds the tenth threshold of 3 seconds, a frontend performance optimization work order is triggered. It should be noted that red alerts indicate core faults requiring immediate intervention, which will affect business continuity; orange alerts indicate potential risks that need to be addressed on the same day, as they may trigger red alerts; and yellow alerts indicate observational warnings, requiring monitoring of trend changes.

[0064] A closed-loop monitoring system is established to monitor the entire data flow from agricultural equipment to the user interface. Any timeout at any stage automatically pinpoints the bottleneck. For example, if the number of pending messages exceeds the fourth threshold of 1000, Kafka expansion will be triggered. Simultaneously, due to the periodicity of business traffic and system load, key metrics such as data assembly latency are designed with dynamic threshold alarms. The dynamic baseline equals the average of the same period over the past seven days plus three times the standard deviation, thus dynamically adapting to periodic fluctuations. An alarm is only triggered when the metric value abnormally deviates from its normal historical pattern. For instance, if a valve operation API has an average latency of 50ms, an alarm will be triggered immediately if it suddenly increases to 200ms.

[0065] The data acquisition module 102 is used to collect monitoring indicator data corresponding to each of the Prometheus embedding points, as well as device response data from the agricultural equipment end in response to the execution command.

[0066] Specifically, based on the Prometheus server, monitoring indicator data is periodically captured and stored from Prometheus endpoints at each stage of the entire chain, and the equipment response data reported by agricultural equipment after executing instructions is collected, realizing the collection of multi-dimensional data and providing a data foundation for subsequent intelligent fault diagnosis and full-chain tracing.

[0067] The equipment fault matching module 103 is used to compare the collected equipment response data with a pre-built abnormal response feature library and generate equipment fault events.

[0068] Specifically, the system first analyzes the collected equipment response data and extracts key features. Then, it matches these extracted features with a pre-built abnormal response feature library in real time. If a match is successful, a structured equipment fault event is generated; if a match fails, the system returns to continuous monitoring, accurately distinguishing the fault type. For example, the abnormal response features in the abnormal response feature library include valve opening / closing angle difference thresholds and pump current mutation patterns.

[0069] Taking the scenario of a business platform issuing a command to a valve to "open to 90 degrees" as an example, all data within a complete command-response cycle is collected and analyzed in real time to extract key features, such as "no ACK response, link completely disconnected," "ACK response, but no angle change," and "ACK response and action, but fixed angle deviation." Typical fault modes in the abnormal response feature library include "mechanical jamming," "sensor drift," and "communication interruption." These three key features are compared with the pre-built abnormal response feature library. "No ACK response, link completely disconnected" matches "communication interruption" in the abnormal response feature library, and is identified as the fault diagnosis result "communication interruption." "ACK response, but no angle change" matches "mechanical jamming" in the abnormal response feature library, and is identified as the fault diagnosis result "mechanical jamming." "ACK response and action, but fixed angle deviation" matches "sensor drift" in the abnormal response feature library, and is identified as the fault diagnosis result "sensor drift." Based on different fault diagnosis results, different response strategies are triggered, thereby achieving precise and automated operation and maintenance.

[0070] The visualization alarm module 104 is used to visualize the collected monitoring indicator data based on Grafana, and to trigger alarms based on preset alarm rules according to the monitoring indicator data and the equipment failure events.

[0071] In this embodiment, Prometheus is configured as the data source in Grafana to visualize the monitoring metrics data collected by each Prometheus tracking point. This provides an intuitive and clear understanding of the entire device and business operation status, aiding in rapid decision-making. Preset thresholds are established for the monitoring metrics data of each Prometheus tracking point. Based on preset alarm rules, the data is routed to Prometheus Alertmanager. After grouping and noise reduction by Prometheus Alertmanager, alarm notifications are sent. Alternatively, threshold alarms can be set directly on the Grafana dashboard to trigger alarms for each monitored metric. The aforementioned generated device failure events need to be converted into Prometheus metrics and exposed to Prometheus. Grafana then directly displays the failure type on the dashboard, such as "mechanical jam," allowing operations personnel to directly visualize the global device status. Simultaneously, triggered alarms can be viewed in the Grafana alarm dashboard based on preset alarm rules. Notifications are triggered and alarms are sent via Prometheus Alertmanager or Grafana's notification channel.

[0072] In some embodiments of this application, the visual alarm module includes: a primary alarm unit for sending triggered alarm notifications to the user terminal for processing; and an advanced alarm unit for automatically executing emergency plans.

[0073] Specifically, the primary alarm unit sends alarm notifications to maintenance personnel via DingTalk or similar platforms for processing. The advanced alarm unit automatically executes emergency plans when equipment failures directly impact production. For example, it automatically cuts off the water supply to the faulty valve V3 and activates the backup valve to ensure uninterrupted irrigation operations. After the equipment failure is resolved, the system automatically pushes an "alarm cleared" notification to the business platform, completing the maintenance loop.

[0074] Furthermore, a specific example is provided using the scenario of fault diagnosis for valve group control in a tank farm to illustrate the end-to-end tracking agricultural monitoring system based on Prometheus and Grafana: A user issues a business command to open 10 valves via an app, and the business platform issues a "open to 90 degrees" command to each of the 10 valves. The system monitors the response data of each valve, and the response data of each valve is reported to the business platform. At this point, it is detected that the opening angle of valve V3 is only 30 degrees, deviating from the target 90 degrees. The key feature extracted is "ACK response present, but no change in angle," which is consistent with the abnormal response characteristics. Matching "mechanical jamming" in the database generates a clear fault event, enabling fault detection and intelligent diagnosis. Prometheus captures command response delays >5s, triggering an alarm to Grafana. Grafana triggers a two-level alarm response: the primary alarm notifies maintenance personnel via channels such as DingTalk, while the advanced alarm executes a preset automated fault emergency plan, automatically cutting off the water supply channel of valve V3 and activating the backup valve. Maintenance personnel go to the site to resolve the fault according to the notification. After the fault is resolved, the system pushes a notification "Alarm cleared: Valve V3 has been replaced" to the business platform.

[0075] Furthermore, such as Figure 4 As shown, a detailed example of the root cause tracing process is provided: A user reports a "valve status delay," prompting operations personnel to check various deployed tracking points. The tracing reveals an "HTTP receive timeout" at the service boundary of the business platform. Continuing to trace the source, they find 5000 messages backlogged in the RabbitMQ message queue. Combined with the "HTTP receive timeout," it can be inferred that the business platform service is unable to consume messages normally, preventing new requests from being processed. Therefore, the root cause is determined to be a "business platform service outage." This demonstrates a closed-loop troubleshooting process from user feedback to root cause location, enabling rapid root cause identification and significantly improving troubleshooting efficiency.

[0076] The end-to-end tracking agricultural monitoring system based on Prometheus and Grafana provided in this application embodiment can automatically distinguish fault types and locate faulty links by designing feature analysis based on device command-response patterns. At the same time, by monitoring the end-to-end data flow from data collection to business push and providing real-time backlog warnings, it ensures that the accuracy of device fault type identification is greater than 95%, the average response time of command operation is less than 3 seconds, a single node supports a data throughput of 50,000 devices / second, the Prometheus time-series data compression ratio reaches 1:10, and the data loss rate is less than 0.001%, which greatly improves data processing capabilities, storage efficiency, and reliability.

[0077] Figure 5This is a flowchart illustrating the end-to-end tracking agricultural monitoring method based on Prometheus and Grafana provided in this application embodiment. Figure 5 As shown, the end-to-end tracking agricultural monitoring method based on Prometheus and Grafana includes the following steps:

[0078] Step S51: Deploy corresponding Prometheus tracking points at each stage of the end-to-end data flow path from agricultural equipment to user.

[0079] Step S52: Collect monitoring indicator data corresponding to each of the Prometheus embedding points, as well as device response data of agricultural equipment responding to execution commands;

[0080] Step S53: Compare the collected device response data with the pre-built abnormal response feature library and generate a device failure event;

[0081] Step S54: Visualize the collected monitoring indicator data using Grafana, and trigger alarms based on preset alarm rules according to the monitoring indicator data and the device fault events.

[0082] It should be understood that the Prometheus and Grafana-based end-to-end tracking agricultural monitoring method of this embodiment can realize the above-mentioned Prometheus and Grafana-based end-to-end tracking agricultural monitoring system, and will not be described in detail here for the sake of brevity.

[0083] It should also be understood that the module division in the embodiments of this application is illustrative and only represents a logical functional division; in actual implementation, there may be other division methods. Furthermore, the functional modules in the various embodiments of this application can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0084] Figure 6 This is a schematic block diagram of the electronic terminal provided in an embodiment of this application. Figure 6 As shown, the electronic terminal 600 includes at least one processor 601, a memory 602, at least one network interface 603, and a user interface 605. The various components in the electronic terminal 600 are coupled together via a bus system 604. It is understood that the bus system 604 is used to implement communication between these components. In addition to a data bus, the bus system 604 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 6 The general will label all buses as bus systems.

[0085] The user interface 605 may include a monitor, keyboard, mouse, trackball, clicker, button, touchpad, or touch screen.

[0086] It is understood that memory 602 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM) or programmable read-only memory (PROM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memories described in the embodiments of this invention are intended to include, but are not limited to, these and any other suitable categories of memory.

[0087] In this embodiment of the invention, the memory 602 is used to store various types of data to support the operation of the electronic terminal 600. Examples of this data include: any executable program for operation on the electronic terminal 600, such as the operating system 6021 and application programs 6022; the operating system 6021 contains various system programs, such as the framework layer, core library layer, driver layer, etc., for implementing various basic services and handling hardware-based tasks. The application program 6022 may contain various applications, such as a media player, browser, etc., for implementing various application services. The methods provided in this embodiment of the invention can be included in the application program 6022.

[0088] The methods disclosed in the above embodiments of the present invention can be applied to processor 601, or implemented by processor 601. Processor 601 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 601 or by instructions in the form of software. The processor 601 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 601 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. General-purpose processor 601 may be a microprocessor or any conventional processor, etc. The steps of the accessory optimization method provided in the embodiments of the present invention can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, which is located in a memory. The processor reads the information in the memory and combines it with its hardware to complete the steps of the aforementioned method.

[0089] In an exemplary embodiment, the electronic terminal 600 may be used by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), or complex programmable logic devices (CPLDs) to perform the aforementioned method.

[0090] According to the method provided in the embodiments of this application, this application also provides a computer program product, which includes: computer program code, which, when run on a computer, causes the computer to execute... Figure 5 The method in the illustrated embodiment.

[0091] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium storing program code, which, when executed on a computer, causes the computer to perform... Figure 5 The method in the illustrated embodiment.

[0092] As used in this specification, the terms "component," "module," "system," etc., are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process and / or an execution thread, and components may be located on a single computer and / or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, and / or a network, such as the Internet interacting with other systems via signals).

[0093] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0094] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0095] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0096] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0097] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0098] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. A computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs, DVDs), or semiconductor media (e.g., solid-state disks, SSDs, etc.).

[0099] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0100] In summary, addressing the technical problems of low diagnostic efficiency, poor real-time data processing, and lack of fine-grained monitoring in existing agricultural equipment technologies, this application provides a full-link tracking agricultural monitoring system, method, medium, terminal, and program product based on Prometheus and Grafana. By deploying corresponding Prometheus tracking points at each stage of the data flow path from the farmer's equipment to the user, monitoring indicator data corresponding to each Prometheus tracking point is collected. The collected monitoring indicator data is then visualized using Grafana, enabling rapid location of delay fault nodes based on the monitoring indicator data at each stage of the tracking process. This achieves fine-grained monitoring and real-time data processing throughout the entire processing stage from data access to the user. Simultaneously, by comparing the collected equipment response data with a pre-built abnormal response feature library, the type of equipment fault can be accurately distinguished, improving the accuracy of equipment fault type identification. Furthermore, alarms are triggered based on preset alarm rules, guiding maintenance personnel to quickly take appropriate measures and reducing maintenance costs. Therefore, this application effectively overcomes the various shortcomings of existing technologies and has high industrial application value.

[0101] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A full-link tracking agricultural monitoring system based on Prometheus and Grafana, characterized in that, include: The event tracking module is used to deploy corresponding Prometheus event tracking points at each stage of the entire data flow path from agricultural equipment to user. The data acquisition module is used to collect monitoring indicator data corresponding to each of the Prometheus embedding points, as well as device response data from the agricultural equipment terminal in response to the execution instructions; The equipment fault matching module is used to compare the collected equipment response data with a pre-built abnormal response feature library and generate equipment fault events. The visualization alarm module is used to visualize the collected monitoring indicator data based on Grafana, and to trigger alarms based on preset alarm rules according to the monitoring indicator data and the device failure events.

2. The end-to-end tracking agricultural monitoring system based on Prometheus and Grafana according to claim 1, characterized in that, The data point deployment module includes: The first data point deployment unit is used to deploy corresponding Prometheus data points at each stage from the agricultural equipment end to the data platform layer, so as to obtain the monitoring indicator data of each Prometheus data point. The second event point deployment unit is used to deploy corresponding Prometheus event points at each stage from the data processing layer to the storage layer in order to obtain the monitoring metric data of each Prometheus event point. The third event tracking deployment unit is used to deploy corresponding Prometheus event tracking points at various stages from the business layer to the user end, in order to obtain monitoring metric data for each Prometheus event tracking point.

3. The end-to-end tracking agricultural monitoring system based on Prometheus and Grafana according to claim 2, characterized in that, The specific process of deploying corresponding Prometheus tracking points at each stage from the agricultural equipment end to the data platform layer to obtain monitoring indicator data for each Prometheus tracking point includes: By embedding Prometheus points at the agricultural equipment end, LoRa air interface transmission latency metrics can be obtained to monitor the network status of the agricultural equipment. By embedding Prometheus tracking points at the gateway level, MQTT sending latency metrics can be obtained to monitor the quality of the network link from the agricultural equipment to the cloud. Integrate Prometheus tracking points into the Kafka cluster to obtain Kafka enqueue time metrics, which are used to monitor the performance of the internal integration link from the MQTT broker to the Kafka cluster. By embedding Prometheus tracking points in the data parsing service, consumption latency metrics can be obtained to monitor the consumption processing capacity of the data parsing service.

4. The end-to-end tracking agricultural monitoring system based on Prometheus and Grafana according to claim 3, characterized in that, The specific process of deploying corresponding Prometheus tracking points at each stage from the data processing layer to the storage layer to obtain monitoring metric data for each Prometheus tracking point includes: Prometheus tracking points are embedded in the protocol parsing process to obtain protocol parsing time metrics, which are used to monitor the performance of the parsing service in deconstructing raw device data. In the data cleaning process, Prometheus tracking points are embedded to obtain field processing latency metrics, which are used to monitor the performance of business logic in data cleaning and transformation. We embed Prometheus tracking points in the Redis caching process to obtain write response time metrics for monitoring cache access performance. By embedding Prometheus tracking points in the PostgreSQL cluster, we can obtain SQL execution time metrics to monitor the database's query and write performance.

5. The end-to-end tracking agricultural monitoring system based on Prometheus and Grafana according to claim 4, characterized in that, The specific process of deploying corresponding Prometheus tracking points at each stage from the business layer to the user end to obtain monitoring metric data for each Prometheus tracking point includes: Integrate Prometheus tracking points into the business API stage to obtain data assembly latency metrics, which are used to monitor the performance of the business API in acquiring data and assembling it into the final return to the front end. We embed Prometheus tracking points in the message queue stage to obtain queue backlog metrics, which are used to monitor the asynchronous processing capabilities of commands issued by the business platform. By embedding Prometheus tracking points in the business platform, we can obtain HTTP reception latency metrics to monitor the response speed of the interface between the user client and the business platform. By embedding Prometheus tracking points on the user side, we can obtain front-end rendering time metrics to monitor the rendering performance of the user interface.

6. The end-to-end tracking agricultural monitoring system based on Prometheus and Grafana according to claim 1, characterized in that, The visual alarm module includes: The primary alarm unit is used to send the triggered alarm notifications to the user terminal for processing; Advanced alarm unit, used to automatically execute emergency response plans.

7. A method for end-to-end tracking and monitoring agriculture based on Prometheus and Grafana, characterized in that, include: Deploy corresponding Prometheus tracking points at each stage of the end-to-end data flow path from agricultural equipment to user; Collect monitoring index data corresponding to each of the Prometheus embedding points, as well as device response data from agricultural equipment in response to execution commands; The collected device response data is compared with a pre-built abnormal response feature library to generate device failure events; The collected monitoring metrics data are visualized using Grafana, and alarms are triggered based on preset alarm rules according to the monitoring metrics data and the device failure events.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in claim 7.

9. A computer program product, characterized in that, The computer program product includes computer program code that, when run on a computer, causes the computer to implement the method as described in claim 7.

10. An electronic terminal, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the method as described in claim 7.

Images