Event Log Management

Abstract

An event log management system. Some implementations described herein relate to a system configured to acquire one or more event logs associated with a tenant of the system. The system can be configured to determine an event rate associated with a tenant based on one or more event logs, and thereby determine a rotation interval based on the event rate. The system can be configured to generate data structures based on the rotation interval for storing tenant-associated event logs acquired during a time window. The system can be configured to acquire one or more additional event logs associated with the tenant within the time window, and to store one or more additional event logs in a data structure based on the acquisition of one or more additional event logs within the time window.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to Indian Patent Application No. 202141059282 entitled “EVENT LOG MANAGEMENT”, filed on December 20, 2021, the entire contents of which are expressly incorporated herein by reference. Background Technology

[0003] Software as a Service (SaaS) is a cloud service that hosts applications or services. In some cases, a multi-tenant SaaS environment can provide resources that will be shared by different tenants of the environment (e.g., different subscribers or groups of customers). Summary of the Invention

[0004] Some implementations described herein relate to a system. This system may include one or more memories and one or more processors. The system may be configured to acquire one or more event logs associated with a tenant of the system. The system may be configured to determine an event rate associated with a tenant based on one or more event logs. The system may be configured to determine a rotation interval based on the event rate. The system may be configured to generate data structures based on the rotation interval for storing tenant-associated event logs acquired during a time window. The system may be configured to acquire one or more additional event logs associated with a tenant within the time window. The system may be configured to store one or more additional event logs in a data structure based on the acquisition of one or more additional event logs within the time window.

[0005] Some implementations described herein involve storing instruction sets for a system on a non-transitory computer-readable medium. When executed by one or more processors of the system, the instruction sets enable the system to determine an event rate associated with a tenant based on one or more event logs associated with the tenant. When executed by one or more processors of the system, the instruction sets enable the system to determine a predicted event rate associated with a tenant based on the event rate. When executed by one or more processors of the system, the instruction sets enable the system to determine a rotation interval based on the predicted event rate. When executed by one or more processors of the system, the instruction sets enable the system to generate data structures based on the rotation interval for storing tenant-associated event logs acquired during a time window. When executed by one or more processors of the system, the instruction sets enable the system to acquire one or more additional event logs associated with a tenant within a time window. When executed by one or more processors of the system, the instruction sets enable the system to store one or more additional event logs in a data structure based on the acquisition of one or more additional event logs within a time window.

[0006] Some implementations described herein relate to a method. This method may include determining an event rate associated with a tenant by the system and based on one or more event logs associated with the tenant of the system. This method may include determining a rotation interval by the system and based on the event rate. This method may include generating a data structure by the system and based on the rotation interval for storing tenant-associated event logs acquired during a time window. This method may include storing one or more additional event logs acquired during the time window in the data structure by the system. Attached Figure Description

[0007] Figures 1A to 1E This is a diagram of the example implementation described in this article.

[0008] Figure 2 It is a diagram of an example environment in which the systems and / or methods described in this article can be implemented.

[0009] Figures 3 to 4 yes Figure 2 A diagram of example components of one or more devices.

[0010] Figure 5 This is a flowchart of an example process related to event log management. Detailed Implementation

[0011] The following example implementation is described in detail with reference to the accompanying drawings. The same reference numerals in different drawings can identify the same or similar elements.

[0012] A typical SaaS system (e.g., one providing security services) receives event logs from the respective devices of tenants in a multi-tenant SaaS environment (e.g., to identify, prevent, and / or mitigate anomalous events, attacks, viruses, worms, or other malicious activities or events associated with individual tenants). In many cases, each tenant sends event logs to the SaaS system at a different rate. For example, the first tenant might send hundreds of event logs per second, the second thousands per second, the third tens of thousands per second, and so on. However, for each tenant, the SaaS system provides a single-sized data structure (e.g., a database) to store event logs received during a specific time period (e.g., one hour). This causes problems when the total size of tenant event logs received during a specific time period exceeds the storage size of the data structure. For example, the SaaS system must utilize computing resources (e.g., processing resources, memory resources, communication resources, and / or power resources, etc.) to dynamically generate new data structures, clean and / or delete older data structures, and / or perform other operations. This impacts the performance of the SaaS system, such as by causing latency associated with queries and / or reports related to the execution of event logs.

[0013] Some implementations described in this paper provide a system that acquires one or more event logs associated with a tenant of the system and determines an event rate associated with the tenant based on the one or more event logs. The system determines a rotation interval (e.g., a time amount, such as an hour, a day, or a week) based on the event rate, thereby generating a data structure for storing the tenant-associated event logs acquired during a time window (e.g., which has a duration equal to the rotation interval). The system acquires one or more additional event logs associated with the tenant within the time window and, based on the acquisition of one or more additional event logs within the time window, stores one or more additional event logs in the data structure.

[0014] In this way, some implementations described in this paper automatically generate data structures for storing tenant event logs based on the event rate of the event logs. This allows data structures suitable for tenant storage needs to be generated and utilized during a time window. Furthermore, this reduces the likelihood that the total size of tenant event logs received during the time window exceeds the storage size of the data structures. Therefore, this reduces the utilization of computing resources (e.g., processing resources, memory resources, communication resources, and / or power resources, etc.) that would otherwise be needed to dynamically generate new data structures, clean and / or delete older data structures, and / or perform other operations. This improves system performance (e.g., compared to a typical SaaS system) by minimizing latency associated with querying and / or reporting related to the event logs.

