Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New network and system fields #288

Closed
8 of 43 tasks
jalvz opened this issue Jun 30, 2020 · 8 comments
Closed
8 of 43 tasks

New network and system fields #288

jalvz opened this issue Jun 30, 2020 · 8 comments

Comments

@jalvz
Copy link
Contributor

jalvz commented Jun 30, 2020

Use case originated by RUM, see comment

Proposed fields

Optional fields, all agents

  • metadata
  • transaction context
Intake API field Elasticsearch field Elasticsearch Type
system.cpu.cores system.cpu.cores integer
system.memory.total system.memory.total long
network.effective_type network.effective_type keyword
network.rtt network.rtt integer
network.downlink network.downlink double
network.downlink_max network.downlink_max double
network.physical network.physical keyword

Optional fields, RUM only:

  • transaction context
Intake API field Elasticsearch field Elasticsearch Type
page.saveData page.saveData boolean
page.servedViaServiceWorker page.servedViaServiceWorker keyword

system.cpu.cores and system.memory.total are aligned with corresponding Metricbeat fields, even if not in ECS.

If this proposal is approved, network.* fields will be proposed to ECS.

Vote

Agent Yes No Indifferent N/A Link to issue
UI
Server
issues/3657
.NET
Go
Java
Node.js
PHP
Python
Ruby
RUM
pull/752
@axw
Copy link
Member

axw commented Jul 2, 2020

I think none of the backend agents will send these fields, but it would be great to get some agreement nevertheless. @elastic/apm-agent-devs could you please take a look in the next week or so?

I think that system.memory.total could be very useful for serverless/lambda, where pricing is typically in "GB seconds". i.e. the cost is based on the amount of time your function runs, and the amount of provisioned memory. So it would be interesting for measuring the cost of running lambdas. CC @basepi

@felixbarny
Copy link
Member

We already report system.memory.total as metrics: https://www.elastic.co/guide/en/apm/agent/java/current/metrics.html#metrics-system

Do you think backend agents should collect that metric on a per-transaction level, too?

@axw
Copy link
Member

axw commented Jul 2, 2020

@felixbarny I haven't come across any use cases that would need that, so I don't think so.

@jalvz
Copy link
Contributor Author

jalvz commented Aug 10, 2020

Hey there - I assume all backend agents will be indifferent, but can you tick boxes / raise comments?
Thanks!

@gregkalapos
Copy link
Contributor

We already report system.memory.total as metrics: https://www.elastic.co/guide/en/apm/agent/java/current/metrics.html#metrics-system

Do you think backend agents should collect that metric on a per-transaction level, too?

Same on .NET, we also send system.memory.total (inspired by the Java agent), similarly only as a metric, not on transaction level.

@felixbarny
Copy link
Member

We've talked about adding this to the RUM intake only. Is this still what's planned?

@jalvz
Copy link
Contributor Author

jalvz commented Aug 10, 2020

yes! (as far as i know)

@jalvz
Copy link
Contributor Author

jalvz commented Aug 14, 2020

So as everyone seems OK with this, I'll close and try to move forward.
Thanks all!

@jalvz jalvz closed this as completed Aug 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants