3.15.1 Performance monitoring function by JP1/IM - Agent

■ Main items to be acquired

The main retrieval items of Windows exporter are defined in Windows exporter metric definition file (default) and Windows exporter (service monitoring) metric definition file (default). For details, see Windows exporter metric definition file (metrics_windows_exporter.conf) in Chapter 2. Definition Files and Windows exporter (service monitoring) metric definition file (metrics_windows_exporter_service.conf) in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

You can add retrieved items to the metric definition file. The following are the metrics that can be specified in the PromQL statement described in the definition file. For details of "Collector" in the table, refer to the description of "Collector" at the bottom of the table.

#

The process-name is set, but ".exe" is omitted.

■ Collector

Windows exporter has a built-in collection process called a "collector" for each monitored resource such as CPU and memory.

If you want to add the metrics listed in the table above as acquisition fields, you must enable the collector corresponding to the metric you want to use. You can also disable collectors of metrics that you do not want to collect to suppress unnecessary collection.

Enable/disable for each collector can be specified with the "--collectors.enabled" option on the Windows exporter command line or in the item "collectors.enabled" in the Windows exporter configuration file (jpc_windows_exporter.yml).

For details about Windows exporter command-line options, see the description of windows_exporter command options in Service definition file (jpc_program-name.service.xml) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

For details about Windows exporter configuration file entry "collectors.enabled", see the description of item collectors in Windows exporter configuration file (jpc_windows_exporter.yml) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

■ Specifying Monitored Services

When using the service monitoring function of Windows exporter, the service to be monitored is specified in the "services-where" field of Windows exporter configuration file (jpc_windows_exporter.yml).

For details about Windows exporter configuration file entry "services-where", see the entry "services-where" in Windows exporter configuration file (jpc_windows_exporter.yml) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

The value of name label of the metric output by service collectors of Windows exporter is set to the service name. If half-width uppercase characters are included in the service name of the monitoring target, they are converted to half-width lowercase characters and set. When full-pitch uppercase characters are included, they are converted to full-pitch lowercase characters and set.

- About Monitoring JP1/IM - Agent Services

For the service name of JP1/IM - Agent service, see 10.1 Service of JP1/IM - Agent in the JP1/Integrated Management 3 - Manager Administration Guide. For details about the service name in a logical host environment, see 7.3.6 Newly installing JP1/IM - Agent with integrated agent host (for Windows) in the JP1/Integrated Management 3 - Manager Configuration Guide.

Note that you cannot use the service monitoring function to monitor Prometheus server and Windows exporter services.

■ Main items to be acquired

The main retrieval items of Node exporter are defined in Node exporter metric definition file (default) and Node exporter (service monitoring) metric definition file (default). For details, see Node exporter metric definition file (metrics_node_exporter.conf) and Node exporter (service monitoring) metric definition file (metrics_windows_exporter_service.conf) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

You can add retrieved items to the metric definition file. The following are the metrics that can be specified in the PromQL statement described in the definition file. For details of "Collector" in the table, refer to the description of "Collector" at the bottom of the table.

■ Collector

The Node exporter has a built-in collection process called a "collector" for each monitored resource such as CPU and memory.

If you want to add the metrics listed in the table above as acquisition fields, you must enable the collector corresponding to the metric you want to use. You can also disable collectors of metrics that you do not want to collect to suppress unnecessary collection.

Per-collector enable/disable can be specified in the Node exporter command line options. Specify the collector to enable with the "--collector.collector-name" option and the collector to disable with the "--no-collector.collector-name" option.

For details about Node exporter command-line options, see the description of node_exporter command options in Unit definition file (jpc_program-name.service) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

■ Specifying monitored services

When using the service monitoring function of Node exporter, the service to be monitored is specified in the "--collector.systemd.unit-include" field of Node exporter unit definition file (jpc_node_exporter.service). Collects performance data for the service specified in this file that meets one of the following conditions:

• Automatic start of monitored services is enabled (running systemctl enable)

• Automatic startup of monitored services is disabled, but the status is active

Performance data for services with auto-start disabled is not collected while the service is stopped. Therefore, if you want to monitor a service that has auto-start disabled and is stopped, start the service that you want to monitor and collect performance data prior to creating IM management node tree.

For unit definition file, see the description in item "--collector.systemd.unit-include" in "node_exporter command options" in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

- About monitoring JP1/IM - Agent services

For unit definition file name of JP1/IM - Agent services, see 10.1 Service of JP1/IM - Agent in the JP1/Integrated Management 3 - Manager Administration Guide. For unit definition file name in a logical host environment, see 8.3.6 Newly installing JP1/IM - Agent with integrated agent host (for UNIX) in the JP1/Integrated Management 3 - Manager Configuration Guide.

Note that you cannot use the service monitoring function to monitor Prometheus server and Node exporter services.

■ Key metric items

The key Process exporter metric items are defined in the Process exporter metric definition file (initial status). For details, see Process exporter metric definition file (metrics_process_exporter.conf) in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

You can add more metric items to the metric definition file. The following table shows the metrics you can specify with PromQL statements used within the definition file.

#

The group-name contains a name that uniquely identifies the collected performance value. In addition, the value is stored according to the contents set by the user in the item "name" of the Process exporter configuration file (jpc_process_exporter.yml).

Important

• Processes whose name contains multi-byte characters cannot be monitored.

• Process exporter still continues to output information of processes that it collected once, even after the processes stop running. Therefore, if Process exporter is configured to collect information based on PIDs, new time-series data is added every time a process is restarted and its PID is changed, resulting in large amounts of unnecessary data.

  Furthermore, it is not recommended to use PIDs in open source software (OSS), and thus version 13-00 of our software is configured not to collect PID information by default (groupname). If the user wants to manage processes on the same command line separately, we recommend operational means, such as a change in the order of arguments or the use of PIDs (however, periodic restarts are needed to prevent collected information from accumulating continuously).

  Note that information collected by Windows exporter is different from what Process exporter collects, because Windows exporter collects the PID information.

• When Process exporter monitors a monitored process, by default it monitors the child processes of the monitored process and acquires the operational data including the child processes.

  To avoid including child processes, unit definition file of Process exporter must be edited.

  For details, see 2.19.2(6)(d) Setting that excludes child processes from monitoring in the JP1/Integrated Management 3 - Manager Configuration Guide.

■ Prerequisites

It is a prerequisite that the ports used by Node exporter for AIX are protected by firewalls, networking configurations, and so on, so that they are not accessed by anything other than Prometheus server of JP1/IM - Agent.

For the ports used by Node exporter for AIX, see the explanation of node_exporter_aix command options in 10.4.2(1) Enabling registering services in the JP1/Integrated Management 3 - Manager Administration Guide.

■ Conditions to be monitored

See the Release Notes for the supporting OS of the host on which you are installing Node exporter for AIX.

WPAR is not supported.

Multiple boots of Node exporter for AIX on the same host are not supported, even if they are booted on both physical and logical hosts.

The logical host configuration of the monitored AIX hosts is supported only if the following conditions are met:

• The hostname of the monitored AIX hostname can be uniquely resolved from Prometheus.

Note: If more than one IP address is assigned to AIX monitored host, Node exporter for AIX can be accessed by all IP addresses.

For the upper limit of Node exporter for AIX that can be monitored by one Prometheus server, refer to the limit value list in JP1/IM - Agent of Appendix D.1 Limits when using the Intelligent Integrated Management Base.

■ Main items to be acquired

