Multiagent-Based Data Presentation Mechanism for Multifaceted Analysis in Network Management Tasks

Although network management tasks are highly automated using big data and artificial intelligence technologies, when an unforeseen cybersecurity problem or fault scenario occurs, administrators sometimes directly analyze system data to make a heuristic decision. However, a wide variety of information is required to address complex cybersecurity risks, whereas current systems are focused on narrowing the candidates of information. In this study, we propose a multiagent-based data presentation mechanism (MADPM) that consists of agents operating data-processing tools that store and analyze network data. Agents in MADPM interact with other agents to form data-processing sequences. In this process, we design not only the composition of the sequence according to requirements, but also a mechanism to expand it to enable multifaceted analysis that supports heuristic reasoning. We tested five case studies in the prototype system implemented in an experimental network. The results indicated that the multifaceted presentation of data can support administrators more than the selected single-faceted optimal presentation. The final outcome of our proposed approach is the provision of a multifaceted and cross-system data presentation for heuristic inference in network management tasks.


Introduction
As information and communications technology (ICT) has become indispensable in our lives, addressing increasingly complex cybersecurity risks has become a major issue. The sophisticated automation of network equipment has allowed non-experts to become administrators. However, when unexpected events occur, data must be analyzed and heuristic inferences must be made, which is a heavy burden for non-experts and a potential risk to network infrastructure. Therefore, there is a need for more advanced automation and support technology for network administrators. Autonomic network management [1][2][3] was proposed for the unmanned operation of network infrastructure. The idea is based on autonomic computing [4,5], which defines the components of network systems as autonomously acting and interacting as in biological organization. In recent years, AI researchers have attempted to develop the concept of the autonomic functions of network management by introducing machine learning [6][7][8]. However, because advanced machine learning has complex internal structures and representations, once unexpected behavior occurs, human administrators cannot know what is occurring in systems [9]. "Explainable AI" is anticipated to be able to provide a solution to the problem [10][11][12]; however, relevant technologies have not been established yet. Thus, complete automation using AI technology is not available now. study, we propose a multiagent-based data-presentation mechanism (MADPM) to integrate heterogeneous DPTs and demonstrate beneficial processing results.
The main contributions of this study are as follows: • We connect data analytics in network management and the idea of serendipity, which is the notion of an innovative encounter, to solve the complexity of recent cybersecurity problems. • We propose a multiagent-based mechanism to provide a multifaceted data presentation (MADPM). • We define the organization process considering accuracy and expansion for user demand. Additionally, we include automated composition of the data presentation process in the organization process. • We present a design process to encapsulate services and systems as agents (dataprocessing agents (DPAs)), including data related to network management. • We conducted several case studies and demonstrated that the multifaceted information provided by the prototype system enabled us to make inferences from new perspectives. • Finally, we discuss the effectiveness and feasibility of the data and information recommendation, including uncertainty represented by the probabilistic process.
This paper is an extended version of the conference paper [44] and provides details of the algorithms and case studies.

Multiagent-Based Data Presentation Mechanism (MADPM)
In this study, we use presentation because the mechanism composes the data-processing flow and recommends the result related to user demand. Figure 1 shows a schematic diagram of the MADPM. First, we create DPAs that include DPTs with the knowledge and functions for handling DPTs. Self-organization means that the interaction between agents establishes the data-processing flow required for providing information according to the request input by users. The design scheme follows the distributed agent systembased hybrid architecture (DASH) framework [45]. The self-organization process proceeds in the agent repository, which is a unique feature of the framework, and the generated organization is activated in the workplace. Finally, data-processing starts.
As shown in Figure 1, we use a user interface (UI) agent (UIA) to serve and manage a UI, which receives the request and returns the results from the active DPAs in the workplace. Thus, the notions of accuracy and expansion are expressed in the organization processes of request-matching and request expansion, respectively.

Request Matching
As shown in Figure 1, when a user inputs a request for data-processing into the UI, the UIA sends a broadcast message of the request to the agent repository. The request is expressed as a triplet: where target i denotes the name of the target device, data i denotes the name of the data (fields), and processing i denotes the name of the requested type of processing. Using appropriate natural language processing methods, the triple is extracted from request r described by a natural language expression. For example, when a request to know the current central processing unit (CPU) usage, "Show CPU usage of the mail server", occurs, the entities of the triple r i are extracted, such as target i = "Mail server", data i = "CPU usage", and processing i = "provide". The entities are used to evoke the functions of DPAs.
In the DASH framework, the program that defines the decision-making of the agent's behavior is called "agent knowledge". In this paper, the response to the received request is determined by agent knowledge. We design two possible types of agent knowledge: agent knowledge about data DK and agent knowledge about the processing procedure PK. DK describes what data are stored or measured in the DPA: where source is the name of the data source, variable is the name of the measured variable observed on the source device, and description is the text that explains the data. By contrast, PK indicates agent knowledge about the processing method for the data: where processing is the name of the possible processing method, keyword is the keyword that triggers the execution of the data processing function, which corresponds to the activation of the DPA, and probability is the probability that the DPA is activated.

