A service level objective (SLO) full life cycle management and analysis method based on time series data

Abstract

The application provides a SLO full life cycle management and analysis method based on time sequence data, which comprises the following steps: creating a service level objective (SLO) rule, and establishing an association relationship between SLI and SLO; starting a first timing task, and calling a cold start function at the first start to calculate and store SLI daily granularity achievement rate data in a historical double configuration period; starting a second timing task, and querying daily granularity achievement rate data of all SLIs belonging to the same SLO of the previous day at a second preset time point every day, and then performing weighted summation according to respective weights; and starting a third timing task, and performing the task according to a preset period, and then obtaining SLO daily granularity achievement rate data in combination with real-time calculated daily SLO achievement rate data to calculate SLO analysis data. Through a data readiness mechanism, the technical problems of long SLI data blank period and non-fault period interference in achievement rate calculation in the traditional scheme are solved.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to a method for SLO full lifecycle management and analysis based on time-series data. Background Technology

[0002] With the widespread adoption of cloud-native and microservice architectures, enterprises have an increasingly urgent need to monitor and manage service quality indicators such as availability and performance of their business systems. Traditional monitoring systems primarily focus on the utilization of infrastructure resources (such as CPU, memory, and disk) and the basic availability of application components (such as process status and HTTP status codes). This "resource-centric" monitoring model struggles to accurately reflect the real-world experience of end users and the health of business flows. Service Level Objectives (SLOs), as the core standard for measuring system service quality, rely on the accurate collection, calculation, and analysis of Service Level Indicators (SLIs) for effective implementation.

[0003] Currently, the technical solutions for SLO management in the industry are mainly divided into two categories: the first category is a combination solution based on general monitoring systems (such as Prometheus), which realizes SLO monitoring and display by manually writing query statements and alarm rules; the second category is a dedicated SLO computing framework or early commercial products (such as the open-source SLO computing framework Sloth and the open-source SLO declarative configuration specification OpenSLO), which attempt to simplify the definition of SLO and rule generation through declarative configuration.

[0004] However, current SLO / SLI management solutions in the industry have the following technical shortcomings: 1. Fragmented data storage and difficult integration: Server metrics and application performance metrics (such as APM data) are usually stored in different systems with inconsistent data formats and a lack of standardized time-series data management methods, which makes data integration difficult and inefficient when generating SLI metrics.

[0005] 2. Low automation in SLI generation and long historical data gaps: Traditional SLI metrics require manual writing of query rules, resulting in high repetition in rule configuration for different services and metrics, and the inability to dynamically generate rules based on business needs. More importantly, after creating a new SLI, it takes more than 24 hours to accumulate enough historical data for SLO calculation, making it impossible to quickly assess the historical achievement status of new SLOs, severely affecting the rationality and timeliness of SLO configuration.

[0006] 3. Insufficient SLO analysis efficiency and high real-time computing pressure: Existing solutions mostly adopt a pure real-time computing mode. When there are many SLOs and a large amount of data, frequent real-time queries will put a huge pressure on the time series database, resulting in a delay in the return of analysis results, which cannot meet the needs of real-time operation and maintenance decision-making.

[0007] 4. Low level of intelligence in error budget management and simple early warning mechanism: The calculation of the burn rate of error budget, the assessment of remaining budget and the prediction of exhaustion time are mostly static rules, lacking dynamic analysis combined with historical data, and the risk level judgment and alarm linkage are not close, which easily leads to problems such as alarm lag or false alarms.

[0008] 5. Lack of full lifecycle management and inconsistencies in configuration: The configuration, editing, deletion of SLOs and their association with alarm rules and SLI metrics are not closed-loop, which can easily lead to inconsistencies in configuration (such as not deleting associated alarm rules after deleting an SLO) and imprecise access control, increasing the complexity of operation and maintenance management.

[0009] 6. Lack of intelligent prediction and simulation capabilities: Existing solutions can only analyze the current error budget status, and cannot intelligently predict the SLO target threshold based on historical data, nor can they simulate the error budget consumption under different business scenarios, making it difficult to avoid service quality risks in advance.

[0010] 7. Lack of hierarchical constraints in baseline threshold adjustment, making early warnings prone to failure: Existing baseline threshold adjustment schemes lack a hierarchical constraint mechanism with respect to the SLO target threshold. When system performance deviates continuously, the baseline threshold adjustment may approach or even exceed the SLO target threshold without restriction, causing the early warning line to fail. The baseline originally intended for early warning has actually coincided with or exceeded the SLO target, rendering it ineffective for early warning.

[0011] Meanwhile, during the implementation of observability platforms, the performance data collected by application performance monitoring (APM) tools (such as SkyWalking) and the indicator data of the monitoring system are difficult to integrate seamlessly. The lack of standardized processes for preprocessing operations such as data cleaning and label conversion further restricts the efficiency and accuracy of SLO / SLI management. Summary of the Invention

[0012] In view of the above situation, the main objective of this invention is to propose a method for SLO full lifecycle management and analysis based on time-series data in order to solve the above-mentioned technical problems.