[0015] Furthermore, in some implementations, the system receives an event log search request and identifies one or more additional data structures for storing event logs during the corresponding time window based on the requested search start and end times. Therefore, based on the event log search request, the system performs one or more data structure queries on the one or more additional data structures to identify event log search information and provides the event log search information (e.g., for display on another device).

[0016] Figures 1A to 1E This is a diagram of one or more example implementations 100 described in this document. The (multiple) example implementations 100 may include an event log management system (ELMS), a network device, and / or one or more endpoint devices, which are combined below. Figures 2 to 4 To describe in more detail. ELMS can be, for example, a multi-tenant cloud-hosted event log management SaaS system, and one or more endpoint devices and network devices can be associated with a tenant in the multi-tenant SaaS environment provided by ELMS. Figures 1A to 1EAs shown, ELMS can include ingress nodes, sink nodes, query nodes, controller nodes, and / or multiple data structures (in... Figure 1A The data structures are represented as 1 to M, where M ≥ 2.

[0017] like Figure 1A As shown in the figure, and via reference numeral 102, ELMS can obtain (e.g., associated with an ELMS tenant) one or more event logs. For example, one or more endpoint devices and / or network devices can (e.g., based on the operation of one or more endpoint devices and / or network devices) generate one or more event logs and can send one or more event logs to ELMS (e.g., in near real-time). In some implementations, the ELMS ingress node can receive one or more event logs.

[0018] As shown by reference numeral 104 in the attached figure, ELMS can determine the event rate associated with a tenant. For example, ELMS (e.g., using an ingress node) can determine the number of event logs obtained by ELMS during a specific time period (e.g., the first 5 minutes) based on one or more event logs and / or other obtained event logs associated with the tenant. Therefore, ELMS can determine the event rate based on the number of event logs and the specific time period (e.g., by dividing the number of event logs by the length of the specific time period).

[0019] like Figure 1B As shown in the figure, and via reference numeral 106, the controller node can obtain the event rate associated with the tenant from the ingress node. Therefore, as shown by reference numeral 108, the ELMS (e.g., using the controller node) can determine the predicted event rate associated with the tenant. In some implementations, the ELMS (e.g., using the controller node) can process the event rate associated with the tenant (e.g., determined by the ELMS) and / or one or more previous event rates associated with the tenant (e.g., previously determined by the ELMS) to determine the predicted event occurrence rate associated with the tenant. For example, the ELMS (e.g., using the controller node) can leverage machine learning models, such as univariate time series forecasting models (e.g., which utilize two variables—time and event rate—to determine the predicted event rate associated with the tenant based on the event rate associated with the tenant and / or one or more previous event rates associated with the tenant. The machine learning model can determine the predicted event rate at uniform time intervals (e.g., every five minutes).

[0020] As shown by reference numeral 110 in the attached figure, the ELMS (e.g., using a controller node) can determine (e.g., based on the event rate and / or predicted event rate) the rotation interval (e.g., a time amount, such as an hour, a day, or a week, etc., associated with storing event logs in a single data structure). For example, the ELMS (e.g., using a controller node) can identify the representative capacity of the data structure (e.g., the number of event logs that can be stored by the data structure) and can determine the number of event logs to be received during a specific time interval (e.g., an hour, a day, a week, or a month, etc.) based on the predicted event rate. In some implementations, the ELMS (e.g., using a controller node) can determine that the number of event logs to be received during a specific time interval is less than or equal to the representative capacity, and thus identify the specific time interval as the rotation interval. For example, when the specific time interval is one hour, the ELMS can make the rotation interval one hour. Alternatively, the ELMS (e.g., using a controller node) can determine that the number of event logs to be received during a specific time interval is greater than the representative capacity, and thus make the rotation interval greater than the specific time interval. For example, when the specific time interval is one day, ELMS can make the rotation interval one week, or when the specific time interval is one week, ELMS can make the rotation interval one month, etc.

[0021] As shown by reference numeral 112 in the attached figure, ELMS can generate data structures (e.g., based on rotation intervals). For example, a controller node can communicate with a sink node to enable the sink node to create data structures such as... Figure 1B The data structure N shown is configured to store event logs associated with a tenant acquired during a time window. The time window can begin at the creation time of the data structure and end after an amount of time equal to the rotation interval has elapsed since its creation (e.g., when the start time of the time window is t, the end time is t+r, where r is the rotation interval). In some implementations, ELMS (e.g., using a pool node) can give the data structure a name that identifies the tenant, the time window, and / or the type of event log to be stored in the data structure (e.g., security event logs, business event logs, and / or other event logs). For example, the data structure could have a name like this: <Tenant Name><Time Window><Event Log Category>. The <Time Window> element could have a structure like this: <Year><Month><Day><Hour>.

[0022] like Figure 1CAs shown in the figure, and via reference numeral 114, ELMS can obtain one or more additional event logs associated with a tenant of ELMS. For example, one or more endpoint devices and / or network devices can generate one or more additional event logs (e.g., based on the operation of one or more endpoint devices and / or network devices) and can send one or more additional event logs to ELMS (e.g., near real-time). In some implementations, the ingress node of ELMS can receive one or more additional event logs.

[0023] In some implementations, ELMS can obtain one or more additional event logs (e.g., associated with a data structure N generated by ELMS) within a time window. Therefore, as shown by reference numeral 116 in the attached figure, ELMS can store one or more additional event logs in a data structure (e.g., data structure N). For example, as... Figure 1C As shown, the entry node can forward one or more supplementary event logs to the aggregation node. The aggregation node can determine that ELMS has acquired one or more supplementary event logs within a time window (e.g., the acquisition time o of one or more supplementary event logs is within the start time t and end time t+r of the time window, so t≤o≤t+r). Therefore, the aggregation node can store one or more supplementary event logs in data structure N.

[0024] like Figure 1D As shown in the figure, and via reference numeral 118, ELMS can obtain event log search requests (e.g., for information associated with one or more event logs obtained by ELMS). For example, a particular endpoint device among one or more endpoint devices can generate an event log search request (e.g., based on input from a user of that particular endpoint device) and can send the event log search request to ELMS. In some implementations, the ELMS ingress node can receive event log search requests and can forward them to a query node.

[0025] As shown by reference numeral 120 in the attached figure, ELMS can execute one or more data structure queries (e.g., based on an event log search request). For example, ELMS (e.g., using a query node) can process an event log search request to determine the search start time and search end time associated with the event log search request (e.g., the time span associated with the event log search request). ELMS (e.g., using a query node) can search another data structure (e.g., a binary search tree, such as a balanced binary search tree, or another data structure that stores information identifying the corresponding start times and time windows of multiple data structures) to identify a set of data structures (e.g., one or more data structures 1 to N) among multiple data structures. Each data structure in the set of data structures may have a time window that is at least partially extended with the time span associated with the event log search request. For example, ELMS can search this other data structure to identify a set of data structures arranged chronologically among multiple data structures, wherein the first data structure in the chronologically arranged set has a start time that occurs before or at the start time of the event log search request, and wherein the last data structure in the chronologically arranged set has a start time that occurs before or at the end time of the event log search request, and an end time that occurs after or at the end time of the event log search request (e.g., indicated by the length of the time window associated with the data structure after its start time). That is, the time span associated with the chronologically arranged set of data structures has a start time that occurs before or at the start time of the event log search request and an end time that occurs after or at the end time of the event log search request.

[0026] Therefore, ELMS (e.g., using query nodes) can perform one or more data structure queries on a set of data structures based on an event log search request. For example, ELMS (e.g., using query nodes) can perform a data structure query on each data structure in a chronologically ordered set of data structures. In this way, ELMS (e.g., using query nodes) can identify log search information (e.g., as a result of one or more data structure queries) and can provide log search information. For example, ELMS can transmit log search information to a specific endpoint device (e.g., send an event log search request to an endpoint device of ELMS), which can cause the specific endpoint device to display the log search information on its display.

[0027] like Figure 1EAs shown in the figure, and via reference numeral 122, ELMS can obtain remaining storage capacity requests (e.g., requests for information related to the amount of storage available for event logs associated with a tenant). For example, a particular endpoint device among one or more endpoint devices can generate a remaining storage capacity request (e.g., based on input from a user of that particular endpoint device) and can send the remaining storage capacity request to ELMS. In some implementations, the ingress node of ELMS can receive remaining storage capacity requests and can forward them to the aggregation node.

[0028] As shown by reference numeral 124 in the attached figure, ELMS can determine (e.g., based on remaining storage capacity requests) the remaining storage capacity (e.g., the amount of storage available for event logs associated with a tenant), expressed, for example, in terms of time. For example, ELMS (e.g., using a aggregation node) can determine the amount of available storage for a tenant (e.g., in megabytes, gigabytes, or terabytes) based on the remaining storage capacity request (e.g., based on pre-configured information, such as what is indicated by the licensing agreement between the tenant and the ELMS operator), thereby determining the number of event logs that can be stored in the tenant's available storage (e.g., by dividing the tenant's available storage by a representative size of the event logs). ELMS (e.g., using an aggregation node) can determine the remaining storage capacity for a tenant, expressed in terms of time, based on the number of event logs that can be stored in the tenant's available storage and the event rate associated with the tenant (e.g., by dividing the number of event logs that can be stored in the tenant's available storage by the event rate associated with the tenant). Thus, ELMS can provide the remaining storage capacity for a tenant, expressed in terms of time. For example, ELMS can transmit the remaining storage capacity for a tenant in terms of time to a specific endpoint device (e.g., the endpoint device that sent the request for the remaining storage capacity for the tenant), which may cause the specific endpoint device to display the remaining storage capacity for the tenant in terms of time on the specific endpoint device's display.

[0029] As indicated above, Figures 1A to 1E This is provided only as one or more examples. Other examples may be provided in conjunction with... Figures 1A to 1E The descriptions are different.

[0030] Figure 2 This is a diagram of example environment 200, in which the systems and / or methods described herein can be implemented. For example... Figure 2 As shown, environment 200 may include an event log management system 201, which may include one or more elements of cloud computing system 202 and / or may be executed within cloud computing system 202. Cloud computing system 202 may include one or more elements 203 to 212, as described in more detail below. Figure 2 As further shown, environment 200 may include network 220, network device 230, and / or one or more endpoint devices 240. The devices and / or elements of environment 200 may be interconnected via wired and / or wireless connections.

[0031] Cloud computing system 202 includes computing hardware 203, resource management component 204, host operating system (OS) 205, and / or one or more virtual computing systems 206. Cloud computing system 202 can run on, for example, Amazon Web Services platform, Microsoft Azure platform, or Snowflake platform. Resource management component 204 can perform virtualization (e.g., abstraction) of computing hardware 203 to create one or more virtual computing systems 206. Using virtualization, such as by creating multiple isolated virtual computing systems 206 from computing hardware 203 of a single computing device, resource management component 204 enables a single computing device (e.g., a computer or server) to operate as multiple computing devices. In this way, computing hardware 203 can operate more efficiently than using separate computing devices, with lower power consumption, higher reliability, higher availability, higher utilization, greater flexibility, and lower cost.

