Stay organized with collections
Save and categorize content based on your preferences.
The nomos command-line tool helps with common administrative tasks for
Config Sync, for example producing a diagnostic
archive. The exact output and layout of the archive is subject to
change and is not considered an API. The code for nomos is available
in the Config Sync repository.
You can get similar information from your cluster by running
kubectl get or kubectl logs, but the advantage of nomos bugreport
is that it creates an archive of key information about the
Config Sync system. When you contact Google Cloud Support, it's
helpful to provide nomos bugreport output.
You can also use the output of nomos bugreport for your own debugging or
internal support.
The nomos bugreport output file structure looks like this:
Nomos version shows the Config Sync version, the output of nomos version.
Nomos status shows the output of nomos status status, for example which commit is synced and any errors.
Information about Config Sync custom resources:
For cluster-scoped resources such as ConfigManagement and ClusterSelectors are located here: raw/cluster-1/cluster/configmanagement/.
For namespace-scoped ones, such as RootSync, RepoSync and ResourceGroup are located here: raw/cluster-1/namespaces/namespace-1.
Resources synced and managed by Config Sync:
If you have RootSync and RepoSync APIs enabled, it's in ResourceGroup's spec. You can get the count of those resources, and their kind, namespace, and name.
If you don't have RootSync and RepoSync APIs enabled and you specify git fields in your ConfigManagement object (deprecated), the full content of the resources is in ClusterConfigs and NamespaceConfigs. You should Migrate your ConfigManagement object.
Logs of all Config Sync Pods are under raw/cluster-1/namespaces/pod-namespace-1/pod-name-1/container-name.txt.
The full content of all Config Sync Pods: under raw/cluster-1/namespaces/pod-namespace-1/pods.txt.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-05 UTC."],[],[],null,["# nomos bugreport contents\n\nThe `nomos` command-line tool helps with common administrative tasks for\nConfig Sync, for example producing a diagnostic\narchive. The exact output and layout of the archive is subject to\nchange and is not considered an API. The code for `nomos` is available\nin the [Config Sync repository](https://github.com/GoogleContainerTools/kpt-config-sync).\n\nYou can get similar information from your cluster by running\n`kubectl get` or `kubectl logs`, but the advantage of `nomos bugreport`\nis that it creates an archive of key information about the\nConfig Sync system. When you contact Google Cloud Support, it's\nhelpful to provide `nomos bugreport` output.\n\nYou can also use the output of `nomos bugreport` for your own debugging or\ninternal support.\n\nThe `nomos bugreport` output file structure looks like this: \n\n - raw/\n - cluster/\n - configmanagement/\n - namespaces/\n - config-management-monitoring/\n - config-management-system/\n - gatekeeper-system/\n - resource-group-system/\n - kube-system/\n - processed/\n - status.txt\n - version.txt\n\nThe information you can get from `nomos bugreport`:\n\n1. Nomos version shows the Config Sync version, the output of `nomos version`.\n2. Nomos status shows the output of `nomos status` status, for example which commit is synced and any errors.\n3. Information about Config Sync custom resources:\n 1. For cluster-scoped resources such as ConfigManagement and ClusterSelectors are located here: `raw/`\u003cvar class=\"readonly\" translate=\"no\"\u003ecluster-1\u003c/var\u003e`/cluster/configmanagement/`.\n 2. For namespace-scoped ones, such as RootSync, RepoSync and ResourceGroup are located here: `raw/`\u003cvar class=\"readonly\" translate=\"no\"\u003ecluster-1\u003c/var\u003e`/namespaces/`\u003cvar class=\"readonly\" translate=\"no\"\u003enamespace-1\u003c/var\u003e.\n4. Resources synced and managed by Config Sync:\n 1. If you have RootSync and RepoSync APIs enabled, it's in ResourceGroup's spec. You can get the count of those resources, and their kind, namespace, and name.\n 2. If you don't have RootSync and RepoSync APIs enabled and you specify git fields in your `ConfigManagement` object (deprecated), the full content of the resources is in ClusterConfigs and NamespaceConfigs. You should [Migrate your `ConfigManagement` object](/kubernetes-engine/enterprise/config-sync/docs/how-to/migrate-multi-repo).\n5. Logs of all Config Sync Pods are under `raw/`\u003cvar class=\"readonly\" translate=\"no\"\u003ecluster-1\u003c/var\u003e`/namespaces/`\u003cvar class=\"readonly\" translate=\"no\"\u003epod-namespace-1\u003c/var\u003e`/`\u003cvar class=\"readonly\" translate=\"no\"\u003epod-name-1\u003c/var\u003e`/`\u003cvar class=\"readonly\" translate=\"no\"\u003econtainer-name\u003c/var\u003e`.txt`.\n6. The full content of all Config Sync Pods: under `raw/`\u003cvar class=\"readonly\" translate=\"no\"\u003ecluster-1\u003c/var\u003e`/namespaces/`\u003cvar class=\"readonly\" translate=\"no\"\u003epod-namespace-1\u003c/var\u003e`/pods.txt`.\n7. Are Config Sync [RootSync and RepoSync APIs](/kubernetes-engine/enterprise/config-sync/docs/reference/rootsync-reposync-fields) enabled (that is, using multi-repo mode) or not?\n 1. Check the `ConfigManagement` resource and if you see `spec.enableMultiRepo: true`, RootSync and RepoSync APIs are enabled.\n 2. If you see components such as RootSync, RepoSync, or reconciler Pods, you have RootSync and RepoSync APIs enabled.\n 3. If you see components such as git-importer Pod, then RootSync and RepoSync APIs aren't enabled and you need to [Migrate your `ConfigManagement` object](/kubernetes-engine/enterprise/config-sync/docs/how-to/migrate-multi-repo)."]]