[0013] This invention proposes a method for SLO (Solution Lifecycle Management) management and analysis based on time-series data, the method comprising the following steps: S1. Create Service Level Objective (SLO) rules, generate unique identifiers (SLO IDs), preprocess multi-source heterogeneous observability data, and store them in a pre-set time series database to obtain standardized time series data. S2. Based on the unique identifier SLO ID, configure the SLO service level index SLI. Each SLI is configured with calculation rules and weights and stored in a preset persistent database to establish the association between SLI and SLO. S3. Based on standardized time-series data and the relationship between SLI and SLO, when an SLI rule is added or modified, the first scheduled task is started. At the first preset time of the day, the invalid time period is eliminated by combining the planned downtime and service deployment time to generate the daily SLI granularity achievement rate and store it in the preset time-series database to obtain the daily SLI granularity achievement rate data. S4. Based on the SLI daily granularity achievement rate data, start the second scheduled task. At the second preset time each day, query the daily granularity achievement rate data of all SLIs belonging to the same SLO from the previous day, perform weighted summation according to their respective weights, and store it in the preset time series database to obtain historical SLO daily granularity achievement rate data. S5. Based on historical SLO daily granularity achievement rate data, start the third timed task and execute it according to the preset cycle. Each time it is executed, obtain the historical SLO daily granularity achievement rate data and combine it with the real-time calculated SLO achievement rate data for the current cycle to obtain the SLO achievement rate and calculate the SLO analysis data; update the SLO analysis data to the cache. S6. When a user accesses SLO, the SLO analysis data is read from the cache and displayed.

[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention solves the technical challenges of long SLI data gaps and interference achievement rate calculations during non-fault periods in traditional solutions through a data-ready mechanism. Unlike existing technologies that rely on manually writing query rules and passively waiting for data accumulation, this invention establishes a unified data cleaning and format conversion mechanism to integrate multi-source heterogeneous data into standardized time-series data. Based on this, a cold-start function is set up to automatically complete historical data when SLI rules are added or modified, enabling newly created SLIs to have months of historical data within minutes. Simultaneously, a "dual-source time window" elimination mechanism automatically removes invalid periods from planned downtime and service deployment times. This collaborative design eliminates data gaps and calculation distortions at the source, freeing maintenance personnel from the arduous task of manually writing repetitive rules.

[0015] 2. This invention achieves complete separation of computation and query through a hybrid computing architecture of "layered pre-computation + query isolation," resulting in an exponential improvement in SLO analysis efficiency. Unlike existing solutions that rely on pure real-time computation, leading to excessive pressure on time-series databases, this invention constructs a three-layered, progressively structured timed task chain: the first layer compresses raw indicator data into daily SLO granularity achievement rates; the second layer performs weighted aggregation to obtain daily SLO granularity achievement rates; and the third layer employs a hybrid model of "historical offline batch processing + daily real-time stream computation," reading historical daily granular data from the time-series database and combining it with real-time computation to obtain SLO analysis data, which is then stored in a high-speed cache. Front-end queries only perform pure read operations. This collaborative design reduces query complexity from aggregating tens of thousands of data points to reading just a few result values, significantly alleviating the pressure on the time-series database and resulting in an exponential improvement in SLO analysis efficiency.

[0016] 3. This invention upgrades the system from static rule-based judgment to dynamic trend early warning through a "weighted aggregation + safety margin constraint" analysis mechanism. Unlike existing technologies where error budget management often relies on static rules and unrestricted benchmark threshold adjustments leading to early warning failures, this invention employs a weighted summation algorithm to aggregate SLO achievement rates according to their business weights, ensuring that SLO achievement rates objectively reflect the actual impact on underlying services. It uses an available time-weighted average method to calculate long-term SLO achievement rates, making the calculation results closer to the actual service operation. A benchmark reference threshold is generated based on historical data completed during cold starts, and safety margin constraints ensure that the benchmark is always lower than the target threshold. The adjusted benchmark is then used for early warning. This collaborative design allows the warning line to adaptively adjust with continuous deviations in system performance while maintaining a fixed hierarchical relationship with the target threshold, significantly reducing the risk of alarm lag and false alarms.

[0017] 4. This invention achieves a balance between flexibility and security in SLO management through a full lifecycle management system of "configuration synchronization + closed-loop permission control." Unlike existing technologies that suffer from non-closed-loop association between SLO configurations and alarm rules, and imprecise permission control, this invention associates SLO configuration information with SLO IDs and stores them in a persistent database. This ensures that all associated configurations are updated or deleted synchronously when an SLO is created, edited, or deleted, forming a closed-loop configuration management system. Furthermore, it embeds joint permission control based on roles and business groups, binding each SLO rule to a business group tag. When a user requests to operate an SLO, their role permissions and business group permissions are simultaneously verified, dynamically binding permission control to the organizational structure. This collaborative design simplifies complex matrix-style permission management into a linear "team-business group" model, significantly improving the flexibility and maintainability of SLO management in multi-team collaboration scenarios while ensuring security.

[0018] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by means of embodiments of the invention. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the steps of a time-series data-based SLO full lifecycle management and analysis method proposed in this invention.

[0020] Figure 2 This is an overall architecture diagram of a time-series data-based SLO full lifecycle management and analysis method proposed in this invention. Detailed Implementation

[0021] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0022] These and other aspects of the embodiments of the present invention will become clear from the following description and accompanying drawings. In these descriptions and drawings, some specific embodiments of the present invention are specifically disclosed to provide some ways of implementing the principles of the embodiments of the present invention; however, it should be understood that the scope of the embodiments of the present invention is not limited thereto.

[0023] Please see Figure 1 This invention proposes a method for SLO full lifecycle management and analysis based on time-series data, which includes the following steps: S1. Create Service Level Target (SLO) rules, generate unique identifiers (SLO IDs), preprocess multi-source heterogeneous observability data, and store them in a pre-defined time-series database to obtain standardized time-series data.

