CN110958149A - Method for automatically aggregating and displaying OpenStack logs - Google Patents
Method for automatically aggregating and displaying OpenStack logs Download PDFInfo
- Publication number
- CN110958149A CN110958149A CN201911256646.5A CN201911256646A CN110958149A CN 110958149 A CN110958149 A CN 110958149A CN 201911256646 A CN201911256646 A CN 201911256646A CN 110958149 A CN110958149 A CN 110958149A
- Authority
- CN
- China
- Prior art keywords
- log
- interface
- displaying
- nova
- uuid
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 31
- 230000004931 aggregating effect Effects 0.000 title claims abstract description 21
- 239000003818 cinder Substances 0.000 claims abstract description 9
- 239000003795 chemical substances by application Substances 0.000 claims description 6
- 230000004044 response Effects 0.000 claims 4
- 238000012423 maintenance Methods 0.000 abstract description 7
- 239000000306 component Substances 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 239000008358 core component Substances 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0695—Management of faults, events, alarms or notifications the faulty arrangement being the maintenance, administration or management system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
- H04L41/0253—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using browsers or web-pages for accessing management information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Human Computer Interaction (AREA)
- Debugging And Monitoring (AREA)
- Testing And Monitoring For Control Systems (AREA)
- Analysing Materials By The Use Of Radiation (AREA)
Abstract
The invention relates to a method for automatically aggregating and displaying OpenStack logs, which specifically comprises the following steps: s1: adding a log collection module on each physical server, and searching logs according to the UUID of the host: (1) obtaining NOVA logs; (2) acquiring a NEUTRON log; (3) acquiring a CINDER log; (4) acquiring a KEYSTONE log; s2: and (3) displaying the result of log collection: (1) adding a log collection result display entry; (2) displaying a log collection result; the method for automatically aggregating and displaying the OpenStack logs can enable operation and maintenance personnel to directly view the logs directly related to the entity and the logs indirectly related to the entity through the graphical interface provided by the function after finding the entity with the problem through the graphical interface of the Horizon, so that the reason of the fault can be quickly known.
Description
Technical Field
The invention relates to the technical field of operation and maintenance of cloud platforms, in particular to a method for automatically aggregating and displaying OpenStack logs.
Background
The OpenStack is an open source code cloud computing management platform project, and is combined by a plurality of core components and a plurality of auxiliary components, so that unified resource scheduling management of a digital center is realized.
During the operation process of OpenStack, all components record events (including normal events and abnormal events) occurring in the operation process in respective logs. Therefore, after running for a period of time, the cloud computing platform based on OpenStack accumulates a huge amount of log files. Meanwhile, OpenStack allocates a UUID (a universal unique identifier, which is a kind of identifier whose length is 128 bits and can ensure independence and uniqueness) to managed entities (such as hosts, storage, ports, subnets, etc.) for easy differentiation. OpenStack also includes the UUID of the entity in the relevant log when recording the event relevant to the entity in the log. However, since OpenStack managed entities may be thousands of, the logs are also flooded with the relevant logs of a large number of different entities.
When a platform fails, the log can be screened manually through the UUID to locate and troubleshoot the problem. However, events related to the same problem often need to be analyzed and judged by looking up logs of multiple components comprehensively, which has high technical requirements on operation and maintenance personnel. And the content of each log is huge, and certain obstacles are caused to problem positioning by looking over a plurality of logs back and forth.
Disclosure of Invention
The invention aims to solve the technical problem of providing a method for automatically aggregating and displaying OpenStack logs to solve the problem that in the prior art, when the problem of positioning in the operation and maintenance process is solved, a large number of log files need to be browsed, and the efficiency is low.
In order to solve the technical problems, the technical scheme of the invention is as follows: the method for automatically aggregating and displaying OpenStack logs is provided, and has the innovation points that: the method specifically comprises the following steps:
s1: adding a log collection module on each physical server, and searching logs according to the UUID of the host
(1) Obtaining NOVA logs;
(2) acquiring a NEUTRON log;
(3) acquiring a CINDER log;
(4) acquiring a KEYSTONE log;
s2: log collection result presentation
(1) Adding a log collection result display entry;
(2) displaying a log collection result;
further, each physical server in S1 includes a host, a storage, a port, and a subnet.
Further, the log collection module provides an API interface through an HTTP protocol to communicate with the log collection result display module.
Further, the step of obtaining the NOVA log in step (1) of S1 includes:
①, defining the interface for obtaining the NOVA log as a GetNovaLog interface, and transmitting UUID parameters to the GetNovaLog interface through a service calling direction;
② scanning nova log files in each server, wherein the nova log files comprise three files, namely nova-computer.log, nova-api.log and nova-scheduler.log;
③, searching all contents containing UUIDs in all nova log files scanned in step ② according to UUID parameters of the GetNovaLog interface, and storing the whole row of records where the contents are located in a memory;
④ after all the nova log files are scanned, the record stored in the memory is transmitted back to the service caller by HTTPResponse.
Further, the step of acquiring the negron log in step (2) of S1 includes:
①, defining an interface for acquiring the NOVA log as a GetNeutronLog interface, and transmitting a UUID parameter to the GetNeutronLog interface through a service calling direction;
②, scanning neutron log files in each server, wherein the neutron log files comprise three files, namely neutron-13-agent.log, neutron-openvswitch-agent.log and neutron-server.log;
③, searching all contents containing UUIDs in all neutron log files scanned in step ② according to UUID parameters transmitted into the GetNeutronLog interface, and storing the whole row records of the contents in a memory;
④ after all neutron log files are scanned, the record stored in the memory is transmitted back to the service caller by way of HTTPResponse.
Further, the step of obtaining the CINDER log in step (3) of S1 includes:
①, defining the interface for obtaining the NOVA log as a GetCinderLog interface, and transmitting a UUID parameter to the GetCinderLog interface through a service calling direction;
② scanning the circle log files in each server, wherein the circle log files comprise four files of circle-api.log, circle-manager.log, circle-volume.log and circle-scheduler.log;
③, searching all contents containing UUIDs in all the ring log files scanned in step ② according to the UUID parameter of the incoming GetCinderLog interface, and storing the whole row of records where the contents are located in a memory;
④ after all the ring log files are scanned, the records stored in the memory are transmitted back to the service caller by means of HTTPResponse.
Further, the step of acquiring the keytone log in step (4) of S1 includes:
①, defining an interface for acquiring the NOVA log as a GetKeystoneLog interface, and transmitting a UUID parameter to the GetKeystoneLog interface through a service calling direction;
②, scanning a keystone log file in each server;
③, searching all the contents containing the UUID in all the keystone log files scanned in step ② according to the UUID parameter of the getkeystone log interface, and storing the whole row of records where the contents are located in the memory;
④ after all the keystone log files are scanned, the records stored in the memory are sent back to the service caller by means of HTTPResponse.
Further, the method for adding a log collection result display entry in step (1) of S2 includes:
① list display tables of management objects are arranged in the management pages of the host, the storage, the subnet and the port, a column is added at the last of the tables, and an entry button is added at the corresponding position of the last column for each object in the tables;
② clicking the entry button, guiding the log entering the management object corresponding to the entry button to view the page, and simultaneously transmitting the UUID of the object to the page.
Further, the method for increasing the log collection result display in the step (2) of S2 includes:
①, when entering the viewing page of the management object, after transferring the UUID needed by the management object, dividing the page into four areas of "host correlation", "storage correlation", "network correlation", and "authentication correlation";
② obtaining addresses of all hosts, accessing API of the log collection module through HTTP request, communicating with the log collection module through API to obtain related log files, and transmitting UUID;
③, after acquiring all log contents related to the UUID from the log collection module, displaying the log contents on different areas of the interface in different categories according to different management objects;
④ obtaining the content returned by the interface through NOVA log, and displaying the content to the 'host correlation' area;
⑤ obtaining the content returned by CINDER log obtaining interface, displaying it in the 'storage relative' area;
⑥ obtaining the content returned by the interface through NEUTRON log, and displaying the content in the 'network related' area;
⑦ get the contents returned by the interface through the KEYSTONE Log, show to the "authentication related" area.
Compared with the prior art, the invention has the following beneficial effects:
(1) according to the method for automatically aggregating and displaying the OpenStack logs, when operation and maintenance personnel need to check the operation logs of the OpenStack, the operation and maintenance personnel do not need to be remotely connected to a host running the OpenStack, but can check the operation logs by accessing the management webpage of the OpenStack through an HTTP protocol, so that the method is convenient and fast, and the efficiency is improved.
(2) According to the method for automatically aggregating and displaying the OpenStack logs, when a system fails, after an operation and maintenance person finds an entity with a problem through a graphical interface of Horizon, the log directly related to the entity and the log indirectly related to the entity can be directly checked through the graphical interface provided by the function, and therefore the reason for the failure can be quickly known.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the embodiments are briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without creative efforts.
Fig. 1 is a schematic flow chart of the fault resolution of the OpenStack platform according to the present invention.
Detailed Description
The technical solution of the present invention will be clearly and completely described by the following detailed description.
When the OpenStack platform fails, the processing method of the OpenStack platform can be solved through the flow diagram shown in FIG. 1, firstly, a management page of an entity is opened, a failed host is selected in a host list, and a relevant log in the host page is clicked to view, so that the OpenStack log can be searched and displayed according to the method for automatically aggregating and displaying the OpenStack log, wherein the method for automatically aggregating and displaying the OpenStack log specifically comprises the following steps:
s1: and adding a log collection module on each physical server, and retrieving logs according to the UUID of the host, wherein each physical server comprises the host, a storage, a port and a subnet, and the log collection module provides an API (application programming interface) interface through an HTTP (hyper text transport protocol) protocol to communicate with the log collection result display module.
(1) Obtaining NOVA logs;
①, defining the interface for obtaining the NOVA log as a GetNovaLog interface, and transmitting UUID parameters to the GetNovaLog interface through a service calling direction;
② scanning nova log files in each server, wherein the nova log files comprise three files, namely nova-computer.log, nova-api.log and nova-scheduler.log;
③, searching all contents containing UUIDs in all nova log files scanned in step ② according to UUID parameters of the GetNovaLog interface, and storing the whole row of records where the contents are located in a memory;
④ after all the nova log files are scanned, the record stored in the memory is transmitted back to the service caller by HTTPResponse.
(2) Acquiring a NEUTRON log;
①, defining an interface for acquiring the NOVA log as a GetNeutronLog interface, and transmitting a UUID parameter to the GetNeutronLog interface through a service calling direction;
②, scanning neutron log files in each server, wherein the neutron log files comprise three files, namely neutron-13-agent.log, neutron-openvswitch-agent.log and neutron-server.log;
③, searching all contents containing UUIDs in all neutron log files scanned in step ② according to UUID parameters transmitted into the GetNeutronLog interface, and storing the whole row records of the contents in a memory;
④ after all neutron log files are scanned, the record stored in the memory is transmitted back to the service caller by way of HTTPResponse.
(3) Acquiring a CINDER log;
①, defining the interface for obtaining the NOVA log as a GetCinderLog interface, and transmitting a UUID parameter to the GetCinderLog interface through a service calling direction;
② scanning the circle log files in each server, wherein the circle log files comprise four files of circle-api.log, circle-manager.log, circle-volume.log and circle-scheduler.log;
③, searching all contents containing UUIDs in all the ring log files scanned in step ② according to the UUID parameter of the incoming GetCinderLog interface, and storing the whole row of records where the contents are located in a memory;
④ after all the ring log files are scanned, the records stored in the memory are transmitted back to the service caller by means of HTTPResponse.
(4) Acquiring a KEYSTONE log;
①, defining an interface for acquiring the NOVA log as a GetKeystoneLog interface, and transmitting a UUID parameter to the GetKeystoneLog interface through a service calling direction;
②, scanning a keystone log file in each server;
③, searching all the contents containing the UUID in all the keystone log files scanned in step ② according to the UUID parameter of the getkeystone log interface, and storing the whole row of records where the contents are located in the memory;
④ after all the keystone log files are scanned, the records stored in the memory are sent back to the service caller by means of HTTPResponse.
S2: log collection result presentation
(1) Adding a log collection result display entry;
① list display tables of management objects are arranged in the management pages of the host, the storage, the subnet and the port, a column is added at the last of the tables, and an entry button is added at the corresponding position of the last column for each object in the tables;
② clicking the entry button, guiding the log entering the management object corresponding to the entry button to view the page, and simultaneously transmitting the UUID of the object to the page.
(2) Displaying a log collection result;
①, when entering the viewing page of the management object, after transferring the UUID needed by the management object, dividing the page into four areas of "host correlation", "storage correlation", "network correlation", and "authentication correlation";
② obtaining addresses of all hosts, accessing API of the log collection module through HTTP request, communicating with the log collection module through API to obtain related log files, and transmitting UUID;
③, after acquiring all log contents related to the UUID from the log collection module, displaying the log contents on different areas of the interface in different categories according to different management objects;
④ obtaining the content returned by the interface through NOVA log, and displaying the content to the 'host correlation' area;
⑤ obtaining the content returned by CINDER log obtaining interface, displaying it in the 'storage relative' area;
⑥ obtaining the content returned by the interface through NEUTRON log, and displaying the content in the 'network related' area;
⑦ get the contents returned by the interface through the KEYSTONE Log, show to the "authentication related" area.
According to the final log list displayed by the method for automatically aggregating and displaying the OpenStack logs, the operation state of the OpenStack and the fault reason of the system can be analyzed, and the problem solving efficiency is improved.
The above-mentioned embodiments are merely descriptions of the preferred embodiments of the present invention, and do not limit the concept and scope of the present invention, and various modifications and improvements made to the technical solutions of the present invention by those skilled in the art should fall into the protection scope of the present invention without departing from the design concept of the present invention, and the technical contents of the present invention as claimed are all described in the technical claims.
Claims (9)
1. A method for automatically aggregating and displaying OpenStack logs is characterized in that: the method specifically comprises the following steps:
s1: adding a log collection module on each physical server, and searching logs according to the UUID of the host
(1) Obtaining NOVA logs;
(2) acquiring a NEUTRON log;
(3) acquiring a CINDER log;
(4) acquiring a KEYSTONE log;
s2: log collection result presentation
(1) Adding a log collection result display entry;
(2) and displaying a log collection result.
2. The method for automatically aggregating and displaying OpenStack logs according to claim 1, wherein: each physical server in the S1 includes a host, a storage, a port, and a subnet.
3. The method for automatically aggregating and displaying OpenStack logs according to claim 1, wherein: the log collection module provides an API interface through an HTTP protocol to communicate with the log collection result display module.
4. The method for automatically aggregating and displaying OpenStack logs according to claim 1, wherein: the step of obtaining the NOVA log in the step (1) of S1 includes:
①, defining the interface for obtaining the NOVA log as a GetNovaLog interface, and transmitting UUID parameters to the GetNovaLog interface through a service calling direction;
② scan the nova log files in each server, the nova log files including
nova-computer.log, nova-api.log and nova-scheduler.log;
③, searching all contents containing UUIDs in all nova log files scanned in step ② according to UUID parameters of the GetNovaLog interface, and storing the whole row of records where the contents are located in a memory;
④ after all the nova log files are scanned, the record stored in the memory is transmitted back to the service caller by HTTP Response.
5. The method for automatically aggregating and displaying OpenStack logs according to claim 1, wherein: the step of acquiring the negron log in step (2) of S1 includes:
①, defining an interface for acquiring the NOVA log as a GetNeutronLog interface, and transmitting a UUID parameter to the GetNeutronLog interface through a service calling direction;
② scanning for neutron log files in each server, the neutron log files including
neutron-13-agent.log, neutron-openvswitch-agent.log and neutron-server.log;
③, searching all contents containing UUIDs in all neutron log files scanned in step ② according to UUID parameters transmitted into the GetNeutronLog interface, and storing the whole row records of the contents in a memory;
④ after all neutron log files are scanned, the records stored in the memory are returned to the service caller by means of HTTP Response.
6. The method for automatically aggregating and displaying OpenStack logs according to claim 1, wherein: the step of obtaining the CINDER log in step (3) of S1 includes:
①, defining the interface for obtaining the NOVA log as a GetCinderLog interface, and transmitting a UUID parameter to the GetCinderLog interface through a service calling direction;
② scanning the order of server's order of index, wherein the order of index includes index of server's order of index of server's order
cinder-api.log, cinder-management.log, cinder-volume.log, cinder-schema.log;
③, searching all contents containing UUIDs in all the ring log files scanned in step ② according to the UUID parameter of the incoming GetCinderLog interface, and storing the whole row of records where the contents are located in a memory;
④ after all the ring log files are scanned, the records stored in the memory are returned to the service caller by means of HTTP Response.
7. The method for automatically aggregating and displaying OpenStack logs according to claim 1, wherein: the step of acquiring the keytone log in step (4) of S1 includes:
①, defining an interface for acquiring the NOVA log as a GetKeystoneLog interface, and transmitting a UUID parameter to the GetKeystoneLog interface through a service calling direction;
②, scanning a keystone log file in each server;
③, searching all the contents containing the UUID in all the keystone log files scanned in step ② according to the UUID parameter of the getkeystone log interface, and storing the whole row of records where the contents are located in the memory;
④ after all the keystone log files are scanned, the records stored in the memory are returned to the service caller by means of HTTP Response.
8. The method for automatically aggregating and displaying OpenStack logs according to claim 1, wherein: the method for adding the log collection result display entry in the step (1) of S2 includes:
① list display tables of management objects are arranged in the management pages of the host, the storage, the subnet and the port, a column is added at the last of the tables, and an entry button is added at the corresponding position of the last column for each object in the tables;
② clicking the entry button, guiding the log entering the management object corresponding to the entry button to view the page, and simultaneously transmitting the UUID of the object to the page.
9. The method for automatically aggregating and displaying OpenStack logs according to claim 1, wherein: the method for increasing the display of the log collection result in the step (2) of S2 includes:
①, when entering the viewing page of the management object, after transferring the UUID needed by the management object, dividing the page into four areas of "host correlation", "storage correlation", "network correlation", and "authentication correlation";
② obtaining addresses of all hosts, accessing API of the log collection module through HTTP request, communicating with the log collection module through API to obtain related log files, and transmitting UUID;
③, after acquiring all log contents related to the UUID from the log collection module, displaying the log contents on different areas of the interface in different categories according to different management objects;
④ obtaining the content returned by the interface through NOVA log, and displaying the content to the 'host correlation' area;
⑤ obtaining the content returned by CINDER log obtaining interface, displaying it in the 'storage relative' area;
⑥ obtaining the content returned by the interface through NEUTRON log, and displaying the content in the 'network related' area;
⑦ get the contents returned by the interface through the KEYSTONE Log, show to the "authentication related" area.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911256646.5A CN110958149B (en) | 2019-12-09 | 2019-12-09 | Method for automatically aggregating and displaying OpenStack logs |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911256646.5A CN110958149B (en) | 2019-12-09 | 2019-12-09 | Method for automatically aggregating and displaying OpenStack logs |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110958149A true CN110958149A (en) | 2020-04-03 |
CN110958149B CN110958149B (en) | 2022-08-16 |
Family
ID=69980559
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201911256646.5A Expired - Fee Related CN110958149B (en) | 2019-12-09 | 2019-12-09 | Method for automatically aggregating and displaying OpenStack logs |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110958149B (en) |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160124793A1 (en) * | 2014-10-31 | 2016-05-05 | International Business Machines Corporation | Log analytics for problem diagnosis |
CN106992876A (en) * | 2017-03-04 | 2017-07-28 | 郑州云海信息技术有限公司 | Cloud platform blog management method and system |
CN110209518A (en) * | 2019-04-26 | 2019-09-06 | 福州慧校通教育信息技术有限公司 | A kind of multi-data source daily record data, which is concentrated, collects storage method and device |
CN110245074A (en) * | 2019-05-21 | 2019-09-17 | 中国平安财产保险股份有限公司 | A kind of generation method of log recording, device, storage medium and server |
-
2019
- 2019-12-09 CN CN201911256646.5A patent/CN110958149B/en not_active Expired - Fee Related
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160124793A1 (en) * | 2014-10-31 | 2016-05-05 | International Business Machines Corporation | Log analytics for problem diagnosis |
CN106992876A (en) * | 2017-03-04 | 2017-07-28 | 郑州云海信息技术有限公司 | Cloud platform blog management method and system |
CN110209518A (en) * | 2019-04-26 | 2019-09-06 | 福州慧校通教育信息技术有限公司 | A kind of multi-data source daily record data, which is concentrated, collects storage method and device |
CN110245074A (en) * | 2019-05-21 | 2019-09-17 | 中国平安财产保险股份有限公司 | A kind of generation method of log recording, device, storage medium and server |
Non-Patent Citations (1)
Title |
---|
陆杰等: "分布式系统中的日志分析及应用", 《高技术通讯》 * |
Also Published As
Publication number | Publication date |
---|---|
CN110958149B (en) | 2022-08-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11775501B2 (en) | Trace and span sampling and analysis for instrumented software | |
US9460187B2 (en) | Creation of a graph database of a virtualization infrastructure | |
US20080040417A1 (en) | System and method for allocating workflow operations to a computing device | |
US9876813B2 (en) | System and method for web-based log analysis | |
CN111221591A (en) | Method, system and medium for detecting availability of micro-service deployed based on Kubernetes | |
US11755531B1 (en) | System and method for storage of data utilizing a persistent queue | |
US9355163B2 (en) | Using a graph database of a virtualization infrastructure | |
US11522812B1 (en) | Workflows for configuring the ingestion of user data from a service provider network into a data intake and query system | |
CN107133231B (en) | Data acquisition method and device | |
CN112579007A (en) | Method and device for acquiring full storage link and electronic equipment | |
US20230420083A1 (en) | Method and apparatus for acquiring gene information of proprietary cloud container cluster | |
CN110515799A (en) | MySQL monitoring system and implementation method based on python language | |
CN106156258B (en) | Method, device and system for counting data in distributed storage system | |
CN110958149B (en) | Method for automatically aggregating and displaying OpenStack logs | |
US10353792B2 (en) | Data layering in a network management system | |
CN110839012A (en) | Troubleshooting method for preventing sensitive information from being leaked | |
US20130024480A1 (en) | Method and system for analysis of database records | |
US9898490B2 (en) | Systems and methods for supporting multiple database server versions on a database machine | |
CN116260878A (en) | Service center system based on global service structure server of distributed computing and storage | |
CN116132250A (en) | Operation and maintenance system, operation and maintenance method, storage medium and electronic equipment | |
KR102093764B1 (en) | Managment server for managing the server and storage | |
CN115913912A (en) | Message interception and service link diagram generation method and device | |
CN109684158A (en) | Method for monitoring state, device, equipment and the storage medium of distributed coordination system | |
CN111698109A (en) | Method and device for monitoring log | |
CN110944144B (en) | Method and system for quickly configuring video terminal to access video system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20220816 |
|
CF01 | Termination of patent right due to non-payment of annual fee |