The main retrieval items for Node exporter for AIX that JP1/IM - Agent ships with are defined in metric definition-file (default) of Node exporter for AIX. For details, see Node exporter for AIX metric definition file (metrics_node_exporter_aix.conf) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

You can add retrieval items to metric definition file. The following table lists metric that can be specified for PromQL expression in the definition file:

Node exporter for AIX is collected for each monitored resource, such as CPU, memories. You can enable or disable collection for each resource that you want to monitor by using Node exporter for AIX command-line options.

For Node exporter for AIX command-line options, see the description of node_exporter_aix command options in 10.4.2(1) Enabling registering services in the JP1/Integrated Management 3 - Manager Administration Guide.

Use Script exporter to collect information about processes. For details on how to configure the settings, see 1.23.2(4)(e) Monitoring processes on monitoring hosts (AIX) (optional) in the JP1/Integrated Management 3 - Manager Configuration Guide.

Use JP1/Base log file trap feature to monitor the log files of the monitored AIX hosts.

■ Notes on logging Node exporter for AIX

Node exporter for AIX log file is output to OS system log. Therefore, the destination depends on OS system log settings. For details on changing the output destination of the system log for Node exporter for AIX logging OS, see 1.23.2(4)(f) Changing the log destination of Node exporter for AIX (optional) in the JP1/Integrated Management 3 - Manager Configuration Guide.

■ Precautions When Using SMT or Micro-Partitioning

In an SMT(Simultaneous multithreading) or Micro-Partitioning deployment, calculating CPU Utilization (cpu_used_rate) metric for Node exporter for AIX does not include physical CPU quotas, but calculating CPU utilization as displayed by sar command includes physical CPU quotas.

Therefore, CPU Utilization (cpu_used_rate) of Node exporter for AIX might show a lower metric than sar command output.

■ Main items to be acquired

The main retrieval items of Yet another cloudwatch exporter are defined in Yet another cloudwatch exporter metric definition file (default). For details, see Yet another cloudwatch exporter metric definition file (metrics_ya_cloudwatch_exporter.conf) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

■ CloudWatch metrics you can collect

You can collect metric of namespace name of AWS that is supported for monitoring by Yet another cloudwatch exporter of JP1/IM - Agent that is listed in 3.15.6(1)(k) Creating an IM Management Node for Yet another cloudwatch exporter.

Specify the metrics to collect by describing the AWS service name and CloudWatch metric name in the Yet another Cloudwatch Exporter configuration file (jpc_ya_cloudwatch_exporter.yml).

The following is an example of the description of the Yet another cloudwatch exporter configuration file when collecting CPUUtilization and DiskReadBytes for CloudWatch metrics for AWS/EC2 services.

discovery:
  exportedTagsOnMetrics:
    ec2:
      - jp1_pc_nodelabel
  jobs:
  - type: ec2
    regions:
      - ap-northeast-1
    period: 60
    length: 300
    delay: 60
    nilToZero: true
    searchTags:
      - key: jp1_pc_nodelabel
        value: .*
    metrics:
      - name: CPUUtilization
        statistics:
        - Maximum
      - name: DiskReadBytes
        statistics:
        - Maximum

