Container unique id for metrics reporting

I’m developing a custom metrics reporting and auto-scaling solution for my aptible environment.
It would be helpful to have a reliable way to pluck a unique_id per container for reporting from multiple containers running an app.

hostname (from shell) seems to return a hash (12 hex digits) that is presumably unique and is used as the prefix for reporting logs to Papertrail according to this post. The post also refers to an env variable APTIBLE_PROCESS_INDEX but either it’s not visible in ephemeral clones created via CLI aptible ssh command or it’s been deprecated.

I’ll go with hostname for now but curious if there’s another preferred variable.

hostname (from shell) seems to return a hash (12 hex digits) that is presumably unique and is used as the prefix for reporting logs to Papertrail

That is indeed a (truncated) container ID. You’ll find it in your logs in Papertrail, as well as the metrics in the Dashboard.

The post also refers to an env variable APTIBLE_PROCESS_INDEX but either it’s not visible in ephemeral clones created via CLI aptible ssh command or it’s been deprecated.

This variable is not present in aptible ssh sessions, because they’re not instances of any particular service.

That variable is however present for your app containers. You can find the documentation for it here: https://www.aptible.com/documentation/enclave/reference/containers/environment.html#aptible-process-index

To compose a unique ID, you should use this variable in combination with APTIBLE_PROCESS_TYPE. The pair of two variables is unique for all containers in a given release of your app.

I’ll go with hostname for now but curious if there’s another preferred variable.

The two variables differ in one way:

  • The container ID is unique across releases. That is, if you redeploy your app, all the containers will get new container IDs, and new hostnames.
  • The APTIBLE_PROCESS_TYPE/ APTIBLE_PROCESS_INDEX pair is not be unique across releases. When you redeploy your app, new containers will use the same values as containers from the past release (you could however use the APTIBLE_RELEASE_HREF variable to work around this).

For your use case, the container ID / hostname is probably more appropriate.