Access Troubleshooting Logs for Scale Out/In | Teradata VantageCloud Enterprise on Azure (DIY) - Accessing Troubleshooting Logs for Scale Out/In - Teradata® VantageCloud Enterprise on Azure

VantageCloud Enterprise on Azure (DIY) Installation and Administration Guide - 3.2.0.0

Deployment
VantageCloud
Edition
Enterprise
Product
Teradata® VantageCloud Enterprise on Azure
Release Number
3.2.0.0
Published
March 2026
ft:locale
en-US
ft:lastEdition
2026-04-07
dita:mapPath
cvo1751050001343.ditamap
dita:ditavalPath
kou1751058502043.ditaval
dita:id
eqk1475705518038
Product Category
Cloud
PrerequisiteIf your role is not Owner or Administrator, see your company's Azure administrator to create a lock.
Since licensing information is logged in the Azure diagnostic storage account (diag), we strongly recommend creating and setting the lock level on this account as CanNotDelete to prevent diagnostic logs from being deleted. A CanNotDelete lock level means users can only read and modify (but not delete) a resource.

To view the status of scaling out and scaling in, access the following logs:

Log Type Action
Standard log file
  1. From inside the VM, switch to the root user environment.
    # sudo su -
  2. Access the standard log file1.
    # /var/log/Reconfig/tdc-reconfig.log
Diagnostic logs
  1. From the Azure console, go to the diagnostic storage account that starts with diag.
  2. Look for Blobs > teradata > FUF and access tdc_reconfig_timestamp.log to get the log of any operation.

A separate log is created each time you scale out or scale in.

1Each time you run the standard log file, the system saves the latest operation to /var/log/Reconfig/tdc-reconfig.log and renames the current log file to /var/log/Reconfig/tdc-reconfig.log.operation_number, where operation_number indicates how many operations were performed to the file.
For example:
  • On the first run, the system saves the latest operation to .log.
  • On the second run, the system renames .log to .log.1 and saves the latest operation to a new .log file.
  • On the third run, the system renames .log to .log.1, renames .log.1 to .log.2, and saves the latest operation to a new .log file.