Generate Support Logs with Recollect
Recollect Logs (rcollect
)¶
rcollect
is a CLI tool that collects a complete technical dump of the Rafay Controller and its associated Rafay services running on Kubernetes. It is used when customers need to share diagnostic information with Support without manually gathering multiple sets of logs. The tool produces a compressed archive containing the collected data.
Why this tool exists¶
- Simplifies gathering Rafay Controller system and Kubernetes resource information in a single command
- Avoids manual, repetitive controller and service log/configuration collection steps
- Ensures Support receives a consistent and complete controller diagnostics package
- Works even after the original workflow or process has completed
How it helps customers share logs with Support¶
- Captures relevant Rafay Controller system diagnostics and Kubernetes resources in a unified archive
- Produces a
.tar.gz
file ready to be attached to Support tickets - Enables faster troubleshooting by Support, as the archive format is consistent
- Supports targeted collection with configurable time ranges and timeouts
Packaging and How to Obtain It¶
The rcollect
tool is included as part of the controller package and is available as a standalone executable after extracting the controller tarball.
Steps to locate rcollect
:
- Download the controller package from the standard distribution source.
- Extract the tarball:
tar -xzf <controller-package>.tar.gz
- Locate the
rcollect
binary in the extracted files. - (Optional) Move it to a directory in your system
PATH
for easier execution:
chmod +x rcollect
mv rcollect /usr/local/bin/
How to Run rcollect
¶
The rcollect
tool can be executed with different subcommands depending on the type of resources you want to collect.
Each run will generate a tarball (.tar.gz
) containing the collected logs and diagnostics, which can be shared with Rafay Support.
Example 1: Collect both Kubernetes and Node resources¶
./rcollect allresources --kubeconfig gke-config.yaml
This command collects both Kubernetes and node-level diagnostics in a single run.
- The
allresources
subcommand triggers collection of both system-level (node) and cluster-level (Kubernetes) resources. - Node data includes CPU, memory, disk usage, running processes, and system configuration.
- Kubernetes data includes namespaces, deployments, services, pods, events, and associated metadata from the cluster defined in the kubeconfig file.
- All collected data is saved in
.tar.gz
archives, making it easy to share with Support.
Output
Collecting both Kube and Node resources
Collecting Node Resources dump in /home/ubuntu/3.3/sample-test-infra_13-August-2025-071102
Collecting system resources.
Created tarball at /home/ubuntu/3.3/sample-test-infra_13-August-2025-071102.tar.gz.
Using kubeconfig from custom-config.yaml
Collecting Kube Resources in /home/ubuntu/3.3/sample_on-prem-123456_us-central1-a_sample-controller_13-August-2025-071156
Successfully collected kube resources.
Created tarball at /home/ubuntu/3.3/sample_on-prem-123456_us-central1-a_sample-controller_13-August-2025-071156.tar.gz.
Example 2: Collect only Node resources¶
./rcollect noderesources
This command collects only node-level diagnostics from the controller where rcollect
is executed.
- The noderesources
subcommand focuses on system-level information such as CPU, memory, disk usage, running processes, and network configuration.
- No Kubernetes API calls are made, making it useful when Kubernetes access is unavailable or not required.
- The collected data is stored in a .tar.gz
archive, ready to be shared with Support.
Output
Collecting Node Resources dump in /home/user/output-directory/node-resources_timestamp
Collecting system resources.
Created tarball at /home/user/output-directory/node-resources_timestamp.tar.gz.
Example 3: Collect only Kubernetes resources¶
./rcollect kuberesources --kubeconfig gke-config.yaml
This command collects only Kubernetes-related diagnostics for Rafay services running on the controller.
- The
kuberesources
subcommand connects to the Kubernetes API using the provided kubeconfig file. - It gathers details such as namespaces, deployments, services, pods, events, and related metadata.
- This is helpful when node-level information is not required or when focusing on cluster-level troubleshooting.
- The collected data is stored in a
.tar.gz
archive, making it easy to share with Support.
Output
Using kubeconfig from custom-config.yaml
Collecting Kube Resources in /home/user/output-directory/kube-resources_timestamp
Successfully collected kube resources.
Created tarball at /home/user/output-directory/kube-resources_timestamp.tar.gz.
💡 Note
If a custom kubeconfig file path is used, specify it with the
--kubeconfig
flag (e.g.,--kubeconfig /path/to/config
). If the kubeconfig file is already configured in the default location (~/.kube/config
), the--kubeconfig
flag is not required.The
--since
flag can be used to control the duration of logs to collect (e.g.,--since 1d
for 1 day).Use
--timeout
to set a maximum collection duration. Default is30m
.