JP2017130111A - Dataflow log generation device, relational database, dataflow log generation method, program, and monitoring system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To generate a dataflow log capable of comprehensively monitoring data crossing various types of components while suppressing a load applied onto a computational system or the like as much as possible.SOLUTION: A dataflow log generation device comprises: a first acquisition part for, when a dataflow between a first object in a first component as a process and a second component occurs, acquiring first position information indicating a start point or end point of the dataflow in the first component; a second acquisition part for acquiring second position information indicating the start point or end point of the dataflow in the second component; and a log generation part for generating a dataflow log in which the first position information and the second position information are recorded.SELECTED DRAWING: Figure 1

Description

  Embodiments described herein relate generally to a data flow log generation device, a relational database, a data flow log generation method, a program, and a monitoring system.

  In recent years, with the improvement of processing efficiency of computers and the advancement of information services, computer systems in which a plurality of computers and programs operate in cooperation have become common. In such a computing system, observation and monitoring of data flow (data flow) across multiple programs is performed in order to realize calculation processing abnormality detection, security diagnosis, debugging, performance monitoring, performance degradation factor analysis, etc. It is known to do.

  The monitoring method for monitoring the data flow as described above requires (1) that data can be comprehensively monitored even when data crosses various types of components such as processes, files, and databases. However, for example, if the OS standard monitoring function is used, it is possible to monitor the data flow based on the file or the inter-process communication, but the data flow inside the process or the data flow between the process and the database is monitored. Is difficult.

  On the other hand, (2) it is also required that the load (overhead) or the configuration change applied to the calculation system be minimized. For example, if a mechanism for adding identification metadata for observing a data flow across components is added, the load on the calculation system increases. Therefore, it is important how to make comprehensive monitoring and the load on the computing system compatible.

JP 2013-242633 A

Chun Hui Suen, Ryan K L Ko, Yu Shyang Tan, Peter Jagadpramana, Bu Sung Lee, "S2Logger: End-to-End Data Tracking Mechanism for Cloud Data Provenance," In Proceedings of 12th IEEE International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom '13), p. 594-602.

  The embodiment of the present invention generates a data flow log that can comprehensively monitor data crossing various types of components while minimizing the load on the computing system.

  When the data flow between the 1st object in the 1st component which is a process and the 2nd component arises, the data flow log generation device as one mode of the present invention WHEREIN: The data in the 1st component A first acquisition unit that acquires first position information indicating a start point or an end point of a flow; a second acquisition unit that acquires second position information indicating a start point or an end point of the data flow in the second component; A log generation unit that generates a data flow log in which one position information and the second position information are recorded.

1 is a block diagram illustrating an example of a schematic configuration of an entire computer system according to a first embodiment. The figure which shows an example of an access destination table. The flowchart of the production | generation process of the data flow log inside a Java program. The flowchart of the production | generation process of the data flow log in the case of reading data from a database. The figure which shows an example of the content preserve | saved at a bind temporary preservation | save part. The flowchart of the data recording process to a bind temporary storage part. The flowchart of the production | generation process of the data flow log in the case of writing data to a database. The figure which shows an example of the content of a temporary log table. The block diagram which shows an example of schematic structure of the whole computer system which concerns on 2nd Embodiment. The figure which shows an example of the information preserve | saved at the access destination file name temporary preservation | save part. The flowchart of the production | generation process of the data flow log in the case of reading data from a file. The flowchart of the production | generation process of the data flow log in the case of writing data to a file. The block diagram which shows an example of schematic structure of the whole computer system which concerns on 3rd Embodiment. The flowchart of the production | generation process of the data flow log inside the Java program which concerns on 3rd Embodiment. 12 is a flowchart of data flow log generation processing between Java programs according to the third embodiment. The block diagram which shows an example of the hardware constitutions in one Embodiment of this invention.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

(First embodiment)
FIG. 1 is a block diagram illustrating an example of a schematic configuration of the entire computer system according to the first embodiment. The computer system according to the first embodiment includes a process 1 by a program, a relational database (RDB) 2, and a log receiving unit 3.

  The computer system according to the first embodiment assumes that a predetermined procedure is performed by a process (program) 1 that is a first component. Then, when a predetermined procedure is performed, various data are exchanged (exchanged). Here, the flow of data exchange is referred to as a data flow. The data exchanged is not particularly limited. Further, for example, not only data transfer but also an event that an object in a program generates another object is included in the data flow.

  Here, it is assumed that Java (registered trademark) is used for the program, and the following description will be made as Java program 1. A program other than Java, such as an object-oriented program having the same function as the Java program 1, may be used.

  The Java program 1 generates a log in which the data flow is recorded. This log is referred to as a data flow log. The data flow log includes information (position information) indicating the start point or end point of the data flow. By generating such a data flow log, it is possible to monitor the data flow.

