Use session logs for traffic tracing to help you quickly locate and troubleshoot issues - NAT Gateway

To quickly locate and resolve business issues, enable the session log feature. You can then view log content at any time for troubleshooting.

Example

A company uses an Internet NAT Gateway to provide unified Internet access for its ECS instances. To quickly identify the cause of any business issues, the company enables the session log feature during the initial deployment.

An employee reports that they cannot access a third-party service website (http://47.XX.XX.157). However, they can access the website using a newly purchased EIP. The company contacts the service provider and learns that the provider's security department detected an abnormal traffic surge from the EIP 47.XX.XX.85 at approximately 15:00 on February 5, 2025, causing a service interruption. To maintain service stability, the provider's security department has added the EIP to a blacklist.

To find the root cause, the company's operations team analyzes the session logs and identifies the ECS instance that caused the traffic surge.

Billing

The session log feature itself is free. However, session logs are stored in Simple Log Service projects, which are billed separately. For pricing details, see Billing of Simple Log Service.

Limitations

Session log is not supported for pay-by-specification NAT gateways (no longer available for purchase).
Session log captures only SNAT sessions — DNAT sessions are not recorded.

Procedure

Step 1: Enable the session log feature

Important

After enabling the session log feature, create indexes and set the log retention period to make sure data is queryable and retained as needed.

Log on to the NAT Gateway console. Find the NAT gateway and click its ID.
On the Monitoring and Logging tab, choose Session Log > Enable Session Log. In the dialog, select an existing Simple Log Service project and Logstore.
On the Monitoring and Logging tab, click the name in the Destination Information column to verify that session logs are being recorded.

Step 2: Analyze log content

Based on the time of the incident provided by the service provider, run the following SQL query to calculate the total traffic from your ECS instances to the service per minute, within a five-minute window around 15:00 on February 5, 2025.
```
select 
    sum(bytes_from_vpc) as total_bytes, /* The core field for issue analysis. */
    date_trunc('minute', __time__) as ts_min /* Group statistics by minute. */
from 
    log 
where 
    pub_ip = '47.XX.XX.157' /* Filter by the destination IP address. */
group by 
    ts_min 
```
After you run the query, click the Chart tab. In the Properties panel on the right, select the line chart type. Set the x-axis to ts_min and the y-axis to total_bytes. The line chart shows that the traffic peaked at 14:57:00 (approximately 8,699,300 bytes) and then gradually decreased.
The query results confirm that the traffic to the service peaked at 14:57. Run the following query to identify the specific ECS instance that caused the issue.
```
select 
    pri_ip, 
    sum(bytes_from_vpc) as total_bytes, /* The core field for issue analysis. */
    date_trunc('minute', __time__) as ts_min /* Group statistics by minute. */
from 
    log 
where 
    pub_ip = '47.XX.XX.157' /* Filter by the destination IP address. */
group by 
    ts_min, pri_ip 
```
Note
If the data volume is large, you can convert the traffic to gigabytes (GB) for readability.
sum(bytes_from_vpc) / 1024 / 1024 / 1024 as total_GB
After you run the query, click the Chart tab and select the Bar Chart type. In the Properties panel on the right, set the x-axis to ts_min, the y-axis to total_bytes, and the series to pri_ip. The chart shows that the traffic from the private IP 172.16.10.13 (approximately 7,109,409 bytes) is significantly higher than that from 172.16.10.15 (735,768 bytes) and 172.16.10.14 (728,288 bytes). This indicates that the ECS instance with this private IP caused the issue.

NAT Gateway:Trace traffic with session logs