[0024] Please see Figure 2 In step S1, Service Level Target (SLO) rules are created, a unique identifier (SLO ID) is generated, and the multi-source heterogeneous observability data is preprocessed and stored in a preset time-series database to obtain standardized time-series data. Specifically, the steps include: Obtain observability data from multiple heterogeneous sources; wherein, the observable data includes: service-level, interface-level, and instance-level service performance indicators defined by the observation analysis language syntax, as well as infrastructure indicators and middleware indicators collected by the monitoring data collector; Based on a pre-configured YAML indicator whitelist, observable data is filtered to remove invalid indicators, resulting in filtered indicator data. The filtered metric data is received via the gRPC protocol, the SkyWalking native tags are converted into a unified Prometheus tag format, and business group tags and environment tags are injected to obtain standardized metric data. The standardized indicator data is written in batches into a preset time series database to obtain standardized time series data.

[0025] In this embodiment of the invention, the implementation is based on the open-source APM tool SkyWalking, the data collector categraf, and the time-series database VictoriaMetrics (VM). The system first defines service-level, interface-level, and instance-level performance metric collection rules using SkyWalking's OAL (Observability Analysis Language) scripts. The collected raw data is streamed via gRPC to a data cleaning service, which filters invalid metrics based on a pre-defined YAML whitelist and converts SkyWalking's native tags (such as service and endpoint) into Prometheus standard format (such as service_name), while injecting business tags such as business groups and environments. Finally, the standardized data is batch-written through VM's Remote Write interface, and categraf directly collects infrastructure and middleware time-series metrics and stores them in VM, constructing a unified time-series data foundation and solving the problem of the separation between APM data and infrastructure metrics in traditional monitoring.

[0026] It should be noted that the core of this invention lies in the layered decoupling of computation and storage. Although SkyWalking, categraf, and VictoriaMetrics are all existing open-source software, this application creatively constructs a three-tiered pipeline architecture of "offline batch processing - real-time stream computation - cached query". Traditional solutions perform full aggregation queries directly on the time-series database, while this solution decomposes and pre-processes complex aggregation calculations through a pre-defined chain of scheduled tasks. This architecture completely isolates query requests from the complex computation process, requiring only the reading of aggregation results from the cache, thereby achieving millisecond-level query responses, a technical effect that cannot be achieved by using existing open-source components alone.

[0027] S2. Based on the unique identifier SLO ID, configure the SLO service level index SLI. Each SLI is configured with calculation rules and weights, and stored in a preset persistent database to establish the association between SLI and SLO.

[0028] In step S2, based on the unique identifier SLO ID, an SLO Service Level Indicator (SLI) is configured. Each SLI is configured with calculation rules and weights, and stored in a preset persistent database to establish the association between SLI and SLO. Specifically, the steps are as follows: Configure SLI based on the SLO corresponding to the unique identifier SLO ID; wherein, the configuration information of each SLI includes the metric name, PromQL calculation rules, weights and data types; The configuration information of each SLI is associated with the SLO ID and stored in a preset persistent database to establish the association between SLI and SLO.

[0029] In this embodiment of the invention, to achieve flexible business adaptation, the system allows users to configure SLI based on the created SLO ID in the front-end visual interface. Specifically, users can define specific PromQL calculation rules for each SLI (e.g., calculating whether a certain minute is available time based on the HTTP request success rate), the data source ID, and the business weight of that metric in the SLO (the sum of all SLI weights is 100%). This configuration information, along with the SLO ID, is serialized and stored in a persistent MySQL database, forming a logical mapping table. This configuration-based approach replaces traditional hard-coding, allowing operations personnel to dynamically change the SLO calculation logic simply by adjusting the weight configuration when business priorities change.

[0030] S3. Based on standardized time-series data and the relationship between SLI and SLO, when an SLI rule is added or modified, the first scheduled task is started. At the first preset time of the day, the invalid time period is eliminated by combining the planned downtime and service deployment time to generate the daily SLI granularity achievement rate and store it in the preset time-series database to obtain the daily SLI granularity achievement rate data.

[0031] In step S3, based on standardized time-series data and the correlation between SLI and SLO, when an SLI rule is added or modified, the first scheduled task is started. At the first preset time each day, invalid time periods are removed by combining planned downtime and service deployment time to generate the daily SLI granularity achievement rate, which is then stored in a preset time-series database to obtain the daily SLI granularity achievement rate data. The specific steps include the following: Based on standardized time-series data and the relationship between SLI and SLO, the first scheduled task is started when a new or modified rule is detected in the SLI configuration. When the first scheduled task starts for the first time, the cold start function is called asynchronously. Based on the standardized time series data, the original data source corresponding to the target SLI is scanned, the historical daily granularity achievement rate of the past preset period is calculated and completed, the daily granularity achievement rate of the past preset period is obtained, and the daily granularity achievement rate of the past preset period is stored in the preset time series database to generate the daily granularity achievement rate data of the past preset period. At the first preset time of each day, the original indicator data of the previous day is obtained based on standardized time-series data. The planned downtime read from the preset persistent database and the service deployment time collected from the CI / CD system are merged and deduplicated to obtain invalid time periods. The invalid time periods are removed from the entire day to obtain the effective duration. Calculate the SLI achievement rate of the previous day based on the effective duration, and generate the SLI daily granular achievement rate and corresponding effective duration for the previous day. The SLI daily granularity achievement rate and corresponding effective duration of the previous day are stored in a preset time series database, and together with the SLI daily granularity achievement rate data of the past preset period, they constitute the SLI daily granularity achievement rate data.