In the computer system according to the first embodiment, a data flow inside the Java program 1 and a data flow between the Java program 1 and the RDB 2 can occur. Therefore, data flow logs relating to the following three types of data flows are generated.
(1) Data flow in Java program 1 (2) Data flow in which Java program 1 reads data from RDB 2 (3) Data flow in which data is written from Java program 1 to RDB 2 (2) and data flow logs in (3) Even when the data flow crosses the first component and another component (second component), comprehensive monitoring can be performed.

  Next, the Java program 1 will be described. The Java program 1 shown in FIG. 1 includes Java objects 101 and 102, a System class 103, a Logger object 104, a JDBC (Java Database Connectivity) driver, a Logger hook 107, and a temporary binding storage unit 105.

  A Java object is an object generated for executing a predetermined procedure, and is a unit for holding data in a Java program. A Java program operates by exchanging data between Java objects.

  The arrows between the Java object 101 and the Java object 102 shown in FIG. 1 mean the data flow inside the Java program 1 of (1) above. Moreover, the arrows between the Java object 102 and the RDB2 mean the data flow between the Java program 1 and the RDB 2 in the above (2) and (3).

  Note that the Java object used varies from procedure to procedure. The Java object used is introduced for each procedure described later.

  The System class 103 gives an object identifier to each Java object and manages the object identifier. In the present embodiment, the object identifier is used to identify the Java object to which data has been exchanged. That is, the object identifier is used to indicate the start point or end point of the data flow.

  The Logger object 104 monitors the data flow inside the Java program 1. In addition, the Logger object 104 generates a Logger hook 107 to be described later and monitors the data flow between the Java program 1 and the RDB 2. Further, the Logger object 104 generates a data flow log and sends the data flow log to the log receiving unit 3.

  The temporary binding storage unit 105 temporarily stores data necessary for the Logger object 104 to generate a data flow log.

  The JDBC driver 106 performs communication related to data exchange between the Java program 1 and the RDB 2. Further, the JDBC driver 106 performs communication for acquiring information necessary for generating a data flow log from the RDB 2.

  The logger hook 107 is generated by the logger object 104 and connected to the JDBC driver 106. As a result, all data flows between the Java program 1 and the RDB 2 go through the Logger hook 107. Then, the Logger hook 107 detects the data flow between the Java program 1 and the RDB 2 so that the data flow between the Java program 1 and the RDB 2 can be covered.

  Next, RDB2 will be described. The RDB 2 includes a database interface (DB_I / F) 201, an access destination table 202, a system catalog 203, and a temporary log table 204.

  DB_I / F 201 is a database operation interface that is open to the Java program 1. Data is exchanged between the Java program 1 and the RDB 2 by the communication between the JDBC driver 106 and the DB_I / F 201.

  The access destination table 202 is a table accessed from the Java object 102 in a predetermined procedure executed by the Java program 1. FIG. 2 is a diagram illustrating an example of the access destination table 202. Here, description will be made assuming that the access destination table 202 has the structure of FIG. Information that is not shown in FIG. 2 may be included.

  It is assumed that the access destination table 202 has a schema name “sample_schema” and a table name “sample_table”. The sample_table has three columns: signal_id, history_time, and signal_value. Here, a pair (combination) of signal_id and history_time is used as a primary key for uniquely identifying a row included in the table.

  The system catalog 203 is a table that holds information regarding all the tables (including the access destination table 202) in the RDB2.

  The primary log table is a table for temporarily storing a log for data writing to the access destination table 202.

  Next, the log receiving unit 3 will be described. The log receiving unit 3 receives the generated data flow log. Any communication means such as TCP / IP communication may be used for transmission / reception of the data flow log. The log receiving unit 3 may store the data flow log or output it to another system or the like in order to analyze the data flow log later.

  In FIG. 1, the log receiving unit 3 is located outside the Java program 1, but may be located inside the Java program 1 or inside the RDB 2.

Next, a specific recording method for generating data flow logs of the above three types of data flows will be described.
(1) Data flow inside Java program 1 As shown in FIG. 1, the data flow inside Java program 1 includes data transfer from Java object 101 to Java object 102, or Java object 102 using Java object 101. There are events such as generation. For example, the code shown below produces a data flow within Java program 1.
Object copied_data = original_data.clone ()
Object processed_data = processData (copied_data)
In the first line, it can be said that a data flow from the original_data object to the copied_data object has occurred. In this case, it can be said that the original_data object is the Java object 101 and the copied_data object is the Java object 102. In addition, it can be said that the data flow from the copied_data object to the processed_data object occurs in the second line.

  As described above, when a data flow occurs in the Java program 1, the Java object 101 that is the start point of the data flow and the Java object 102 that is the end point of the data flow are passed to the Logger object 104, so that the Logger The object 104 can detect the occurrence of a data flow.

More specifically, the Java objects 101 and 102 are passed to the Logger object 104 by calling a flow method for the Logger object 104. Calling the flow method for the above two data flows results in the following code.
logger.flow (original_data, copied_data)
logger.flow (copied_data, processed_data)
The logger of the above code means the logger object 104. logger. The flow method is called by the flow, and the object in parentheses is passed to the Logger object 104. In the above code example, the first object in the parentheses is passed to the Logger object 104 as the Java object 101 that is the start point of the data flow, and the second object in the parentheses is the Java object 102 that is the end point of the data flow.

  The Logger object 104 that has detected the occurrence of the data flow generates a data flow log of the data flow. FIG. 3 is a flowchart of the data flow log generation process inside the Java program. As described above, this flow starts when the flow method is called.

  The Logger object 104 first calls the identifyHashCode method of the System class 103 to acquire the object identifiers of the Java objects 101 and 102 (S101 and S102). Next, the Logger object 104 generates a data flow log based on the acquired identifiers (S103). The generated data flow log is sent to the log receiving unit 3 (S104). For the log transmission, any communication means such as TCP / IP communication may be used. The above is the flow of data flow log generation processing.

  This flowchart is an example, and the present invention is not limited to this. For example, the order of S101 and S102 may be different. The same applies to flowcharts in the embodiments described below.

The data flow log is generated, for example, as text data in JSON (Java Script (registered trademark) Object Notation) format. An example of a data flow log generated as JSON format text data is shown below.
{
“Src”: {
“Type”: “java_internal”,
“Object_hash”: “1487365346”
},
“Dst”: {
“Type”: “java_internal”,
“Object_hash”: “1786281489”
},
“Time”: “1439172160987”
}
src indicates information related to the start point of the data flow. dst indicates information regarding the end point of the data flow. The type field included in src and dst indicates the type of component. The value field Java_internal of the type field means a Java object. The object_hash field indicates the identifier of the object. Therefore, it is possible to analyze the Java object at the start point and the Java object at the end point of the data flow from the data flow log. The time field indicates the time when the data flow log is generated.

  The data flow log may include various information in addition to the above information. For example, the host name of the computer on which the Java program 1 is running, the process ID of the Java program 1, the thread ID of the Java program 1, the class name of the Java object at the start or end point, the file name of the code that calls the flow method, and the file The data flow log may include information such as the line number in the table or the class name and method name that calls the flow method.

  Thus, the Logger object 104 acquires an object identifier indicating the start point of the data flow and an object identifier indicating the end point of the data flow from the System class 103. The Logger object 104 generates a data flow log in which both object identifiers are recorded. As a result, the data flow inside the Java program can be monitored based on the generated data flow log.

(2) Data flow in which the Java program 1 reads data from the RDB 2 The data flow in which the Java program 1 reads data from the RDB 2 is, for example, as shown in FIG. There is something to get. Information regarding the data flow between the Java program 1 and the RDB 2 is collected by the Logger hook 107.

The Logger hook 107 is an additional function connected to the JDBC driver 106. The Logger hook 107 is, for example, Java. lang. reflect. This can be realized by using the function of the Proxy class. Then, the Logger object 104 calls the wrap method and wraps (connects) the Logger hook 107 to the JDBC driver 106 as shown in the following code.
connection = logger.wrap (connection)
connection is Java. which is a part of the JDBC driver 106. sql. It is a Connection type object. The wrap method connects the Logger hook 107 to a given connection and returns the result as a return value. Accordingly, the Logger hook 107 is connected to the connection, and all operations performed on the object generated from the connection and the connection are monitored by the Logger hook.

  When data is read from RDB2 using the JDBC driver 106, a ResultSet object is mainly used. The Logger hook 107 detects an operation of reading data for the ResultSet object. Then, the Logger object 104 that has received the detection notification generates a data flow log related to an operation of reading the detected data.

The following is an example of data reading code using a ResultSet object. In the code below, the rs. Since the RDB2 data is read by the getObject method, rs. When the getObject method is called, the Logger hook 107 detects a data flow.
PreparedStatement ps = connection.prepareStatement (
“SELECT signal_id, history_value, signal_value”
+ “FROM sample_schema.sample_table”
+ “WHERE signal_id =? ORDER BY history_time ASC LIMIT 1”
);
ps.setInt (1,1);
ResultSet rs = ps.executeQuery ();
while (rs.next ()) {
Double value = (Double) rs.getObject (“signal_value”);
}

  In the above code, the Java object 102 that is the data reading destination is obtained as a return value as a result of calling a data reading method such as getObject on the ResultSet object, not on the ResultSet object.

  FIG. 4 is a flowchart of data flow log generation processing when data is read from the database. As described above, this flow starts when the ResultSet object calls a data reading method such as getObject or getString.

  The Logger hook 107 confirms the automatic commit setting of the Connection object that generated the ResultSet object. If the automatic commit setting is valid, the Logger hook 107 invalidates the automatic commit setting (S201). The reason for invalidating the autocommit setting is to generate an accurate data flow log.

  Invalidation of the automatic commit setting is realized by calling the getAutoCommit method for the Connection object, checking the automatic commit setting, and then calling the setAutoCommit method. Details will be described later.

  Next, when data is read from the RDB2 by the Java object 102 (S202), the Logger hook 107 uses the ResultSet object to acquire information indicating the location (position) of the RDB2 where the read data is stored. (S203 to S205). Information indicating the location (position) of the RDB 2 is a database name, catalog name, schema name, table name, column name, and table primary key name and value. Here, these pieces of information are referred to as database related information. By including the name and value of the primary key of the table, it is possible to recognize in which row of the access destination table 202 of RDB2 the data is written.

  First, the Logger hook 107 acquires a database name (S203). The database name can be acquired by acquiring a URL character string indicating the connection destination RDB2. The URL string is rs. getStatement (). getConnection (). getMetaData (). It can be obtained by calling the getURL () method. Note that rs means a ResultSet object as shown in the sixth line of the above code.

  Next, the Logger hook 107 acquires a catalog name, a schema name, a table name, and a column name (S204). These names are rs. It can be acquired by executing the getCatalogName, getSchemaName, getTableName, and getColumnName methods for the ResultSetMetaData type object acquired by getMetaData ().

  Next, the Logger hook 107 acquires the name of the primary key of the table (S205). The name of the primary key is the acquired catalog name, schema name, table name, rs. getStatement (). getConnection (). getMetaData (). It can be obtained by passing it as an argument of the getPrimaryKeys () method. Thereafter, the Logger hook 107 acquires the value of the data whose column name is included in the primary key among the data included in the ResultSet object rs, and stores it as a pair of the primary key name and value (S206).

  Note that the method executed in the processing from S203 to S205 finally makes an inquiry to the system catalog 203 of RDB2 via the ResultSet object.

  The database related information acquired by the Logger hook 107 is passed to the Logger object 104, and the Logger hook 107 is activated when invalidating the connection auto-commit setting (S207). The Logger object 104 acquires the object identifier of the Java object 102 from which the acquired data is read from the system class 103 (S208).

  The Logger object 104 generates a data flow log using the database related information acquired from the Logger hook 107 and the object identifier acquired from the System class 103 (S209). The Logger object 104 transmits the generated data flow log to the log receiving unit 3 (S210). The above is the flow of data flow log generation processing when data is read from the RDB2.

  The reason why the Logger hook 107 invalidates the connection auto-commit setting is that the data read from the ResultSet object and the subsequent inquiry to the system catalog 203 from the Logger hook 107 are executed in the same transaction. . If these processes are performed in separate transactions, a problem may occur if another program executes an instruction to the RDB 2 immediately after reading data from the ResultSet. For example, when information is read from the system catalog 203 after another program issues a table name change instruction to the RDB 2, the information cannot correctly represent the data read from the ResultSet. Therefore, by operating the automatic commit setting and executing each process in the same transaction, the above information does not occur and correct information can always be acquired from the system catalog 203.

  In the above description, the connection auto-commit setting is operated. However, similarly, the transaction isolation level may be temporarily operated using the getTransactionIsolation method and the setTransactionIsolation method. For example, when the transaction isolation level is temporarily set to TRANSACTION_SERIALIZEABLE, which is the strongest isolation level, a correct data flow log can be obtained more reliably than when not.

The following is an example of the generated data flow log. The data flow log is data when the Java object 102 reads the signal_value column (value is 100.4) in the second row (excluding the column name row) from the top in the access destination table 202 shown in FIG. It is a flow log.
{
“Src”: {
“Type”: “rdb”,
“Db_name”: “sample_db”,
“Db_catalog”: “”,
“Db_schema”: “sample_schema”,
“Db_table”: “sample_table”,
“Db_pk_signal_id”: “1”,
“Db_pk_history_time”: “2015-09-07 10: 05: 48.392 + 09: 00”,
“Db_column”: “signal_value”
},
“Dst”: {
“Type”: “java_internal”,
“Object_hash”: “337422011”
},
“Time”: “1439172160332”
}

  The src field shown from the second line of the data flow log includes information on the start point of the data flow. Here, the starting point of the data flow is in the RDB2, and the src field includes database related information such as the data recording location (catalog name, schema name, table name, column name) in the RDB2.

  The value “rdb” of the type field in the src field represents a database. db_name, db_catalog, db_schema, db_table, and db_column indicate the database name, catalog name, schema name, table name, and column name, respectively. For example, the database name is sample_db.

  The db_pk_signal_id field and the db_pk_history_time field are a pair that constitutes the primary key of sample_table. In this way, since the primary key is recorded in the log, it is possible to specify up to the row of the access destination table 202 where the data was stored. The time field is the time when this data flow log is generated.

  The dst field shown from the 13th line of the data flow log includes information regarding the end point of the data flow. Here, the end point of the data flow is the Java object 102. Each field in the dst field is the same as the internal data flow of the Java program 1 described above.

  The data flow log may include various information in addition to the information described above. For example, an IP address related to RDB2, a standby port number, or a product name and its version number may be included in the data flow log. Further, the transaction ID when accessing RDB2, the row ID assigned by RDB2 to the row to be read, the values of columns other than the primary key of the row to be read, and the like may be included in the data flow log.

  In the process of S206 shown in FIG. 4, the Logger hook 107 acquires the value of the primary key from the ResultSet object. However, generally, the primary key of the table to be read is not necessarily included in the ResultSet object. Absent. Therefore, when the Java program 1 issues a data read command (a SELECT statement in SQL) to the RDB 2 in order to guarantee that the ResultSet object includes the primary key value, the Logger hook 107 issues the data read command. The data read command may be rewritten and transmitted to the RDB 2 so that the data is captured and analyzed and read together with the primary key of the table to be read. Reading instructions can be supplemented by monitoring method calls to the Connection class, Statement class, PreparedStatement class, etc. in the JDBC. As a result, an accurate data flow log can be recorded regardless of the data read from the RDB 2 by the Java program 1.

  As described above, the Logger object 104 acquires an object identifier indicating the start point of the data flow from the System class 103. Further, the Logger hook 107 makes an inquiry to the RDB 2 to acquire database related information indicating the end point of the data flow. The Logger object 104 generates a data flow log in which information indicating the start point of the data flow and information indicating the end point are recorded. Accordingly, it is possible to monitor the data flow in which the Java program 1 reads data from the RDB 2 based on the generated data flow log.

