Issue / Proposed Feature
This is more of a feature request than it is an issue. I'm going to tweak the rest of the template appropriately.
In addition to instance index, Diego also provides an instance_id field that more accurately identifies an individual container. It would be helpful for app operators if the Process Stats endpoint (GET /v3/apps/:guid/processes/:type/stats) included this id in its response.
Context
Developers can see instance_id in their logs so they would be able to more easily correlate info from the stats endpoint with what they are seeing there:
Example logs:
2022-05-26T16:16:11.09-0600 [RTR/0] OUT dora.dirt-fairy.capi.land - [2022-05-26T22:16:11.073797015Z] "GET / HTTP/2.0" 200 0 13 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:100.0) Gecko/20100101 Firefox/100.0" "24.9.143.210:53261" "10.244.0.139:61002" x_forwarded_for:"24.9.143.210" x_forwarded_proto:"https" vcap_request_id:"e44db4a0-a5b4-4cea-43de-283078631d83" response_time:0.024315 gorouter_time:0.000436 app_id:"34ac676f-5adc-4605-a412-c0a69eb2dbaf" app_index:"0" instance_id:"6907c81e-99c4-4322-4594-ac1d" x_cf_routererror:"-" x_b3_traceid:"107759ce815e7d6518d96017570f490b" x_b3_spanid:"18d96017570f490b" x_b3_parentspanid:"-" b3:"107759ce815e7d6518d96017570f490b-18d96017570f490b"
This information is available on the ActualLRP resource that the Process Stats endpoint is already referencing under the instance_guid field so it already there for Cloud Controller to consume:
[5] pry(VCAP::CloudController)> bbs_client.lrp_instances(ProcessModel.first)
=> [<Diego::Bbs::Models::ActualLRP: actual_lrp_key: <Diego::Bbs::Models::ActualLRPKey: process_guid: "34ac676f-5adc-4605-a412-c0a69eb2dbaf-96a9abd2-ee3a-42ad-8a7b-ff2f4bd695cb", index: 0, domain: "cf-apps">, actual_lrp_instance_key: <Diego::Bbs::Models::ActualLRPInstanceKey: instance_guid: "6907c81e-99c4-4322-4594-ac1d", cell_id: "78f750ce-2c4d-439f-9dea-0acd2f010bde">, actual_lrp_net_info: <Diego::Bbs::Models::ActualLRPNetInfo: address: "10.244.0.139", ports: [<Diego::Bbs::Models::PortMapping: container_port: 8080, host_port: 61000, container_tls_proxy_port: 61001, host_tls_proxy_port: 61002>, <Diego::Bbs::Models::PortMapping: container_port: 8080, host_port: 61000, container_tls_proxy_port: 61443, host_tls_proxy_port: 61003>, <Diego::Bbs::Models::PortMapping: container_port: 2222, host_port: 61001, container_tls_proxy_port: 61002, host_tls_proxy_port: 61004>], instance_address: "10.255.146.163", preferred_address: :HOST>, crash_count: 0, crash_reason: "", state: "RUNNING", placement_error: "", since: 1653602948459414637, modification_tag: <Diego::Bbs::Models::ModificationTag: epoch: "5dfdfbce-8ec8-46e6-7dbc-e484bf909c3c", index: 2>, presence: :ORDINARY, actual_lrp_internal_routes: []>]
Eventually it would be nice to wire this through to the CLI so that it could show the id as well (or a portion of it). In addition to improving the app operator's debugging experience this also helps open the door for instance representations that don't rely on the numeric instance indices.
Acceptance Criteria
AS AN App Developer
WHEN I Have cf pushed an app and make the following API request to view the stats for one of its processes
curl "https://api.example.org/v3/processes/[guid]/stats" \
-X GET \
-H "Authorization: bearer [token]"
THEN I See the LRP's instance_id along with the other instance information in the response.
HTTP/1.1 200 OK
Content-Type: application/json
{
"resources": [
{
"type": "web",
"index": 0,
"state": "RUNNING",
"usage": {
"time": "2016-03-23T23:17:30.476314154Z",
"cpu": 0.00038711029163348665,
"mem": 19177472,
"disk": 69705728
},
"host": "10.244.16.10",
"instance_id": "6907c81e-99c4-4322-4594-ac1d",
"instance_ports": [
{
"external": 64546,
"internal": 8080,
"external_tls_proxy_port": 61002,
"internal_tls_proxy_port": 61003
}
],
"uptime": 9042,
"mem_quota": 268435456,
"disk_quota": 1073741824,
"fds_quota": 16384,
"isolation_segment": "example_iso_segment",
"details": null
}
]
}
Notes:
Issue / Proposed Feature
This is more of a feature request than it is an issue. I'm going to tweak the rest of the template appropriately.
In addition to instance index, Diego also provides an
instance_idfield that more accurately identifies an individual container. It would be helpful for app operators if the Process Stats endpoint (GET /v3/apps/:guid/processes/:type/stats) included this id in its response.Context
Developers can see
instance_idin their logs so they would be able to more easily correlate info from the stats endpoint with what they are seeing there:Example logs:
This information is available on the
ActualLRPresource that the Process Stats endpoint is already referencing under theinstance_guidfield so it already there for Cloud Controller to consume:Eventually it would be nice to wire this through to the CLI so that it could show the id as well (or a portion of it). In addition to improving the app operator's debugging experience this also helps open the door for instance representations that don't rely on the numeric instance indices.
Acceptance Criteria
AS AN App Developer
WHEN I Have
cf pushed an app and make the following API request to view the stats for one of its processesTHEN I See the LRP's
instance_idalong with the other instance information in the response.Notes:
idinstead ofinstance_idin the API response?