[0032] In this embodiment of the invention, when the first timed task is started for the first time, a cold start function is asynchronously called. Based on standardized time-series data, the original data source corresponding to the target SLI is scanned, the historical daily granularity achievement rate of the past preset period is calculated and completed, the daily granularity achievement rate of the past preset period is obtained, and the daily granularity achievement rate of the past preset period is stored in a preset time-series database to generate the daily granularity achievement rate data of the past preset period. Specifically, this includes the following sub-steps: When a new or modified rule is detected in the SLI configuration, the start command of the first scheduled task is initiated. When the first scheduled task is triggered for the first time, the historical time range that needs to be backfilled is determined based on the corresponding unique identifier SLO ID and the preset backfill period parameter to obtain the cold start time window. The preset backfill period parameter is at least twice the number of days of the SLO calculation period. Based on the cold start time window, a query request is initiated to the preset time series database for the original data source corresponding to SLI, and all original time series data points within the cold start time window are obtained to obtain the original data point sequence; wherein, the original data point sequence includes: timestamps and corresponding indicator values; The original data point sequence is grouped by natural day. For each day within the cold start time window, the achievement rate is calculated from the original data points of that day according to the PromQL calculation rules configured for SLI, to obtain the SLI achievement rate for that day. If there are missing original data points for that day, a data completion operation is performed to obtain the completed SLI achievement rate for that day. All dates within the cold start time window are traversed, and the SLI achievement rate for that day and the completed SLI achievement rate for that day are combined to generate a historical daily granular achievement rate sequence. Each achievement rate value in the historical daily granularity achievement rate sequence, along with the corresponding date tag and the unique identifier ID of SLI, is encapsulated as a time-series data point to obtain the batch of data to be written; Using a batch writing method, the data to be written is written to a preset time-series database in batches at once, generating SLI daily granularity achievement rate data for the past preset period.

[0033] It should be noted that after the batch write is completed, a cold start completion flag is set, and the SLI daily granularity achievement rate data of the past preset period is used as the basis data for the first scheduled task executed daily, so that the first scheduled task can directly read and use it during subsequent execution. The above cold start mechanism includes the following core designs that differ from existing technologies: First, triggering timing design: when a service level indicator rule is detected to be added or modified, the cold start function is immediately called asynchronously, instead of passively waiting for the next day's scheduled task, thereby compressing the historical data readiness time from the traditional 24 hours or more to a few minutes; Second, data source selection: the cold start function directly queries the original data points in the time series database, instead of relying on pre-aggregated recording rules. The technical advantages of this system are as follows: First, even if the SLI calculation rules change multiple times, each cold start can be recalculated based on the same original factual data, avoiding the loss of historical data or the need for manual recalculation due to rule changes. Second, missing data handling: for dates with missing original data points, the system automatically performs data completion operations (such as linear interpolation or forward filling) to ensure the continuity and statistical validity of the historical daily granularity achievement rate sequence, overcoming the calculation deviation caused by simply leaving blanks or ignoring missing data in existing solutions. Third, batch writing strategy: the achievement rate data of all dates within the backfill period (default 60 days) are packaged into a batch and written to the time series database at once, which can reduce network input / output overhead by about 95% compared to writing one record at a time, avoiding triggering database write rate limiting. Fourth, completion flag and data reuse: after batch writing, a cold start completion flag is set, and the solidified historical daily granularity data is used as the basis data for subsequent daily scheduled tasks, realizing "one-time backfill, multiple uses", eliminating the waste of resources from repeatedly calculating historical data. In comparison, existing technical solutions (such as Sloth, OpenSLO) or self-built solutions based on open-source system monitoring and alarm toolkits (Prometheus) lack the aforementioned proactive backfilling and data readiness mechanisms. After creating a new SLI, it is necessary to wait for real-time queries or scheduled tasks to gradually accumulate data, resulting in a data gap period of up to tens of days, and the consistency of historical data after rule changes cannot be guaranteed.

[0034] In this embodiment of the invention, to overcome the pain points of insufficient calculation accuracy caused by data gaps and invalid times in newly configured daily SLI granular data, the system designs a hybrid mechanism of "cold start + dual-source window removal". When an SLI rule is added or modified, the system immediately calls the cold start function asynchronously to directly scan the original data source and backfill the historical daily SLI granular achievement rate data of the past 60 days, enabling the new metric to immediately have historical analysis capabilities. In addition, in the scheduled task executed at midnight every day, the system does not simply aggregate the data of the whole day, but reads the manual maintenance planned downtime in MySQL and the service deployment time collected from Jenkins (an open-source continuous integration tool based on Java), merges these two types of time, removes duplicates, and marks them as "invalid time periods". When calculating the SLI achievement rate of the previous day, the system automatically removes these invalid time periods and writes the precise "valid duration" as a label (such as valid_time) back to the VM database, thereby ensuring that the SLO calculation results are not distorted due to release or planned maintenance.

[0035] It should be noted that, to optimize query performance and reduce storage costs under massive time-series data, the system adopts a hot and cold data separation and tiered caching storage strategy. Hot data processing: For real-time calculation results requiring high-frequency read / write and low-latency response (such as the daily SLO real-time achievement rate, error budget burn rate, and remaining budget percentage), the system writes them to a high-speed cache. The data structure in the cache uses Hash or String format to support millisecond-level Kanban refresh. Warm data processing: For historical aggregation results that have been solidified (such as yesterday's and previous SLI daily granularity achievement rate, SLO daily granularity achievement rate, and historical error budget consumption records), the system writes them in batches to the VictoriaMetrics (VM) time-series database. This data serves as evidence for long-term analysis and is queried less frequently. Cold data processing: For metadata that changes very little (such as SLI PromQL calculation rules, weight configurations, and SLO static thresholds), the system stores it in a persistent MySQL database.

[0036] With this architecture, the system prioritizes reading from the cache during queries. If the cache becomes invalid, it goes back to the source to calculate and update the cache, thereby transforming complex raw data aggregation queries into simple cache reads, which greatly improves the system's concurrent processing capabilities.

[0037] It is important to note that the "cold start function" described in this application specifically refers to a data backfilling mechanism triggered when an SLI rule is first created or when critical data changes occur. This is fundamentally different from traditional system hardware or application container cold starts. This mechanism aims to solve the "monitoring gap period" problem that exists after configuring new metrics, enabling new metrics to instantly acquire historical analysis capabilities through proactive calculation rather than passive waiting. The historical period (e.g., 60 days) for cold start function completion is independent of the calculation period (e.g., 30 days) for SLO evaluation. The cold start period should be greater than or equal to the calculation period to ensure sufficient historical data support for subsequent period calculations.

[0038] S4. Based on the SLI daily granularity achievement rate data, start the second scheduled task. At the second preset time each day, query the daily granularity achievement rate data of all SLIs belonging to the same SLO from the previous day, perform weighted summation according to their respective weights, and store it in the preset time series database to obtain the historical SLO daily granularity achievement rate data.

[0039] In step S4, based on the SLI daily granularity achievement rate data, a second timed task is started. At the second preset time each day, the daily granularity achievement rate data of all SLIs belonging to the same SLO from the previous day are queried, weighted and summed according to their respective weights, and stored in a preset time-series database to obtain historical SLO daily granularity achievement rate data. Specifically, the steps are as follows: Start the second scheduled task and set the second preset time of the day as the execution time; Based on the association between SLI and SLO, at the start of execution time, all SLI associated with the corresponding SLO are queried according to the unique identifier SLO ID in the association between SLI and SLO to obtain the SLI list; Based on the SLI list, obtain the daily granularity achievement rate and corresponding effective duration of each SLI from the daily granularity achievement rate data of the previous day; Based on the preset weights of each SLI, the daily granularity achievement rate of each SLI on the previous day is calculated by weighted summation to obtain the daily granularity achievement rate of SLO on the previous day; wherein, the weighted summation calculation is: multiply the daily granularity achievement rate of each SLI by its corresponding weight coefficient, and then add the weighted results of all SLIs. The previous day's SLO daily granularity achievement rate is stored in a preset time-series database to obtain historical SLO daily granularity achievement rate data.

[0040] In this embodiment of the invention, a second scheduled task is used to perform hierarchical aggregation calculation of Service Level Objectives (SLOs). At a specific time each day (e.g., 5:00 AM), the system queries the VM for the daily granular achievement rate data of all relevant SLIs from the previous day based on the SLO ID. Unlike a simple arithmetic average, this system uses a weighted summation algorithm: the achievement rate of each SLI yesterday is multiplied by its configured weight coefficient (e.g., 70% for core interfaces and 30% for secondary interfaces), and the results are summed. This calculation method can objectively reflect the actual impact of different business indicators on the overall service quality. The calculated "yesterday's SLO daily granular achievement rate" is then stored in the VM as warm data, serving as the basis for subsequent long-term analysis.

[0041] It should be noted that SLI daily granularity achievement rate data is stored in the time series database in the form of indicators plus labels. Each data point includes the achievement rate value, the effective duration, and the corresponding timestamp (by daily granularity). The system can retrieve data for a specified date by querying the time range.

[0042] S5. Based on historical SLO daily granularity achievement rate data, start the third timed task and execute it according to the preset cycle. Each time it is executed, obtain the historical SLO daily granularity achievement rate data and combine it with the real-time calculated daily SLO achievement rate data to obtain the SLO achievement rate in the current cycle, and calculate the SLO analysis data; update the SLO analysis data to the cache.

[0043] In step S5, based on historical SLO daily granularity achievement rate data, a third timed task is started and executed according to a preset cycle. Each execution acquires historical SLO daily granularity achievement rate data and combines it with the real-time calculated SLO achievement rate data for the current cycle to obtain the SLO achievement rate for the current cycle, and calculates the SLO analysis data. The SLO analysis data is then updated to the cache, specifically including the following steps: Based on historical SLO daily granularity achievement rate data, the third scheduled task is started; the execution cycle of the third scheduled task is 30 seconds. Determine the number of days in the preset calculation period to obtain the preset calculation period; Each time the third scheduled task is executed, according to the preset calculation cycle, the historical SLO daily granularity achievement rate data and the corresponding effective duration are read from the historical SLO daily granularity achievement rate data within the preset calculation cycle, excluding the current day, to obtain historical data fragments. Based on the SLI daily granularity achievement rate data and the weight configuration in the relationship between SLI and SLO, the real-time achievement rate of each SLI from 0:00 on the day to the current time is obtained. The real-time achievement rate of each SLI is weighted and summed according to the weight corresponding to each SLI to obtain the SLO achievement rate data and the corresponding effective duration for the day. By splicing historical data fragments with the daily SLO achievement rate data and corresponding effective duration, a complete SLO achievement rate time series data and corresponding effective duration sequence within the preset calculation period are obtained. Based on the complete SLO achievement rate time series data and the corresponding effective duration sequence, the total SLO achievement rate in the current period is calculated using the available time weighted average method. Based on the total SLO achievement rate in the current cycle and the preset SLO target threshold, the erroneous budget consumption ratio and burn rate are calculated to obtain SLO analysis data; Store SLO analysis data in a cache.

[0044] In this embodiment of the invention, to balance computational accuracy and query performance, the system initiates a third scheduled task (e.g., executed every 30 seconds) to maintain the cache. This task first reads historical SLO daily granularity data from the VM for the past n-1 days, and then calculates the SLO achievement rate from 00:00 on the current day to the current time in real time (weighted based on real-time SLI data). The system concatenates the historical data with the real-time data and uses the available time weighted average method to calculate the total SLO achievement rate within the current period. Simultaneously, based on this data, the error budget consumption ratio, burn rate, and estimated time to exhaustion (ETA) are derived in real time. These highly timely analysis results (hot data) are updated in the cache to support the second-level refresh requirements of the front-end dashboard.

[0045] It should be noted that the preset calculation period is the evaluation period for SLO achievement rate, such as 30 days. This period can be configured by the user according to business needs when creating SLO rules; the system default is 30 days. The formula for calculating the available time-weighted average method is: Total SLO achievement rate in the current period = (Sum of daily SLO achievement rate × daily effective duration) / Total effective duration. Here, daily effective duration refers to the number of effective minutes or seconds after deducting planned downtime and service deployment time on that day. The analyzed and processed SLO metric data will serve as the core basis for alarm decision-making and will enter the alarm response phase. The system will automatically compare these real-time calculated SLO metrics with preset alarm rules. Once an anomaly is detected, such as the SLO achievement rate falling below a threshold, the system will immediately trigger an alarm notification mechanism. This mechanism can accurately push the anomaly to relevant responsible persons through various channels such as email, instant messaging tools, or SMS, ensuring that fluctuations in service levels can be perceived and handled immediately, thus forming a complete closed loop from data calculation to anomaly response.

[0046] S6. When a user accesses SLO, the SLO analysis data is read from the cache and displayed. When a user accesses SLO, the SLO analysis data is read from the cache and time-series database and displayed, specifically including the following sub-steps: When a user accesses the SLO dashboard through the front-end interface, the back-end service receives the query request. The backend service reads the SLO analysis data from the cache; wherein, the SLO analysis data includes the total SLO achievement rate, error budget consumption ratio, and burn rate within the current period; The retrieved SLO analysis data is returned to the front end and visualized in chart form. The query process does not involve real-time aggregation calculation of the original SLI data points in the time series database; it only performs pure read operations.

[0047] The method further includes: a hot and cold data separation and hierarchical caching storage strategy; The hot and cold data separation and tiered caching storage strategy includes: The latest configuration of SLO rules, the SLO achievement rate and burn rate calculated in real time on the same day, and the remaining error budget ratio are stored as hot data in the cache. The daily SLI calculation value, daily SLO achievement rate, historical SLO remaining error budget ratio and effective duration are stored as warm data in a preset time series database. The SLI calculation rules and weights are stored as cold data in a pre-defined persistent database. The tiered caching storage strategy includes: offline computing stage, real-time computing stage, and query stage; The offline computing phase includes: pre-calculating the SLO achievement rate and effective duration for each historical day through a scheduled task in the early morning, obtaining daily granular aggregation results, and storing the daily granular aggregation results in a preset time-series database; The real-time calculation phase includes: calculating the SLO achievement rate, burn rate, and remaining error budget ratio from the start time to the current time of the day according to a preset cycle, obtaining real-time intermediate results, and storing the real-time intermediate results in a cache; The query phase includes: when a user accesses the SLO dashboard, the backend directly reads the SLO achievement rate, burn rate and remaining error budget ratio analysis data stored in the cache, without involving the query of the original SLI data points; The method further includes: joint access control based on roles and business groups, specifically including the following steps: Each SLO rule is bound to a business group tag, which is used to identify the business team to which the SLO rule belongs; Configure a role-based access control matrix to define the URL access permissions for different roles to perform SLO operations; When a user requests access to an SLO rule, the system determines whether the user has access rights to the current URL based on their role. If the user has access to the current URL, it is further determined whether the user has the operation permission of the business group bound to the SLO rule; SLO operations are allowed only if the user meets both the role permissions and the business group permissions; otherwise, SLO operations are denied.

[0048] In this embodiment of the invention, when a user initiates a query request through the front-end interface, the back-end service adopts a "query isolation" strategy. The system directly reads pre-calculated SLO analysis data (including overall achievement rate, burn rate, remaining error budget ratio, etc.) from the cache, instead of initiating complex aggregation query requests to the time-series database. After receiving the data, the front-end renders it into a visual dashboard containing an SLO achievement rate trend chart, an error budget consumption watermark, and risk level cards. This architecture reduces query response time from seconds to milliseconds, ensuring a smooth user experience even in scenarios with a large number of SLO rules.

[0049] In summary, this invention first standardizes and stores multi-source heterogeneous data into a VM through a data cleaning module. Then, a first scheduled task is initiated daily at midnight to calculate the daily SLI (Service Level Indicator) granularity achievement rate based on planned downtime and service deployment time, and uses a cold start mechanism to supplement historical data. Next, a second scheduled task performs weighted aggregation based on the SLI daily granularity data to obtain the daily SLO (Service Level Outcome) granularity achievement rate. A third scheduled task reads historical SLO data from the VM every 30 seconds and calculates the current day's data in real time. After concatenation, it uses an available time weighted average method to calculate the total SLO achievement rate and error budget within the period, and stores this analysis data in a high-speed cache. Front-end queries directly read from the cache, achieving millisecond-level response times. Simultaneously, joint access control based on roles and business groups ensures the security of multi-team collaboration.

[0050] It should be noted that, in order to adapt to the complex scenarios of enterprise-level multi-team collaboration, this invention implements joint access control based on roles and business groups.

[0051] Specifically, the system binds a business group label (Biz_Group) to each SLO rule. When a user initiates a request to create, modify, or query an SLO, the backend service executes double-checking logic: Role verification: Verify whether the user's role (such as Admin, Dev, Ops) has the URL access permissions for the current operation (e.g., whether they are allowed to perform the "delete" operation).

[0052] Business group verification: After role permissions are granted, further verification is performed to confirm whether the business group to which the user belongs matches the business group bound to the SLO rule of the requested operation.

[0053] For example, developer A belongs to the "Transaction Group." He can only view and edit the SLO rules under the "Transaction Group" and cannot see the data of the "Payment Group." This dual filtering mechanism of "role + attribute" ensures both the standardization of operations and achieves logical isolation at the data level, avoiding the configuration explosion problem of traditional RBAC in microservice multi-tenant scenarios.

[0054] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0055] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0056] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A method for SLO full lifecycle management and analysis based on time-series data, characterized in that, The method includes the following steps: S1. Create Service Level Objective (SLO) rules, generate unique identifiers (SLO IDs), preprocess multi-source heterogeneous observability data, and store them in a pre-set time series database to obtain standardized time series data. S2. Based on the unique identifier SLO ID, configure the SLO service level index SLI. Each SLI is configured with calculation rules and weights and stored in a preset persistent database to establish the association between SLI and SLO. S3. Based on standardized time-series data and the relationship between SLI and SLO, when an SLI rule is added or modified, the first scheduled task is started. At the first preset time of the day, the invalid time period is eliminated by combining the planned downtime and service deployment time to generate the daily SLI granularity achievement rate and store it in the preset time-series database to obtain the daily SLI granularity achievement rate data. S4. Based on the SLI daily granularity achievement rate data, start the second scheduled task. At the second preset time each day, query the daily granularity achievement rate data of all SLIs belonging to the same SLO from the previous day, perform weighted summation according to their respective weights, and store it in the preset time series database to obtain historical SLO daily granularity achievement rate data. S5. Based on historical SLO daily granularity achievement rate data, start the third scheduled task, which will be executed according to a preset calculation cycle. Each time it is executed, it will acquire historical SLO daily granularity achievement rate data and combine it with the real-time calculated SLO achievement rate data for the current cycle to obtain the SLO achievement rate for the current cycle, and calculate the SLO analysis data; update the SLO analysis data to the cache, specifically including the following steps: The execution cycle of the third scheduled task is 30 seconds. Determine the number of days in the preset calculation period to obtain the preset calculation period; Each time the third scheduled task is executed, according to the preset calculation cycle, the historical SLO daily granularity achievement rate data and the corresponding effective duration are read from the historical SLO daily granularity achievement rate data within the preset calculation cycle, excluding the current day, to obtain historical data fragments. Based on the SLI daily granularity achievement rate data and the weight configuration in the relationship between SLI and SLO, the real-time achievement rate of each SLI from 0:00 on the day to the current time is obtained. The real-time achievement rate of each SLI is weighted and summed according to the weight corresponding to each SLI to obtain the SLO achievement rate data and the corresponding effective duration for the day. By splicing historical data fragments with the daily SLO achievement rate data and corresponding effective duration, a complete SLO achievement rate time series data and corresponding effective duration sequence within the preset calculation period are obtained. Based on the complete SLO achievement rate time series data and the corresponding effective duration sequence, the total SLO achievement rate in the current period is calculated using the available time weighted average method. Based on the total SLO achievement rate in the current cycle and the preset SLO target threshold, the erroneous budget consumption ratio and burn rate are calculated to obtain SLO analysis data; Store SLO analysis data in a cache; S6. When a user accesses SLO, the SLO analysis data is read from the cache and displayed.

2. The SLO full lifecycle management and analysis method based on time-series data according to claim 1, characterized in that, In step S1, Service Level Target (SLO) rules are created, a unique identifier (SLO ID) is generated, and the multi-source heterogeneous observability data is preprocessed and stored in a preset time-series database to obtain standardized time-series data. Specifically, the steps include: Obtain observability data from multiple heterogeneous sources; wherein, the observable data includes: service-level, interface-level, and instance-level service performance indicators defined by the observation analysis language syntax, as well as infrastructure indicators and middleware indicators collected by the monitoring data collector; Based on a pre-configured YAML indicator whitelist, observable data is filtered to remove invalid indicators, resulting in filtered indicator data. The filtered metric data is received via the gRPC protocol, the SkyWalking native tags are converted into a unified Prometheus tag format, and business group tags and environment tags are injected to obtain standardized metric data. The standardized indicator data is written in batches into a preset time series database to obtain standardized time series data.

3. The SLO full lifecycle management and analysis method based on time-series data according to claim 2, characterized in that, In step 2, based on the unique identifier SLO ID, the SLO Service Level Indicator (SLI) is configured. Each SLI is configured with calculation rules and weights, and stored in a preset persistent database to establish the association between SLI and SLO. Specifically, the steps are as follows: Configure SLI based on the SLO corresponding to the unique identifier SLO ID; wherein, the configuration information of each SLI includes the metric name, PromQL calculation rules, weights and data types; The configuration information of each SLI is associated with the SLO ID and stored in a preset persistent database to establish the association between SLI and SLO.