(3) Data flow for writing data from Java program 1 to RDB2 When data is written from Java program 1 to RDB2, information related to the data flow is collected by Logger hook 107, as is the case when Java program 1 reads data from RDB2. It is done.

When writing data to the RDB 2 using the JDBC driver 106, a PreparedState object is mainly used. The Logger hook 107 detects an operation of writing data by this PreparedStatement object.

The following is an example of a data write code using a PreparedStatement object.
PreparedStatement ps = connection.prepareStatement (
“UPDATE sample_schema.sample_table”
+ “SET signal_value =?”
+ “WHERE signal_id =?”
);
ps.setObject (1, write_value);
ps.setInt (2, 2);
ps.execute ();

  The data write code shown above is composed of three procedures. First, as shown in the first line, (i) connection. PreparedStatement generates a PreparedStatement object having an SQL instruction for RDB2. In the above code, the 3rd to 5th lines are SQL instructions. Next, as shown in the 6th and 7th lines, (ii) the Java object 102 and the parameter are bound to the PreparedStatement. Then, as shown in the eighth line, (iii) ps. With execute, data is written to RDB2.

  The procedure (ii) above associates (binds) the Java object 102 with the placeholder in the SQL instruction issued to the RDB 2. As a result, the Java program 1 can write data to the RDB 2.

  In the above code, the Java object 102 that is the data write source is not the PreparedState object, but is bound to the PreparedState object.

  The data flow log generation process in the above code is divided into three processes. First, when the procedure (i) is performed, the Logger hook 107 performs processing for storing information related to data writing in the temporary binding storage unit 105. Next, when the procedure (ii) is performed, the Logger hook 107 acquires the identifier of the bound Java object 102 and associates it with the data stored in the temporary binding storage unit 105. When the procedure (iii) is performed, the Logger hook 107 acquires primary key information for determining the row of the access destination table 202 in which data is written. The Logger object then generates a data flow log.

  FIG. 5 is a diagram illustrating an example of contents stored in the bind temporary storage unit 105. The temporary binding storage unit 105 stores four types of data including a prepared statement object, information on the access destination table 202 in the RDB 2 (catalog name, schema name, table name, column name), placeholder index, and bind object. It has a data structure for managing in association with each other.

  The PreparedStatement object identifier is an identifier of a PreparedStatement object. The placeholder index is a sequence number in which the placeholder appears in the SQL instruction. The bind object identifier is an identifier of the bound Java object 102.

  In general, when writing data from the Java program 1 to the RDB 2, a placeholder representing the name of the write destination column and the data to be written is written in the SQL instruction. For example, in the above code, the character string “signal_value =?” Represents a set of “signal_value” that is the name of the column and “?” That is the placeholder.

  In the case of the placeholder paired with the above signal_value, the index is 1 because it is the first placeholder in the SQL instruction. Therefore, 1 is stored in the placeholder index in the first row in FIG. Generally, there are a plurality of pairs of column names and placeholder indexes in one SQL instruction. In that case, a separate line is generated in the temporary binding storage unit 105 for each pair.

  The bind temporary storage unit 105 may be secured on the memory of the Java program 1, may be secured on the RDB 2, or may be secured on any other storage area. Each data (each row) stored in the temporary binding storage unit 105 may be deleted when the corresponding prepared statement object is no longer used.

  FIG. 6 is a flowchart of a data recording process to the bind temporary storage unit 105. Recording to the temporary binding storage unit 105 is performed by using the connection. The processing is performed in two stages, that is, processing that is performed when the prepareStatement method is executed and processing that is performed when the Java object 102 is bound in (ii). FIG. 6A shows the connection. FIG. 6B shows the flow of processing that is performed when the prepareStatement method is executed. FIG. 6B shows the flow of processing that is performed when the Java object 102 is bound in (ii).

  First, a process performed when the prepareStatement method shown in FIG. This flow is started when the Java program 1 executes a prepareStatement method call for the Connection object. The Logger hook 107 acquires a PreparedStatement object that is a return value of the prepareStatement method (S301). Next, the Logger hook 107 analyzes the SQL instruction character string, and acquires a pair of column names corresponding to the catalog name, schema name, table name, and placeholder index of the write destination (S302). As a result, information other than the bind object identifier in the data structure of the temporary bind storage unit 105 is acquired. The Logger hook 107 records the acquired information in the bind temporary storage unit 105 (S303).

  The PreparedStatement object identifier can be acquired from the System class 103.

  Next, processing that is performed when the Java object 102 shown in FIG. 6B is bound will be described. This flow is started when the Java program 1 executes a method call such as setObject for the PreparedStatement object. The Logger hook 107 acquires the placeholder index given as an argument to a method such as setObject and the Java object 102 to be bound, and the object identifier of the PreparedStatement object from which the method is called (S401). The Logger hook 107 searches each row of the temporary binding storage unit 105 based on the placeholder index and the prepared statement object identifier (S402). When there is a row in which the placeholder index and the prepared statement object identifier have the same value (YES in S403), the Logger hook 107 uses the object identifier of the Java object 102 to be bound as the bind object identifier for the detected row. Record (S404). If there is no row having the same value for the placeholder index and the PreparedStatement object identifier (NO in S403), the Logger hook 107 does nothing and this flow ends. Recording to the bind temporary storage unit 105 is completed by the above two procedures.

  FIG. 7 is a flowchart of data flow log generation processing when data is written to the database. As described above, this flowchart is started when a data write execution method such as execute or executeUpdate method is called for the PreparedStatement object of (iii) above.

  First, the Logger hook 107 temporarily invalidates the automatic commit setting of the Connection object (S501). This invalidation is based on the same method and reason as that performed in the data flow log generation process when data is read from the RDB 2 shown in FIG. Further, the Logger hook 107 deletes all the contents of the temporary log table 204 (S502).

  When data is written to the RDB 2 (S503), the trigger set in the access destination table 202 records data write destination information in the temporary log table 204 (S504).

  In this embodiment, a trigger is set in advance in the access destination table 202. “Trigger” means a procedure executed in the RDB 2 when an operation is performed on a table. Here, the trigger is set in the access destination table 202, and the trigger activated when the data write operation is executed in the access destination table 202 is set to record the data write destination information in the temporary log table 204. deep. Many RDB2 products provide a function for setting and executing a trigger, and the function may be used.

  FIG. 8 is a diagram illustrating an example of the contents of the temporary log table 204. The temporary log table 204 stores a catalog name, a schema name, a table name, a name and a value of a primary key of a write destination row, and a name of a write destination column. When writing to a plurality of tables, a plurality of rows, or a plurality of columns occurs in one writing operation, a plurality of rows corresponding to the writing are written to the temporary log table 204. Note that information such as the name of the column on which writing has been performed is appropriately read from the system catalog 203 and written to the temporary log table 204.

  Returning to the description of the flow in FIG. When the trigger writes the write destination database information to the temporary log table 204, the Logger hook 107 reads the information of the temporary log table 204 from the RDB 2 and transfers the information of the temporary log table 204 to the Logger object 104 (S505). Further, the Logger hook 107 restores the connection auto-commit setting (S506).

  The Logger object 104 acquires information on the temporary log table 204 from the Logger hook 107 (S507), searches the bind temporary storage unit 105 based on the information on the temporary log table 204, and acquires a bind object identifier (S508). .