Information request
Browse outputs

Agent repository
Multiagent-based data presentation mechanism Agent workplace Self-organized data processing

Proposal
Sending processing results A DPA checks the correspondence between the incoming request r i and its own knowledge dk i and pk i , and decides to start working. We introduce a probabilistic decision model to express flexibility in the organizing process. Note that the notion of decision flexibility is not new and is the basis of fuzzyness [46,47]. Our probabilistic decision model is defined using the activation probability ap i defined as where n rd i is the number of nouns in data i of request r i , and n rkd i is the number of nouns included in description i of dk i and included in data i of r i . The DPA is always activated if the target device target i matches the data source source i . The term n rd i − m rkd i /n rd i represents the matching rate between a request and the knowledge of a DPA. α ∈ [0.0, 1.0] is an activation coefficient that can be set directly in the knowledge description. If α = 0, then ap i = 1 indicates that the agent is always activated for any request. For example, when data i = "CPU usage" and description i = "CPU utilization rate in user space.", "CPU usage" can be divided into the nouns "CPU" and "usage," then n rd i = 2 and "CPU" is also included in description i ; therefore, n rkd i = 1. Finally, if α = 0.5 and ap i = 0.75, then the agent will be activated by 75%. Because the prototypical implementation in this study is for Japanese, we use a morphological analysis tool to extract the words from a request. The coefficient may be replaced with an algorithm to change the value temporally. This remains a topic for future work.
If the DPA does not have dk i but has pk i , this means that the DPA does not store data but can be part of a data-processing flow; then the DPA only responds to requests r i for processing. For example, if processing in pk i is matched to that in r i , the DPA is activated by the probability parameter in pk i . At least one candidate is determined for the processing request, and then the process is completed.

Request Expansion
Mining hidden potential information is the core idea of serendipity [41]. We introduce request expansion to apply the idea in the self-organization process. The MADPM permits DPAs to generate a modified request in chains. Figure 2 shows an example of request expansion. Now, the initial request r 0 is received as r 0 =< "Mail server", "CPU usage", "Fourier transform" >, (5) and then the two agents are activated. A possible example is that an abstract word, "Mail server", can be concretized to the hostname "host A " on which mail server applications are installed. The DPA of the wiki (wiki agent), which has the management information shared by administrators, generates a secondary request: and sends the agent repository. Another possible example is that the activated DPA requires subsequent processes, such as plotting. As shown in Figure 2, a DPA of a discrete Fourier transformation (DFT) generates a secondary request r 2 as r 2 =< "Mail server", "CPU usage", "Bar plot" > .
Notably, not only the hidden demands of the information, but also the data processing flows, can be composed using the expansion type in Equation (7).
We have defined the matching and expansion processes in this section; the combination provides helpful information for heuristic problem solving in network management. Note that the mechanism should be designed considering the possibility of convergence.

Data Processing Agent (DPA)
In this section, we define the structure of a DPA. Figure 3 indicates a schematic diagram of a DPA. DPAs are the agents that use DPTs, for example, ELS [27] and ZBX [32]. The ADIPS/DASH [45] framework divides an agent into the two design components of brain and body parts. The brain component describes agent knowledge and actions used to interact with the other agents. For example, when receiving a message from other agents or measuring environmental change, an agent decides what action should be taken for the recognized scenario using installed knowledge. According to the framework, the rule-based inference model describes the knowledge of an ADIPS/DASH agent. The body component is called the "base process", which is a process that the wrapper for the DPT program uses to provide the actions triggered in the brain component. We describe the details of each component in the following sections. ! : "Mail server" ! : "CPU usage" ! : "Bar plot" " : ℎ # " : "CPU usage" " : "Fourier transform" $ : "Mail server" $ : "CPU usage" $ : "Fourier transform"   Figure 4 shows the list of entities used to construct agent knowledge for data processing. Agent knowledge is written in object-attribute-value format and divided into four types: "data", "process", "next" and "related_word". "data" is agent knowledge used to obtain data from the particular DPTs that store logs or performance data. "process" stores the possible functions of processing and calculating in the DPT. "next" contains the names or keywords of the processing method that the DPA recommends to perform the next process. For example, if the DPA acquires the time series of network traffic data and wants to plot it on a line graph, we can write the value of attribute "process" as "Line plot". If the DPA has additional information to provide to the user, it can be defined in the knowledge of "relatedword". Using this knowledge, for instance, if "Web server" is related to "host A ", which is a particular hostname, we can write the values of the attributes "wordA" and "wordB".

Base Process
The DPA can control the existing or original DPTs using encapsulation. The encapsulated program is called the base process in the ADIPS/DASH framework. Figure 5 shows the structure of a base process. Encapsulation consists of four modules: the module that the agent calls directly, the data-receiving module, the query module, and the data-sending module. The "data-sending module" directly exchanges data with other agents by establishing the data stream. Note that the agent can configure and control the data stream at the level of agent interaction, which refers to the message exchange using knowledge defined in the previous section. Then, the received data are transferred to the "data-processing module" to process and execute the query in the DPT. The results of DPT-processing or the query are sent to other agents via the data-sending module. Figure 6 depicts the data exchanged via the data-sending module. Data are delivered as components of variables with metadata in JSON format. The metadata include "title", "x-axis", "y-axis", "unit", "process" and "data_list". In this study, because the prototypical implementation defines terminal processing as visualization, the information required to draw a graph is delivered as part of the metadata. "process" defines the type of graph. If "process" is not specified, the graph type is inferred from the description of "unit". A code example of the base process is included in the Supplementary Materials. Figure 7 is a diagram of the lifecycle of a DPA. The DPA in the agent repository waits for request messages from other agents. When it receives a message, the DPA checks whether the request is acceptable by verifying it with the knowledge. If the request is not acceptable, the message is dropped and the state returns to the waiting state. If the requested process can run, the DPA is instantiated in the workplace. The DPAs in the repository support the processing flow. Because the process is recursive, a processing flow that answers the request is organized. Then, the DPA establishes a direct connection between the base processes of the before and after processes of the data processing sequence. After the processing flow is organized, the state becomes "processing" and data processing is run. When the agent has completed the processing task, the state of the agent changes to "title" : graph title text "x-axis" :

Lifecycle
label for x axis "y-axis" : label for y axis "unit" : unit name of y axis "process" : name for processing "data_list" : list of 2 dimensional data series  . Action flow diagram for the DPA. We developed the common parts (templates) of the steps in orange. When encapsulating another DPT, the blue part must be implemented.

Prototype Implementation
In this section, we implement a prototypical system to demonstrate the MADPM practically and evaluate its advantages. First, we consider a broad set of monitoring tools for a small-or medium-scale network as follows: • Log collection tool collects logs on the servers, such as mail servers, web servers, and firewalls, and displays statistics and time series. • Performance management tool collects performance data, such as CPU usage, memory usage, and the amount of traffic on network interfaces from the servers and networking devices, and provides statistics and visualization. • Service management tool provides the function of service management, which includes monitoring, testing, and providing alerts on the service status. • Knowledge tool stores knowledge for management tasks and provides functions to share among employees. Figure 8 shows a diagram of the experimental environment. We conducted experiments on our laboratory network with the experimental servers, which included the five DPTs listed in Table 1. We executed all the implemented agents on IDEA [45], which is a development and runtime tool for ADIPS/DASH agents. The experimental server included a web server and a mail server process to test the case study described later in this paper. We conducted experiments on a test PC connected to the same subnet. The ELS and IDB tools were used on different ports on the same server for convenience. Table 1. List of data collection tools deployed in the experimental network.

Name Description
InfluxDB [28] a performance management tool Elasticsearch [27] a log collection tool Zabbix [32] a service management tool Fess [48] and Wiki a knowledge tool (Fess provides the search engine for Wiki) Data visualization an original tool implemented by Python  Figure 8. Experimental environment for the prototype system. We deployed four physical servers and five DPTs on the servers. The virtual fault scenarios occurred on the "experimental server", and the experimenter (administrator) demonstrated the case studies using a "User PC" via the "UI server". Figure 9 shows a screenshot of the runtime environment window of IDEA when the system started (initial state). According to the ADIPS/DASH framework regulations, the runtime environment included the agent workplaces and repository. The agent repository stored agents that were inactive but capable of exchanging messages. We implemented eight DPAs that appeared in the agent repository. We designed each agent according to the MADPM. We provide a brief description of the agents below.

