This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Troubleshooting

This section contains general troubleshooting guidance for your Anchore Enterprise instance. If you are not sure where to start, the Quick Reference maps common observable symptoms to the most likely diagnostic path. Otherwise, the recommended general approach is to first verify all Anchore Enterprise services are up, use the event subsystem to narrow down particular issues, and then navigate to the logs for specific services to find out more information.

If you have worked through the relevant pages and still cannot isolate the cause, gather a Diagnostic Bundle before contacting Anchore Customer Success.

Throughout this section, AnchoreCTL commands are used to assist with troubleshooting. For more information on AnchoreCTL, see the AnchoreCTL section.

1 - Quick Reference

Use this page as a starting point. Match the symptom you are seeing to the most likely diagnostic path, then follow the linked page for detailed steps.

If your symptom is not represented here — or you have worked through the linked path without resolving the issue — gather a Diagnostic Bundle before contacting Anchore Customer Success.

Common Symptoms

Symptom	Likely cause	Start here
A service shows as `down` or `unavailable` in `anchorectl system status`.	The service process has crashed, the container has exited, or the readiness probe is failing.	Verifying Service Health
A service shows as `orphaned` in the GUI System view.	The service can no longer reach the catalog or its database registration has lapsed.	Verifying Service Health, then inspect that service’s log.
An image is stuck in the `analyzing` state for an extended period.	The analyzer cannot pull the image, registry lookup is failing, or the analyzer is overloaded.	Viewing Logs — trace the analyzer thread for that image.
`registry_lookup_failed` events appear repeatedly.	Registry credentials are missing or expired, or the registry is unreachable from the catalog.	Viewing System Events
Vulnerability data is stale or missing for one or more feed groups.	The Data Syncer has not pulled the relevant dataset, or the upstream provider is unreachable.	Data Syncer
Newly-published CVEs are not appearing on existing analyses.	Feed sync completed after the image was analyzed; the analysis needs to be re-evaluated.	Data Syncer
A policy evaluation returns an unexpected result (`stop` vs `pass`, or vice versa).	Policy or feed data has changed, or a gate is referencing data that is not yet available.	Viewing System Events and review the policy evaluation output.
AnchoreCTL cannot connect to Anchore Enterprise.	The URL, credentials, TLS trust, or API version are misconfigured.	Run `anchorectl system status -vvvv` and inspect the configuration dump along with any TLS or HTTP errors.
You need to validate the system end-to-end after an upgrade or configuration change.	A known-good baseline check is required.	Smoke Testing

If Your Symptom Is Not Listed

Re-run anchorectl system status and confirm every service reports up and available.
Run anchorectl event list and look for recent error-level events tied to the affected resource.
Pull the relevant service log (see Viewing Logs) and grep for the resource identifier (image digest, image tag, or thread number).
If you still cannot isolate the cause, prepare a Diagnostic Bundle for Anchore Customer Success.

2 - Smoke Testing

This term typically refers to a testing methodology which validates critical or crucial functionality of software. Versions of AnchoreCTL post-5.6.0 include a smoke-tests option, which can be used to validate general functionality of your Anchore Enterprise.

We recommend using this mechanism to validate functionality after upgrades.

The test check-admin-credentials looks for an admin user in the admin account context as defined in your anchorectl.yaml.

anchorectl system smoke-tests run
...
 ✔ Ran smoke tests