4. The SLO full lifecycle management and analysis method based on time-series data according to claim 3, characterized in that, In step S3, based on standardized time-series data and the correlation between SLI and SLO, when an SLI rule is added or modified, the first scheduled task is started. At the first preset time each day, invalid time periods are removed by combining planned downtime and service deployment time to generate the daily SLI granularity achievement rate, which is then stored in a preset time-series database to obtain the daily SLI granularity achievement rate data. The specific steps include the following: Based on standardized time-series data and the relationship between SLI and SLO, the first scheduled task is started when a new or modified rule is detected in the SLI configuration. When the first scheduled task starts for the first time, the cold start function is called asynchronously. Based on the standardized time series data, the original data source corresponding to the target SLI is scanned, the historical daily granularity achievement rate of the past preset calculation period is calculated and completed, the daily granularity achievement rate of the past preset calculation period is obtained, and the daily granularity achievement rate of the past preset calculation period is stored in the preset time series database to generate the daily granularity achievement rate data of the past preset calculation period. At the first preset time of each day, the original indicator data of the previous day is obtained based on standardized time-series data. The planned downtime read from the preset persistent database and the service deployment time collected from the CI / CD system are merged and deduplicated to obtain invalid time periods. The invalid time periods are removed from the entire day to obtain the effective duration. Calculate the SLI achievement rate of the previous day based on the effective duration, and generate the SLI daily granular achievement rate and corresponding effective duration for the previous day. The SLI daily granularity achievement rate and corresponding effective duration of the previous day are stored in a preset time series database, and together with the SLI daily granularity achievement rate data of the past preset calculation period, they constitute the SLI daily granularity achievement rate data.