Correlation Coefficient (CRR) Agent
The CRR agent provides the Pearson correlation coefficient for the received time series using the preliminary stored anomaly time series. Simultaneously, the CRR agent sends the anomalous time series to other agents, such as the data visualization agent. When CRR is in the repository, if the received request r i includes "Correlation analysis", then CRR is activated by 100%, if r i includes "Analysis", then CRR is activated by 80%, otherwise, CRR is activated by 10%. To compare the present time series with the visualized anomaly time series, CRR rewrites process i -entity in r i as "Line plot" and sends it to the repository.

Discrete Fourier Transform (DFT) Agent
DFT is an original agent that provides the power spectrum calculated from the received time series data. The agent is activated by 1000% if the name of process in request r i is "Fourier transform", 80% if process is "Analysis", and 10% otherwise. DFT replaces process with "Bar plot" to visualize the power spectrum.
Descending Sort (DSS) Agent DSS is also an original agent that sorts the received time series in order of the average value. This agent aims to present important data first. DSS is activated by 100% if process is "Descending sort", 80% if process is "Analysis", and 10% otherwise. DSS also rewrites process as "Plot." (2) (3) Agent workplace poses the agents organized in the agent repository.

Elasticsearch (ELS) Agent
ELS is an agent that encapsulates ELS [27] software for collecting logs from servers. Through the functions on ELS that use query operations, the agent provides a function to retrieve log data, retrieve the count per minute, and construct time series. We define three types of log data on the experiment server with the hostname "tsuga" as the knowledge of the agent part of ELS. Then, ELS is activated by 100% if the target device name target in r i is "host A ". The knowledge of data can be improved to extend the function to retrieve monitoring hostnames from the database. As an additional action, if process is "provide", ELS rewrites process as "Bar plot".

FESS (FES) Agent
FES encapsulates the search engine FES [48] for local sites. FES can retrieve multiple sites. The FES agent provides search results for the search keyword from local wiki sites or other services in the local network. The agent can respond by 100% to every request. If target is "Web server" or "Core switch," the agent rewrites target as "host A " or the IP address of the core switch, respectively. We require that the action rule is constructed from knowledge in the wiki and aim to extract it automatically in the future.

InfluxDB (IDB) Agent
IDB encapsulates the OSS database engine IDB [28]. The agent provides time series by retrieving and calculating the CPU usage, memory usage, and amount of traffic according to the received request r i . In this study, we implement five entities and ten entities for the experiment server and core switch, respectively. When the agent returns the data, we set the tic of the time series to one minute. IDB is activated by 100% if the target device target is "host A " or the IP address of the core switch. If process in r i is "Provide", then the agent rewrites it as "Line plot".

Plotly (PLT) Agent
PLT is an agent that encapsulates the data visualization tool PLT [49]. When the agent receives time series data, it returns an HTML file with the corresponding graph. For example, PLT is activated by 100% if process is one of "Line plot", "Bar plot" or "Plot" and 10% otherwise.

Zabbix (ZBX) Agent
ZBX encapsulates the popular NMS, ZBX [32], which monitors and analyzes hosts and switches in the target networks. The agent provides the result from the retrieved health status of the target hosts. The ZBX agent is always activated for any request.

User Interface Agent (UIA)
We implemented the UIA using the Django framework in the Python language. Figure 10 shows screenshots of the UI. The UI contains the request form and the search button for launching analytics. After the MADPM process, the results are displayed below the input form.

(a) Initial page
Show the web server status.

Displayed results
Alerts on "Zabbix" Access log information on "tsuga"

System-log amounts [N]
System-log amounts on "tsuga" (ℎ ! ) System-log amounts on "tsuga" (ℎ ! ) Figure 10. Screenshot of the UI server: (a) An initial state. We can input the request for the system in natural language and data processing starts when the user pushes the search button. (b) Example result after processing is complete. The results are ordered and displayed below the input form.

Experiments with the Prototype System
We conducted experiments using the prototype system to evaluate the MADPM. In [44], we tested two cases and demonstrated the advantage of the MADPM. In this paper, we present five more case studies for the prototype system. In each case, all the phenomena are caused manually so that the actual operation of the laboratory is not affected.