┌───────────────────────────────────────┬─────────────────────────────────────────────────┬────────┬────────┐
│ NAME                                  │ DESCRIPTION                                     │ RESULT │ STDERR │
├───────────────────────────────────────┼─────────────────────────────────────────────────┼────────┼────────┤
│ wait-for-system                       │ Wait for the system to be ready                 │ pass   │        │
│ check-admin-credentials               │ Check anchorectl credentials to run smoke tests │ pass   │        │
│ create-test-account                   │ Create a test account                           │ pass   │        │
│ list-test-policies                    │ List the test policies                          │ pass   │        │
│ get-test-policy                       │ Get the test policy                             │ pass   │        │
│ activate-test-default-policy          │ Activate the test default policy                │ pass   │        │
│ create-test-image                     │ Create a test image and wait for analysis       │ pass   │        │
│ get-test-image                        │ Get the test image                              │ pass   │        │
│ activate-test-subscription            │ Activate a test subscription                    │ pass   │        │
│ get-test-subscription                 │ Get the test subscription                       │ pass   │        │
│ deactivate-test-vuln-subscription     │ Deactivate the vuln subscription                │ pass   │        │
│ deactivate-test-policy-subscription   │ Deactivate the policy subscription              │ pass   │        │
│ deactivate-test-tag-subscription      │ Deactivate the tag subscription                 │ pass   │        │
│ deactivate-test-analysis-subscription │ Deactivate the analysis subscription            │ pass   │        │
│ check-test-image                      │ Check the test image                            │ pass   │        │
│ get-test-image-vulnerabilities        │ Get the test image vulnerabilities              │ pass   │        │
│ delete-test-image                     │ Delete the test image                           │ pass   │        │
│ disable-test-account                  │ Disable the test account                        │ pass   │        │
│ delete-test-account                   │ Delete the test account                         │ pass   │        │
└───────────────────────────────────────┴─────────────────────────────────────────────────┴────────┴────────┘

Troubleshooting Failing Steps

wait-for-system

Polls the API until the vulnerability feed reports as ready (300s timeout). Failure means: The data syncer cannot reach https://data.anchore-enterprise.com or feeds have not completed their initial sync.

Verify external connectivity: curl -v https://data.anchore-enterprise.com
Check feed sync status: anchorectl feed list
Check data syncer events: anchorectl event list --level error --service data_syncer
See Data Syncer Troubleshooting for deeper diagnosis of feed sync issues.

get-test-policy / activate-test-default-policy

Verifies the policy engine is functional and default policies exist. Failure means: Policy engine is unhealthy or feed data has not been loaded yet. These steps commonly fail as a cascade when wait-for-system also fails.

See Verifying Service Health to confirm the policy engine service is up and responding.

create-test-image / get-test-image / get-test-image-vulnerabilities

Submits a test image for analysis and verifies the full analysis pipeline. Failure means: The analyzer, catalog, or policy engine is not functioning correctly.

See Verifying Service Health to check the status of the analyzer and catalog services.
See Viewing Logs and Viewing System Events for deeper diagnosis.

Note: all test resources (account, image) are cleaned up automatically at the end of the run.

3 - Viewing Logs

Anchore Enterprise services produce detailed logs that contain information about user interactions, internal processes, warnings and errors. The verbosity of the logs is controlled using the logging.log_level setting in config.yaml (for manual installations) or the corresponding ANCHORE_LOG_LEVEL environment variable (for docker compose or Helm installations) for each service.

The log levels are DEBUG, INFO, WARNING, ERROR, and CRITICAL, where the default is INFO. Most of the time, the default level is sufficient as the logs will contain WARNING, ERROR and CRITICAL messages as well. But for deep troubleshooting, it is always recommended to increase the log level to DEBUG in order to ensure the availability of the maximum amount of information.

Raising the log level to DEBUG significantly increases log output and adds load to the system. Use it while actively troubleshooting, and return the level to INFO once you have gathered what you need.

You can find further info on configuring logs in Configuration.

Anchore Enterprise logs can be accessed by inspecting the docker logs for any anchore service container using the regular docker logging mechanisms, which typically default to displaying to the stdout/stderr of the containers themselves - for example:

docker ps
CONTAINER ID   IMAGE                                       COMMAND                  CREATED          STATUS                    PORTS                                         NAMES
f7bd1bff4c90   anchore/anchore-ui:v6.0.0                   "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   0.0.0.0:3000->3000/tcp, [::]:3000->3000/tcp   anchore-6000-ui-1
37637df74cda   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   8228/tcp                                      anchore-6000-policy-engine-1
bf516667e360   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   0.0.0.0:8558->8228/tcp, [::]:8558->8228/tcp   anchore-6000-reports-1
701dbb4a9ac4   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   8228/tcp                                      anchore-6000-component-catalog-1
b64829f694ac   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   8228/tcp                                      anchore-6000-reports_worker-1
b1044667f188   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   0.0.0.0:8668->8228/tcp, [::]:8668->8228/tcp   anchore-6000-notifications-1
00c47016e3d9   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   8228/tcp                                      anchore-6000-analyzer-1
5bac7677d307   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   0.0.0.0:8228->8228/tcp, [::]:8228->8228/tcp   anchore-6000-api-1
3107c52d182c   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   0.0.0.0:8778->8228/tcp, [::]:8778->8228/tcp   anchore-6000-data-syncer-1
aae305b431c7   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   8228/tcp                                      anchore-6000-catalog-1
965a7c795d5c   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   8228/tcp                                      anchore-6000-queue-1
de7993ad0f8e   redis:7.4.6                                 "docker-entrypoint.s…"   12 minutes ago   Up 12 minutes (healthy)   6379/tcp                                      anchore-6000-ui-redis-1
4ebc23aaf9ed   anchore-6000-anchore-db                     "docker-entrypoint.s…"   12 minutes ago   Up 12 minutes (healthy)   5432/tcp                                      anchore-6000-anchore-db-1

docker logs anchore-6000-analyzer-1
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-02T09:57:44.646254+00:00] [MainProcess] [MainThread] [INFO] [anchore_enterprise.common.service/_register_instance_handlers():594] | Registering api handlers
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-02T09:57:44.646589+00:00] [MainProcess] [MainThread] [INFO] [anchore_enterprise.common.service/_process_stage_handlers():231] | Processing init handlers for bootstrap stage: pre_config
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-02T09:57:44.646758+00:00] [MainProcess] [MainThread] [INFO] [anchore_enterprise.common.service/_configure():293] | Loading and initializing global configuration
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-02T09:57:44.646901+00:00] [MainProcess] [MainThread] [INFO] [anchore_enterprise.common.services/_init_versions():105] | Initializing enterprise versions
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-02T09:57:44.647043+00:00] [MainProcess] [MainThread] [INFO] [anchore_enterprise.common.service/_configure():296] | Anchore version 6.0.0, DB Schema 6000
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-02T09:57:44.647247+00:00] [MainProcess] [MainThread] [INFO] [anchore_enterprise.common.service/_configure():320] | Configuration complete
...
...

If you are using Kubernetes to run Anchore Enterprise, you can retrieve the logs from the service pods directly using kubectl commands:

You can find the desired pod name with kubectl get pods.

kubectl logs -n <your-namespace> <your-anchore-pod-name>
[service:anchore-enterprise-apiext-v6.0.0] [2024-11-12T18:11:21.475751+00:00] [MainProcess] [WSGI_2] [INFO] [anchore_enterprise.common.service/log_request():948] [req-id-aa93785c77c94d7081b1cff51d59d0aa] | 172.18.0.15:50682 - "GET /health HTTP/1.1" 200 request:0bytes response:5bytes 1.13ms
[service:anchore-enterprise-apiext-v6.0.0] [2024-11-12T18:11:21.494813+00:00] [MainProcess] [WSGI_0] [INFO] [anchore_enterprise.common.service/log_request():948] [req-id-fdec0048c96348b9ae3385866908931f] | 172.18.0.15:50694 - "GET /version HTTP/1.1" 200 request:0bytes response:86bytes 1.27ms
[service:anchore-enterprise-apiext-v6.0.0] [2024-11-12T18:11:30.499957+00:00] [MainProcess] [WSGI_2] [INFO] [anchore_enterprise.common.service/log_request():948] [req-id-8c6dd69ca53241958cfc63287ff97403] | 172.18.0.16:50360 - "GET /metrics HTTP/1.1" 200 request:0bytes response:18483bytes 14.08ms
[service:anchore-enterprise-apiext-v6.0.0] [2024-11-12T18:11:31.533531+00:00] [MainProcess] [WSGI_0] [INFO] [anchore_enterprise.common.service/log_request():948] [req-id-7d0b21bb200d491db6a63fffaeb95bf2] | 172.18.0.15:51316 - "GET /health HTTP/1.1" 200 request:0bytes response:5bytes 1.5ms
[service:anchore-enterprise-apiext-v6.0.0] [2024-11-12T18:11:31.539215+00:00] [MainProcess] [WSGI_2] [INFO] [anchore_enterprise.common.service/log_request():948] [req-id-6090039eb148412cb50bd64ceb61a634] | 172.18.0.15:51324 - "GET /version HTTP/1.1" 200 request:0bytes response:86bytes 0.94ms
[service:anchore-enterprise-apiext-v6.0.0] [2024-11-12T18:11:40.149191+00:00] [MainProcess] [WSGI_0] [INFO] [anchore_enterprise.common.service/log_request():948]

If you want to trace an image’s journey through the analyzer to track whether it completes successfully, you can do this using the logged events and finding the Thread that the analysis is occurring on - in the below example, we noticed that the processes related to the node:latest image we submitted for analysis were occurring on Thread-5 when observing analyzer logs, so we were able to grep for this to see the entire process;

kubectl logs -n anchore anchore-enterprise-analyzer-5f49795899-9zc65 | grep Thread-5
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:12:10.145453+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/process_analyzer_job():468] | image dequeued for analysis: admin : sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:12:10.190503+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/perform_analyze():264] | performing analysis on image: ['admin', 'docker.io/library/node@sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c', 'docker.io/library/node:latest']
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:12:10.193547+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/perform_analyze():269] | analyzing image admin: docker.io/library/node@sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:12:10.193750+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.localanchore_standalone/analyze_image():812] | Analyzing Full Tag: docker.io/library/node:latest with Source: registry Dockerfile Mode: Guessed and Contents: False
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:12:10.194239+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.localanchore_standalone/pull_image():501] | Downloading image docker.io/library/node@sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c for analysis to /analysis_scratch/5538f6c3-366e-4e47-8d18-690bb2eb66dd/raw
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:12:30.139926+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.utils/timer():910] | Execution of Executing analyzer /home/anchore/venv/lib64/python3.12/site-packages/anchore_enterprise/services/analyzer/analyzers/modules/01_analyzer_meta.py took: 1.13681960105896 seconds
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:12:31.355471+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.utils/timer():910] | Execution of Executing analyzer /home/anchore/venv/lib64/python3.12/site-packages/anchore_enterprise/services/analyzer/analyzers/modules/02_analyzer_windows.py took: 1.2146642208099365 seconds
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:02.832641+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analyzers.syft.adapters/_convert_syft_to_engine():322] | filtering owned packages
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:04.437364+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/perform_analyze():286] | performing analysis on image complete admin: docker.io/library/node@sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:04.438051+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/process_analyzer_job():521] | No anchore hints found in retrieved image data
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:04.439172+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/store_analysis_results():726] | adding image analysis data to catalog: account_name=admin image_id=0b58171b7f6dcafeb1893f84ae02f743f3e7facb3112987afc5c6f2b66e591dc image_digest=sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:04.439421+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.utils/upload_document_with_retry():269] | Attempting upload of syft_sbom
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:05.219587+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.utils/upload_document_with_retry():276] | Successfully uploaded syft_sbom
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:05.219947+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.utils/upload_document_with_retry():269] | Attempting upload of analysis_data
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:06.323650+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.utils/upload_document_with_retry():276] | Successfully uploaded analysis_data
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:06.975603+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/import_to_policy_engine():350] | loading image into policy engine: account_name=admin image_id=0b58171b7f6dcafeb1893f84ae02f743f3e7facb3112987afc5c6f2b66e591dc image_digest=sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:11.908357+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.utils/update_analysis_complete():126] | Updating image catalog record with analysis results
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:11.935663+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/process_analyzer_job():553] | analysis complete: admin sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c

4 - Viewing System Events

If you’ve successfully verified that all Anchore Enterprise services are up, but are still running into issues operating Anchore, a good place check is the event log.

The event log subsystem provides users with a mechanism to inspect asynchronous events occurring across various Anchore Enterprise services. Anchore events include periodically-triggered activities such as vulnerability data feed sync in the policy_engine service, image analysis failures originating from the analyzer service, and other informational or system fault events. The catalog service may also generate events for any repositories or image tags that are being watched when Anchore Enterprise encounters connectivity, authentication, authorization, or other errors in the process of checking for updates.

The event log is aimed at troubleshooting most common failure scenarios, especially those that happen during asynchronous operations, and to pinpoint the reasons for failures that can be used subsequently to help with corrective actions. Events can be cleared from Anchore Enterprise in bulk or individually.

Viewing Events

The recent events can be viewed inside the Anchore Enterprise GUI on the Events & Notifications tab:

If using AnchoreCTL, running the following command will give a list of recent Anchore Enterprise events: anchorectl event list

Viewing list of recent Anchore Enterprise events

anchorectl event list
 ✔ List events
┌──────────────────────────────────┬──────────────────────────────────────────────┬───────┬───────────────────────────────────────────────────────┬─────────────────┬────────────────┬────────────────────┬─────────────────────────────┐
│ UUID                             │ EVENT TYPE                                   │ LEVEL │ RESOURCE ID                                           │ RESOURCE TYPE   │ SOURCE SERVICE │ SOURCE HOST        │ TIMESTAMP                   │
├──────────────────────────────────┼──────────────────────────────────────────────┼───────┼───────────────────────────────────────────────────────┼─────────────────┼────────────────┼────────────────────┼─────────────────────────────┤
│ 329ff24aa77549458e2656f1a6f4c98f │ system.image_analysis.registry_lookup_failed │ error │ docker.io/alpine:3.4                                 │ image_reference │ catalog        │ anchore-quickstart │ 2022-08-24T22:08:29.026352Z │
│ 4010f105cf264be6839c7e8ca1a0c46e │ system.image_analysis.registry_lookup_failed │ error │ docker.io/alpine:latest                              │ image_reference │ catalog        │ anchore-quickstart │ 2022-08-24T22:08:28.991101Z │
│ 6924eb83313746ff8b842a88654e3ac1 │ system.image_analysis.registry_lookup_failed │ error │ docker.io/alpine:3.12                                │ image_reference │ catalog        │ anchore-quickstart │ 2022-08-24T22:08:28.956321Z │
│ efdcf727647c458f85cb6464926e474d │ system.image_analysis.registry_lookup_failed │ error │ docker.io/nginx:latest                               │ image_reference │ catalog        │ anchore-quickstart │ 2022-08-24T22:08:28.920222Z │
...
│ 1eb04509b2bc44208cdc7678eaf76fef │ user.image.analysis.completed                │ info  │ docker.io/ubuntu:latest                               │ image_tag       │ analyzer       │ anchore-quickstart │ 2022-08-24T22:06:13.736004Z │
│ 6f735f8db7e84ce19b221d3b024318af │ user.image.analysis.processing               │ info  │ docker.io/ubuntu:latest                               │ image_tag       │ analyzer       │ anchore-quickstart │ 2022-08-24T22:06:13.128912Z │
│ 480eb191f87440b48c9f8cfa6529badf │ user.image_tag.added                         │ info  │ docker.io/ubuntu:latest                               │ image_tag       │ catalog        │ anchore-quickstart │ 2022-08-24T22:06:08.307039Z │
...
└──────────────────────────────────┴──────────────────────────────────────────────┴───────┴───────────────────────────────────────────────────────┴─────────────────┴────────────────┴────────────────────┴─────────────────────────────┘

Details About a Specific Event

If you would like more information about a specific event, you can run the following command: anchorectl event get <event-id>

Details about a specific Anchore Enterprise event

anchorectl event get 1eb04509b2bc44208cdc7678eaf76fef
 ✔ Fetched event
UUID: 1eb04509b2bc44208cdc7678eaf76fef
Event:
  Event Type: user.image.analysis.completed
  Level: info
  Message: Image analysis available
  Resource:
    Resource ID: docker.io/ubuntu:latest
    Resource Type: image_tag
    User Id: admin
  Source:
    Source Service: analyzer
    Base Url: http://analyzer:8228
    Source Host: anchore-quickstart
    Request Id:
  Timestamp: 2022-08-24T22:06:13.736004Z
  Category:
  Details:
Created At: 2022-08-24T22:06:13.832881Z

Depending on the output from the detailed events, looking into the logs for a particular servicename (example: policy_engine) is the next troubleshooting step.

5 - Data Syncer

Anchore Enterprise runs a hosted data service called the Anchore Data Service. This service publishes datasets from a number of provider sources. The Data Syncer Service is a core component of Enterprise. Its job is to periodically query Anchore Data Service and download any new datasets available.

Performing a Basic Health Check

Run anchorectl feed list as admin and ensure that:

The last sync date shown is recent and that the feed has enabled set to true.

Run anchorectl feed sync as admin which will:

Queue an update to fetch the data from the data service and propagate feed data across internal services.
- Otherwise, this runs on a regular schedule.

You can also visually check the health in the System section of the GUI when logged in as admin.

Configuration Checks

Check that the feed pod/container has enough disk space:

Storage

Ensure your data syncer pod has enough storage (around 2 GB of writable space) to cache the datasets to disk, this reduces database queries.

Memory

Ensure the data syncer pod has sufficient memory (around 2 GB), especially if you are running multiple analyzers

Network

Ensure your data-syncer pod / container has network connectivity to hosted feed service by exec’ing into the container and then:
- If you have a network proxy deployed, you might need to configure your feed service to utilize it:
Ensure your policy pod / container has network connectivity to your local data-syncer pod / container
- Run e.g. curl http://anchore-data-syncer:8228/v2/datasets/vulnerability_db/6/latest returns success to confirm connectivity.

Operational Checks and Verification

Feed list show up empty: Check if your feed syncs are happening, there should be data_syncer events in the event log. You should see successful events in the event log. In case there are failures click on the event log and see the cause for failure.
Data-syncer is reporting errors fetching new datasets: Check the Anchore Data Service Status Page. If the service is reporting up and running then check your firewall settings. If the service is reporting any failures please wait for the service to recover.
I see a lot of 404’s in the data-syncer and policy engine logs as soon as the services start: This is normal, the data-syncer takes a few minutes after startup to successfully sync down the configured datasets from the Anchore Data Service. The Policy Engine Service starts asking for the latest vulnerability dataset as soon as it starts up, it takes a few minutes for the system to reconcile. (This is only true for new greenfield deployments)
My first analyzer scan takes longer than the rest: First analyzer scan can take up to 5 minutes, this is just due to the analyzer waiting for the data-syncer to sync down a ClamAV database. Subsequent scans will not incur this penalty.

6 - Verifying Service Health

You can verify which services have registered themselves successfully, along with their status, by running: anchorectl system status

anchorectl system status
 ✔ Status system
┌───────────────────┬────────────────────┬───────────────────────────────┬──────┬────────────────┬────────────┬──────────────┐
│ SERVICE           │ HOST ID            │ URL                           │ UP   │ STATUS MESSAGE │ DB VERSION │ CODE VERSION │
├───────────────────┼────────────────────┼───────────────────────────────┼──────┼────────────────┼────────────┼──────────────┤
│ simplequeue       │ anchore-quickstart │ http://queue:8228             │ true │ available      │ 6000       │ 6.0.0        │
│ component_catalog │ anchore-quickstart │ http://component-catalog:8228 │ true │ available      │ 6000       │ 6.0.0        │
│ notifications     │ anchore-quickstart │ http://notifications:8228     │ true │ available      │ 6000       │ 6.0.0        │
│ reports_worker    │ anchore-quickstart │ http://reports_worker:8228    │ true │ available      │ 6000       │ 6.0.0        │
│ data_syncer       │ anchore-quickstart │ http://data-syncer:8228       │ true │ available      │ 6000       │ 6.0.0        │
│ reports           │ anchore-quickstart │ http://reports:8228           │ true │ available      │ 6000       │ 6.0.0        │
│ analyzer          │ anchore-quickstart │ http://analyzer:8228          │ true │ available      │ 6000       │ 6.0.0        │
│ apiext            │ anchore-quickstart │ http://api:8228               │ true │ available      │ 6000       │ 6.0.0        │
│ catalog           │ anchore-quickstart │ http://catalog:8228           │ true │ available      │ 6000       │ 6.0.0        │
│ policy_engine     │ anchore-quickstart │ http://policy-engine:8228     │ true │ available      │ 6000       │ 6.0.0        │
└───────────────────┴────────────────────┴───────────────────────────────┴──────┴────────────────┴────────────┴──────────────┘

This can also be found in the GUI under the System tab, where each service will be laid out with information on its name, status, and other related information:

gui_service_health

If specific services are down, you can investigate the logs for the services. For more information, see Viewing Logs.

The -vvvv and -o json Options

Passing a high-verbosity flag (-vvvv) to AnchoreCTL can often help narrow down particular issues by displaying the client configuration and client functions as they are running:

Example system status with -vvvv

anchorectl system status -vvvv
[0000]  INFO anchorectl version: v6.0.0
[0000] DEBUG application config:
  url: http://localhost:8228
  username: admin
  password: '******'
  account: ""
  skip-api-version-check: false
  ui-url: ""
  check-for-updates: true
  config: /Users/lzw/.anchorectl.yaml
  quiet: false
  log:
    level: trace
    file: ""
  debug:
    api: false
    events: false
  http:
    tls-insecure: true
    timeout: 180
    headers: {}
  dev:
    profile-cpu: false
    profile-mem: false
  registry:
    insecure-skip-tls-verify: false
    insecure-use-http: false
    auth: []
  secret-search:
    cataloger:
      enabled: false
      scope: all-layers
    additional-patterns: {}
    exclude-pattern-names: []
    reveal-values: false
    skip-files-above-size: 1048576
  content-search:
    cataloger:
      enabled: false
      scope: all-layers
    patterns: {}
    reveal-values: false
    skip-files-above-size: 1048576
  file-contents:
    cataloger:
      enabled: false
      scope: squashed
    skip-files-above-size: 1048576
    globs: []
  syft-parallelism: 0
[0000] DEBUG command config:
  format: text
[0000] DEBUG checking for anchorectl updates from Enterprise
[0000] DEBUG current anchorectl version: v6.0.0
[0000] DEBUG querying Enterprise for available tools (darwin/arm64)
[0000] DEBUG version check result: enterprise=6.0.0, anchorectl=v6.0.0, mismatch=false
[0000] DEBUG anchorectl version matches Enterprise (current: v6.0.0, enterprise: 6.0.0)
[0000] TRACE worker stopped component=eventloop
[0000] TRACE bus stopped component=eventloop
┌───────────────────┬────────────────────┬───────────────────────────────┬──────┬────────────────┬────────────┬──────────────┐
│ SERVICE           │ HOST ID            │ URL                           │ UP   │ STATUS MESSAGE │ DB VERSION │ CODE VERSION │
├───────────────────┼────────────────────┼───────────────────────────────┼──────┼────────────────┼────────────┼──────────────┤
│ simplequeue       │ anchore-quickstart │ http://queue:8228             │ true │ available      │ 6000       │ 6.0.0        │
│ catalog           │ anchore-quickstart │ http://catalog:8228           │ true │ available      │ 6000       │ 6.0.0        │
│ notifications     │ anchore-quickstart │ http://notifications:8228     │ true │ available      │ 6000       │ 6.0.0        │
│ reports_worker    │ anchore-quickstart │ http://reports_worker:8228    │ true │ available      │ 6000       │ 6.0.0        │
│ data_syncer       │ anchore-quickstart │ http://data-syncer:8228       │ true │ available      │ 6000       │ 6.0.0        │
│ reports           │ anchore-quickstart │ http://reports:8228           │ true │ available      │ 6000       │ 6.0.0        │
│ analyzer          │ anchore-quickstart │ http://analyzer:8228          │ true │ available      │ 6000       │ 6.0.0        │
│ apiext            │ anchore-quickstart │ http://api:8228               │ true │ available      │ 6000       │ 6.0.0        │
│ policy_engine     │ anchore-quickstart │ http://policy-engine:8228     │ true │ available      │ 6000       │ 6.0.0        │
│ component_catalog │ anchore-quickstart │ http://component-catalog:8228 │ true │ available      │ 6000       │ 6.0.0        │
└───────────────────┴────────────────────┴───────────────────────────────┴──────┴────────────────┴────────────┴──────────────┘

Passing the -o json option to AnchoreCTL commands will output the API response data in JSON, which often contains much more information than what the CLI outputs by default for both regular successful operations, and for operations that are resulting in an error:

anchorectl -o json system status
 ✔ Status system
{
  "serviceStates": [
    {
      "baseUrl": "http://reports_worker:8228",
      "hostid": "anchore-quickstart",
      "serviceDetail": {
...
...

7 - Diagnostic Bundle

When you raise a support issue, Anchore Customer Success may need logs, configuration, and other diagnostic information from your deployment to investigate. Anchore Enterprise provides a way to collect this material into a single diagnostic bundle directly from your own systems, so you can gather everything in one step and share it with Customer Success.

Reach out to Anchore Customer Success for the support bundle utility, maydayctl.