Set up the agent for Microsoft SQL Server workloads

This document shows how to install Agent for Compute Workloads on Compute Engine instances, and configure the agent to connect with a Microsoft SQL Server workload running on those compute instances.

After you install and configure the agent, it collects metrics from your SQL Server workload and the underlying compute instances and sends them to Workload Manager. You can then use Workload Manager evaluation to scan your SQL Server workloads for deviations from best practices for infrastructure, operating system, and workload configurations.

Before you begin

Before you install and configure Agent for Compute Workloads, you need to make sure that the following prerequisites are met:

• You've deployed a SQL Server workload on one or more compute instances.
• You've granted the required IAM roles for the agent.
• You've enabled access to Cloud APIs.
• You've granted the required permissions on SQL Server.

Required IAM roles for the agent

Agent for Compute Workloads uses the service account attached to the compute instance for authentication and to access Google Cloud resources.

To improve security, we recommend that you use a single-purpose service account rather than using the Compute Engine default service account.

To ensure that the service account has the necessary permissions to let Agent for Compute Workloads authenticate with Google Cloud and access Google Cloud resources, ask your administrator to grant the service account the following IAM roles on your project:

Important: You must grant these roles to the service account, not to your user account. Failure to grant the roles to the correct principal might result in permission errors.

• Compute Viewer (roles/compute.viewer): to collect metrics from the compute instance.
• Workload Manager Insights Writer (roles/workloadmanager.insightWriter): to write data to Workload Manager data warehouse.
• (Recommended) Logs Writer (roles/logging.logWriter): to send agent logs to Cloud Logging.
• (Optional) Secret Manager Secret Accessor (roles/secretmanager.secretAccessor): if you are using Secret Manager to store the password to connect with the SQL Server instance.

For more information about granting roles, see Manage access to projects, folders, and organizations.

Your administrator might also be able to give the service account the required permissions through custom roles or other predefined roles.

Enable access to Cloud APIs

Compute Engine recommends configuring your instances to allow all access scopes to all Cloud APIs and using only the IAM permissions of the instance service account to control access to Google Cloud resources. For more information, see Create a VM that uses a user-managed service account.

If you limit access to the Cloud APIs, then the Agent for Compute Workloads requires at minimum the following Cloud APIs access scopes on the host compute instance:

https://www.googleapis.com/auth/cloud-platform

For more information, see Scopes best practice.

If you're running SQL Server applications on a compute instance that doesn't have an external IP address, then you need to enable Private Google Access on the instance's subnet so that Agent for Compute Workloads can access the Google APIs and services. For information about how to enable Private Google Access, see Configure Private Google Access.

Required permissions on SQL Server

Use the following script to assign required permissions to the user account configured in the agent.

    USE [master]
    GO 

    GRANT VIEW SERVER STATE TO [user_name]
    GRANT VIEW ANY DEFINITION TO [user_name] 

    -- Adds db_datareader role to the user
    EXEC sp_MSForEachDB
    '
    USE ?
    IF NOT EXISTS(SELECT * FROM sys.database_principals WHERE name = ''user_name'')
    BEGIN
      CREATE USER [user_name] FOR LOGIN [user_name]
    END
    EXEC sp_addrolemember ''db_datareader'', ''user_name''
    '
  

Install and configure the agent by using package manager

Note: If the legacy Agent for SQL Server is already installed on the VM, during the installation process, then Agent for Compute Workloads automatically migrates the agent configuration file to the new location and deletes Agent for SQL Server from the VM.

This section shows you how to install the Agent for Compute Workloads on your compute instance, and configure it to connect with a SQL Server instance, by using a package manager.

To install the Agent for Compute Workloads, complete the following steps:

Windows

On Windows, you install Agent for Compute Workloads by using the googet package management command. This command completes the following tasks:

• Downloads the latest version of the agent.
• Creates a Windows service named google-cloud-workload-agent.
• Creates a scheduled task that runs every minute to check if the service is running and if necessary, restart the service.