Case 1: Trouble on the Web Server
Human error is a major reason for system failures. In this case, we demonstrate misconfiguration on the web server. The specific procedure for the experiment is as follows: 1.
access the UI server and input the test request as "Web server is not running". 3.
check the returned list of information. Figure 11 shows the output of the prototypical system. Figure 11a shows an alert on the ZBX server. The alert indicates "Apache is not running", with the hostname of the "monitored server" (displayed hostname is host A ). Figure 11b shows a time series of the system logs; below are the access logs and performance data. The shape of the graph in Figure 11b looks periodic, which implies that the system worked normally before it halted. Figure 11c shows corresponding information on the knowledge management system (wiki) of the experimental (lab.) network. From the output of (c), the administrator can know complementary information about failure detection.  Figure 11. Example result for the prototype system in Case 1. We assert three remarkable results: (a) status of host A , (b) amount of the system log on host A , and (c) wiki page including the word "host A ". Figure 12 shows a screenshot of the agent repository and workplaces when the output of Figure 11 was displayed. The actual self-organization process executed for the request is presented as follows: 1.
The UIA generates the request as r 1 =< "Web server", "NULL", "Analysis" > (8) and sends it to the agent repository.

2.
The FES and ZBX agents appear in the workplace according to the entity "Web server" in r 1 .

4.
The IDB and ELS agents respond to "host A " in r 2 and come into the workplace. The two agents resend r 2 to the agent repository.

5.
The two DSS agents corresponding to the IDB and ELS agents are instantiated with "Descending sort" in r 2 . 6.
From the relation in the knowledge of the DSS agent, a new request r 3 is created as r 3 =< "host A ", "NULL", "Plot" > (10) and sent to the agent repository. 7.
The PLT agent is instantiated with "Plot" in r 3 . 8.
The processing flow is automatically organized through the IDB, DSS, and PLT agents.
The result confirms the self-organized mechanism to verify that complex user demand works expectedly.

Agent repository
Agent workplace "Web server" "ℎ ! " "Descending sort" "Plotting" Agent repository Agent workplace Figure 12. Screenshot of the agent runtime environment (IDEA) when the result of Case 1 was displayed. In this case, six agents were activated from the agent repository and eight active agents organized the three data-processing streams.

Case 2: Amount of Traffic on the Network Switch
Case 2 presents the reaction to the request for providing performance information over time on network devices, for example, time series of the amount of traffic on Ethernet ports. Performance information over time is a popular monitoring entity for an enterprise-scale system and dedicated workers monitor this 24 hours a day, 7 days a week. However, because it is difficult to cover this type of work for small networks, such as laboratory networks, an administrator checks traffic on demand or when it is troubling. In this case, we test the following process:

1.
Input the phrase "Show the amount of traffic on the core switch in descending order".

2.
Check the output information. Figure 13 shows a screenshot of the output for the above test input. The top of the UI (Figure 13a) displays the upstream (WAN) traffic and that into Room A. There is also knowledge of a device (core switch) with the same IP address. From the input of "the core switch", the administrator can know not only the amount of traffic on the switch, but also management information to understand the consistency of the IP address, hostname, and role. Because administrators are often not fixed in small networks, inferences that are effective for problem-solving can be made by displaying not only visualized time-series data, but also shared knowledge about the target server within the laboratory. The flow for the organization and providing data for the input request is as follows: 1.
UIA generates the request triple as r 1 =< "Core switch", "Amount of traffic", "Descending sort" > (11) and sends r 1 to the agent repository as the broadcasting message, which is sent to all agents in the repository.

2.
The FES agent is activated by reacting to the keyword "Core switch" and instantiated in the workplace. 3.
4. The IDB and ELS agents respond to "<IPaddress B>" in r 2 and come into the workplace.

5.
The DSS agent is instantiated with "Descending sort" in r 2 . 6.
From the relation in the knowledge of the DSS agent, a new request r 3 is created as r 3 =< "IPaddress B ", "Amount of amount", "Plot" > (13) and sent to the agent repository. 7.
The PLT agent is instantiated with "Plot" in r 3 . 8.
The processing flow is automatically organized through the IDB, DSS and Plotting agents.

Case 3: Denial of Service (DoS) Attack
A DoS attack stops the service by sending huge transactions to the server or service network. In this scenario, the administrator should quickly investigate the network and take sufficient action to stop the damage. In this case, we use the Apache JMeter [50] to obtain the load on the target server. The test procedure consists of the following steps:

1.
Generate five transactions from a terminal to "host A " per second.

2.
After a while, generate 60 transactions from another terminal to "host A " per second.

3.
Confirm that the website on "host A " is down.