[0032] Computing hardware 203 includes hardware and corresponding resources from one or more computing devices. For example, computing hardware 203 may include hardware from a single computing device (e.g., a single server) or from multiple computing devices (e.g., multiple servers), such as multiple computing devices in one or more data centers. As shown, computing hardware 203 may include one or more processors 207, one or more memories 208, and / or one or more network components 209. Examples of processors, memories, and network components (e.g., communication components) are described elsewhere herein.

[0033] Resource management component 204 includes a virtualization application (e.g., executing on hardware such as computing hardware 203) capable of virtualizing computing hardware 203 to start, stop, and / or manage one or more virtual computing systems 206. For example, resource management component 204 may include a hypervisor (e.g., a bare-metal or Type 1 hypervisor, a managed or Type 2 hypervisor, or another type of hypervisor) or a virtual machine monitor, such as when virtual computing system 206 is virtual machine 210. Additionally or alternatively, resource management component 204 may include a container manager, such as when virtual computing system 206 is container 211 (e.g., which includes one or more threads). In some implementations, resource management component 204 executes within and / or coordinates with host operating system 205. In some implementations, resource management component 204 includes an ingress node, a convergence node, a query node, a controller node, and / or, as described herein, a specific type of virtual machine. Figures 1A to 1E The description includes multiple data structures.

[0034] Virtual computing system 206 includes a virtual environment that uses computing hardware 203 to implement cloud-based execution of the operations and / or processes described herein. As shown, virtual computing system 206 may include virtual machines 210, containers 211, or a hybrid environment 212 including virtual machines and containers, etc. Virtual computing system 206 may use a file system to execute one or more applications, which includes binaries, software libraries, and / or other resources required to execute applications on a guest operating system (e.g., within virtual computing system 206) or host operating system 205.

[0035] Although the event log management system 201 may include one or more elements 203 to 212 of the cloud computing system 202, may execute within the cloud computing system 202, and / or may be hosted within the cloud computing system 202, in some implementations, the event log management system 201 may not be cloud-based (e.g., may be implemented outside the cloud computing system) or may be partially cloud-based. For example, the event log management system 201 may include one or more devices that are not part of the cloud computing system 202, such as... Figure 3 Device 300 may include a standalone server or another type of computing device. Event log management system 201 may perform one or more operations and / or processes described in more detail elsewhere herein. In some implementations, the event log management system may provide a multi-tenant SaaS environment to one or more tenants (e.g., in the case where the tenants include network device 230 and one or more endpoint devices 240).

[0036] Network 220 includes one or more wired and / or wireless networks. For example, network 220 may include cellular networks, public land mobile networks (PLMNs), local area networks (LANs), wide area networks (WANs), private networks, the Internet, and / or combinations thereof, or other types of networks. Network 220 enables communication between devices in environment 200.

[0037] Network device 230 includes one or more devices capable of receiving, processing, storing, routing, and / or providing services (e.g., packets or other information or metadata) in the manner described herein. For example, network device 230 may include routers such as label switching routers (LSRs), label edge routers (LERs), ingress routers, egress routers, provider routers (e.g., provider edge routers or provider core routers), virtual routers, or other types of routers. Additionally or alternatively, network device 230 may include gateways, switches, firewalls, hubs, bridges, reverse proxies, servers (e.g., proxy servers, cloud servers, or data center servers), load balancers, and / or similar devices. In some implementations, network device 230 may be a physical device implemented within a enclosure (e.g., a chassis). In some implementations, network device 230 may be a virtual device implemented by one or more computer devices in a cloud computing environment or data center. In some implementations, network device group 230 may be a group of data center nodes used to route service flows through network 220. In some implementations, network device 230 may be associated with a tenant in a multi-tenant SaaS environment provided by event log management system 201.

[0038] Endpoint device 240 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information such as the information described herein. For example, endpoint device 240 may include mobile phones (e.g., smartphones or cordless phones), laptop computers, tablet computers, desktop computers, handheld computers, gaming devices, wearable communication devices (e.g., smartwatches, smart glasses, heart rate monitors, fitness trackers, smart clothing, smart jewelry, or head-mounted displays), network devices, or similar types of devices. In some implementations, endpoint device 240 may receive network traffic from event log management system 201 and / or network device 230 via network 220 and / or provide network traffic to event log management system 201 and / or network device 230. In some implementations, endpoint device 240 may be associated with a tenant in a multi-tenant SaaS environment provided by event log management system 201.