The Logger object 104 includes a data flow log as shown below for a combination of data including a database name, catalog name, schema name, table name, primary key name and value, column name, and bind object identifier. Is generated (S509). When a plurality of data combinations are acquired, a data flow log is generated for each data combination.
{
“Src”: {
“Type”: “java_internal”,
“Object_hash”: “337422011”
},
“Dst”: {
“Type”: “rdb”,
“Db_name”: “sample_db”,
“Db_catalog”: “”,
“Db_schema”: “sample_schema”,
“Db_table”: “sample_table”,
“Db_pk_signal_id”: “2”,
“Db_pk_history_time”: “2015-09-07 10: 10: 53.334 + 09: 00”,
“Db_column”: “signal_value”
},
“Time”: “1439172160332”
}
The object_hash field in the src field of the data flow log indicates the bind object identifier. Each field in the dst field indicates information on the write destination RDB2, and (2) is the same as the data flow log when the Java program 1 reads data from the RDB2. The time field represents the time when this data flow log was generated.

  The Logger object 104 transmits the generated data flow log to the log receiving unit 3 (S510). The above is the flow of the data flow reporting process.

  In the data flow reporting process, “name and value of primary key” are used, but instead of this, a row ID used to identify each row in the RDB 2 may be used. The data flow log may include various other related information.

  Thus, the Logger hook 107 acquires the bind object identifier indicating the start point of the data flow from the System class 103. Further, the Logger hook 107 acquires database related information indicating the end point of the data flow based on the information of the temporary binding storage unit 105 and the information of the temporary log table. The Logger object 104 generates a data flow log in which information indicating the start point of the data flow and information indicating the end point are recorded. As a result, the data flow in which the Java program 1 writes data to the RDB 2 can be monitored based on the generated data flow log.

  As described above, according to the present embodiment, (1) the data flow in the Java program 1, (2) the data flow in which the Java program 1 reads data from the RDB 2, and (3) the data from the Java program 1 to the RDB 2 Can be recorded in a unified format. As a result, the data flow across the Java program 1 and the RDB 2 can be recorded in detail and exhaustively. For example, a data flow can be recorded in which data is read from a database, converted inside a Java program, written to the database, and read by another Java program. In addition, according to the present embodiment, it is not necessary to add metadata such as a tag to the data itself, which can be easily realized.

(Second Embodiment)
In the first embodiment, the method for recording the data flow in the system configured by the Java program 1 and the RDB 2 has been described. In this embodiment, a method for recording a data flow of a system constituted by the Java program 1 and the file service 4 will be described. Even if the second component is the file service 4, the data flow can be traced. Note that a description overlapping that of the first embodiment is omitted.

  FIG. 9 is a block diagram illustrating an example of a schematic configuration of the entire computer system according to the second embodiment. The computer system according to the second embodiment is different from the first embodiment in that the access destination of the Java program 1 is the file service 4. Accordingly, the Java program 1 includes a Random Access File object 108 instead of the JDBC driver 106 and an access destination file name temporary storage unit 109 instead of the temporary binding storage unit 105.

  The file service 4 includes an access destination file 401, a file service interface (I / F) 402, and a file pointer management unit 403. The file service 4 sends and receives files and data in the files to the Java program 1.

  The access destination file 401 has data therein, and the Java program 1 reads and writes the data. The file service I / F 402 is an interface for exchanging files and data with the Java program 1.

  The file pointer management unit 403 manages file pointers. The file pointer is information indicating the location (position) of data reading / writing currently performed in the access destination file 401. The file pointer is represented by the number of bytes from the beginning of the file.

  On the other hand, the Random Access File object 108 of the Java program 1 is a function included in the Java standard library. The Java program 1 uses the RandomAccessFile object 108 to exchange data with the file system I / F. The Logger object 104 connects the Logger hook 107 to the Random Access File object 108 and monitors the data flow through the Random Access File object 108.

  The access destination file name temporary storage unit 109 temporarily stores the file name to which the Random Access File object 108 accesses.

In the computer system according to the second embodiment, the following three types of data flows are assumed and monitored.
(1) Data flow in Java program 1 (2) Data flow in which Java program 1 reads data from a file (3) Data flow in which data is written from Java program 1 to a file (1) The data flow in Java program 1 is Since it is the same as that of 1st Embodiment, it abbreviate | omits.

In order to record the data flow between the Java program 1 and the file service 4, the Java program 1 generates a Random Access File object 108 to which the Logger hook 107 is connected through the Logger object 104. The generation of the RandomAccessFile object 108 is realized by calling an openFile method or the like on the Logger object 104, for example. The following is an example of the code for calling the openFile method.
RandomAccessFile file = logger.openFile (“/ home / user / sample.dat”, “rw”);

  The openFile method generates a RandomAccessFile object 108 using a given argument. In the above code, “sample.dat” and “rw” are arguments. Then, the openFile method connects the Logger hook 107 to the RandomAccessFile object 108. At that time, the Logger object 104 stores information such as the file name of the access destination in the access destination file name temporary storage unit 109.

  FIG. 10 is a diagram illustrating an example of information stored in the access destination file name temporary storage unit 109. The Logger object 104 is a logger. The first argument of the openFile method and the object identifier of the RandomAccessFile object 108 are stored in the access destination file name temporary storage unit 109. In the above code, “/home/user/sample.dat” is stored as the name of the access destination file 401. Thereby, the Random Access File object 108 is associated with the name of the file accessed by the Random Access File object 108. The information stored in the access destination file name temporary storage unit 109 may be deleted when the Random Access File object 108 is no longer used.

  In data reading using the RandomAccessFile object 108, data is read into the Java object 102 by calling methods such as read and readLine on the RandomAccessFile object 108.

