If you are having issues with a specific command within Habitat Studio, please provide the contents of /hab/sup/default/sup.log attached to the ticket for review. This is useful if the supervisor is unable to start or flaps periodically.
In addition to logs, we have a customized script which can glean some necessary information about the environment on which the application is running.
If you're seeing issues with a Habitat application on a target/supervisor node, we'll need a minimum of logs shipped as an attached file to the ticket. We'd advise providing at least 10000 lines depending on the intermittence of the issue. Feel free to tune the following command depending on whether you think the output captures the pattern of the issue from start to finish:
journalctl -u HABITAT_SERVICE -n 10000 | tee -a $(hostname)-HABITAT_SERVICE-$(date -u +"%Y-%m-%dT%H:%M:%SZ").log
Should a standard error log not suffice, or you wish to provide a more verbose log and it's possible to interrupt the process of events, you can also set the RUST_LOG and start (or restart) the supervisor:
env RUST_LOG=debug RUST_BACKTRACE=1 hab sup run
Please see https://www.habitat.sh/docs/reference/sup-log-configuration/ for more info.
Please see https://github.com/habitat-sh/on-prem-builder/blob/master/on-prem-docs/logs.md for the specifics of Builder log file configuration and location. If the Builder was deployed by Chef Automate, please use a chef-automate gather-logs to capture the builder-api service logs and additional services running alongside Builder.
If your organization is seeing an issue with an Effortless pattern, we will engage the engineering/professional services team you have collaborated with. It is likely that they will require some context/information, especially if you are developing/elaborating on the Effortless patterns and leveraging them outside of anything previously delivered with Chef. With that in mind, it's likely that, at a minimum, we'll need:
- Whether the pattern you are using involves 'scaffolding' - the wrapper configuration provided and maintained by Chef for core effortless concepts. If you are unsure of this, we should be able to figure this out from plans and references within your application configuration.
- Whether the package you are using is an Official Chef Habitat package (our Support SLAs apply to code we maintain and which you consume as part of the Effortless pattern, we will treat non-official packages with best-effort response times)
- The version/release/architecture of the system on which Habitat is running
- The Habitat plan, ideally bundled as a tar file and uploaded to the ticket
- The runhook file and how the runhook is called (depending on your CI/CD and whether your are experiencing build or runtime issues)
- Any other context you feel is relevant to the issue at hand (recent changes, behaviorial observations etc)
The Application groups concept applies to Chef Automate and we'll need a chef-automate gather-logs to understand event stream and application lifecycle visibility issues, in conjunction with logs from a failing node.
We'll leave it to your discretion to understand how this best applies to the issue you're experiencing and select the appropriate steps so we can review and resolve your issue.