[0039] Figure 2 The number and arrangement of devices and networks shown are provided as examples. In practice, with Figure 2 Compared to those shown, there can be more devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks with different arrangements. Furthermore, Figure 2 The two or more devices shown can be implemented within a single device, or Figure 2The single device shown can be implemented as multiple distributed devices. Additionally or alternatively, a group of devices in environment 200 (e.g., one or more devices) can perform one or more functions described as being performed by another group of devices in environment 200.

[0040] Figure 3 This is a diagram illustrating example components of device 300, which may correspond to event log management system 201, computing hardware 203, network device 230, and / or endpoint device 240. In some implementations, event log management system 201, computing hardware 203, network device 230, and / or endpoint device 240 include one or more devices 300 and / or one or more components of device 300. Figure 3 As shown, device 300 may include bus 310, processor 320, memory 330, input component 340, output component 350 and communication component 360.

[0041] Bus 310 includes one or more components that enable wired and / or wireless communication between components of device 300. Bus 310 can... Figure 3 Two or more components are coupled together, such as via operational coupling, communication coupling, electronic coupling, and / or electrical coupling. Processor 320 includes a central processing unit, graphics processing unit, microprocessor, controller, microcontroller, digital signal processor, field-programmable gate array, application-specific integrated circuit, and / or another type of processing component. Processor 320 is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, processor 320 includes one or more processors capable of being programmed to perform one or more operations or processes described elsewhere herein.

[0042] Memory 330 includes volatile and / or non-volatile memory. For example, memory 330 may include random access memory (RAM), read-only memory (ROM), hard disk drive, and / or another type of memory (e.g., flash memory, magnetic storage, and / or optical storage). Memory 330 may include internal memory (e.g., RAM, ROM, or hard disk drive) and / or removable memory (e.g., removable via a universal serial bus). Memory 330 may be a non-transitory computer-readable medium. Memory 330 stores information, instructions, and / or software (e.g., one or more software applications) related to the operation of device 300. In some implementations, such as via bus 310, memory 330 includes one or more memories coupled to one or more processors (e.g., processor 320).

[0043] Input component 340 enables device 300 to receive input, such as user input and / or sensed input. For example, input component 340 may include a touchscreen, keyboard, keypad, mouse, button, microphone, switch, sensor, GPS sensor, accelerometer, gyroscope, and / or actuator. Output component 350 enables device 300 to provide output, such as via a display, speaker, and / or light-emitting diode. Communication component 360 enables device 300 to communicate with other devices via wired and / or wireless connections. For example, communication component 360 may include a receiver, transmitter, transceiver, modem, network interface card, and / or antenna.

[0044] Device 300 can perform one or more operations or procedures described herein. For example, a non-transitory computer-readable medium (e.g., memory 330) can store an instruction set (e.g., one or more instructions or code) for execution by processor 320. Processor 320 can execute the instruction set to perform one or more operations or procedures described herein. In some implementations, the instruction set is executed by one or more processors 320 to cause one or more processors 320 and / or device 300 to perform one or more operations or procedures described herein. In some implementations, hardwired circuitry is used in place of instructions or in combination with instructions to perform one or more operations or procedures described herein. Additionally or alternatively, processor 320 can be configured to perform one or more operations or procedures described herein. Therefore, the implementations described herein are not limited to any particular combination of hardware circuitry and software.

[0045] Figure 3 The number and arrangement of components shown are provided as an example. Device 300 may include... Figure 3 The components shown may be compared to more components, fewer components, different components, or components arranged differently. Additionally or alternatively, the component set of device 300 (e.g., one or more components) may perform one or more functions described as being performed by another component set of device 300.

[0046] Figure 4 This is a diagram illustrating example components of device 400. Device 400 may correspond to event log management system 201, computing hardware 203, network device 230, and / or endpoint device 240. In some implementations, event log management system 201, computing hardware 203, network device 230, and / or endpoint device 240 may include one or more devices 400 and / or one or more components of device 400. Figure 4As shown, device 400 may include one or more input components 410-1 to 410-B (B≥1) (hereinafter collectively referred to as input components 410, individually referred to as input components 410), switching component 420, one or more output components 430-1 to 430-C (C≥1) (hereinafter collectively referred to as output components 430, individually referred to as output components 430), and controller 440.

[0047] Input component 410 may be one or more connection points of a physical link and may be one or more entry points for incoming traffic such as packets. Input component 410 may process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In some implementations, input component 410 may transmit and / or receive packets. In some implementations, input component 410 may include an input line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more interface cards (IFCs), packet forwarding components, line card controller components, input ports, processors, memory, and / or input queues. In some implementations, device 400 may include one or more input components 410.

[0048] Switching component 420 interconnects input component 410 with output component 430. In some implementations, switching component 420 may be implemented via one or more crossbar switches, via a bus, and / or using shared memory. Shared memory may act as a temporary buffer to store packets from input component 410 before final scheduling for delivery to output component 430. In some implementations, switching component 420 enables input component 410, output component 430, and / or controller 440 to communicate with each other.

[0049] Output component 430 can store packets and schedule packets for transmission over the output physical link. Output component 430 can support data link layer encapsulation or decapsulation, and / or various higher-level protocols. In some implementations, output component 430 can transmit and / or receive packets. In some implementations, output component 430 may include an output line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more IFCs, packet forwarding components, line card controller components, output ports, processors, memory, and / or output queues. In some implementations, device 400 may include one or more output components 430. In some implementations, input component 410 and output component 430 may be implemented from the same set of components (e.g., the input / output component may be a combination of input component 410 and output component 430).