(2) Data flow in which Java program 1 reads data from a file FIG. 11 is a flowchart of data flow log generation processing when data is read from a file. This flow is started when a data reading method for the RandomAccessFile object 108 is called by the Logger hook 107.

  The Logger hook 107 acquires a file pointer from the file pointer management unit 403 before reading the data in order to obtain the location of the file from which the data has been read (S601). Thereafter, when data is actually read from the file (S602), the Logger hook 107 acquires the file pointer from the file pointer management unit 403 again (S603). Thereby, the file pointer before and after reading the data is acquired.

  The Logger hook 107 can acquire the file pointer from the file pointer management unit 403 by calling the getFilePointer method of the RandomAccessFile object 108.

  The Logger hook 107 transfers the acquired Random Access File object 108, the data reading destination Java object 102, the file pointer before reading, and the file pointer after reading to the Logger object 104 (S604). The Logger object 104 that has received the information from the Logger hook 107 searches the access destination file name temporary storage unit 109 using the RandomAccessFile object 108 and acquires the file name (S605). Then, the Logger object 104 acquires the object identifier of the Java object 102 that is the data reading destination from the System class 103 (S606).

  The Logger object 104 generates a data flow log from the acquired access destination file 401 name, the file pointer before reading, the file pointer after reading, and the object identifier of the reading Java object 102 (S607). The Logger object 104 transmits the generated data flow log to the log receiving unit 3 (S608). The above is data flow log generation processing when data is read from a file.

The following is an example of a data flow log when reading data from a file.
{
“Src”: {
“Type”: “file”,
“Path”: “/ home / user / sample.dat”,
“From”: “10”,
“To”: “32”
},
“Dst”: {
“Type”: “java_internal”,
“Object_hash”: “337422011”
},
“Time”: “1439172160332”
}
The src field represents data in the access destination file 401, and the dst field represents the Java object 102 to be read. The value “file” in the type field of the src field indicates that the src field represents data in the file. The path field of the src field is the name of the access destination file 401. The from field of the src field indicates a file pointer before reading. The to field of the src field indicates the file pointer after reading.

  As described above, the Logger hook 107 acquires the file pointer indicating the start point of the data flow from the file pointer management unit 403. Further, the Logger object 104 acquires an object identifier indicating the end point of the data flow from the System class 103. The Logger object 104 generates a data flow log in which information indicating the start point of the data flow and information indicating the end point are recorded. Thereby, the data flow in which the Java program 1 reads file data from the file service 4 can be monitored based on the generated data flow log.

(3) Data Flow for Writing Data from Java Program 1 to File FIG. 12 is a flowchart of data flow log generation processing when data is written to a file.

  The Logger hook 107 acquires a file pointer from the file pointer management unit 403 before writing the data in order to obtain the location of the file in which the data is written (S701). Thereafter, when data is actually written to the file (S702), the Logger hook 107 acquires the file pointer from the file pointer management unit 403 again (S703). Thereby, the file pointer before and after the data writing is acquired.

  In the data writing using the RandomAccessFile object, data is written to the file by calling a method such as write or writeUTF on the RandomAccessFile object.

  The Logger hook 107 transfers the obtained RandomAccessFile object 108, the Java object 102 from which data is written, the file pointer before writing, and the file pointer after writing to the Logger object 104 (S704). The Logger object 104 that has received the information from the Logger hook 107 searches the access destination file name temporary storage unit 109 using the RandomAccessFile object 108 and acquires the name of the access destination file 401 (S705). Then, the Logger object 104 acquires the object identifier of the Java object 102 that is the data writing source from the System class 103 (S706).

  The Logger object 104 generates a data flow log from the acquired access destination file 401 name, the file pointer before writing, the file pointer after writing, and the object identifier of the writing Java object 102 (S707). The Logger object 104 transmits the generated data flow log to the log receiving unit 3 (S708). The above is data flow log generation processing when data is written to a file.

The following is an example of a data flow log when writing data to a file.
{
“Src”: {
“Type”: “java_internal”,
“Object_hash”: “337422011”
},
“Dst”: {
“Type”: “file”,
“Path”: “/ home / user / sample.dat”,
“From”: “3”,
“To”: “35”
},
“Time”: “1439172160332”
}
The src field represents the writing source Java object 102, and the dst field represents the data in the access destination file 401. Others are the same as the data flow log when data is read from a file.

  As shown in the above data flow log, the from field and to field of the dst field are indicated by the number of bytes. Thereby, even when a plurality of Java objects are written in one file, the location of data in the file can be distinguished.

  As described above, the Logger hook 107 acquires the file pointer indicating the end point of the data flow from the file pointer management unit 403. Also, the Logger object 104 acquires an object identifier indicating the start point of the data flow from the System class 103. The Logger object 104 generates a data flow log in which information indicating the start point of the data flow and information indicating the end point are recorded. Accordingly, it is possible to monitor the data flow in which the Java program 1 writes the file data to the file service 4 based on the generated data flow log.

  As described above, according to the present embodiment, the data flow between the Java program 1 and the file service 4 can be recorded. Further, since the location of data in the file is recorded by a file pointer indicated by the number of bytes, the location of data in the file can be discriminated.

(Third embodiment)
In the first embodiment, the method for recording the data flow in the Java program 1 has been described. In the present embodiment, a method for recording a data flow log in the case where data is directly exchanged between two Java programs instead of the Java program 1 will be described. And even if the second component is a process, the data flow can be traced. Note that a description overlapping that of the first embodiment is omitted.

  FIG. 13 is a block diagram illustrating an example of a schematic configuration of the entire computer system according to the third embodiment. Here, the two Java programs are distinguished by being referred to as a first Java program 1A and a second Java program 1B. There may be another Java program for the first Java program 1A and the second Java program 1B. The first Java program 1A and the second Java program 1B have the same configuration. Compared with the Java program 1 of the first embodiment, the first Java program 1A and the second Java program 1B are not the bind temporary storage unit 105, the JDBC driver 106, and the Logger hook 107, but the object transmission unit 110, the object reception unit 111, And the process ID management unit 112.

  The object transmission unit 110 transmits a Java object in the Java program 1 to another Java program 1. The object receiving unit 111 receives Java object data transmitted from another Java program 1. Although FIG. 13 shows the case where the first Java program 1A performs transmission (transmission side) and the second Java program 1B performs reception (reception side), the reverse may be possible.

  The process ID management unit 112 holds a process ID assigned to the Java program 1. The process ID management unit 112 is a Java. lang. management. A Runtime MXBean object or the like can be used.

  In the third embodiment, the Logger object 104 acquires the process IDs of the Java objects 101 and 102 from the process ID management unit 112. In the third embodiment, a plurality of Java programs 1 operate, and each of the plurality of Java programs 1 generates a data flow log inside the Java program 1. Therefore, in order to identify the Java program 1 that generated the data flow log, it is necessary to include the identifier of the Java program 1 that generated the data flow log. Therefore, the third embodiment includes the process ID of the Java program 1 in the data flow log.

