I wonder whether there is just a small set of key metrics that basically everyone wants like CPU, memory, network IO that we could just implement on each supported platform.

Or is each deployment a special snowflake in this regard such that template authors should be defining these?

@spikecurtis it's a good inquiry. There is so much ambiguity around "compute resources" that I struggle to see how hard-coded metrics would be compatible with our product's tenet of flexibility. Some examples:

• Disk is consumed across both storage and inodes. In a massive npm codebase (many small files), you may run out of inodes before you run out of storage.
• There could be multiple disks attached to different mountpoints, further complicating "disk used".
• CPU can be presented across usr and sys or combined.
• Memory can be looked at from various perspectives similar to CPU.
• In containers and overprovisioning scenarios, it may be misleading to show the host's CPU, memory, etc.

I like the idea of defining these in blocks. In many cases though, the metrics might already be being collected somewhere else though. For example, if you're launching workspaces as pods in a Kubernetes cluster, there are already going to be a lot of metrics available via a Prometheus stack. Perhaps a type of block to connect these by specifying a Prom endpoint and query? I think both the simple exec definitions and a way to link existing metrics would be desirable.

This issue is becoming stale. In order to keep the tracker readable and actionable, I'm going close to this issue in 7 days if there isn't more activity.

It could be cool if there was a value_type = "tty", then we could preserve coloring/formatting on commands like git diff.

It'd be interesting if output would render as markdown... then you could do something like:

echo [$(git rev-parse --abbrev-ref HEAD)](https://github.com/coder/coder/tree/$(git rev-parse --abbrev-ref HEAD))

Which would render as:

[branch-name](https://github.com/coder/coder/tree/branch-name)

and be clickable in the UI...

value_type = "markdown|tty|code|string"...

I see a lot of potential for these. Talking to @bpmct and @ammario yesterday I can visualize it being used for metrics as well:

...
item {
  type = "metrics:usage"
  key = "Disk"
  value_cmd = "sh ./getDiskUsage.sh"
  value_cmd_interval = "1hour"
  value_total_usage = "2" // Only available for metrics:usage type and used for UI purposes to display "1GB of 2GB"
  value_unit = "GB" // When the value has a unit, used for UI
  ttl = "30days" // By default we don't save the results, but we can save it for an specified time and display a chart in the UI with those info
}

item {
  type = "metrics:execution" // This type would create an alias for the "make build" and store the execution time, so the user could track the performance of a command execution overtime. 
  key = "Build time"
  value_cmd = "make build"
  ttl = "30days"
}
...

How is this gonna work for docker/kubernetes where top and htop doesn’t show accurate data? cgroup stuff or using the Kubernetes metrics server?

@bpmct — probably one of those two methods, but that the decision is left to the user.

Are we going to include agent metadata in our Kubernetes example? Want to make sure we have a solid answer for monitoring Kubernetes CPU, memory, disk usage.

Yeah, we should. I probably won't go through that effort in my PR though.

Are we going to include agent metadata in our Kubernetes example? Want to make sure we have a solid answer for monitoring Kubernetes CPU, memory, disk usage.

I can update the templates after #6614 is merged.