Warning: Don't stop the google-cloud-workload-agent Windows service manually or delete its scheduled task.

To install and configure Agent for Compute Workloads on a Windows based compute instance, complete the following steps:

1. Establish a connection with your compute instance by using RDP.

   For information about how to do this, see Connect to Windows VMs using RDP.

2. As an administrator, run the following commands from PowerShell:

   googet addrepo google-cloud-workload-agent  https://packages.cloud.google.com/yuck/repos/google-cloud-workload-agent-windows-x86_64
   googet install google-cloud-workload-agent
   

3. Open the agent's configuration file:

   %ProgramFiles%\Google\google-cloud-workload-agent\conf\configuration.json
   

4. Specify values for all mandatory parameters, as described in Configuration parameters.

5. Save the configuration file

6. Restart the agent for the changes to take effect.

RHEL

On Red Hat Enterprise Linux (RHEL), you install Agent for Compute Workloads by using the yum package management command. This command completes the following tasks:

• Downloads the latest version of the agent.
• Creates a systemd service for the agent, named google-cloud-workload-agent.
• Enables and starts the google-cloud-workload-agent service.

To install and configure Agent for Compute Workloads on a RHEL based compute instance, complete the following steps:

1. Establish an SSH connection with your compute instance.

2. In your terminal, install the agent:

   sudo tee /etc/yum.repos.d/google-cloud-workload-agent.repo << EOM
   [google-cloud-workload-agent]
   name=Google Cloud Agent for Compute Workloads
   baseurl=https://packages.cloud.google.com/yum/repos/google-cloud-workload-agent-$basearch
   enabled=1
   gpgcheck=0
   repo_gpgcheck=1
   gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
   EOM
   sudo yum install google-cloud-workload-agent
   

3. Open the agent's configuration file:

   /etc/google-cloud-workload-agent/configuration.json
   

4. Specify values for all mandatory parameters, as described in Configuration parameters.

5. Save the configuration file

6. Restart the agent for the changes to take effect.

SLES

On SUSE Linux Enterprise Server (SLES), you install Agent for Compute Workloads by using the zypper package management command. This command completes the following tasks:

• Downloads the latest version of the agent.
• Creates a systemd service for the agent, named google-cloud-workload-agent.
• Enables and starts the google-cloud-workload-agent service.

To install and configure Agent for Compute Workloads on a SLES based compute instance, complete the following steps:

1. Establish an SSH connection with your compute instance.

2. In your terminal, install the agent:

   sudo zypper addrepo --refresh https://packages.cloud.google.com/yum/repos/google-cloud-workload-agent-$basearch
   google-cloud-workload-agent
   sudo zypper install google-cloud-workload-agent
   

3. Open the agent's configuration file:

   /etc/google-cloud-workload-agent/configuration.json
   

4. Specify values for all mandatory parameters, as described in Configuration parameters.

5. Save the configuration file

6. Restart the agent for the changes to take effect.

Debian

On Debian, you install Agent for Compute Workloads by using the apt package management command. This command completes the following tasks:

• Downloads the latest version of the agent.
• Creates a systemd service for the agent, named google-cloud-workload-agent.
• Enables and starts the google-cloud-workload-agent service.

To install and configure Agent for Compute Workloads on a Debian based compute instance, complete the following steps:

1. Establish an SSH connection with your compute instance.

2. In your terminal, install the agent:

   echo 'deb https://packages.cloud.google.com/apt google-cloud-workload-agent-x86-64-apt main' | sudo tee -a /etc/apt/sources.list.d/google-cloud-workload-agent.list
   sudo apt-get update
   sudo apt-get install google-cloud-workload-agent
   

3. Open the agent's configuration file:

   /etc/google-cloud-workload-agent/configuration.json
   

4. Specify values for all mandatory parameters, as described in Configuration parameters.

5. Save the configuration file

6. Restart the agent for the changes to take effect.