In the computer system according to the third embodiment, the following two types of data flows are assumed and monitored.
(1) Data flow inside Java program 1 (2) Data flow between Java programs 1 (between first Java program 1A and second Java program 1B)

(1) Data Flow Inside Java Program 1 FIG. 14 is a flowchart of data flow log generation processing inside the Java program according to the third embodiment. As in the first embodiment, this flow starts when the Java objects 101 and 102 that are the start and end points of the data flow are passed to the Logger object 104 by calling the flow method.

  At the start of the flow, the Logger object 104 acquires the process ID of the Java program 1 from the process ID management unit 112 (S801). The subsequent flow from S101 to S104 is the same as the data flow log generation process inside the Java program 1 according to the first embodiment. In S103, the Logger object 104 uses the process ID acquired in S801 as the data flow log. Included. Therefore, the generated data flow log is different from the first and second embodiments.

The following is an example of the data flow log inside the Java program 1 of the third embodiment.
{
“Src”: {
“Type”: “java_internal”,
“Process_id”: “3233”,
“Object_hash”: “1487365346”
},
“Dst”: {
“Type”: “java_internal”,
“Process_id”: “3233”,
“Object_hash”: “1786281489”
},
“Time”: “1439172160987”
}
In the present embodiment, a process_id field is included in each of the src field and the dst field. The process_id field indicates the process ID of the Java program 1. Since it is a data flow log inside the Java program 1, the value of the process_id field of the src field and the dst field ("3233" in the above example) is the same. As a result, the Java program 1 that is the generation source can be identified. Others are the same as in the first embodiment.

  As described above, the Logger object 104 acquires the object identifier of the Java object 101 from the System class 103 and the process ID of the Java program 1 from the process ID management unit 112 as information indicating the start point of the data flow. Further, the Logger object 104 acquires the object identifier of the Java object 102 from the system class 103 and the process ID of the Java program 1 from the process ID management unit 112 as information indicating the end point of the data flow. The Logger object 104 generates a data flow log in which information indicating the start point and the end point is recorded. Thereby, the data flow inside the Java program of each Java program can be monitored based on the generated data flow log.

(2) Data Flow Between Java Programs 1 Next, a method for recording data flow between Java programs 1 will be described. FIG. 15 is a flowchart of data flow log generation processing between Java programs according to the third embodiment.

  The Logger object 104A on the transmission side (first Java program 1A) acquires the object identifier from the System class 103A (S901). Further, the Logger object 104A on the transmission side acquires the process ID from the process ID management unit 112A (S902). Then, the transmission-side object transmission unit 110A transmits the acquired object identifier and process ID, and the serialized Java object 102A to the reception side (second Java program 1B) (S903).

  When the object transmission unit 110A on the transmission side transmits the Java object 102A, the Java object must be converted into a format that can be transmitted to the communication path. This conversion is called serialization. The object receiving unit 111B on the receiving side receives the transmitted data, and generates the Java object 101B from the serialized data (S904). Generating a Java object from this serialized data is called deserialization. For serialization and deserialization, the Serializable interface of the Java program 1 may be used.

  Note that the communication between the object transmission unit 110A on the transmission side and the object reception unit 111B on the reception side is communication using a pipe, UNIX domain socket, TCP / IP, or some message bus in the UNIX (registered trademark) system. It can be realized using various means.

  The object identifier of the Java object 101B from which the receiving-side Logger object 104B is deserialized is acquired from the System class 103B (S905). Further, the Logger object 104B on the receiving side acquires the process ID from the process ID management unit 112B (S906). Then, the Logger object 104B on the reception side generates a data flow log using the object identifier and process ID received from the transmission side, and the object identifier and process ID acquired on the reception side (S907). The Logger object 104B on the receiving side transmits the generated data flow log to the log receiving unit 3 (S908). The above is the flow of data flow log generation processing between Java programs 1 according to the third embodiment.

The following is an example of a data flow log between Java programs 1 of the third embodiment.
{
“Src”: {
“Type”: “java_internal”,
“Process_id”: “3233”,
“Object_hash”: “1786281489”
},
“Dst”: {
“Type”: “java_internal”,
“Process_id”: “1832”,
“Object_hash”: “558392438”
},
“Time”: “1439172173920”
}
In the data flow log, the process_id field of the src field represents the process ID of the sending Java program 1A, and the process_id field of the dst field represents the process ID of the receiving Java program 1B. Thereby, the Java program 1A on the transmission side and the Java program 1B on the reception side can be distinguished.

  As described above, the object receiving unit 111B on the receiving side acquires the object identifier of the Java object 102A and the process ID of the Java program 1A as information indicating the starting point of the data flow. Further, the Logger object 104 on the receiving side acquires the object identifier of the Java object 101B deserialized from the System class 103B as information indicating the end point of the data flow, and the process ID of the Java program 1B from the process ID management unit 112B. . The Logger object 104B generates a data flow log in which information indicating the start point and the end point is recorded. Thereby, the data flow between the Java programs 1 can be monitored based on the generated data flow log.

  As described above, according to the present embodiment, when a Java object is serialized and transmitted, both the object identifier in the transmission-side Java program 1 and the process ID of the transmission-side Java program 1 are transmitted. By using this information, the receiving Java program 1 generates a data flow log, whereby the data flow when the Java programs 1 directly exchange data can be recorded in detail. In addition, the Java program 1 that is the source of the data flow log in the Java program 1 can be identified even when a plurality of Java programs 1 are operating.

  The data flow log generation device in the embodiment described above can be realized by, for example, using a general-purpose computer device as basic hardware and causing a processor mounted on the computer device to execute the program.

  FIG. 16 is a block diagram illustrating an example of a hardware configuration according to an embodiment of the present invention. The data flow log generation device includes a processor 501, a main storage device 502, an auxiliary storage device 503, a network interface 504, a device interface 505, an input device 506, and an output device 507, which are connected via a bus 508. It can be realized as a device.

  The processor 501 reads out the Java program 1 from the auxiliary storage device 503, expands it in the main storage device 502, and executes it, thereby realizing each function in the Java program 1.

  The data flow log generation device according to the present embodiment may be realized by previously installing a program executed by the data flow log generation device in a computer device, or may store the program in a storage medium such as a CD-ROM. Alternatively, it may be realized by being distributed through a network and appropriately installed in a computer device.

  The network interface 504 is an interface for connecting to a communication network. When connected to the RDB 2, the log receiving unit 3, the file service 4, and the like by communication, this network interface 504 may be used. Although only one network interface is shown here, a plurality of network interfaces may be installed.

  The device interface 505 is an interface connected to a device such as the external storage medium 6. The external storage medium 6 may be an arbitrary recording medium such as an HDD, a CD-R, a CD-RW, a DVD-RAM, a DVD-R, and a SAN (Storage area network). The RDB 2 may be connected by a device interface 505.

  The main storage device 502 is a memory device that temporarily stores instructions executed by the processor 501, various data, and the like, and may be a volatile memory such as a DRAM or a non-volatile memory such as an MRAM. The temporary binding storage unit 105, the access destination file name temporary storage unit 109, the process ID management unit, and the like can be realized by the main storage device 502. The auxiliary storage device 503 is a storage device that permanently stores programs, data, and the like, such as an HDD or an SSD.

  Although one embodiment of the present invention has been described above, these embodiment are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalents thereof.

