CN116737679A - A log storage method based on ELK - Google Patents
A log storage method based on ELK Download PDFInfo
- Publication number
- CN116737679A CN116737679A CN202310400371.8A CN202310400371A CN116737679A CN 116737679 A CN116737679 A CN 116737679A CN 202310400371 A CN202310400371 A CN 202310400371A CN 116737679 A CN116737679 A CN 116737679A
- Authority
- CN
- China
- Prior art keywords
- log
- exception
- recorder
- parameter
- call
- 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.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
- G06F16/1815—Journaling file systems
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
-
- 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)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明公开了一种基于ELK的日志存储方法，属于计算机技术领域，包括：S1：建立调用链日志记录器、异常日志记录器和重要日志记录器；S2：通过调用链日志记录器获取链路日志，通过异常日志记录器获取异常日志，通过重要日志记录器获取重要日志；S3：使所述调用链日志记录器、异常日志记录器和重要日志记录器共享requestId、sessionId、用户ID、用户名和入口方法名。所述基于ELK的日志存储方法解决了现有的日志存储方式保存的日志量有限，并且异常日志会抛出从而丢失了异常日志的问题。
The invention discloses a log storage method based on ELK, which belongs to the field of computer technology and includes: S1: establishing a call chain log recorder, an exception log recorder and an important log recorder; S2: obtaining a link through the call chain log recorder Log, obtain exception logs through the exception logger, and obtain important logs through the important logger; S3: Make the call chain logger, exception logger and important logger share requestId, sessionId, user ID, user name and Entry method name. The ELK-based log storage method solves the problem that the existing log storage method can save a limited amount of logs, and abnormal logs will be thrown and thus the abnormal logs are lost.
Description
Technical Field
The invention relates to the technical field of computers, in particular to a log storage method based on ELK.
Background
ELK is an abbreviation for three open source software, representing: elasticsearch, logstash and Kibana, both of which are open source software. The elastiscearch is an open source distributed search engine, provides three functions of collecting, analyzing and storing data, and is characterized in that: distributed, zero configuration, auto discovery, index auto-sharding, index copy mechanism, restful style interface, multiple data sources and auto-search load, etc. The logstack is mainly used as a tool for collecting, analyzing and filtering logs, supports a large number of data acquisition modes, generally works in a c/s architecture, a client end is installed on a host computer needing to collect logs, and a server end is responsible for filtering, modifying and other operations of received node logs on an elastic search. Kibana is also an open source and free tool, and Kibana can provide log analysis friendly web interfaces for Logstash and elastic search, and can help summarize, analyze and search important data logs. ELK is used as a logging system by many companies within the industry.
Most of the solutions currently used in the industry are to output all logs in the call link uniformly into one log index of the elastic search (the index in the elastic search is equivalent to the concept of a table in the database), as shown in fig. 1.
When a user accesses a web, a call chain as in fig. 2 will be generated: web- > service a- > service C- > database, or web- > service a- > service B- > database. Existing solutions of this type typically generate a requestId at the entry of the call, and the call via either the method or the service (via the service in fig. 2) has a log probe that records the current method name, the entry, the exit, the time taken for the call, etc. along with the requestId into the ELK system.
But this approach has the following problems:
the logging call chain will generate a large number of logs (especially in large systems), which results in a limited amount of logs that can be saved, requiring regular cleaning. In a typical system, only three to six months of logs would be kept. There are some important log enterprises that wish to be kept permanently.
When an exception occurs in the call chain, the exception log and the link log are stored under the same index, so that the search of the exception log is not facilitated. It can be seen from fig. 1 that when there is an exception log, it is not immediately known from the current view at which position the exception occurred. In addition, because the link logs are massive, searching for exception logs in the link logs can be relatively slow. In addition, in the java program, some exceptions may not be thrown but try catch (capturing exceptions), as shown in fig. 3, where there is an exception, but the traffic does not want to be thrown, and at this time, the exception log is lost.
Disclosure of Invention
In order to overcome the defects in the prior art, the invention provides an ELK-based log storage method for solving the problems.
The technical scheme adopted for solving the technical problems is as follows: an ELK-based log storage method, comprising:
s1: establishing a call chain log recorder, an abnormal log recorder and an important log recorder;
s2: acquiring a link log by calling a link log recorder, acquiring an abnormal log by an abnormal log recorder, and acquiring an important log by an important log recorder;
s3: the call chain logger, exception logger, and importance logger are made to share requestId, sessionId, user ID, user name, and entry method name.
It should be noted that, in the step S1, a method info (String method, date state time, object result, object targets) is set in the call chain log recorder, where the parameter String method is a String method, the parameter Date state time is a method start time, the parameter Object result is an Object result, and the parameter Object targets is a return result;
acquiring requestId, sessionId, user ID and user name in the link log context by method info (Stringmethod, date state Time, object result, object region) and recording requestId, sessionId, user ID and user name together with parameter String method, parameter Date state Time, parameter Object result and parameter Object region into the link log;
after the call chain log recorder is established, the call chain log recorder is arranged in a web entry log layer, a web exception interception layer, a dubbo call interception layer, a mybatis interception layer and a dubbo service front-end interception layer, and is arranged in a state invisible to a programmer.
Optionally, in the step S1, a method error (Throwable e) or a method error (running message, running able e) is set in the exception logger, where the parameter running able e is a jettisonable exception object e, and the parameter running message is an exception description;
acquiring requestId, sessionId, user ID, user name and entry method in the exception log context by a method error (Throwable e) or a method error (running message), and recording requestId, sessionId, user ID, user name and entry method together with parameter running message and/or parameter running message into the exception log;
after the exception log recorder is established, the exception log recorder is arranged in a web exception interception layer, a dubbo call interception layer, a mybatis interception layer and a dubbo service front interception layer and is set to be in a callable state by a programmer.
Specifically, in the step S1, a method log (String funName, string message) is set in the important logger, where a parameter String funName is a function name and a parameter String message is function information;
acquiring requestId, sessionId, user ID, user name and entry method in the important log context by a method log (StringfunName, stringmessage), and recording requestId, sessionId, user ID, user name and entry method together with parameters StringfunName and parameter stringmessage into the important log;
after the critical log logger is built, a programmer-callable state is set.
Preferably, in the step S1, when a request to enter the web portal log layer is made, the method start time and the parameters of the portal method are recorded first, and when the request is returned, the result record is returned, and then the link log is output by using the call link log recorder.
Optionally, in the step S1, after the request enters the entry method, and when the entry method throws an exception, the request is intercepted by the web exception interception layer, then a method, a method start time and parameters are acquired from the web entry log layer, the exception information is used as a result, the call chain log recorder is used to output an exception log, then the error (Throwable e) method of the exception log recorder is used to output detailed exception information, and finally the detailed exception information is returned to the 500 pages designated by the user.
It should be noted that, in the step S1, parameters of the service method and the parameters of the service method corresponding to the transmission are obtained from an org.apoche.dubbo.rpc.filter interface corresponding to the dubbo call interception layer, and start time is recorded, requestId, sessionId, user ID and user name are obtained from a link log context, or requestId, sessionId, user ID, user name and entry method are obtained from an exception log context, and rpccontext.getcontext (). Setattach (strucment) method provided by a dubbo framework corresponding to the dubbo call interception layer is called, requestId, sessionId, user ID, user name and entry method are recorded to an attachment of a transmission packet, and then the invoke method of the parameters of the service method is called to call remote duo service; when a return result exists, a call chain log recorder is used for outputting a chain log; when the exception is thrown by remote call, the call chain log recorder is used for outputting a link log, then the error (Throwable e) method of the exception log recorder is called for outputting detailed information of the exception as an exception log, and the exception is thrown continuously.
Specifically, in the step S1, an interface method Result invoke (invoke <; when a return result exists, a calling chain log recorder is utilized to output a chain log; when the service call throws the exception, the link log is output by the call link log recorder, the error (Throwable e) method of the exception log recorder is then called to output the detailed information of the exception as the exception log, the exception is thrown continuously, and finally the link log context and/or the exception log context are emptied.
Preferably, in the step S1, an interface method Object interface (Invocation invocation) corresponding to the org.apache.ibatis.plug.interntor interface of the mybatis interception layer is used to obtain a query statement of the database to be executed from the parameter indication as a method, and further the parameter is taken out from the parameter indication, the start time is recorded, and then the procedure of the parameter indication is called to call the database; when a return result exists, a call chain log recorder is used for outputting a chain log; when the query statement of the database executes exception rejection, the link log is output by using the call link log recorder, then the detailed information of the exception is output by using the error (Throwable e) method of the exception log recorder as the exception log, and the exception is continuously rejected.
Optionally, step S4 is further included, and step S4 includes: when the internal web interface is required to be called by using the http, before the http initiates the call, the requestId is acquired from the link log context, the exception log context and/or the important log context, and the value of the requestId is filled into the request header as_requestid.
The invention has the beneficial effects that: in the ELK-based log storage method, the call link log, the abnormal log and the important log are split, so that the inquiry of abnormal time is facilitated, and the important log is stored for a longer time. The call link log, the abnormal log and the important log are respectively stored in three different log recorders, so that the log storage quantity can be improved. The link log, the exception log and the important log are recorded under different indexes and share the requestId, so that the related information can be searched under another index by using the requestId under one index, the provided exception logger records the exception in the try catch, and the link log, the exception log and the important log share the session identifier, the user ID, the user name and the entry method name besides the requestId (the entry method name is particularly important in the important log because a certain log is likely to have passed for a long time, when the link log searching entry is wanted to be called through the requestId, and the abnormal log can be searched through the requestId under one index when the abnormality occurs in the calling chain.
Drawings
FIG. 1 is an index of an elastomer search in the prior art;
FIG. 2 is a flow chart of a user accessing a web in the prior art;
FIG. 3 is a prior art center section of a java program with exceptions but not desirable for ejection;
FIG. 4 is a flow chart of an ELK-based log storage method in one embodiment of the invention;
FIG. 5 is a configuration diagram of three types of loggers and six types of interceptor layers in one embodiment of the invention;
FIG. 6 is a user-specified 500 page in one embodiment of the invention.
Detailed Description
The following describes the embodiments of the present invention further with reference to the drawings. The description of these embodiments is provided to assist understanding of the present invention, but is not intended to limit the present invention. In addition, the technical features of the embodiments of the present invention described below may be combined with each other as long as they do not collide with each other.
The method is suitable for providing interception layers of the spring MVC and the dubbo under a micro-service framework of the spring MVC and the dubbo.
As shown in fig. 1-6, an ELK-based log storage method includes:
s1: establishing a call chain log recorder, an abnormal log recorder and an important log recorder;
s2: acquiring a link log by calling a link log recorder, acquiring an abnormal log by an abnormal log recorder, and acquiring an important log by an important log recorder; the exception in the try catch is also recorded by the exception log recorder
S3: the call chain logger, exception logger, and importance logger are made to share requestId, sessionId, user ID, user name, and entry method name.
In the ELK-based log storage method, the call link log, the abnormal log and the important log are split, so that the inquiry of abnormal time is facilitated, and the important log is stored for a longer time. The call link log, the abnormal log and the important log are respectively stored in three different log recorders, so that the log storage quantity can be improved. The link log, the exception log and the important log are recorded under different indexes and share the requestId, so that the related information can be searched under another index by using the requestId under one index, the provided exception logger records the exception in the try catch, and the link log, the exception log and the important log share the session identifier, the user ID, the user name and the entry method name besides the requestId (the entry method name is particularly important in the important log because a certain log is likely to have passed for a long time, when the link log searching entry is wanted to be called through the requestId, and the abnormal log can be searched through the requestId under one index when the abnormality occurs in the calling chain.
It should be noted that, in the step S1, a method info (String method, date state time, object result, object targets) is set in the call chain log recorder, where the parameter String method is a String method, the parameter Date state time is a method start time, the parameter Object result is an Object result, and the parameter Object targets is a return result;
acquiring requestId, sessionId, user ID and user name in the link log context by method info (Stringmethod, date state Time, object result, object region) and recording requestId, sessionId, user ID and user name together with parameter String method, parameter Date state Time, parameter Object result and parameter Object region into the link log;
after the call chain log recorder is established, the call chain log recorder is arranged in a web entry log layer, a web exception interception layer, a dubbo call interception layer, a mybatis interception layer and a dubbo service front-end interception layer, and is arranged in a state invisible to a programmer. The link log recorded by the called link log recorder is output to the index of userlog of ELK.
Optionally, in the step S1, a method error (Throwable e) or a method error (threadable) is set in the exception logger, where a parameter threadable is an exception object e that can be thrown, and is used to set the exception object e to be thrown, and a parameter threadable is an exception description, and is used to set an exception description for the exception object;
acquiring requestId, sessionId, user ID, user name and entry method in the exception log context by a method error (Throwable e) or a method error (running message), and recording requestId, sessionId, user ID, user name and entry method together with parameter running message and/or parameter running message into the exception log;
after the exception log recorder is established, the exception log recorder is arranged in a web exception interception layer, a dubbo call interception layer, a mybatis interception layer and a dubbo service front interception layer and is set to be in a callable state by a programmer. The exception log recorded by the modulated exception log recorder will be output under the index of the ELK's exception log.
Preferably, in the step S1, a method log (String funName, string message) is set in the important logger, where a parameter String funName is a function name and a parameter String message is function information;
acquiring requestId, sessionId, user ID, user name and entry method in the context of the important log by a method log (String funnname, string message), and recording requestId, sessionId, user ID, user name and entry method together with the parameter String funnname and parameter String message into the important log;
after the critical log logger is built, a programmer-callable state is set. The important log recorded by the important log recorder is output to the ELK under the index of normal operation log.
Specifically, in the step S1, when a request to enter the web portal log layer is made, the method start time and the parameters of the portal method are recorded first, and when the request is returned, the result record is returned, and then the link log is output by using the call link log recorder.
It should be noted that, in the step S1, after the request enters the entry method, and when the entry method throws an exception, the request is intercepted by the web exception interception layer, then the method, the method start time and the parameters are obtained from the web entry log layer, the exception information is used as a result, the call chain log recorder is used to output the exception log, then the error (Throwable e) method of the exception log recorder is used to output the detailed exception information, and finally the detailed exception information is returned to the 500 pages designated by the user. The value of the requestId may be shown in an alternative on page 500, as shown in fig. 6. A web anomaly interception layer is arranged in web engineering, a user can set an error page at the layer, when anomalies are thrown out, the requestId is exposed, and the anomaly source can be conveniently and rapidly located.
Preferably, in the step S1, parameters to be transmitted corresponding to the service method and the service method are obtained from parameter Invoker and parameter invocation in an interface method Result invoke (invoke <; when a return result exists, a call chain log recorder is used for outputting a chain log; when the exception is thrown by remote call, the link log is output by the call link log recorder, the simple information of the exception is taken as a result, the error (Throwable e) method of the exception log recorder is called to output the detailed information of the exception as an exception log, and the exception is thrown continuously.
Optionally, in the step S1, an interface method Result invoke (invoke <; when a return result exists, a calling chain log recorder is utilized to output a chain log; when the service call throws the exception, firstly, a call chain log recorder is used for outputting a link log, at the moment, the simple information of the exception is taken as a result, then, a error (Throwable e) method of the exception log recorder is called for outputting detailed information of the exception as an exception log, the exception is continuously thrown out, and finally, the link log context and/or the exception log context are emptied.
It should be noted that, in the step S1, an interface method Object interface (Invocation invocation) corresponding to the org.apoche.ibatis.plug.interntor interface of the mybatis interception layer is utilized, a query statement of the database to be executed is obtained from the parameter indication as a method, the parameter is also taken out from the parameter indication, the start time is recorded, and then the procedure method for calling the parameter indication calls the database; when a return result exists, a call chain log recorder is used for outputting a chain log; when the query statement of the database executes exception rejection, the link log is output by calling the link log recorder, the simple information that the link log is the exception at the moment is taken as a result, the error (Throwable e) method of the exception log recorder is called to output the detailed information of the exception as the exception log, and the exception is continuously rejected.
The ELK-based log storage method further utilizes a basic information acquisition layer to firstly attempt to acquire a value of a request header "_requestid" from a request header of an HttpServletRequest object, if the request header "_requestid" is acquired, if the request header "_requestid" is not acquired, then attempt to acquire the value of the "_requestid" from a url parameter of the request, if the request header "_requestid" is acquired, and if the request header "_requestid" is acquired, then generate the requestId for the current request, if the request header "_requestid" is not acquired, then acquire sessionId, sesssion information, a user ID and a user name from the HttpServletRequest object, and then store requestId, sessionId, the user ID and the user name into a link log context, an abnormal log context or an important log context. The sessioninformation is directly used by the web portal log layer, and when the request processing returns to the basic information acquisition layer, the log context is cleared.
As shown in fig. 5, six kinds of interception layers are provided, and the six kinds of interception layers only need to be configured, and a programmer is not required to write codes. Their positions are shown in fig. 5. Wherein the mybatis interception layer and the dubbo call interception layer are optional configuration, and are configured only when the engineering needs.
It should be noted that, for the internal http call, the call chain is disconnected, that is, the requestId is lost when the http is requested, so in this embodiment, the ELK-based log storage method further includes step S4, where step S4 includes: when the internal web interface is required to be called by using the http, before the http initiates the call, the requestId is acquired from the link log context, the exception log context and/or the important log context, and the value of the requestId is filled into the request header as_requestid. Thus, when the web receives a request, the basic information acquisition layer acquires the requestId, and when an internal http call is made, the call chain is not disconnected.
The link log context, exception log context, and/or importance log context maintain a jdk provided ThreadLocal object that can save variables among threads currently executing. The variables stored in the link log context, the exception log context and/or the important log context are Map objects for accessing common information required by the log.
Because three kinds of logs (link log, exception log, and importance log) are stored separately by three indexes, in the elastic search, the stored policies can be set by indexes. Thus, the expiration time of index userlog is set short, and the time of index normal operation log is set long, so that the requirements of long storage and important log storage time are met.
The embodiments of the present invention have been described in detail above with reference to the accompanying drawings, but the present invention is not limited to the described embodiments. It will be apparent to those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, and yet fall within the scope of the invention.
Claims (10)
1. An ELK-based log storage method, comprising:
s1: establishing a call chain log recorder, an abnormal log recorder and an important log recorder;
s2: acquiring a link log by calling a link log recorder, acquiring an abnormal log by an abnormal log recorder, and acquiring an important log by an important log recorder;
s3: the call chain logger, exception logger, and importance logger are made to share requestId, sessionId, user ID, user name, and entry method name.
2. The ELK-based log storage method of claim 1, wherein: in the step S1, a method info (String method, date state time, object result, object region) is set in the call chain log recorder, wherein the parameter String method is a String method, the parameter Date state time is a method start time, the parameter Object result is an Object result, and the parameter Object region is a return result;
acquiring requestId, sessionId, user ID and user name in the link log context by the method info (String method, date state Time, object result, object region) and recording requestId, sessionId, user ID and user name together with parameter String method, parameter Date state Time, parameter Object result and parameter Object region into the link log;
after the call chain log recorder is established, the call chain log recorder is arranged in a web entry log layer, a web exception interception layer, a dubbo call interception layer, a mybatis interception layer and a dubbo service front-end interception layer, and is arranged in a state invisible to a programmer.
3. The ELK-based log storage method of claim 2, wherein: in the step S1, a method error (Throwable e) or a method error (threadable e) is set in the exception log recorder, wherein a parameter threadable e is an anomaly object e that can be thrown out, and a parameter threadable is an anomaly specification;
acquiring requestId, sessionId, user ID, user name and entry method in the exception log context by a method error (Throwable e) or a method error (running message), and recording requestId, sessionId, user ID, user name and entry method together with parameter running message and/or parameter running message into the exception log;
after the exception log recorder is established, the exception log recorder is arranged in a web exception interception layer, a dubbo call interception layer, a mybatis interception layer and a dubbo service front interception layer and is set to be in a callable state by a programmer.
4. A log storage method based on ELK according to claim 3, wherein: in the step S1, a method log (String funName, string message) is set in the important log recorder, wherein a parameter String funName is a function name, and a parameter String message is function information;
acquiring requestId, sessionId, user ID, user name and entry method in the context of the important log by a method log (String funName, string message), and recording requestId, sessionId, user ID, user name and entry method together with the parameter String funName and the parameter String message into the important log;
after the critical log logger is built, a programmer-callable state is set.
5. The ELK-based log storage method of claim 4, wherein: in the step S1, when a request is made to enter the web portal log layer, the method start time and the parameters of the portal method are recorded first, and when the request is returned, the result record is returned, and then the link log is output by using the call link log recorder.
6. The ELK-based log storage method of claim 5, wherein: in the step S1, after the request enters the entry method, and when the entry method throws an exception, the request is intercepted by the web exception interception layer, then the method, the method start time and the parameters are acquired from the web entry log layer, the exception information is used as a result, the call chain log recorder is used for outputting the exception log, then the error (Throwable e) method of the exception log recorder is used for outputting the detailed exception information, and finally the detailed exception information is returned to the 500 pages designated by the user.
7. The ELK-based log storage method of claim 6, wherein: in the step S1, parameters of a service method and a corresponding transmission parameter of the service method are obtained from an org.apoche.dubbo.rpc.filter interface corresponding to the dubbo call interception layer, and start time is recorded, then requestId, sessionId, user ID and user name are obtained from a link log context, or requestId, sessionId, user ID, user name and entry method are obtained from an abnormal log context, and rpccontext.gettext (). Setattribute (strument) method provided by a dubbo framework corresponding to the dubbo call interception layer is called, requestId, sessionId, user ID, user name and entry method are recorded in an attachment of a transmission packet, and then the input method of the parameter Invoker is called to call a remote bbo service; when a return result exists, a call chain log recorder is used for outputting a chain log; when the exception is thrown by remote call, the call chain log recorder is used for outputting a link log, then the error (Throwable e) method of the exception log recorder is called for outputting detailed information of the exception as an exception log, and the exception is thrown continuously.
8. The ELK-based log storage method of claim 7, wherein: in the step S1, an interface method Result invoke (invoke <; when a return result exists, a calling chain log recorder is utilized to output a chain log; when the service call throws the exception, the link log is output by the call link log recorder, the error (Throwable e) method of the exception log recorder is then called to output the detailed information of the exception as the exception log, the exception is thrown continuously, and finally the link log context and/or the exception log context are emptied.
9. The ELK-based log storage method of claim 8, wherein: in the step S1, an interface method Object interface (Invocation invocation) corresponding to an org.apache.ibatis.plug.interntor interface of the mybatis interception layer is utilized, a query statement of a database to be executed is obtained from a parameter indication as a method, parameters are also taken out from the parameter indication, the starting time is recorded, and then a process method of the parameter indication is called to call the database; when a return result exists, a call chain log recorder is used for outputting a chain log; when the query statement of the database executes exception rejection, the link log is output by using the call link log recorder, then the detailed information of the exception is output by using the error (Throwable e) method of the exception log recorder as the exception log, and the exception is continuously rejected.
10. The ELK-based log storage method as claimed in claim 9, wherein: further comprising a step S4, said step S4 comprising: when the internal web interface is required to be called by using the http, before the http initiates the call, the requestId is acquired from the link log context, the exception log context and/or the important log context, and the value of the requestId is filled into the request header as_requestid.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310400371.8A CN116737679A (en) | 2023-04-14 | 2023-04-14 | A log storage method based on ELK |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310400371.8A CN116737679A (en) | 2023-04-14 | 2023-04-14 | A log storage method based on ELK |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116737679A true CN116737679A (en) | 2023-09-12 |
Family
ID=87906780
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310400371.8A Pending CN116737679A (en) | 2023-04-14 | 2023-04-14 | A log storage method based on ELK |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116737679A (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101425034A (en) * | 2008-08-11 | 2009-05-06 | 深圳市金蝶中间件有限公司 | Log recording method and log system |
| CN104205111A (en) * | 2012-03-19 | 2014-12-10 | 高通股份有限公司 | Computing device to detect malware |
| WO2016098376A1 (en) * | 2014-12-15 | 2016-06-23 | 三菱電機株式会社 | Surveillance recorder and startup method therefor |
-
2023
- 2023-04-14 CN CN202310400371.8A patent/CN116737679A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101425034A (en) * | 2008-08-11 | 2009-05-06 | 深圳市金蝶中间件有限公司 | Log recording method and log system |
| CN104205111A (en) * | 2012-03-19 | 2014-12-10 | 高通股份有限公司 | Computing device to detect malware |
| WO2016098376A1 (en) * | 2014-12-15 | 2016-06-23 | 三菱電機株式会社 | Surveillance recorder and startup method therefor |
Non-Patent Citations (1)
| Title |
|---|
| 吴世聪: "基于JME的三维无源定位系统的研究与实现", 《中国优秀硕士学位论文全文数据库 信息科技辑》, 15 May 2013 (2013-05-15), pages 138 - 2066 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8578017B2 (en) | Automatic correlation of service level agreement and operating level agreement | |
| US8051163B2 (en) | Synthetic transactions based on system history and load | |
| Mayer et al. | An approach to extract the architecture of microservice-based software systems | |
| US7953850B2 (en) | Monitoring related content requests | |
| US9740991B2 (en) | Calculating in-flight metrics for non-interruptible business transactions | |
| US7003781B1 (en) | Method and apparatus for correlation of events in a distributed multi-system computing environment | |
| US8656006B2 (en) | Integrating traffic monitoring data and application runtime data | |
| US8812434B2 (en) | Data structure for efficiently identifying transactions | |
| US20200201699A1 (en) | Unified error monitoring, alerting, and debugging of distributed systems | |
| US20070266045A1 (en) | Hierarchy for characterizing interactions with an application | |
| KR101797185B1 (en) | Efficiently collecting transaction-separated metrics in a distributed environment | |
| US20140013302A1 (en) | Log configuration of distributed applications | |
| US20080098359A1 (en) | Manipulation of trace sessions based on address parameters | |
| CN108197200A (en) | Daily record method for tracing, device, computer equipment and storage medium | |
| WO2007036932A2 (en) | Data table management system and methods useful therefor | |
| US11681707B1 (en) | Analytics query response transmission | |
| US20210149773A1 (en) | Qualification parameters for captain selection in a search head cluster | |
| US8037458B2 (en) | Method and system for providing a common structure for trace data | |
| CN114422564A (en) | Audit tracing method and device for access data, computer equipment and storage medium | |
| CN114168421B (en) | Customized code compatibility analysis system and method based on microservice call chain | |
| CN113946556A (en) | A slow log collection method for MongoDB instances | |
| CN113986895A (en) | Three-layer auditing method under micro-service distributed scene | |
| CN115455059B (en) | Method, device and related medium for analyzing user behavior based on underlying data | |
| US20190190981A1 (en) | Intelligent trace generation from compact transaction runtime data | |
| CN116737679A (en) | A log storage method based on ELK |
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 |