5. The SLO full lifecycle management and analysis method based on time-series data according to claim 4, characterized in that, In step S4, based on the SLI daily granularity achievement rate data, a second timed task is started. At the second preset time each day, the daily granularity achievement rate data of all SLIs belonging to the same SLO from the previous day are queried, weighted and summed according to their respective weights, and stored in a preset time-series database to obtain historical SLO daily granularity achievement rate data. Specifically, the steps are as follows: Start the second scheduled task and set the second preset time of the day as the execution time; Based on the association between SLI and SLO, at the start of execution time, all SLI associated with the corresponding SLO are queried according to the unique identifier SLO ID in the association between SLI and SLO to obtain the SLI list; Based on the SLI list, obtain the daily granularity achievement rate and corresponding effective duration of each SLI from the daily granularity achievement rate data of the previous day; Based on the preset weights of each SLI, the daily granularity achievement rate of each SLI on the previous day is calculated by weighted summation to obtain the daily granularity achievement rate of SLO on the previous day; wherein, the weighted summation calculation is: multiply the daily granularity achievement rate of each SLI by its corresponding weight coefficient, and then add the weighted results of all SLIs. The previous day's SLO daily granularity achievement rate is stored in a preset time-series database to obtain historical SLO daily granularity achievement rate data.

6. The SLO full lifecycle management and analysis method based on time-series data according to claim 5, characterized in that, In step S6, when a user accesses SLO, the SLO analysis data is read from the cache and time-series database and displayed, specifically including the following sub-steps: When a user accesses the SLO dashboard through the front-end interface, the back-end service receives the query request. The backend service reads the SLO analysis data from the cache; wherein, the SLO analysis data includes the total SLO achievement rate, error budget consumption ratio, and burn rate within the current period; The retrieved SLO analysis data is returned to the front end and visualized in chart form. The query process does not involve real-time aggregation calculation of the original SLI data points in the time series database; it only performs pure read operations.

7. The SLO full lifecycle management and analysis method based on time-series data according to claim 6, characterized in that, The method also includes: a hot and cold data separation and hierarchical caching storage strategy; The hot and cold data separation and tiered caching storage strategy includes: The latest configuration of SLO rules, the SLO achievement rate and burn rate calculated in real time on the same day, and the remaining error budget ratio are stored as hot data in the cache. The daily SLI calculation value, daily SLO achievement rate, historical SLO remaining error budget ratio and effective duration are stored as warm data in a preset time series database. The SLI calculation rules and weights are stored as cold data in a pre-defined persistent database. The hierarchical pre-computation and query isolation architecture includes: offline computation stage, real-time computation stage, and query stage; The offline computing phase includes: pre-calculating the SLO achievement rate and effective duration for each historical day through a scheduled task in the early morning, obtaining daily granular aggregation results, and storing the daily granular aggregation results in a preset time-series database; The real-time calculation phase includes: calculating the SLO achievement rate, burn rate, and remaining error budget ratio from the start time to the current time of the day according to a preset calculation cycle, obtaining real-time intermediate results, and storing the real-time intermediate results in a cache; The query phase includes: when a user accesses the SLO dashboard, the backend directly reads the SLO achievement rate, burn rate, and remaining error budget ratio analysis data stored in the cache, without involving querying the original SLI data points.

8. The SLO full lifecycle management and analysis method based on time-series data according to claim 7, characterized in that, The method also includes: joint access control based on roles and business groups, specifically including the following steps: Each SLO rule is bound to a business group tag, which is used to identify the business team to which the SLO rule belongs; Configure a role-based access control matrix to define the URL access permissions for different roles to perform SLO operations; When a user requests access to an SLO rule, the system determines whether the user has access rights to the current URL based on their role. If the user has access to the current URL, it is further determined whether the user has the operation permission of the business group bound to the SLO rule; SLO operations are allowed only if the user meets both the role permissions and the business group permissions; otherwise, SLO operations are denied.

Images