Install and manage the agent on a fleet of VMs by using VM Extension Manager

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

Set up VM Extension Manager

To set up VM Extension Manager, complete the following steps:

• In the VM Extension Manager documentation, review the Before you begin section.

• Set up the IAM roles needed to create and manage VM Extension Manager policies. For more information, see the following:

  • Create VM extension policies
  • Update VM extension policies
  • Delete VM extension policies
  • List and describe VM extension policies

Install the agent on a fleet of VMs

To install the latest version of Agent for Compute Workloads on your VM fleet within a specific zone by using a VM Extension Manager policy, complete the following steps:

Console

1. In the Google Cloud console, go to the VM extension policies page.

   Go to VM extension policies

2. Click Create extension policy.

3. In the Name field, enter a name for the policy.

4. Optional: In the Description field, enter a description for the policy.

5. In the Priority field, specify a priority number to resolve conflicts between policies. Lower numbers indicate higher priority. The default value is 1000.

6. Using the Region and Zone lists, select the zone where you want to apply this policy.

7. In the Extensions section, click Add extension and then do the following:

   1. From the Extension list, select Google Cloud's Extension for Compute Workloads.

   2. Leave the Version field blank.

      This directs the policy to install the latest version of Agent for Compute Workloads.

   3. In the Configuration file content field, enter the configuration that you want to apply to the agent.

      For information about the configuration parameters supported by the agent for your SQL Server workload, see Configuration parameters.

      Note: If you apply a VM Extension Manager policy to VMs on which the Agent for Compute Workloads is already running, then the policy overrides the existing agent's version and configuration with what you've set in the policy.

      The existing configuration of the agent is written to a BAK file in the /etc/google-cloud-workload-agent/ directory on the respective VMs.

   4. Click Done.

8. Optional: To limit the policy rollout to the required VMs, do the following:

   1. Click Add labels and include the labels that identify the required VMs.
   2. Click Done.

9. Click Create.

gcloud

gcloud beta compute zone-vm-extension-policies create POLICY_NAME \
    --zone=ZONE \
    --extensions=google-cloud-workload-extension \
    --config-from-file=google-cloud-workload-extension=CONFIG_FILE_PATH \
    [--description="DESCRIPTION" \]
    [--inclusion-labels=KEY_1=VALUE_1 \]
    [--inclusion-labels=KEY_2=VALUE_2,KEY_3=VALUE_3 \]
    [--priority=PRIORITY]

Replace the following:

• POLICY_NAME: a name for the VM extension policy.

  The command fails if a policy with the specified name already exists in the zone.

• ZONE: the zone where you want to apply this policy.

• CONFIG_FILE_PATH: the local path to the JSON file that contains the configuration for the Agent for Compute Workloads to connect with your SQL Server workload.

  • Alternatively, to provide configuration as an inline string, use the --config flag instead of --config-from-file. For example, --config=google-cloud-workload-extension="CONFIG". Google Cloud recommends that you use --config-from-file.
  • You can use either --config-from-file or --config, but not both in the same command.
  • For information about the configuration parameters supported by the agent for your SQL Server workload, see Configuration parameters.
  Note: If you apply a VM Extension Manager policy to VMs on which the Agent for Compute Workloads is already running, then the policy overrides the existing agent's version and configuration with what you've set in the policy.

  The existing configuration of the agent is written to a BAK file in the /etc/google-cloud-workload-agent/ directory on the respective VMs.

• DESCRIPTION: an optional description for the policy.

• KEY_1=VALUE_1: a comma-separated list of key-value pairs that define the labels using which the policy targets VMs.

  • For a VM to be targeted by your policy, the VM must have all the specified labels.
  • If you specify --inclusion-labels multiple times, then the policy targets VMs that match any of the provided selectors (logical OR). If you omit this flag, then the policy targets all VMs in the specified zone.

• PRIORITY: an integer from 0 to 65535 that defines the policy's priority. Lower numbers indicate higher priority. The default value is 1000.

Example:

The following command creates a policy named test-agent-policy in the Google Cloud project named test-project, which installs the latest version of Agent for Compute Workloads on all VMs deployed in the zone us-centrail-f. The configuration specified in the agent-config.json is applied to the agent.

gcloud beta compute zone-vm-extension-policies create test-agent-policy  \
    --project=test-project \
    --zone=us-central1-f \
    --extensions=google-cloud-workload-extension \
    --config-file-path=google-cloud-workload-extension="/usr/agent-config.json"

Verify agent installation

To verify that the agent is running as expected, complete the following steps:

Windows

1. Establish a connection with your compute instance by using RDP.

   For information about how to do this, see Connect to Windows VMs using RDP.

2. As an administrator, run the following command from PowerShell:

   $(Get-Service -Name 'google-cloud-workload-agent' -ErrorAction Ignore).Status
   

   If the agent is running as expected, then you see the status as Running.

RHEL

1. Establish an SSH connection with your compute instance.

2. Check the status of the agent package:

   systemctl status google-cloud-workload-agent
   

   If the agent package is running as expected, then the output contains active (running). For example:

   google-cloud-workload-agent.service - Google Cloud Agent for Compute Workloads
   Loaded: loaded (/usr/lib/systemd/system/google-cloud-workload-agent.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2025-07-30 18:59:12 UTC; 10s ago
   Main PID: 14412 (google_cloud_sq)
     Tasks: 7
   Memory: 12.9M (max: 1.0G limit: 1.0G available: 1011.0M)
   CGroup: /system.slice/google-cloud-workload-agent.service
           └─ 14412 /usr/bin/google_cloud_sql_server_agent --action=run

SLES

1. Establish an SSH connection with your compute instance.

2. Check the status of the agent package:

   systemctl status google-cloud-workload-agent
   

   If the agent package is running as expected, then the output contains active (running). For example:

   google-cloud-workload-agent.service - Google Cloud Agent for Compute Workloads
   Loaded: loaded (/usr/lib/systemd/system/google-cloud-workload-agent.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2025-07-30 18:59:12 UTC; 10s ago
   Main PID: 14412 (google_cloud_sq)
     Tasks: 7
   Memory: 12.9M (max: 1.0G limit: 1.0G available: 1011.0M)
   CGroup: /system.slice/google-cloud-workload-agent.service
           └─ 14412 /usr/bin/google_cloud_sql_server_agent --action=run

Debian

1. Establish an SSH connection with your compute instance.

2. Check the status of the agent package:

   systemctl status google-cloud-workload-agent
   

   If the agent package is running as expected, then the output contains active (running). For example:

   google-cloud-workload-agent.service - Google Cloud Agent for Compute Workloads
   Loaded: loaded (/usr/lib/systemd/system/google-cloud-workload-agent.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2025-07-30 18:59:12 UTC; 10s ago
   Main PID: 14412 (google_cloud_sq)
     Tasks: 7
   Memory: 12.9M (max: 1.0G limit: 1.0G available: 1011.0M)
   CGroup: /system.slice/google-cloud-workload-agent.service
           └─ 14412 /usr/bin/google_cloud_sql_server_agent --action=run

Configuration parameters

The following table describes the parameters for the agent's configuration file.

Parameters
log_level	String To set the logging level of the agent, set the required value. The available log levels are as follows: DEBUG INFO WARNING ERROR The default log level is INFO. Don't change the logging level unless you are directed by Cloud Customer Care.
log_to_cloud	Boolean To redirect the agent's logs to Cloud Logging, specify true. The default value is true.
agent_properties.log_usage_metrics	Boolean To enable logging of the agent's health metrics, set the value to true. The default value is false.
common_discovery.collection_frequency	Duration Specify the frequency, in seconds, at which the agent's workload discovery service runs. The default value is 10800s. Make sure that this parameter's value ends with a lowercase s.
sqlserver_configuration.enabled	Boolean To enable SQL Server metrics collections within the agent, set the value as true. Default is false. Note: For other SQL Server agent-specific configuration parameters to take effect, set sqlserver_configuration.enabled to true.
sqlserver_configuration.collection_configuration.collect_guest_os_metrics	Boolean To enable OS metrics collection, set the value as true. Default is true. Don't set sqlserver_configuration.collection_configuration.collect_guest_os_metrics to false unless you are directed by Cloud Customer Care.
sqlserver_configuration.collection_configuration.collect_sql_metrics	Boolean To enable SQL Server metrics collection, specify true. Default is true. Don't set sqlserver_configuration.collection_configuration.collect_sql_metrics to false unless you are directed by Cloud Customer Care.
sqlserver_configuration.collection_configuration.collection_frequency	Duration Agent for Compute Workloads metrics collection frequency, in seconds. Default is 3600s. You can update the collection frequency. However, we recommend keeping the default value.
sqlserver_configuration.credential_configurations[].connection_parameters[].host	String The SQL Server hostname.
sqlserver_configuration.credential_configurations[].connection_parameters[].username	String Specify the user account that is used to query the SQL Server instance. To configure account permissions, review the permissions required in the permission script and grant them according to your internal policies. Note: If you are using Windows Authentication, make sure to specify the username in the following format: domain-name\\user-name
sqlserver_configuration.credential_configurations[].connection_parameters[].secret.project_id	String The ID of the project where the secret is stored. Set it to an empty string ("") if the secret and the host VM instance exist in the same Google Cloud project.
sqlserver_configuration.credential_configurations[].connection_parameters[].secret.secret_name	String To securely provide the password for the database user account that the agent uses to query SQL Server, specify the name of the secret in Secret Manager that contains the security credentials for the database user account. Note: The secret and the host VM instance must exist in the same Google Cloud project.
sqlserver_configuration.credential_configurations[].connection_parameters[].port	Int Specify the port on which your SQL Server instance accepts queries.
sqlserver_configuration.credential_configurations[].remote_win.connection_parameters.host	String IP address or FQDN of the remote Windows VM
sqlserver_configuration.credential_configurations[].remote_win.connection_parameters.username	String Specify the user account that is used to remotely connect to the Windows VM.
sqlserver_configuration.credential_configurations[].remote_win.connection_parameters.secret.secret_name	String To securely provide the password for the Windows user account that the agent uses to remotely connect to the VM, specify the name of the secret in Secret Manager that contains the security credentials for the database user account. Note: The secret and the host VM instance must exist in the same Google Cloud project.
sqlserver_configuration.credential_configurations[].local_collection	Boolean Specify true to indicate that the agent is doing local data collection. Default is true.
sqlserver_configuration.credential_configurations[].remote_linux.connection_parameters.host	String IP address or FQDN of the remote Linux VM.
sqlserver_configuration.credential_configurations[].remote_linux.connection_parameters.username	String Specify the user account that is used to remotely connect to the Linux VM.
sqlserver_configuration.credential_configurations[].remote_linux.connection_parameter.port	Int Specify the SSH port number for the remote Linux VM.
sqlserver_configuration.credential_configurations[].remote_linux.linux_ssh_private_key_path	String Specify the path to the SSH private key file.
sqlserver_configuration.credential_configurations[].vm_properties.instance_name	String Specify the name of your Compute Engine VM instance. Note: Optional for local collection.
sqlserver_configuration.credential_configurations[].vm_properties.instance_id	String Specify the ID of your Compute Engine VM instance. Note: Optional for local collection.
sqlserver_configuration.collection_timeout	Duration The timeout for metrics collection, in seconds. Default is `10s`.
sqlserver_configuration.max_retries	Int The maximum number of retries when a failed collection occurs. The default value is `3`.
sqlserver_configuration.retry_frequency	Duration Specify the frequency at which the agent should retry when a collection fails. The default value is `3600s`.
sqlserver_configuration.remote_collection	Boolean Specify true to indicate that the agent is doing remote data collection. The default is false.

Example configuration file

The following is an example configuration that lets Agent for Compute Workloads connect with a SQL Server instance:

Local collection

{
"log_level": "INFO",
"common_discovery": {
    "collection_frequency": "10800s"
},
"sqlserver_configuration": {
    "enabled": true,
    "collection_configuration": {
        "collect_guest_os_metrics": true,
        "collect_sql_metrics": true,
        "collection_frequency": "60s"
    },
    "credential_configurations": [
        {
            "connection_parameters": [
                {
                    "host": ".",
                    "username": "db_user_name",
                    "secret": {
                        "project_id": "",
                        "secret_name": "idb_pwd_secret_name"
                    },
                    "port": 1433
                }
            ],
            "local_collection": true
        }
    ],
    "collection_timeout": "60s",
    "max_retries": 5,
    "retry_frequency": "3600s"
}
}

Remote collection

{
"log_level": "INFO",
"common_discovery": {
    "collection_frequency": "10800s"
},
"sqlserver_configuration": {
    "enabled": true,
    "collection_configuration": {
        "collect_guest_os_metrics": true,
        "collect_sql_metrics": true,
        "collection_frequency": "60s"
    },
    "credential_configurations": [
        {
            "connection_parameters": [
                {
                    "host": "sql_server_instance",
                    "username": "db_user_name",
                    "secret": {
                        "project_id": "",
                        "secret_name": "db_pwd_secret_name"
                    },
                    "port": 1433
                }
            ],
            "remote_win": {
                "connection_parameters": {
                    "host": "sql_server_instance",
                    "username": "user_name",
                    "secret": {
                        "project_id": "",
                        "secret_name": "pwd_secret_name"
                    }
                }
            },
            "vm_properties": {
                "instance_name": "db01",
                "instance_id": "9999999999999999999"
            }
        },
        {
            "connection_parameters": [
                {
                    "host": "sql_server_instance",
                    "username": "db_user_name",
                    "secret": {
                        "project_id": "",
                        "secret_name": "db_pwd_secret_name"
                    },
                    "port": 1433
                }
            ],
            "remote_linux": {
                "connection_parameters": {
                    "host": "sql_server_instance",
                    "username": "user_name",
                    "secret": {
                        "project_id": "",
                        "secret_name": "pwd_secret_name"
                    },
                    "port": 22
                },
                "linux_ssh_private_key_path": "path of the private key"
            },
            "vm_properties": {
                "instance_name": "db02",
                "instance_id": "9999999999999999999"
            }
        }
    ],
    "collection_timeout": "10s",
    "max_retries": 3,
    "retry_frequency": "3600s",
    "remote_collection": true
}
}

Check the version of the agent

To check the version of your agent, complete the following steps:

Windows

1. Use RDP to connect to the host machine.
2. As an administrator, run the following command from PowerShell:

   googet installed google-cloud-workload-agent

RHEL

1. Use SSH to connect to the host machine.
2. Run the following command:

   yum info google-cloud-workload-agent

SUSE

1. Use SSH to connect to the host machine.
2. Run the following command:

   zypper info google-cloud-workload-agent

Debian

1. Use SSH to connect to the host machine.
2. Run the following command:

   dpkg -s google-cloud-workload-agent | grep version

Restart the agent

If Agent for Compute Workloads stops working or you update its configuration, then restart the agent.

Select your operating system, and then follow the steps:

Windows

1. Use RDP to connect to the host machine.
2. As an administrator, run the following command from PowerShell:

   Restart-Service -Name 'google-cloud-workload-agent' -Force

Linux

1. Use SSH to connect to the host machine.
2. Run the following command:

   sudo systemctl restart google-cloud-workload-agent

Update the agent

To ensure that you have the latest version of the agent, you need to check for updates periodically and update the agent.

Check for updates

Select your operating system, and then follow the steps:

Windows

1. Use RDP to connect to the host machine.
2. As an administrator, run the following command from PowerShell:

   googet latest google-cloud-workload-agent

RHEL

1. Use SSH to connect to the host machine.
2. Run the following command:

   sudo yum check-update google-cloud-workload-agent

SLES

1. Use SSH to connect to the host machine.
2. Run the following command:

   sudo zypper list-updates -r google-cloud-workload-agent

Debian

1. Use SSH to connect to the host machine.
2. Run the following command:

   sudo apt list google-cloud-workload-agent

Install an update

Select your operating system, and then follow the steps:

Windows

1. Use RDP to connect to the host machine.
2. As an administrator, run the following command from PowerShell:

   googet install google-cloud-workload-agent

RHEL

1. Use SSH to connect to the host machine.
2. Run the following command:

   sudo yum --nogpgcheck update google-cloud-workload-agent

SLES

1. Use SSH to connect to the host machine.
2. Run the following command:

   sudo zypper --no-gpg-checks update google-cloud-workload-agent

Debian

1. Use SSH to connect to the host machine.
2. Run the following command:

   sudo apt-get install google-cloud-workload-agent

View the agent's logs in Cloud Logging

By default, the logs for Agent for Compute Workloads are redirected from your VM instances to Cloud Logging.

To view the agent's logs in Logging, follow these steps:

1. In the Google Cloud console, go to the Logs Explorer page.

   Go to Logs explorer

2. Go the Query pane.

3. From the Resources drop-down menu, select Global, and then click Apply.

4. In the query editor, enter google-cloud-workload-agent.

5. Click Run query.

   You should see the logs generated by the agent instances running on all your VM instances. To filter the logs from a specific machine, use the filters available in the interface.

Disable the agent's logs in Cloud Logging

To disable the default redirection of agent's logs to Cloud Logging, follow these steps:

1. Establish an RDP or SSH connection with your host VM instance.

2. Open the agent's configuration file:

   Windows

   %ProgramFiles%\Google\google-cloud-workload-agent\conf\configuration.json

   Linux

   /etc/google-cloud-workload-agent/configuration.json

3. For the property log_to_cloud, update the value to false.

4. Save the configuration file.

5. Restart the agent for this change to take effect.

Troubleshoot

The following sections provide information about common issues related to using Agent for Compute Workloads, their causes and resolution.

Insufficient authentication scopes

Issue: If you limit the access scopes on your host VM instance, then Agent for Compute Workloads logs might show insufficient IAM permissions error.

  googleapi: Error 403: Request had insufficient authentication scopes.
  Details:
  [
    {
      "@type": "type.googleapis.com/google.rpc.ErrorInfo",
      "domain": "googleapis.com",
      "metadata": {
        "method": "google.cloud.workloadmanager.datawarehouse.v1.DataCollectService.WriteInsight",
        "service": "workloadmanager.googleapis.com"
      },
      "reason": "ACCESS_TOKEN_SCOPE_INSUFFICIENT"
    }
  ]


More details:
  Reason: insufficientPermissions, Message: Insufficient Permission

Cause: Agent for Compute Workloads requires minimum Cloud API access scopes on the host VM instance.

Resolution: To resolve this issue, enable the required access scopes

Failed to load configuration file

Issue: If the configuration file has invalid values, you see the following error.

"Failed to load configuration","pid":3524,"error":"proto: (line 19:42): unknown
field "{field_name}"

Resolution: To resolve this issue, update the configuration file using the details in Configuration parameters.

Failed to initialize data collection

Issue: After installing the agent if the configuration file is not updated, you see the following error:

"Failed to initialize guest collection","pid":2112,"error":"invalid value for "user_name" "secret_name"

Resolution: To resolve this issue, initialize the credential configuration using Configuration parameters.

What's next

• Learn more about workload evaluations.