For details about what Yet another cloudwatch exporter configuration file describes, see Yet another cloudwatch exporter configuration file (jpc_ya_cloudwatch_exporter.yml in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

You can also add new metrics to the Yet another cloudwatch exporter metrics definition file using the metrics you set in the Yet another cloudwatch exporter configuration file.

The metrics and labels specified in the PromQL statement described in the definition file conform to the following naming conventions:

- Naming conventions for Exporter metrics

Yet another cloudwatch exporter treats the metric name of CloudWatch as the metric name of the exporter as the automatic conversion of the metric name in CloudWatch by the following rules. Also, the metric specified on the PromQL statement is described using the indicator name of the exporter.

"aws_"^#1+name-space^#2+"_"+CloudWatch-metric^#2+"_"+statistic-type^#2

#1

Appended if the namespace does not begin with "aws_".

#2

Indicates the name you set in the Yet another cloudwatch exporter configuration file (jpc_ya_cloudwatch_exporter.yml). It is converted by the following rules:

• It is converted from camel case notation to snake case notation.

  CamelCase is a notation that capitalizes word breaks, such as "CamelCase" or "camelCase."

  Snakecase is a notation that separates words with "_", such as "snake_case".

• The following symbols are converted to "_".

  whitespace,comma,tab, /, \, half-width period, -, :, =, full-width left double quote, @, <, >

• "%" is converted to "_percent".

- Exporter label naming conventions

Yet another cloudwatch exporter treats the CloudWatch dimension tag name as the Exporter's label name, which is automatically converted by the following rules. Also, labels specified on the PromQL statement are described using the label name of the Exporter.

• For dimensions

  "dimension"+"_"+dimensions_name^#

• For tags

  "tag"+"_"+tag_name^#

• For custom tags

  "custom_tag_"+"_"+custom tag_name^#

#

Indicates the name you set in the Yet another cloudwatch exporter configuration file (jpc_ya_cloudwatch_exporter.yml).

■ About policies for IAM users in your AWS account

To connect to AWS CloudWatch, you must create a policy with the following permissions and assign it to an IAM user.

"tag:GetResources",
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"

For details on how to set JSON format information, refer to "1.21.2(7)(b) Modify Setup to connect to CloudWatch (for Windows) (optional)" in the manual JP1/Integrated Management 3-Manager Configuration Guide. (The references for Linux are the same.)

■ Environment-variable HTTPS_PROXY

Environment-variable that you specify when you connect to CloudWatch from a Yet another cloudwatch exporter through a proxy. The URL that can be set in the environment-variable HTTPS_PROXY is http only. Note that the only Authentication method supported is Basic authentication.

You can set the environment-variable HTTPS_PROXY to connect to AWS CloudWatch through proxies. The following shows an example configuration.

HTTPS_PROXY=http://username:password@proxy.example.com:5678

■ How to handle monitoring targets JP1/IM - Agent does not support

If you have a product or metric that cannot be monitored by JP1/IM - Agent, you must retrieve it, for example, using user-defined Exporter.

■ Key metric items

The key Promitor metric items are defined in the Promitor metric definition file (initial status). For details, see the description under Promitor metric definition file (metrics_promitor.conf) in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

■ Metrics you can collect

Promitor can collect metrics for the following services to monitor:

You specify metrics you want to collect in the Promitor Scraper configuration file (metrics-declaration.yaml).

If you want to change the metrics specified in the Promitor Scraper settings file, see Change monitoring metrics (optional) in the JP1/Integrated Management 3 - Manager Configuration Guide 1.21.2(8) Set up of Promitor (d) Configuring scraping targets (required).

You can also add new metrics to the Promitor metric definition file, based on the metrics specified in the Promitor Scraper configuration file. Metrics defined in Promitor Scraper configuration file can be specified to the PromQL statement written in the definition file.

Legend:

Y: Automatic discovery is supported.

--: Automatic discovery is not supported.

■ Checking how Azure SDKs used by Promitor are supported

Promitor employs Azure SDK for .NET. An end of Azure SDK support is announced 12 months in advance. For details on the lifecycle of Azure SDK, see Lifecycle FAQ at the following website:

https://learn.microsoft.com/ja-jp/lifecycle/faq/azure#azure-sdk-----------

For the lifecycles of versions of Azure SDK libraries, you can find them in the following website:

https://azure.github.io/azure-sdk/releases/latest/all/dotnet.html

■ Credentials required for account information

Promitor can connect to Azure through the service principal method or the managed ID method. For details on the credentials assigned to the service principal and managed ID, see (a) Configuring the settings for establishing a connection to Azure (required) in the JP1/Integrated Management 3 - Manager Configuration Guide 1.21.2(8) Set up of Promitor.

■ Main items to be acquired

The main retrieval items of Blackbox exporter are defined in Blackbox exporter metric definition file (default). For details, see Blackbox exporter metric definition file (metrics_blackbox_exporter.conf) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

You can add retrieved items to the metric definition file. The following are the metrics that can be specified in the PromQL statement described in the definition file.

■ IP communication with monitored objects

Only IPv4 communication is supported.

■ Encrypted communication with monitored objects

HTTP monitoring enables encrypted communication using TLS. In this case, the Blackbox exporter acts as a TLS client to the monitored object (TLS server).

When using encrypted communication using TLS, specify it in item "tls_config" in the Blackbox exporter configuration file (jpc_blackbox_exporter.yml). In addition, the following certificate and key files must be prepared.

The available TLS versions and cipher suites are supported below.

■ Timeout for collecting health information

In a network environment where response is slow (under normal conditions), operating information can be collected by adjusting the timeout period.

On the Prometheus server, you can specify the scrape request timeout period in the entry "scrape_timeout" of the Prometheus configuration file (jpc_prometheus_server.yml). For details, see the description of item scrape_timeout in Prometheus configuration file (jpc_prometheus_server.yml) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

In addition, the timeout period when connecting from the Blackbox exporter to the monitoring target is 0.5 seconds before the value specified in "scrape_timeout" above.

■ Certificate expiration

When collecting operation information by HTTPS monitoring, the exporter receives a certificate list (server certificate and certificate list certifying server certificate) from the monitoring target.

The Blackbox exporter allows you to collect the expiration time (UNIX time) of the closest expiring certificate as a probe_ssl_earliest_cert_expiry metric.

You can also use the features in 3.15.1(3) Performance data monitoring notification function to monitor certificates that are close to their deadline, because you can calculate the number of seconds remaining before the deadline with the value calculated in probe_ssl_earliest_cert_expiry Metric Value-PromQL's time() function.

■ User-Agent value in HTTP request header when monitoring HTTP

The default value of User-Agent included in HTTP request header during HTTP monitoring is as shown below:

• For version 13-00 or earlier

  "Go-http-client/1.1"

• For version 13-00-01 or later

  "Blackbox Exporter/0.24.0"

You can change the value of User-Agent in the setting of item "headers" in the Blackbox exporter configuration file (jpc_blackbox_exporter.yml).

The following is an example of changing the value of User-Agent to "My-Http-Client".

modules:
  http:
    prober: http
    http:
      headers:
        User-Agent: "My-Http-Client"

For details, see the description of item headers in Blackbox exporter configuration file (jpc_blackbox_exporter.yml) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

■ About HTTP 1.1 Name-Based Virtual Host Support

The Blackbox exporter supports HTTP 1.1 name-based virtual hosts and TLS Server Name Indication (SNI). You can monitor virtual hosts that disguise one HTTP/HTTPS server as multiple HTTP/HTTPS servers.

■ About TLS Server Authentication and Client Authentication

In Blackbox exporter's HTTPS monitoring, server authentication is performed using the CA certificate described in item "ca_file" of the Blackbox exporter configuration file (jpc_blackbox_exporter.yml) and the server certificate sent by the server when HTTPS communication with the server starts (TLS handshake).

If the sent certificate is incorrect (server name is incorrect, expired, self-certificate is used, etc.), HTTPS communication cannot be started and monitoring fails.

In addition, when a request is made to send a certificate from the monitored server at the start of HTTPS communication (TLS handshake), the client certificate described in item "cert_file" of the Blackbox exporter configuration file (jpc_blackbox_exporter.yml) is sent to the monitored server.

If the server validates the sent certificate, recognizes it as invalid, and returns an error to the Blackbox exporter via the TLS protocol (or if communication cannot be continued due to a loss of communication, etc.), the monitoring fails.

For details on the verification contents related to the client certificate and the operation in the event of an error on the monitored server, check the specifications of the monitored server (or relay device such as a load balancer).

To detect fraudulent certificates during server authentication, if you specify "true" in item "insecure_skip_verify" in the Blackbox exporter configuration file (jpc_blackbox_exporter.yml), HTTPS communication can be started without errors. However, in that case, the verification operation related to client authentication at the server will be invalidated.

For details, see the description of item insecure_skip_verify in Blackbox exporter configuration file (jpc_blackbox_exporter.yml) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

Server authentication cannot be performed using certificates that the host name is not listed in the Subject Alternative Name field.

■ About cookie information

The Blackbox exporter does not use cookie information sent from the monitored target in the next HTTP communication request.

■ About external resources referenced from content included in the response body of HTTP communication

In Blackbox exporter, external resources (subframes, images, etc.) referenced from the content included in the response body of HTTP communication are not included in the monitoring range.

■ About Monitoring of Content Included in HTTP Communication Response Body

Since the Blackbox exporter does not parse the content, the execution result and execution time based on the syntax (HTML, javascript, etc.) in the content included in the response body of HTTP communication are not reflected in the monitoring result.

■ Precautions when the monitoring destination of HTTP monitoring redirects with Basic authentication

If the Blackbox exporter's HTTP monitoring destination redirects with Basic authentication, the Blackbox exporter sends the same Basic authentication username and password to the redirect source and destination. Therefore, when performing Basic authentication on both the redirect source and the redirect destination, the same user name and password must be set on the redirect source and the redirect destination.

■ Key metric items

The key Script exporter metric items are defined in the Script exporter metric definition file (initial status). For details, see Script exporter metric definition file (metrics_script_exporter.conf) in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

You can add more metric items to the metric definition file. The following table shows the metrics you can specify with PromQL statements used within the definition file.

■ Conditions to be monitored

The following are the Oracle Database configurations and database character sets that JP1/IM - Agent supports for monitoring:

• Configuring Oracle Database

  • For non-clusters

    Non CDB and CDB configurations

  • For Oracle RAC

    CDB configuration

Because OracleDB exporter connects to one service in a single process, it launches more than one OracleDB exporter if there is more than one target.

Note

• Oracle RAC One Node and Oracle Database Cloud Service are not supported.

• HA clustering configuration on Oracle Database is not supported.

• Oracle Database database-character set

  • AL32UTF8(Unicode UTF-8)

  • JA16SJIS (Japanese-language SJIS)

  • ZHS16GBK (Simplified Chinese GBK)

■ Acquisition items

The metrics that can be retrieved with the OracleDB exporter shipped with the JP1/IM - Agent are the metrics and cache_hit_ratio defined by the OracleDB exporter default.

OracleDB exporter retrieval items are defined in metric definition-file (default) of OracleDB exporter. For details, see OracleDB exporter metric definition file (metrics_oracledb_exporter.conf) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

The following tables list metric that can be specified for PromQL expression in the definition file. The value of each metric is obtained by executing the SQL statement shown in the table to Oracle Database. For details about metric, contact Oracle based on SQL statement of the data source.

#1

In a PDB, the table in the source v$resource_limit is empty and cannot be retrieved.

#2

In a PDB, the table in the source v$waitclassmetric is empty and cannot be retrieved.

Important

• Prior to using OracleDB exporter, make sure that SQL statements that serve as the data source can be executed, for example, with SQL*Plus command. This ensures that the required information can be displayed. Use OracleDB exporter to connect to Oracle Database when checking.

• OracleDB exporter provided by JP1/IM - Agent does not support the ability to collect any metric (custom metrics).

■ Requirements for monitoring Oracle Database

If you want to monitor Oracle Database on OracleDB exporter, Oracle Database must have the following settings:

You do not need to install Oracle Client, etc. on JP1/IM - Agent host-side.

• Oracle listener

  • Configure Oracle listener and servicename so that they can connect to the target.

  • Oracle listener is configured to accept unencrypted connect requests.

• Oracle Database

  Set Oracle Database database-character set to one of the following:

  • AL32UTF8 (Unicode UTF-8)

  • JA16SJIS (Japanese-language SJIS)

  • ZHS16GBK (Simplified Chinese GBK)

• Users used to access Oracle Database

  • The user used to connect to Oracle Database must have the following permissions:

    - Login permissions

    - SELECT permissions to the following tables

    dba_tablespace_usage_metrics

    dba_tablespaces

    v$system_wait_class

    v$asm_diskgroup_stat

    v$datafile

    v$sysstat

    v$process

    v$waitclassmetric

    v$session

    v$resource_limit

  • User used to connect to Oracle Database

    For details about the character types and maximum lengths that can be specified for user names, see Environment variables.

  • Password of the user used to connect to Oracle Database

    The following character types can be used for passwords:

    - Uppercase letters, lowercase letters, numbers, @, +, ', !, $, :, ., (, ), ~, -, _

    - The password can be from 1 to 30 bytes in length.

■ Obfuscation of Oracle Database passwords

OracleDB exporter shipped with JP1/IM - Agent manages the passwords in secret obfuscation capabilities for accessing Oracle Database from OracleDB exporter. For details, see 3.15.10 Secret obfuscation function.

■ Notes on Oracle Database log files

Monitoring Oracle Database with OracleDB exporter can generate a large number of logfiles. Therefore, Oracle Database administrator should consider deleting logfiles periodically.

Below is a sample command line for deleting ".trc" or ".trm" files with older renewal dates. If necessary, consider running such commands periodically to delete unnecessary logs.

Set the $ORACLE_BASE and %ORACLE_BASE% environment variables as needed.

■ Environment variables

The following environment variables are required when using OracleDB exporter.

- Environment-variable "DATA_SOURCE_NAME" (required)

Specify the destination of OracleDB exporter in the following format: There is no default value.

• For Windows

oracle://user-name@host-name:port/service-name?connection timeout=10[&instance name=instance-name]

• For Linux

oracle://user-name@host-name:port/service-name?connection timeout=10[&instance name=instance-name]

user-name

• Specifies the username to connect to Oracle listener. Up to 30 characters can be specified.

• You can use uppercase letters, numbers, underscores, dollar signs, pound signs, periods, and at signs. Note that lowercase letters are not allowed.

• For Linux, replace the pound sign with "%%23" when you include your username in unit definition file. For example, if you are a shared CDB user, specify "C##USER" as "C%%23%%23USER".

• For Windows, replace the pound sign with %23 when you include the username in service definition file. For example, if you are a shared CDB user, specify "C##USER" as "C%23%23USER".

host-name

• Specifies the host name of Oracle Database host to monitor. Up to 253 characters can be specified.

• You can use uppercase letters, lowercase letters, numbers, hyphens, and periods.

port

• Specifies the port number for connecting to Oracle listener.

service-name

• Specifies the service name of Oracle listener. Up to 64 characters can be specified.

• You can use uppercase letters, lowercase letters, numbers, underscores, hyphens, and periods.

Option

You can specify the following options. If you specify more than one, connect them with &amp; in Windows and & in Linux.

• connection timeout=number

  Specifies the connection timeout in seconds. This option must be specified.

  Be sure to specify 10. If you specify a value other than 10 or do not specify this option, scrape of Prometheus server times out and up metric may be 0 even if OracleDB exporter is running.

• instance name=instance-name

  Specifies instance to connect to. Specifying this option is optional.

(Example of specification)

oracle://orauser@orahost:1521/orasrv?connection timeout=10

• For Windows

oracle://orauser@orahost:1521/orasrv?connection timeout=10&instance name=orcl1

• For Linux

oracle://orauser@orahost:1521/orasrv?connection timeout=10
&instance name=orcl1

- Environment variable DATA_SOURCE_NAME (required)

Specify the full path of jp1ima directory under JP1/IM - Agent installation directory.

For a logical host, specify the full path of jp1ima directory under JP1/IM - Agent shared directory.

(Example of specification)

• For Windows

C:\Program files\Hitachi\jp1ima

• For Linux

/opt/jp1ima

■ Notes

• If you try to stop the monitored Oracle Database instance and containers prior to stopping OracleDB exporter, NORMAL shutdown of Oracle may not terminate. Stop OracleDB exporter in advance or stop Oracle Database by IMMEDIATE shutdown

• Shut down OracleDB exporter before making configuration changes or maintaining Oracle Database instance and containers.

■ Key metric items

You define what figures you need from the log files created by your monitoring targets in the log metrics definition file (fluentd_any-name_logmetrics.conf). These definitions allow you to get quantified data (log metrics) as metric items.

For details on the log metrics definition file, see Log metrics definition file (fluentd_any-name_logmetrics.conf) in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

■ Sample files

The following provides descriptions of sample files for when you use the log metrics feature. If you copy the sample files, be careful of the linefeed codes. For details, see the description of each file of 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference. These sample files are based on the assumptions in Assumptions of the sample files. Copy each file and change the settings according to your monitoring targets.

- Assumptions of the sample files

The sample files described here assume that HostA, a monitored host (integrated agent host), exists and JP1/IM - Agent is installed in it, and that WebAppA, an application running on HostA, creates the following log file.

- ControllerLog.log

As shown in target log message 1, a log message is created, saying that an HTTP endpoint in WebAppA is used, at the start of processing of the request for that endpoint. The log message also indicates the number of records handled upon request processing.

Target log message 1:

...
2022-10-19 10:00:00 [INFO] c.b.springbootlogging.LoggingController : endpoint "/register" started. Target record: 5.
...

In the sample files, a regular expression to match target log message 1 is used, and the number of the log messages that match the expression is counted. The number is then displayed in the Trends tab of the JP1/IM integrated operation viewer as log metric 1, Requests to the register Endpoint.

The definition for log metric 1 uses counter as its log metric type.

In addition, the regular expression used in the above also extracts the number indicated as Target record from target log message 1, and then the extracted numbers are summed up. The total is then displayed in the Trends tab of the JP1/IM integrated operation viewer as log metric 2, Number of Registered Records.

The definition for log metric 2 uses counter as its log metric type.

Fluentd workers (multi-process workers feature) for the number of log files to be monitored are required. For details on the worker settings related to the log metrics feature, see the log metrics definition file (fluentd_any-name_logmetrics.conf). Here, it is assumed that 11 fluentd workers are running, and ControllerLog.log is monitored by a worker whose worker ID is 10.

These sample files also assume the tree structure consisting of the following IM management nodes:

All Systems
 + Host A
    + Application Server
       + WebAppA

- Target files in this example

The target files used in this example are as follows:

• Integrated manager host

  - User-specific metric definition file

• Integrated agent host

  - Prometheus configuration file

  - User-specific discovery configuration file

  - Log metrics definition file

  - Fluentd log monitoring target definition file

- Sample user-specific metric definition file

- File name: metrics_logmatrics1.conf

- Written code

[
  {
    "name":"logmetrics_request_endpoint_register",
    "default":true,
    "promql":"logmetrics_request_endpoint_register and $jp1im_TrendData_labels",
    "resource_en":{
      "category":"HTTP",
      "label":"request_num_of_endpoint_register",
      "description":"The request number of endpoint register",
      "unit":"request"
    },
    "resource_ja":{
      "category":"HTTP",
      "label":"registerへのリクエスト数",
      "description":"The request number of endpoint register",
      "unit":"リクエスト"
    }
  },
  {
    "name":"logmetrics_num_of_registeredrecord",
    "default":true,
    "promql":"logmetrics_num_of_registeredrecord and $jp1im_TrendData_labels",
    "resource_en":{
      "category":"DB",
      "label":"logmetrics_num_of_registeredrecord",
      "description":"The number of registered record",
      "unit":"record"
    },
    "resource_ja":{
      "category":"DB",
      "label":"登録されたレコード数",
      "description":"The number of registered record",
      "unit":"レコード"
    }
  }
]

Note

The storage directory, written code, and file name follow the format of the user-specific metric definition file (metrics_any-Prometheus-trend-name.conf).

- Sample Prometheus configuration file

- File name: jpc_prometheus_server.yml

- Written code

global:
  ...
(omitted)
  ...
scrape_configs:
  - job_name: 'LogMetrics'
    
    file_sd_configs:
      - files:
        - 'user/user_file_sd_config_logmetrics.yml'
    
    relabel_configs:
      - target_label: jp1_pc_nodelabel
        replacement: Log trapper(Fluentd)
    
    metric_relabel_configs:
      - target_label: jp1_pc_nodelabel
        replacement: ControllerLog
      - source_labels: ['__name__']
        regex: 'logmetrics_request_endpoint_register|logmetrics_num_of_registeredrecord'
        action: 'keep'
      - regex: (jp1_pc_multiple_node|jp1_pc_agent_create_flag)
        action: labeldrop
 
  ...
(omitted)
  ...

Note

The storage directory and written code follow the format of the Prometheus configuration file (jpc_prometheus_server.yml). You do not have to create a new file. Instead, you add the scrape_configs section for the log metrics feature to the Prometheus configuration file (jpc_prometheus_server.yml) created during installation.

- Sample user-specific discovery configuration file

- File name: user_file_sd_config_logmetrics.yml

- Written code

- targets:
  - HostA:24830
  labels:
    jp1_pc_exporter: logmetrics
    jp1_pc_category: WebAppA
    jp1_pc_trendname: logmetrics1
    jp1_pc_multiple_node: "{__name__=~'logmetrics_.*'}"
    jp1_pc_agent_create_flag: false

Note

The storage directory and written code follow the format of the user-specific discovery configuration file (file_sd_config_any-name.yml).

ControllerLog.log is monitored by the worker whose Fluentd worker ID is 10. Thus, when 24820 is set for port in the Sample log metrics definition file, the port number of the worker monitoring ControllerLog.log is 24820 + 10 = 24830.

- Sample log metrics definition file

- File name: fluentd_WebAppA_logmetrics.conf

- Written code

## Input
<worker 10>
  <source>
    @type prometheus
    bind '0.0.0.0'
    port 24820
    metrics_path /metrics
  </source>
</worker>
## Extract target log message 1
<worker 10>
  <source>
    @type tail
    @id logmetrics_counter
    path /usr/lib/WebAppA/ControllerLog/ControllerLog.log
    tag WebAppA.ControllerLog
    pos_file ../data/fluentd/tail/ControllerLog.pos
    read_from_head true
    <parse>
      @type regexp
      expression /^(?<logtime>[^\[]*) \[(?<loglebel>[^\]]*)\] (?<class>[^\[]*) : endpoint "\/register" started. Target record: (?<record_num>\d[^\[]*).$/
      time_key logtime
      time_format %Y-%m-%d %H:%M:%S
      types record_num:integer
    </parse>
  </source>
 
## Output
## Define log metrics 1 and 2
  <match WebAppA.ControllerLog>
    @type prometheus
    <metric>
      name logmetrics_request_endpoint_register
      type counter
      desc The request number of endpoint register
    </metric>
    <metric>
      name logmetrics_num_of_registeredrecord
      type counter
      desc The number of registered record
      key record_num
      <labels>
      loggroup ${tag_parts[0]}
      log ${tag_parts[1]}
      </labels>
    </metric>
  </match>
</worker>

Note

The storage directory and written code follow the format of the log metrics definition file (fluentd_any-name_logmetrics.conf).

- Sample Fluentd log monitoring target definition file

- File name: jpc_fluentd_common_list.conf

- Written code

## [Target Settings]
  ...
(omitted)
  ...
@include user/fluentd_WebAppA_logmetrics.conf

Note

The storage directory and written code follow the format of the Fluentd log monitoring target definition file (jpc_fluentd_common_list.conf) in JP1/IM - Agent definition files. You do not have to create a new file. Instead, you add the include section for the log metrics feature to the Fluentd log monitoring target definition file (jpc_fluentd_common_list.conf) created during installation.

■ Prerequisites

When you use Web scenario monitoring function, you have the following prerequisites:

• Prerequisite browser

  The following browsers must be installed before you can create and monitor Web scenarios.

  • Google Chrome

  • Microsoft Edge

  In addition, you must be able to access the targets from the above browsers.

  The above browsers are used to create Web scenarios and to monitor Web scenarios using Web scenarios.

• Agent host

  We recommend that you create Web scenarios on the same host and monitor Web scenarios on the same host.

  If you want to migrate Web scenario file to a different host, you must perform the steps in 1.5.1(9)(c) Migrating Web Scenario Files to another host in the JP1/Integrated Management 3 - Manager Administration Guide.

  In addition, Web scenario monitoring function can only be used by agent host on Windows host that have JP1/IM - Agent for Windows installed.

• Web exporter

  The listen port used by Web exporter must be protected, for example, by a firewall or networking configuration, so that it is not accessed by anything other than JP1/IM - Agent's Prometheus server. For the port used by Web exporter, see the explanation of web_exporter command options in Service definition file (jpc_program-name_service.xml) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

■ Network configuration

We recommend that you install JP1/IM - Agent on a networked host that is close to the user who is using the monitored Web contents to monitor according to user's Web scenarios. If the network path from JP1/IM - Agent to the monitoring target differs greatly from that of the user using Web contents, it is difficult to detect monitoring errors due to failure of the relay device.

■ Function List

Web scenario monitoring function monitors the response time of the user's experience by automatically playing back the user's actions on the browser screen and measuring the playing time.

Web scenario monitoring function consists of Web operation information collection function, which collects performance information for Web operation responses based on Web operation scenario, and Web scenario creation support function, which helps create a Web operation scenario (Web scenario).

■ Web Scenario Creation Support Function

Web Scenario creation support function launches Web Scenario creation function, which launches a browser and records what user interact with in the browser as a Web scenario.

■Scenarios that can be created

You can monitor Web contents using Web scenarios that record the following actions:

• Operations for displaying the top page

  This is just the operation to display the top page. No other operations are required.

• To log on from the Login screen

  Enter the username and password and click the logon button.

• Operation of the logoff button on the logoff screen

■ Web Scenario Creation Function (playwright codegen)

Web Scenario creation function provides the ability to assist in the creation of Web manipulation scenarios (Web scenarios). Web Scenario creation function uses Playwright of OSS.

■Prerequisites

When you run playwright command manually, the current folder must be Playwright working folder. For Playwright working folders, see Appendix A.4(3) Integrated agent host (Windows).

It must be run in built-in Administrator.

■Starting Codegen

Web Scenario creation function uses Codegen of Playwright.

The user who runs Codegen must be the same user as the user who runs Web exporter.

Use playwright codegen command to perform Web scenario creation function.

Playwright codegen command is a command that opens a Web site and generates a code-based page in response to your actions. Allows users to run on the terminal.

Recording starts when Web Scenario creation function is activated.

npx playwright codegen --target playwright-test --channel channels --lang locale URL -o ./tests/Web-scenario-filename

Codegen opens two windows: a browser window for interacting with the monitored Web site and a Playwright Inspector window for recording Web scenario code.

When a user runs a Codegen and performs an action in a browser, Playwright generates the code according to the action.

For details about the parameters that can be specified in playwright codegen command, see the following tables.

• npx playwright codegen command option

  Item	Description	Changeability	What You Setup in Your JP1/IM - Agent	JP1/IM - Agent Defaults Value
  -o filename or --output filename	Save the generated script to a file	REQ	Specifies the path to the filename of the destination Web scenario file relative to the command-execution directory. If not specified, the script will be discarded when Codegen terminates. The generated script must be copied to a text file, for example, by the user. File names have the following rules: The filename must be in the format "String.spec.ts". The file name can contain only single-byte alphanumeric characters and underscores (_). The maximum number of bytes that can be specified for a parameter is 256 bytes. You cannot specify folders and files on a network drive. If specified, operation cannot be guaranteed in the event of a network failure or delay (in the event of a Windows). The following pathnames cannot be specified: - File name with a leading "-" (hyphen) - Folder or file name containing environment-dependent characters If you specify a file that does not exist, a new file is created. If you specify a file name that already exists, the file is overwritten. For details about the storage location of the output Web scenario file, see Appendix A.4(3) Integrated agent host (Windows).	./tests/Web-scenario-filename
  --target language	Select the language for generating the script.	--	None	None
  --channel channels	Specifies the distribution channel for Chromium.	REQ	Specify one of the following as the browser for executing Codegen. "chrome" Specify if you want to use Google Chrome. "msedge" Specify if you want to use Microsoft Edge.	None
  --lang language	Specify the language and locale. <Example of specification> "ja-JP"	REQ	One of the following, depending on the language code at the time of the test run: "en-US" "ja-JP" "zh-CN" "th" If not specified, a Web scenario is generated in a language code that differs from the language code at the time of the test. Originally, a successful Web scenario may fail.	None
  --proxy-server proxies	Specify the proxy server. <Example of specification> "http://myproxy:3128" "socks5://myproxy:8080"	Y	Specifies the proxy used for the request. Specify the entire domain with up to 253 alphanumeric characters.	None
  --proxy-bypass Bypass proiesy	Specifies a comma-separated domain of proxies to bypass. <Example of specification> ".com,chromium.org,.domain.com"	Y	Specifies the domain for proxy bypass, up to 253 alphanumeric characters.	None
  URL	Specify URL to be monitored.	Y	Specify the entire domain with up to 253 alphanumeric characters. Specify URL in the following format: Protocol://Hostname:port-number	None

Legend:

REQ: Required setting, Y: Changeable, --: Not applicable

■Recording screen operations

When recording operations such as mouse clicking, text entry, and HTML operations, perform the operations you want to record in the browser window while recording is already started. As you work, a Web scenario code is generated on Playwright Inspector window.

The following tables show the browser operations and operations that can be recorded and measured as Web scenarios.

Table 3‒38: Operation and operation of browsers that can be recorded and measured as Web scenario

Classification		Operation	Record	Remarks	Sample Codes Recorded by codegen
Mouse operation	--	--	--	The mouse operation itself is not recorded, but it is recorded as button operation, etc. caused by mouse operation.	--
	Click	Y	Y	--	await page.getByRole('button', { name: 'Login' }).click();
	Double click	Y	Y	--	await page.getByRole('button', { name: 'Clear' }).dblclick();
	Sub button click	Y	Y	--	await page.locator('body').click({ button: 'right' });
Keyboard operation (key entry operation)	--	--	--	--	--
	Entering Characters	Y	Y	The value being input is reflected in real time. The entered value is recorded as a HTML action, etc.	await page.locator('input[name="username"]').fill('username');
	Shortcut key input	--	--	This is the same as browser operation.	This is the same as browser operation.
	Accelerate key input	--	--
	Other key input	--	--
Browser operations	--	--	--	--	--
	Move next item [Tab]	Y	Y	Only recorded if an element in HTML is selected.	await page.locator('body').press('Tab');
	Move previous item [Shift]+[Tab]	Y	Y		await page.locator('body').press('Shift+Tab');
	Go to next page [Alt]+[→]	Y	Y	Keyboard actions are disabled. Page transitions are recorded.	await page.goto('URL');
	Go to previous page [Alt]+[←] [BackSpace]	Y	Y
	Context menu display [Right-click] [Shift]+[F10]	Y	Y	--	await page.locator('body').press('Shift+F10');
	Scroll up [↑]	Y	Y	--	await page.locator('body').press('ArrowUp');
	Scroll down [↓]	Y	Y	--	await page.locator('body').press('ArrowDown');
	Page Up Scroll [PgUp]	Y	Y	--	await page.locator('body').press('PageUp');
	Page Down Scroll [PgDn]	Y	Y	--	await page.locator('body').press('PageDown');
	Go to top of page [Home]	Y	Y	--	await page.locator('body').press('Home');
	Go to End of Page [End]	Y	Y	--	await page.locator('body').press('End');
	Stop operation [Esc]	Y	Y	--	await page.locator('body').press('Escape');
	Link-click [Enter] [Click]	Y	Y	This is the same as HTML linking operation. Page transitions are recorded.	This is the same as HTML linking operation.
	Multiple selection operation [Ctrl] +[click]	Y	Y	--	await page.getByRole('listbox').selectOption(['apple', 'banana', 'orange']);
	Cut [Ctrl]+[X]	Y	Y	--	await page.locator('body').press('Control+x');
	Copy [Ctrl]+[C]	Y	Y	--	await page.locator('body').press('Control+c');
	Paste [Ctrl]+[V]	Y	Y	--	await page.locator('body').press('Control+v');
	Select All [Ctrl]+[A]	Y	Y	--	await page.locator('body').press('Control+a');
Dialog operation	--	--	--	The operation itself may not be recorded, but page transitions are recorded.	await page.goto('URL');
	Text input	Y	#1	--	--
	Key operation	Y	#1	--	--
	Other input items	Y	#1	--	--
HTML operation	--	--	--	Records operations related to input operations and page transitions.	--
	Link operation	Y	Y	--	--
	INPUT TEXT handling (text-entry)	Y	Y	--	await page.getByLabel('Name (4 to 8 characters):').fill('test');
	INPUT PASSWORD (password-entry)	Y	Y	--	await page.getByLabel('password (8 characters or more):').fill('pwdtest1');
	INPUT CHECKBOX	Y	Y	--	await page.getByRole('checkbox').check();
	INPUT RADIO	Y	Y	--	await page.getByLabel(''apple').check();
	INPUT SUBMIT	Y	Y	--	await page.getByRole('button', { name: 'Send' }).click();
	INPUT RESET	Y	Y	--	await page.getByRole('button', { name: 'Reset Form' }).click();
	INPUT BUTTON	Y	Y	--	await page.getByRole('button', { name: 'test' }).click();
Script operation	--	--	--	Scripts without page transitions, HTML operations, or button operations are not recorded, but page transitions, HTML operations, and button operations that are caused by script operations are recorded. #2	--
	Page transition operation	Y	Y	Actions implemented inside the script may not be recorded, but page transitions are recorded.	--

Legend

Operation field Y: Can be operated --: Not applicable

Recording field Y: Recording object --: Not applicable

Other than the above --: Not applicable

#1

The data is recorded based on the values entered in the dialog or the operation results by pressing the button. However, some dialogs may not be recorded correctly. Be sure to run it after creating Web scenario to see if it runs correctly.

Dialogs that do not run correctly in Web scenario, such as stopping while dialogs are open, cannot be handled.

#2

Depending on the page-transitions, HTML and button-operation timings caused by scripting, recording may not be possible.

Be sure to run it after creating Web scenario to see if it runs correctly.

Operations or behaviors not described in the above tables cannot be recorded and measured as Web scenarios.

Note that dialogue authentication (other than user ID and passwords) and ActiveX in-control are not supported. Also, ftp is not supported.

■Record of assertion

Assertion is an operation that checks whether the elements displayed on Web website match the expected content. When you run Codegen to create a Web scenario, clicking on an element displayed in the browser window and adding an assert to Web scenario determines whether the element displayed on the browser window when Web scenario is run matches the element displayed on the browser window when Codegen is run.

The following types of assertions are available:

• assert visibility

  Assert that the element exists.

• assert text

  Asserts that the element contains certain text.

• assert value

  Asserts that an element has a specific value.

If you want to add an assertion to a Web scenario, click one of the buttons on assert visibility,assert text,assert value and select the element to be asserted in the browser window. An assertion is generated for the selected element in Playwright Inspector window.

■Pausing Recording

If you want to pause recording, press Record. Clicking Record button again resumes recording.

■Saving the generated Web scenario code

When you exit Web scenario creation function, the generated Web scenario is saved in Web scenario file specified in the command-line options at the beginning of Web scenario creation function.

■Exiting Codegen

To exit Web scenario creation function, press the Ctrl+C keys in the terminal where playwright codegen command was executed to exit, or close the browser window that was opened when Web scenario creation function was started.

■Codegen Window Structure

When you use playwright codegen command to execute Web scenario creation function, the following window is displayed.

• Browser window

  Web site where you want to run the scenarios is displayed. Records clicks and typing actions by navigating Web pages.

  The following tables show the buttons and operations that are used to record Web page operations. For details, see Playwright documentation.

  Item number	Button	How to operate
  1	--	Drag this button to move the tab.
  2	Record	Click this button to stop or resume recording.
  3	assert visibility	Click this button, and then select the element that you want to assert that the element is visible. Click this button again to return to normal operation recording.
  4	assert text	Click this button, then select the element for which you want to assert that the element contains specific text. Click this button again to return to normal operation recording.
  5	assert value	Click this button, then select the element for which you want to assert that the element has a specific value. Click this button again to return to normal operation recording.

• Playwright Inspector window

  Allows you to record Web scenarios.

  The following buttons and procedures are used to record Web scenarios: For details, see Playwright documentation.

  Item number	Button	How to operate
  1	Record	Same as Browser window.
  2	assert visibility	Same as Browser window.
  3	assert text
  4	assert value

■Notes

1. Web scenario created by Web scenario creation function cannot be used to determine the status code of HTTP. Therefore, if "404 Not Found" or "500 Internal server error" is returned, it may be determined that Web entry was successful.

2. When using Web scenario creation function to verify that Web page transitions, you will not be able to detect successful or unsuccessful page transitions when using the following Web scenario:

   <Example of operation to check>

   On integrated operation viewer login page (URL:'http://hostname:20703/login'), enter your registered username and password to verify that you can successfully log in.

   <Some coding that Codegen writes to Web scenarios>

   test('test', async ({ page }) => {
     await page.goto('http://hostname:20703/login');
     await page.locator('input[name="username"]').fill('username');
     await page.locator('input[name="password"]').fill('password');
     await page.getByRole('button', { name: 'Login'}).click();
   });

   When the above Web scenario is played back, the operation to click Login button is played, and playback is terminated regardless of whether or not the screen is displayed after logging in. Therefore, page transitions cannot be detected as successful or unsuccessful.

   The following are the actions to be taken to verify a successful page transition:

   Use assertion of Codegen to add an action that asserts that the page displays its own elements after the page transition.

   For details on how to record assertions, see ■Record of assertion.

   Here is an example of a Web scenario with the above example modified:

   <Some coding that Codegen writes to Web scenarios>
   test('test', async ({ page }) => {
     await page.goto('http://hostname:20703/login');
     await page.locator('input[name="username"]').fill('username');
     await page.locator('input[name="password"]').fill('password');
     await page.getByRole('button', { name: 'Login' }).click();
     await expect(page.getByRole('button', { name: Logout' })).toBeVisible();
   });

   In the example of the modified Web scenario above, we added an action to assert that the page that transitions after the login process shows Logout button that should be displayed on that page. If the assertion of Logout button fails, it can detect that the page transitions after logging in failed.

3. When URL transitions are recorded in Codegen, if a transfer (redirection^#) is made to another new URL when accessed in the specified URL, URL transition to the redirection source is not recorded, only URL transition to the redirection destination may be recorded.

   If Codegen records actions that are redirected to a different URL by a server of the specified URL, the monitoring scope cannot include redirection from the redirection source to the destination.

   #

   Refers to the redirection performed by HTTP protocol using HTTP status code (in the 300 range) and Location header field.

   The following example shows where URL transitions to the redirection source are not recorded, but only URL transitions to the redirection destination are recorded.

   • When servers redirect from URL to new URL due to, for example, the transfer of a monitored site

   • When a forward slash (/) is missing at the end of URL specified in Codegen and the servers automatically add the forward slash and redirect it to the correct URL.

   Note that redirects that do not involve the following HTTP protocols do not fall under this precaution, and URL transitions of the redirection source and the redirection destination are recorded.

   • HTML redirection using the <meta> element of HTML

   • JavaScript redirection executed due to the URL string of the window.location property set by a client script such as JavaScript

■ Web operation information collection function (Web exporter)

Web operation information collection function (Web exporter) executes the scenario for Web scenario file created beforehand using Prometheus server's scrape request as the trigger, and returns the execution result as scrape result. Detailed motion at the time of scenario execution is output as a trace and can be viewed by the user using the trace viewer function.

■Acquisition items

The metrics that can be retrieved with Web exporter (Web operation information collection function are probe_webscena_success (Displays whether the probe was successful^#1) and probe_webscena_duration_seconds (The seconds taken by the web scenario probe^#2).

#1

Signifies the success or failure of the entire collection, including preparation for collection (such as process startup).

#2

If the collection fails, metric may not be retrieved.

Web exporter retrieval items are defined in metric definition file (metrics_web_exporter.conf) of Web exporter. For details, see Web exporter Metric Definition File (metrics_web_exporter.conf) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

■Monitoring when a monitoring target is temporarily stopped

To suppress error detection during a power failure or maintenance, you must stop collecting activity information for the target.

The collection of operational information can be stopped by deleting the applicable monitoring target in targets of Web exporter discovery configuration file (jpc_file_sd_config_web.yml). For details, see Web exporter discovery configuration file (jpc_file_sd_config_web.yml) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

■ Web scenario execution function

Use playwright to perform Web scenario execution functions.

Playwright exporter configuration file specifies the parameters for Web scenario execution function.

For Playwright configuration file, see Playwright configuration file (jpc_playwright.config.ts) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

■Trace

Web scenario execution function outputs the trace during Web scenario execution to a trace file in the following Web exporter: Web scenario file displays the results of the actions performed and HTTP communication traces.

• For physical hosts

  Agent-path\logs\web_exporter\trace\Web-scenario-filename-test-project-name-number-of-retries_generation-number\trace.zip

• For logical hosts

  shared-folder\jp1ima\logs\web_exporter\trace\Web-scenario-filename-test-project-name-number-of-retries_generation-number\trace.zip

Web-scenario-filename

If Web scenario filename ends with ".spec.ts", the text without ".spec.ts" is stored.

project-name

The character string specified in name parameter of Playwright configuration file is set.

Spaces, control characters, and the following characters are converted to a hyphen (-).

! " # $ % & ' ( ) * + , . / : ; < = > ? @ [ \ ] ^ _ { | } ~

number-of-retries

Used if retries parameter of Playwright configuration file is 1 or more. retry1, retry2, retry3, ... is set according to the number of retries when Web scenario execution failed.

The "- number-of-retries" part is granted only when retrying. Therefore, it is not granted to the first-run tracing of Web scenarios per scrape.

generation-number

The 4-digit number is set.

For the number of generations of traces to be saved, see tracenum in Web exporter configuration file (jpc_web_exporter.yml) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

The file size of the trace is a few MB (it varies greatly depending on the content of the monitored content). For Web scenarios where you log in to and log off from Intelligent Integrated Management Base, it is approximately 2MB per scenario. If 2000 generations and 0 retries are retained every 6 minutes (defaults), approximately 4GB of disc space is required.

■Trace Viewer

Web exporter trace file can be referenced in the trace viewer.

The trace viewer is used to investigate the details when an error is detected.

For details about the trace viewer, see 3.15.1(1)(n) Trace Viewer Function (playwright show-trace).

■ Monitoring with Other Monitoring Function

Web scenario monitor function allows you to monitor Web contents from the user's point of view, but does not allow detailed monitoring of HTTP communication (name resolution times or certificate expiration time) or monitoring inside the monitoring target. Therefore, if an error occurs, you cannot investigate the cause of the error using only metric information acquired by Web scenario monitoring function.

For example, you need to monitor HTTP communication using Blackbox exporter outline monitoring and monitor the inside of the monitored side (HTTP servers and DB servers) using log trapper of Fluentd.

■ Handling of Public Key Infrastructure (PKI: Public Key Infrastructure) Certificates Used in TLS Communication

If the monitoring target is a HTTPS server, register the certificate below in OS (for Windows, register it in the certificate store).

• CA certificate of authentication authority that issued the server certificate

• Client certificate (if HTTPS server requires a client certificate during TLS handshake) and private key

For details about how to register with OS, see the documentation for your OS.

■ Understanding Web Scenarios for HTTP authentication with Passwords

If the monitored Web contents require HTTP authentication with a username and password (such as Basic authentication), enter the username and password in URL fields of Web scenario creation function as follows:

http://username:password@domain-name:port/Web-content-path

■ Handling passwords

HTTP authentication and Web contents the passwords that you use in your own authentication (if you are prompting for a username and password on the form) are stored in Web exporter configuration file, Web scenario file, and the trace file. When providing the information for failure investigation to the requester, the user should perform masking such as replacing the password part with a different character string to prevent leakage.

■ Configuring HTTP Proxies

To set up a HTTP proxy server to communicate from JP1/IM - Agent host to the monitoring target, set "proxy" in Playwright configuration file (jpc_playwright.config.ts) item.

For details about Playwright configuration file, see Playwright configuration file (jpc_playwright.config.ts) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

For details on configuration file editing procedure, see To edit the configuration files (for Windows) in 1.19.3(1)(a) Common way to setup in the JP1/Integrated Management 3 - Manager Configuration Guide.

■ About Reviewing Web scenarios

Web scenario monitoring function does not provide the ability to independently test Web scenario. Actually monitor Web scenarios. Make sure that the monitoring is successful. Refer to metric of the probe_webscena_success to determine whether it is normal.

■ Timeout Settings and User Tasks When Timeout Occurs

Web scenario creation support function suspends the collection of too-long activity information (collection of Web scenario execution times) due to timeouts.

The following parameters relate to timeouts:

#1

For details about Prometheus configuration file parameters, see Prometheus configuration file (jpc_prometheus_server.yml) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

#2

For details about the options of the web_exporter command, see Service definition file (jpc_program-name_service.xml) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

The timeout setting is always applied, and the collection is interrupted when the timeout period is exceeded. As a result, the collection does not continue indefinitely without interruption.

The timeout period is --timeout-offset(0.5 seconds) subtracted from the scrape_timeout time.

This timeout time must include the execution time of the processing required to collect the activity information. Collection of operational information includes manipulation of Web contents (browser operations) according to Web scenarios.

In practice, it is recommended that you set a timeout of 30 seconds more than it would take to run the actual Web scenario. This is because there is a startup process for browsers and other processes.

If processing is aborted due to a timeout, one or more of the following messages is output to the log. At this time, the probe_webscena_success metric may be 0 (failed) or the metric may not be sent. Check the following log file to see if the processing was aborted by a timeout.

Even if the timeout occurred, the child process that started is terminated, so the user does not need to terminate it.

■ Notes

• The following monitoring cannot be performed using Web scenario monitoring function:

  • Monitoring Web contents that do not support JP1/IM - Agent supported browsers

  • Monitoring Web contents that behave differently than when creating Web scenarios

  • Monitoring HTTP status codes

  • Monitoring Web sites using external authentication providers for authentication

• If a timeout occurs during the collection of operational information, the browser process may remain unfinished. In this case, the user must stop the applicable process. For details, see ■Timeout Settings and User Tasks When Timeout Occurs.

■ Prerequisites

It is a prerequisite that the ports used by VMware exporter are protected by firewalls, networking configurations, and so on, so that they are not accessed by anything other than Prometheus server of JP1/IM - Agent.

For the port used by VMware exporter, see vmware_exporter command options in Service definition file (jpc_program-name_service.xml) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

■ Conditions to be monitored

• VMware vCenterServer are not monitored.

• VMware exporter target is VMware ESXi. For details about the supported VMware ESXi versions, see the Release Notes.

• The name of the datastore^# managed by VMware ESXi must be the same as the host name. If the datastore name and host name are different, separate nodes are created for the datastore and the hypervisor, and the available metrics are separated.

  When nodes are divided into datastores and hypervisors, the metrics that can be retrieved for each node are as follows.

  • Data store

    vmware_host_size, vmware_host_used, vmware_host_free, vmware_datastore_used_percent

  • Hypervisor

    Metrics for hosts, except: vmware_host_size, vmware_host_used, vmware_host_free, vmware_datastore_used_percent

  For details about each metric and its description, see VMware exporter metric definition file for host (metrics_vmware_exporter_host.conf) and VMware exporter metric definition file for VM (metrics_vmware_exporter_vm.conf) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

  #: If there is more than one data store, use "host-name_any-string".

• Do not use duplicate VM names that are managed by VMware ESXi. If VM names are duplicated, the same node will be displayed with more than one monitor result. Therefore, be sure to set VM name to a unique name.

■ Acquisition items

VMware exporter shipped with JP1/IM - Agent has metric that is defined by VMware exporter defaults.

VMware exporter retrieval items are defined in metric definition file for host and metric definition file for VM of VMware exporter. For details, see VMware exporter metric definition file for host (metrics_vmware_exporter_host.conf) and VMware exporter metric definition File for VM (metrics_vmware_exporter_vm.conf) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.

Metric are obtained using OSS's pyVmomi and VMware's officially provided vRealize Operations of metric. Metric of vRealize Operations used by metric are listed in the following tables.