1 process (Java program)
1A 1st Java program 1B 2nd Java program 101, 101A, 101B, 102, 102A, 102B Java object 103, 103A, 103B System class 104, 104A, 104B Logger object 105 Bind temporary storage unit 106 JDBC driver 107 Logger hook 108 RandomAccess object 109 Access destination file name temporary storage unit 110, 110A, 110B Object transmission unit 111, 111A, 111B Object reception unit 112, 112A, 112B Process ID management unit 2 Relational database (RDB)
201 Database interface (DB_I / F)
202 Access destination table 203 System catalog 204 Temporary log table 3 Log receiving unit 4 File service 401 Access destination file 402 File service interface (file service I / F)
403 File pointer manager 501 Processor 502 Main storage 503 Auxiliary storage 504 Device interface 505 Network interface 506 Bus 6 External storage medium

Claims (17)

When a data flow occurs between a first object in a first component that is a process and a second component, first position information indicating a start point or an end point of the data flow in the first component is acquired. A first acquisition unit;
A second acquisition unit for acquiring second position information indicating a start point or an end point of the data flow in the second component;
A log generation unit that generates a data flow log in which the first position information and the second position information are recorded;
A data flow log generation device comprising: The data flow log generation device according to claim 1, wherein the first acquisition unit, the second acquisition unit, and the log generation unit operate in the process of the first component. A first identifier management unit for managing an identifier of an object in the first component;
The data flow log generation device according to claim 1 or 2, wherein the first acquisition unit acquires the identifier of the first object as a part or all of the first position information from the first identifier management unit. The second component is a relational database;
The data flow includes reading data from the relational database into the first object,
The data flow log according to any one of claims 1 to 3, wherein the second acquisition unit acquires, as the second position information, a position where data related to the data reading is stored from the relational database. Generator. The second component is a relational database;
The data flow includes writing data from the first object to the relational database;
A storage unit for storing data relating to the data writing;
The second acquisition unit acquires, as the second position information, a position where data related to the data writing is stored from the relational database based on the data stored in the storage unit. The data flow log generation device according to any one of the above. The data flow according to claim 4 or 5, wherein the second position information includes any one of a database name, a catalog name, a schema name, a table name, a column name, and a table primary key of the relational database. Log generator. The data flow log generation device according to any one of claims 4 to 6, wherein the second acquisition unit issues an instruction relating to validation or invalidation of an automatic commit setting to the relational database. The second component is a file service;
The data flow includes reading data from the file service to the first object or writing data from the first object to the file service,
The second acquisition unit receives, from the file service, at least one of a file path related to the data reading or data writing and a file pointer indicating a position of data related to the data reading or data writing in the file. The data flow log generation device according to any one of claims 1 to 3, which is acquired as a part or all of the second position information. The second component is a process;
The data flow includes a data flow from the second object to the first object in the second component,
The second acquisition unit acquires an identifier of the second object and a process ID of the second component as part or all of the second position information,
4. The first acquisition unit acquires the identifier of the first object and the process ID of the first component as part or all of the first position information. 5. Data flow log generator. The second acquisition unit acquires an identifier of the second object serialized by the second component,
The data flow log generation device according to claim 9, wherein the first acquisition unit acquires the identifier of the second object deserialized by the first component as the identifier of the first object. When a data flow occurs between the first object and a different second object in the first component,
The first acquisition unit acquires an identifier of the first object as part or all of the first position information, and acquires an identifier of the second object as part or all of the second position information. The data flow log generation device according to any one of 1 to 10. The data flow log generation device according to claim 11, wherein the first acquisition unit further acquires a process ID of the first component as a part of the first position information. A second position information storage unit for storing the second position information;
A transmission unit that transmits the second position information to the data flow log generation device according to any one of claims 4 to 7,
Relational database with The relational database is
A temporary data storage unit for temporarily storing data write destination position information;
The relational database according to claim 13, further comprising: a trigger for copying write destination position information of the written data to the temporary data storage unit when data is written from the first component. When a data flow occurs between a first object in a first component that is a process and a second component, first position information indicating a start point or an end point of the data flow in the first component is acquired. A first acquisition step;
A second acquisition step of acquiring second position information indicating a start point or an end point of the data flow in the second component;
A log generation step of generating a data flow log in which the first position information and the second position information are recorded;
A data flow log generation method in which a computer executes. When a data flow occurs between a first object in a first component that is a process and a second component, first position information indicating a start point or an end point of the data flow in the first component is acquired. A first acquisition step;
A second acquisition step of acquiring second position information indicating a start point or an end point of the data flow in the second component;
A log generation step of generating a data flow log in which the first position information and the second position information are recorded;
A program that causes a computer to execute. A monitoring system comprising: a first component that is a process; a second component; and a log receiving unit that receives a log relating to a data flow performed between the first component and the second component,
The second component is:
A sending unit for sending second position information indicating a start point or an end point of the data flow in the second component;
The first component is:
A first acquisition unit for acquiring first position information indicating a start point or an end point of the data flow in the first component;
A second acquisition unit for acquiring the second position information from the sending unit;
A log generation unit that generates a data flow log in which the first position information and the second position information are recorded;
A monitoring system comprising: