Skip to main content

Analyzing the transactions

Hitmap​

Home > Select Project > Analysis > Hitmap

On the initial screen of the WhaTap Monitoring service, select a project and then click Analysis > Hitmap.

Note

Hitmap can be also accessed through the Hitmap widget in Dashboard > Application Dashboard.

Detailed analysis​

Hitmap

number1 agent area​

You can filter by selecting agents linked with the current project. If you select the Icon icon, the HITMAP transaction chart can be viewed in the number2 area.

number2 HITMAP transaction​

If transactions with latency issues are included, they appear in orange or red on the HITMAP transaction chart. If only normal transactions are included, they appear in blue.

number3 Selection area​

If you drag the real-time hitmap chart, the number5 TX trace list appears where number4 Applications list and transaction information can be viewed in the selected area.

number4 Applications​

You can check the numbers of transactions and errors included in the selected area on the chart. If you select the desired application in the list, the information details of the application appear in number5 TX trace.

number5 TX trace​

The TX trace list contains information details. If you select a desired transaction from the list, the Transaction information window appears. In the Transaction information window, you can see the detailed trace details for the transaction. For more information, see the following.

Understanding the hitmap patterns​

The hitmap is a distribution chart whose X-axis is the transaction end time, and Y-axis is the response time. A normal web application displays a distribution concentrated in a few seconds or less.

hitmap-pattern

Analyzing the hitmap lines​

  • Vertical line (LOCK symptom) pattern

    If a temporary lock (not only DB lock) occurs during transaction processing, the processing is queued. If the lock is released, pending transactions are finished together at a similar time. This creates vertical lines as follows:

    hitmap-lock

    Detecting locks in vertical line patterns is a very powerful concept. Especially in the microservice architecture, locks from backend systems can be equally detected.

    hitmap-front-api-db

    The vertical lines for response patterns in the front applications are also detected when any lock occurs in the DB used by the back-end system.

  • Horizontal line (timeout) pattern

    In the 10-second timeout condition, if the resources are insufficient, the transactions wait for 10 seconds until a timeout error occurs. At this time, horizontal lines appear near 10 seconds of the hitmap as follows:

    hitmap-timeout

    If there is a logic to retry after timeout, the horizontal lines repeat every 10 seconds as shown in the figure. The following is the hitmap for failures.

    hitmap-error

    (1) The response time increased in the section and (2) the red lines in the section are horizontal line patterns. (1) ConnectionPool is exhausted due to section load, (2) the secondary timeout failure occurred due to insufficient ConnectionPool.

Using the pattern analysis​

A line in the transaction response distribution indicates a bottleneck. If the lock is temporary, a vertical line is generated. If the bottleneck is release by timeout, a horizontal line is generated.

hitmap-pattern-analysis

When analyzing a problem, you can quickly pinpoint a transaction included in the line for selective analysis.

Analyzing the machine learning based response patterns​

This function automatically detects abnormalities after analyzing the hitmap patterns with an aid of machine learning technology and then issues an alert.

Machine learning analytics

Abnormal pattern example​

It learns abnormal patterns from hundreds of TB of performance data every month and issues an alarm when a pattern similar to the learned abnormal one is detected.

  • Vertical line pattern

    hitmap-abnormal1

  • Horizontal line pattern

    hitmap-abnormal2

  • Composite pattern

    hitmap-abnormal3

  • Hitmap alarm

    hitmap ai alert

Note

For more information about the analysis method of the HITMAP transaction chart, see the following.

Exception handling (WARNING) criteria​

The criteria for Node.js agent exception handling for errors that occur in the Node.js application environment are explained. The Node.js agent handles errors only in the following cases:

  • Status Code 400 or higher error handling

  • Error handling for HTTP calls

  • Handling the errors defined in WhaTap

Error display on the service screen​

hitmap, Trace analysis

Most Error level that can be seen throuth the Hitmap widget and Trace analysis window are for the WARNING level.

Status Code 400 or higher error handling​

If the HTTP response code is 400 or more, it is treated as an error even if no exception class occurs. The following is the agent option that sets whether or not to enable error handling based on the HTTP status code.

whatap.conf
transaction_status_error_enable=true
Note

For more information about the transaction_status_error_enable option, see the following.

Error handling for HTTP calls​

The errors that occur during HTTP calls appear in the SLOW_HTTPC or httpc error format.

Handling the errors defined in WhaTap​

The WhaTap monitoring service handles errors depending on specific conditions.

  • TOO_MANY_RECORDS: The number of fetches is 10,000 or more.

    For the related agent options, see the following: profile_error_sql_fetch_max=10000

  • SLOW_SQL: SQL time is 30,000 ms or more.

    For the related agent options, see the following document: profile_error_sql_time_max=30000

  • SLOW_HTTPC: The elapsed time for the HTTP call is 10,000 ms or more.

    For the related agent options, see the following document: profile_error_httpc_time_max=10000

  • httpc error: HTTP call status code of 400 or more

    Note

    httpc error is automatically collected without agent configuration.

  • status error: Transaction status code of 400 or more

    For the related agent options, see the following document: transaction_status_error_enable=true

Transaction error step INFO processing​

Some errors can be displayed as normal or ignored through the agent settings. The level displayed in the Hitmap widget is INFO (blue).

If the following conditions are met, they are not treated as errors.

  • In case the value of the transaction_status_error_enable option is false

    whatap.conf
    # default true
    transaction_status_error_enable=false

  • In case the status code of the transaction is defined in the status_ignore option

    whatap.conf
    # Separated by commas(,)
    status_ignore=400,404,500

  • In case the URL and status code are combined for a specific transaction defined in the status_ignore_set option

    whatap.conf
    # URL:StatusCode
    status_ignore_set=/api/posts/test/timeout:200,/error:500

  • In case the HTTP status code is defined in the httpc_status_ignore option

    whatap.conf
    # Separated by commas(,)
    httpc_status_ignore=400,404,500

  • In case the URL and HTTP status code are combined for the httpc_status_ignore_set option

    whatap.conf
    httpc_status_ignore_set=/api/posts/test/timeout:408,/api/apache/httpclient/posts/timeout:500
Note