4.
Access the UI server and input "host A is down". 5.
Check the output of the UI server. Figure 14 shows a screenshot of the output displayed on the UI server. For visibility, we drew a red dashed line to indicate the attack time of Step 2 above. Figure 14a shows the number of system logs on host A , which rapidly increased at the attack time. The logs provided notification of the data collection failure from the data collector agent on host A . Additionally, the amount of access logs (Figure 14b) and CPU usage (Figure 14c) of host A increased simultaneously. From the three results in (a)-(c), the administrator could infer the existence of a DoS attack at that time. In this case, the prototypical system reacted to the test input "host A is down." and organized the agents as follows: 1.
The UIA generates the request as r 1 =< "host A ", "NULL", "analysis" > (14) and sends it to the repository.

2.
The IDB and ELS agents appear in the workplace according to the entity "host A " in r 1 .

3.
The two agents resend r 1 to the repository.

4.
The DSS agent is instantiated in the workplace according to "Analysis" in r 1 .
The PLT agent is instantiated in the workplace by "Plot" of r 2 . 7.
The processing flow of the data is automatically constructed.

Case 4: Brute Force Attack
A brute force attack is a cyberattack that challenges various patterns of passwords for logging into the target host. In this case study, we virtually generate a brute force attack on "host A " and check the output of the prototypical system. The experimental procedure is as follows: 1.
Access "hoat A " from a terminal five times per second.

2.
Generate a virtual brute force attack on "host A " ten times per minute.

3.
After continuing Step 2 for 2 hours, input "Analyze the logs on host A ".

4.
Analyze the output from the prototypical system. Figure 15 shows a screenshot of the output of the above experiment. Figure 15a indicates there were periodic login challenges to the page "/wp-login.php" on "host A ". Figure 15b shows the Fourier analysis result for the data in Figure 15a. The graph also indicates the periodic activity of login challenges; the red circled spike represents n = 12, which equals 10 minutes. By integrating the two results, the administrator could suspect a brute force attack on host A . The processing flow in the prototypical system when it receives the request "Analyze the logs on host A ." is as follows: 1.
The UIA generates request r 1 from the input text as r 1 =< "host A ", "Logs", "Analysis" > (16) and sends it to the agent repository.

2.
The ELS agent is activated by reacting to the keyword "host A " and instantiated in the workplace. 3.
Using the stored knowledge, the ELS agent resends r 1 to the agent repository. 4.
The DFA and DSS agents are activated by reacting to the keyword "Analysis" and instantiated in the workplace. 5.
Using the stored knowledge, the DFA agent newly generates another request r 2 as r 2 =< "host A ", "Logs", "Bar plot" > (17) and sends it to the DPAs in the agent repository. 6.
Using the stored knowledge, the DSS agent newly generates another request r 3 as r 3 =< "host A ", "Logs", "Plotting" > (18) and sends it to the DPAs in the agent repository. 7.
The PLT agent is instantiated with "BarPlotting" in r 2 and "Plot" in r 3 .

8.
The processing flow is automatically organized through the instantiated agents.

Case 5: Data Correlation for Anomaly Detection
As a particular use case for the prototypical system, correlation analysis among heterogeneous data on network equipment provides a good demonstration. For instance, a method using the correlation between two different measures of network traffic was proposed for network monitoring [11].
In this case study, we conduct an experimental analysis of the inter-temporal correlation between CPU usage data. The experimental flow is as follows:

1.
Generate access to host A five times per second.

2.
Input "Analyze the CPU usage on host A ." to the UI server.

3.
Check the output from the prototypical system. Figure 16 shows a screenshot of the output for the experiment described above. Figure 16a,c indicate the time series when the request was input and when an anomaly occurred in the past, respectively. Furthermore, Figure 16b shows the correlation value between the data in (a) and (c). Because the correlation value was 0.97 in the case study, the administrator could infer that something wrong occurred on host A .
The processing flow in the prototypical system when it receives the request "Analyze the CPU usage on HostA." is as follows: 1.
The UIA generates request r 1 from the input text as r 1 =< "host A ", "CPU usage", "Analysis" > (19) and sends it to the agent repository.

2.
The ELS and IDB agents are activated by reacting to the keyword "HostA" and instantiated in the workplace. 3.
Using the stored knowledge, the ELS and IDB agents resend r 1 to the agent repository. 4.
The CRR and DSS agents are activated by reacting to the keyword "Analysis" and instantiated in the workplace. 5.
Using the stored knowledge, the CRR agent newly generates another request r 2 as r 2 =< "host A ", "CPU usage", "Line plot" > (20) and sends it to the DPAs in the agent repository.

