{"action":"created","issue":{"url":"https://api.github.com/repos/elastic/apm/issues/22","repository_url":"https://api.github.com/repos/elastic/apm","labels_url":"https://api.github.com/repos/elastic/apm/issues/22/labels{/name}","comments_url":"https://api.github.com/repos/elastic/apm/issues/22/comments","events_url":"https://api.github.com/repos/elastic/apm/issues/22/events","html_url":"https://github.com/elastic/apm/issues/22","id":383886684,"node_id":"MDU6SXNzdWUzODM4ODY2ODQ=","number":22,"title":"[agents] Read docker container id from filesystem","user":{"login":"roncohen","id":744,"node_id":"MDQ6VXNlcjc0NA==","avatar_url":"https://avatars0.githubusercontent.com/u/744?v=4","gravatar_id":"","url":"https://api.github.com/users/roncohen","html_url":"https://github.com/roncohen","followers_url":"https://api.github.com/users/roncohen/followers","following_url":"https://api.github.com/users/roncohen/following{/other_user}","gists_url":"https://api.github.com/users/roncohen/gists{/gist_id}","starred_url":"https://api.github.com/users/roncohen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/roncohen/subscriptions","organizations_url":"https://api.github.com/users/roncohen/orgs","repos_url":"https://api.github.com/users/roncohen/repos","events_url":"https://api.github.com/users/roncohen/events{/privacy}","received_events_url":"https://api.github.com/users/roncohen/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":11,"created_at":"2018-11-23T16:54:14Z","updated_at":"2018-11-27T15:16:16Z","closed_at":null,"author_association":"NONE","body":"Agents should try to read the current container ID from the local filesystem. Elasticsearch already [does this](https://github.com/elastic/elasticsearch/blob/06993e0c356cd549fdbea759e214aabd289510a6/server/src/main/java/org/elasticsearch/monitor/os/OsProbe.java#L188-L248). \r\n\r\nThere's previously been discussion around issues that could arise because the agent could be blocked while fetching this information. I'm not too concerned about blocking the agent startup for a little bit while we check if the file exists and read/parse it. It should only take a few milliseconds. If we start supporting AWS Lambda and similar we could skip the check outright based on an environment variable that is automatically set by the provider. \r\n\r\nThere are some complications involved in parsing the file so it would be nice if one of the agents buildt a reference implementation that others can take model their own implementation on.  \r\n\r\nPleas add the field to metadata as `system.container.id`.\r\n\r\nThe field will end up in Elasticsearch as `container.id`: https://github.com/elastic/ecs/blob/master/schemas/container.yml#L19-L23\r\n\r\n\r\n@elastic/apm-agent-devs Please link your issue or PR and then mark the checkbox when the implementation is merged:\r\n\r\n- [ ] - Java - https://github.com/elastic/apm-agent-java/issues/325\r\n- [ ] - Python https://github.com/elastic/apm-agent-python/issues/346\r\n- [ ] - Ruby - https://github.com/elastic/apm-agent-ruby/issues/253\r\n- [x] - Go - https://github.com/elastic/apm-agent-go/issues/328\r\n- [ ] - dotNet\r\n- [ ] - Node.js - https://github.com/elastic/apm-agent-nodejs/issues/693\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/elastic/apm/issues/comments/442095180","html_url":"https://github.com/elastic/apm/issues/22#issuecomment-442095180","issue_url":"https://api.github.com/repos/elastic/apm/issues/22","id":442095180,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0MjA5NTE4MA==","user":{"login":"watson","id":10602,"node_id":"MDQ6VXNlcjEwNjAy","avatar_url":"https://avatars3.githubusercontent.com/u/10602?v=4","gravatar_id":"","url":"https://api.github.com/users/watson","html_url":"https://github.com/watson","followers_url":"https://api.github.com/users/watson/followers","following_url":"https://api.github.com/users/watson/following{/other_user}","gists_url":"https://api.github.com/users/watson/gists{/gist_id}","starred_url":"https://api.github.com/users/watson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/watson/subscriptions","organizations_url":"https://api.github.com/users/watson/orgs","repos_url":"https://api.github.com/users/watson/repos","events_url":"https://api.github.com/users/watson/events{/privacy}","received_events_url":"https://api.github.com/users/watson/received_events","type":"User","site_admin":false},"created_at":"2018-11-27T15:16:16Z","updated_at":"2018-11-27T15:16:16Z","author_association":"MEMBER","body":"When I say blocking, I mean blocking in the technical sense. In Node.js _all_ I/O operations are non-blocking by default and the issue descriptions calls for switching that off for this task. This is probably fine, but every time we do this we have to be careful. By introducing a flag to switch this off we essentially add an escape hatch, so users who experience problems with it can disable it.\r\n\r\nI'm not an expert in this file. Will it always be virtual, might it also exist on cloud functions, but behave differently? I don't know the answers to these questions, but while I don't except any problems, I just wanted to be cautious."}}
{"actor":{"display_login":"watson"}}