[0050] Controller 440 includes a processor, which may take the form of, for example, a CPU, GPU, APU, microprocessor, microcontroller, DSP, FPGA, ASIC, and / or other types of processor. The processor is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, controller 440 may include one or more processors that can be programmed to perform functions.

[0051] In some implementations, controller 440 may include RAM, ROM and / or another type of dynamic or static storage device (e.g., flash memory, magnetic storage, optical storage, etc.) that stores information and / or instructions for use by controller 440.

[0052] In some implementations, controller 440 can communicate with other devices, networks, and / or systems connected to device 400 to exchange information about the network topology. Controller 440 can create routing tables based on the network topology information, create forwarding tables based on the routing tables, and forward the forwarding tables to input component 410 and / or output component 430. Input component 410 and / or output component 430 can use the forwarding tables to perform route looks for incoming and / or outgoing packets.

[0053] Controller 440 may execute one or more processes described herein. Controller 440 may execute these processes in response to executing software instructions stored on a non-transitory computer-readable medium. Computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space distributed across multiple physical storage devices.

[0054] Software instructions may be read from another computer-readable medium or from another device via a communication interface into the memory and / or storage components associated with controller 440. When executed, the software instructions stored in the memory and / or storage components associated with controller 440 may cause controller 440 to perform one or more processes described herein. Additionally or alternatively, hard-wired circuitry may be used in place of or in combination with the software instructions to perform one or more processes described herein. Therefore, the implementation described herein is not limited to any particular combination of hardware circuitry and software.

[0055] Figure 4 The number and arrangement of components shown are provided as an example. In practice, device 400 may include... Figure 4 The components shown may be more, fewer, different, or arranged differently than other components. Additionally or alternatively, the set of components of device 400 (e.g., one or more components) may perform one or more functions described as being performed by another set of components of device 400.

[0056] Figure 5 This is a flowchart of example process 500 associated with event log management. In some implementations, Figure 5 One or more process blocks are executed by the system (e.g., event log management system 201). In some implementations, Figure 5 One or more process frames are executed by another device or set of devices that are separate from or include the system, such as computing hardware (e.g., computing hardware 203), network devices (e.g., network device 230), and / or endpoint devices (e.g., endpoint device 240). Additionally or alternatively, Figure 5 One or more processing blocks may be executed by the following components: one or more components of device 300, such as processor 320, memory 330, input component 340, output component 350 and / or communication component 360; one or more components of device 400, such as input component 410, switching component 420, output component 430 and / or controller 440; and / or one or more components of another device.

[0057] like Figure 5 As shown, process 500 may include obtaining one or more event logs associated with a tenant of the system (box 510). For example, the system may obtain one or more event logs associated with a tenant of the system, as described above.

[0058] like Figure 5 As further shown, process 500 may include determining the event rate associated with a tenant based on one or more event logs (box 520). For example, the system may determine the event rate associated with a tenant based on one or more event logs, as described above.

[0059] like Figure 5 As further shown, process 500 may include determining the rotation interval based on the event rate (block 530). For example, the system may determine the rotation interval based on the event rate, as described above.

[0060] like Figure 5 As further shown, process 500 may include generating a data structure based on a rotation interval for storing event logs associated with tenants acquired during a time window (box 540). For example, the system may generate a data structure based on a rotation interval for storing event logs associated with tenants acquired during a time window, as described above.

[0061] like Figure 5 As further shown, process 500 may include obtaining one or more additional event logs associated with a tenant within a time window (box 550). For example, the system may obtain one or more additional event logs associated with a tenant within a time window, as described above.

[0062] like Figure 5 As further shown, process 500 may include storing one or more additional event logs in a data structure based on obtaining one or more additional event logs within a time window (box 560). For example, the system may store one or more additional event logs in a data structure based on obtaining one or more additional event logs within a time window, as described above.

[0063] Process 500 may include additional implementations, such as any single implementation or any combination of implementations described below and / or in combination with one or more other processes described elsewhere herein.

[0064] In the first implementation, determining the rotation interval includes: using a machine learning model to process the event rate and one or more previous event rates associated with the tenant to determine a predicted event rate, and determining the rotation interval based on the predicted event rate.

[0065] In the second implementation, determining the rotation interval, either alone or in combination with the first implementation, includes: using a univariate time series forecasting model to process the event rate and one or more previous event rates associated with the tenant to determine a predicted event rate, and determining the rotation interval based on the predicted event rate.

[0066] In the third implementation, determining the rotation interval, either alone or in combination with one or more of the first and second implementations, includes: determining a predicted event rate based on the event rate; identifying the representative capacity of the data structure; determining the number of event logs to be received during a specific time interval based on the predicted event rate; determining that the number of event logs to be received during a specific time interval is less than or equal to the representative capacity; and identifying the specific time interval as the rotation interval.

[0067] In the fourth implementation, determining the rotation interval, either alone or in combination with one or more of the first to third implementations, includes: determining a predicted event rate based on the event rate; identifying the representative capacity of the data structure; determining the number of event logs to be received during a specific time interval based on the predicted event rate; determining that the number of event logs to be received during the specific time interval is greater than the representative capacity; and making the rotation interval greater than the specific time interval.

[0068] In the fifth implementation, either alone or in combination with one or more of the first to fourth implementations, the name of the data structure identifies at least one of the following: tenant, time window, or event log category to be stored in the data structure.

[0069] In the sixth implementation, either alone or in combination with one or more of the first to fifth implementations, process 500 includes: obtaining an event log search request; determining a time span associated with the event log search request based on the event log search request; searching another data structure based on the time span associated with the event log search request to identify a set of data structures, wherein each data structure in the set of data structures stores tenant-associated event logs obtained during a specific time window, which at least partially extends with the time span associated with the event log search request; performing one or more data structure queries on the set of data structures based on the event log search request to identify event log search information; and providing the event log search information.

[0070] In the seventh implementation, either alone or in combination with one or more of the first through sixth implementations, the other data structure is a binary search tree.

[0071] In the eighth implementation, either alone or in combination with one or more of the first to seventh implementations, process 500 includes: obtaining a remaining storage capacity request; determining the amount of available storage for a tenant based on the remaining storage capacity request; determining the number of event logs that can be stored in the tenant's available storage based on the amount of available storage for the tenant; determining the remaining storage capacity for the tenant in terms of time based on the number of event logs that can be stored in the tenant's available storage and the event rate associated with the tenant; and providing the tenant with the remaining storage capacity in terms of time.

[0072] although Figure 5 An example box of process 500 is shown, but in some implementations, process 500 includes... Figure 5 The boxes described in the diagram may be more, fewer, different, or arranged differently. Alternatively, two or more boxes in process 500 may be executed in parallel.

[0073] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the implementation to the precise form disclosed. Modifications and variations can be made based on the foregoing disclosure, or modifications and variations can be derived from the practice of implementation.

[0074] As used herein, the term "component" is intended to be interpreted broadly as hardware, firmware, or a combination of hardware and software. It is evident that the systems and / or methods described herein can be implemented in various forms of hardware, firmware, and / or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limiting in its implementation. Therefore, this document describes the operation and behavior of the systems and / or methods without reference to any specific software code—it should be understood that software and hardware can be used to implement the systems and / or methods based on the description herein.

[0075] Although specific combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of various implementations. In fact, many of these features can be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may be directly subordinated to a claim, the disclosure of various implementations includes combinations of each dependent claim with each other claim in the claim set. As used herein, the phrase “at least one” in the list of items refers to any combination of these items, including single members. For example, “at least one of a, b, or c” is intended to cover a, b, c, a to b, a to c, b to c, and a to b to c, as well as any combination having multiple identical items.

[0076] Unless explicitly stated otherwise, no element, action, or instruction used herein should be construed as critical or necessary. Furthermore, as used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more.” Furthermore, as used herein, the articles “the” and “the” are intended to include one or more items referenced in connection with the articles “the” and “the” and may be used interchangeably with “one or more.” Furthermore, as used herein, the terms “set” and “group” are intended to include one or more items (e.g., related items, unrelated items, or a combination of related and unrelated items) and may be used interchangeably with “one or more.” If only one item is intended, the phrase “only one” or similar language is used. Furthermore, as used herein, the terms “having” and the like are intended to be open-ended terms. Furthermore, unless explicitly stated otherwise, the phrase “based on” is intended to mean “at least partially based on.” Furthermore, as used herein, the term “or” when used in a series of forms is intended to be inclusive and may be used interchangeably with “and / or” unless explicitly stated otherwise (e.g., if with “either” or “only one of them”).

Claims

1. A system for managing event logs, comprising: One or more memory units; as well as One or more processors, for: Obtain one or more event logs associated with a tenant of the system; The event rate associated with the tenant is determined based on the one or more event logs, wherein the event rate is calculated based on the number of event logs obtained during a specific time period; The rotation interval is determined based on the event rate as follows: The event rate and one or more previous event rates associated with the tenant are processed using a machine learning model to determine the predicted event rate; as well as The rotation interval is determined based on the predicted event rate; The data structure is generated based on the rotation interval for storing event logs associated with the tenant acquired during a time window, wherein the time window begins at the time the data structure is created and ends after an amount of time equal to the rotation interval. Obtain one or more additional event logs associated with the tenant within the time window; as well as Based on the acquisition of the one or more additional event logs within the time window, the one or more additional event logs are stored in the data structure.

2. The system of claim 1, wherein the one or more processors for determining the rotation interval are configured to: A univariate time series forecasting model is used to process the event rate and one or more previous event rates associated with the tenant to determine the predicted event rate; and The rotation interval is determined based on the predicted event rate.

3. The system of claim 1, wherein the one or more processors for determining the rotation interval are configured to: The predicted event rate is determined based on the event rate; The representative capacity of the identifier data structure; The number of event logs to be received during a specific time interval is determined based on the predicted event rate. The number of event logs to be received during the specific time interval is determined to be less than or equal to the representative capacity; as well as The specific time interval is identified as the rotation interval.

4. The system of claim 1, wherein the one or more processors for determining the rotation interval are configured to: The predicted event rate is determined based on the event rate. The representative capacity of the identifier data structure; The number of event logs to be received during a specific time interval is determined based on the predicted event rate. The number of event logs to be received during the specific time interval is determined to be greater than the representative capacity; as well as Make the rotation interval greater than the specific time interval.

5. The system of claim 1, wherein the name of the data structure identifies at least one of the following: The tenant; The time window; or The event log category to be stored in the data structure.

6. The system of claim 1, wherein the one or more processors are further configured to: Obtain an event log search request; Based on the event log search request, the time span associated with the event log search request is determined by processing the event log search request to determine the search start time and search end time associated with the event log search request; Based on the time span associated with the event log search request, search another data structure to identify the data structure set. Each data structure in the data structure set stores an event log associated with the tenant, obtained during a specific time window, which is at least partially extended by the time span associated with the event log search request. Based on the event log search request, perform one or more data structure queries on the data structure set to identify the event log search information; as well as Provides the event log search information.

7. The system according to claim 6, wherein the other data structure is a binary search tree.

8. The system of claim 1, wherein the one or more processors are further configured to: Request to obtain remaining storage capacity; The amount of available storage for the tenant is determined based on the requested remaining storage capacity. The number of event logs that can be stored in the available storage for the tenant is determined based on the amount of available storage for the tenant. The remaining storage capacity for the tenant, expressed in terms of time, is determined based on the number of event logs that can be stored in the available storage for the tenant and the event rate associated with the tenant. as well as The remaining storage capacity, expressed in terms of the time duration, is provided to the tenant.

9. A non-transitory computer-readable medium storing an instruction set, the instruction set comprising: One or more instructions, which, when executed by one or more processors of the system, cause the system to: The event rate associated with a tenant is determined based on one or more event logs associated with the tenant of the system, wherein the event rate is calculated based on the number of event logs obtained during a specific time period; The rotation interval is determined by the system and based on the event rate as follows: The event rate and one or more previous event rates associated with the tenant are processed using a machine learning model to determine the predicted event rate; as well as The rotation interval is determined based on the predicted event rate; The data structure is generated based on the rotation interval for storing event logs associated with the tenant acquired during a time window, wherein the time window begins at the time the data structure is created and ends after an amount of time equal to the rotation interval. Obtain one or more additional event logs associated with the tenant within the time window; as well as Based on the acquisition of the one or more additional event logs within the time window, the one or more additional event logs are stored in the data structure.

10. The non-transitory computer-readable medium of claim 9, wherein the one or more instructions that cause the system to determine the predicted event rate cause the system to: The event rate is processed using a univariate time series forecasting model to determine the predicted event rate.

11. The non-transitory computer-readable medium of claim 9, wherein the one or more instructions that cause the system to determine the rotation interval cause the system to: The number of event logs to be received during a specific time interval is determined based on the predicted event rate. The number of event logs to be received during the specific time interval is determined to be less than or equal to the representative capacity of the data structure; as well as The specific time interval is identified as the rotation interval.

12. The non-transitory computer-readable medium of claim 9, wherein the one or more instructions that cause the system to determine the rotation interval cause the system to: The number of event logs to be received during a specific time interval is determined based on the predicted event rate. The number of event logs to be received during the specific time interval is determined to be greater than the representative capacity of the data structure; as well as Make the rotation interval greater than the specific time interval.

13. The non-transitory computer-readable medium of claim 9, wherein one or more instructions further cause the system to: Obtain an event log search request; Based on the event log search request, the time span associated with the event log search request is determined by processing the event log search request to determine the search start time and search end time associated with the event log search request; Based on the time span associated with the event log search request, another data structure is searched to identify a set of data structures that store event logs associated with the tenant and are associated with the time span associated with the event log search request. Based on the event log search request, perform one or more data structure queries on the data structure set to identify the event log search information; as well as Provides the event log search information.

14. The non-transitory computer-readable medium of claim 9, wherein one or more instructions further cause the system to: Request to obtain remaining storage capacity; The number of event logs that can be stored in the available storage for the tenant is determined based on the remaining storage capacity request; The remaining storage capacity for the tenant, expressed in terms of time, is determined based on the number of event logs that can be stored in the available storage for the tenant and the event rate associated with the tenant. as well as The remaining storage capacity, expressed in terms of the time duration, is provided to the tenant.

15. A method for managing event logs, comprising: The event rate associated with a tenant is determined by the system and based on one or more event logs associated with the tenant of the system, wherein the event rate is calculated based on the number of event logs obtained during a specific time period; The rotation interval is determined by the system and based on the event rate as follows: The event rate and one or more previous event rates associated with the tenant are processed using a machine learning model to determine the predicted event rate; as well as The rotation interval is determined based on the predicted event rate; The system generates a data structure based on the rotation interval for storing an event log associated with the tenant acquired during a time window, wherein the time window begins at the time the data structure is created and ends after an amount of time equal to the rotation interval. as well as The system causes one or more additional event logs obtained within the time window to be stored in the data structure.

16. The method of claim 15, wherein determining the rotation interval comprises: The number of event logs to be received during a specific time interval is determined based on the event rate. The number of event logs to be received during the specific time interval is determined to be less than or equal to the representative capacity of the data structure; as well as The specific time interval is identified as the rotation interval.

17. The method of claim 15, wherein determining the rotation interval comprises: The number of event logs to be received during a specific time interval is determined based on the event rate. The number of event logs to be received during the specific time interval is determined to be greater than the representative capacity of the data structure; as well as Make the rotation interval greater than the specific time interval.

Images