6.
Using the stored knowledge, the DSS agent newly generates another request r 3 as r 3 =< "host A ", "CPU usage", "Plotting" > (21) and sends it to the DPAs in the agent repository. 7.
The PLT agent is instantiated with "Line plot" in r 2 and "Plot" in r 3 . 8.
The processing flow is automatically organized through the instantiated agents.

Effectivity and Heterogeneity
To evaluate the MADPM, we compared the burden on human administrators by counting how many databases are used to create results. We chose this number because the manual process takes the same steps if the human uses different systems to acquire the number of results. Figure 17 shows the counted heterogeneity and number of databases for the presented information. We define the heterogeneity of the data presentation as if the results had been collected from different data analytics systems. For example, the output of Case 1 was collected from three types of DPTs, that is, ZBX, ELS, and FES, as shown in Figure 11. If an administrator performs the same task manually, this generates three times the burden of the prototype system because the administrator has to use at least three systems to collect the same data. The result indicates that the proposed self-organization scheme can efficiently collect and present heterogeneous data using the multiagent cooperation mechanism. Table 2 shows a comparison of the functional coverage of data presentation between the traditional approach and MADPM. The traditional approach uses tools for respective types of network data. For example, ELS is normally used to collect logs because of its advanced search capability. The remarkable sets of outputs shown in Figures 11 and 13-16 can be provided for each tool individually. However, cross-sectional findings are only provided by the proposed MADPM. As discussed in the previous section, functionality is realized by the cooperation and autonomy of DPAs. Heterogeneity (efficienty) Figure 17. Comparison of heterogeneity, which is counted using the types of information provided by the prototype system. If the administrators (experimenters) collect the same types of information, they have the burden of accessing and operating the systems.  X X X X Zabbix [32] X Fess [48] and Wiki X X MADPM X X X X X X X X X X X X X

Performance and Scalability
Because our MADPM includes the request expansion process, combinatorial explosion can occur. For example, in Figure 6 in the original conference paper [44], we measured the processing time by increasing the quantity of data stored in the system. As a result, there was a difference between DPTs: in the case of the FES agent, even if the number of items on the wiki site used as the search source was increased from 20 to 100, there was no significant difference in processing time. This result was caused by the performance of the FES software. By contrast, the processing time increased linearly according to the number of graphs generated by the PLT agent. Considering practical uses, DPAs are designed to exhibit the capability of DPTs. Additionally, we have not investigated the scalability of increasing the number of agents because of the complexity. We have not provided a solution in this paper for processing performance. In many research fields, load-balancing methods for data processing have been studied, for example, edge computing [34], and can be applied to MAPDM.

Limitations
In the prototype system, the output variety depends on the probability coefficient α. In Case 4, for the request "Analyze the logs of host A ", the outputs of (a) and (b) in Figure 15 were presented with a probability of 72%. By contrast, if the request "Analyze the data of host A " was input, the same outputs were provided with a probability of 36%. The description in dk i caused the difference because it was written as "The number of access logs for the login page." in the log acquisition (ESS) agent. The probability ap i was 1 if data in r i was "Logs"; however, ap i was 0.5 if data was "data", where α = 0.5. Figure 18 shows the output of the unfavorable result. In this case, the request "Analyze the logs of host A " was input into the system. However, the output was only power spectrums, which are not advisable in this scenario. The current prototype system design and implementation cannot respond sufficiently to a variation in notation. This should be improved in a future version.
Only power spectrums are presented. Power spectrum of access-log amounts on ℎ ! Power spectrum of access-log amounts on ℎ ! Power spectrum of access-log amounts to "wp-login.php" on ℎ ! Power spectrum of access-log amounts to "wp-login.php" on ℎ !
Search results of Elasticsearch Figure 18. Example of the undesirable output. In this case, the request "Analyze the logs of host A ." was input. The system output only the power spectrums of the logs, but it was not a high-priority analysis for the target data.

Implications
Although advanced network infrastructure management has become possible, cyberattacks and system failures remain unresolved for a long period. Current network management systems quickly provide information on serious scenarios that occur in systems and rapid communication systems also allow users to report any problems they notice quickly. Conventionally, a failure recovery process is defined such that, after an event is detected, the cause is diagnosed and necessary recovery work is performed. However, in unpredictable circumstances, such as a sudden increase in network usage caused by the effect of COVID-19, problems may occur in unexpected places, and recovery may take longer than expected. In such cases, the proposed system can cause the administrator to notice the cause of the problem, which is usually difficult to determine by displaying information from different perspectives in response to a request from the administrator.
We can also address the issue of the education of non-professional administrators. Newly appointed administrators do not yet know the details of the network. The MADPM, which proposes a method to collect related information using a flexible free word search, is an effective mechanism for such administrators because it can simultaneously provide domain knowledge in addition to current data analysis. Although cross-system cooperation must handle a huge amount of relational information, the proposed approach solves this problem by distributing it well and selecting it stochastically using a multiagent mechanism.

Conclusions
We proposed a multiagent-based mechanism to present data analytics for network management tasks. We introduced accuracy and expansion into request-matching for the agent organization process by considering creative heuristics in exploratory analysis. We designed agents to encapsulate the DPTs that handle and process network management data. We implemented the prototype system in an experimental network to evaluate the proposed approach. We conducted five case studies on the experimental network using the prototype system. Through the case studies, multifaceted result presentations supported the exploration task for cause detection. Even though AI-based automation technologies are spreading widely, the demand for human creativity will remain while the cause of cybersecurity risks comes from humans. Our proposed approach can contribute to technologies empowering humanity in the use of practical systems. As discussed in Section 4, the limitations of flexibility and parameter-tuning remain to be addressed in future work. The final goal of our proposed approach is to achieve multifaceted and cross-system data presentation. Author Contributions: Conceptualization, K.S., G.K. and T.K.; methodology, K.S., R.F. and G.K.; software, K.S. and R.F.; validation, K.S. and R.F.; formal analysis, K.S.; investigation, K.S.; resources, K.S., G.K. and T.K.; data curation, K.S.; writing-original draft preparation, K.S.; writing-review and editing, K.S.; visualization, K.S.; supervision, G.K. and T.K.; project administration, K.S. and T.K.; funding acquisition, K.S. All authors have read and agreed to the published version of the manuscript.

Appendix A.2. Example of IDB Agent
Listing A2 is an example code of implemented DPAs. In this case, the DPA is specially built for InfluxDB. Lines 13 to 18 include action rules common to DPAs. The rules for each file are described in the Supplementary Materials. This code is the data-processing agent that controls the data-processing tools (IDB) managing the performance data. The 6th to 8th lines of the code describe the name of the base process to be loaded, the URL of the data processing tool to be controlled and the path of the result output file, respectively. The 10th and 14th lines correspond to knowledge dk i and describe the amount of traffic received by HOST_A and the amount of traffic flowing to ROOM_X of the core switch (CORE_SW), respectively. The description on the 17th line describes the processing performed by this data-processing agent. In this example, when the processing p i to be performed on the data of request r i is "provide", the agents that perform line graph drawing described in lines 21 and 22 are called. The rules described below the 47th line execute data processing. Lines 49, 59, and 71 are limited to cases where the knowledge of (state :name "processing") is retained, and, on line 75, the knowledge is changed (modify) to (state :name "post-processing").

Appendix B.2. Example Codes of Base Process
Listings A5 and A6 show example descriptions of the base process and data-processing module in the IDB agent, respectively. In this example, the class corresponding to the query creation/data-creation module is "SetupInfluxDB". Since this module acquires time-series data from the database, "new NothingInput()" is written on the 15th line of Listing A3 and no code is written in the process method on the 23rd line of Listing A6. The process method on the 13th line executes the query necessary for data retrieval every second. The add method on line 32 receives the search results from "QueryInfluxDB" and, when all the issued queries are processed, the data is converted to a byte array and passed to the data send module.
1 public class B PI nf l ux DB A ge n t extends D a t a P r o c e s s i n g A g e n t implements I E v e n t D a t a P r o c e s s { 4 5 private List < QueryInfluxDB > q u e r y I n f l u x D B L i s t ; 6 private List < ExchangeFormat > e x c h a n g e F o r m a t L i s t ; if ( e x c h a n g e F o r m a t L i s t . size () == q u e r y I n f l u x D B L i s t . size () ) { 40 E x c h a n g e L i s t F o r m a t e x c h a n g e L i s t F o r m a t = new E x c h a n g e L i s t F o r m a t () ; 41 e x c h a n g e L i s t F o r m a t . list = e x c h a n g e F o r m a t L i s t ; 42 rais ePostE vent ( new PostEvent ( this , gson . toJson ( 43 e x c h a n g e L i s t F o r m a t ) . getBytes () ) ) ; 44 } 45 } 46 }