profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/free/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

free/sql_exporter 334

Database agnostic SQL exporter for Prometheus

free/prometheus 41

The Prometheus monitoring system and time series database.

free/concurrent-writer 34

Highly concurrent drop-in replacement for bufio.Writer

free/rust-prometheus 1

Prometheus instrumentation library for Rust applications

free/alertmanager 0

Prometheus Alertmanager

free/awesome-go 0

A curated list of awesome Go frameworks, libraries and software

free/docs 0

Prometheus documentation: content and static site generator

free/promcache 0

Prometheus Caching HTTP Proxy

free/sachet 0

SMS alerts for Prometheus' Alertmanager

pull request commentprometheus/docs

instrumenting/clientlibs: add process_threads

Also, is the threading model the same accross all OS? Would that metric mean the same for different OS?

I believe a lot of things are not standard across OSs. E.g. I believe Fuchsia does not have file descriptors. And for all I know there may be OSs without a concept or resident vs. virtual memory.

But overall, I believe all widely used OSs have the concept of threads. And again, the documentation says "leave it out if it doesn't make sense", so there doesn't seem to be a requirement that all process metrics make sense on every single OS. I mean some of the things Prometheus monitors aren't even processes.

lucab

comment created time in 2 months

pull request commentprometheus/docs

instrumenting/clientlibs: add process_threads

One argument in favor of adding process_threads to the list of standard process metrics, is that on Linux it is one of the fields provided by /proc/<pid>/stat (search for num_threads), which is the most likely source for all other process metrics.

Also, the document already says "client libraries SHOULD prefer leaving out the corresponding metric over exporting bogus, inaccurate, or special values", so it's not like this addition will break any client library's compatibility or anything. E.g. if Java uses a different mechanism to retrieve thread count (and Java threads are not necessarily the same as OS threads), then it can simply leave this out (which I suspect it already does with all process metrics).

lucab

comment created time in 2 months

pull request commenttikv/rust-prometheus

Export thread count from `process_collector`

I'd be happy to see the "Number of OS threads" metrics standardized upstream, and once that is published we can promptly merge this.

Is anything like that being worked on? On the one hand the Golang library has go_threads and Java has jvm_threads_current (and I'm sure other language libraries have their own).

On the other hand, the only other way of getting this metric (other than everyone rolling their own implementation, which is what we ended up doing) is to enable the (by default disabled) processes collector of node-exporter (above which there's a warning that the collector may be disabled due to "prolonged runtime" or "significant resource usage"). While adding the metric here boils down to simply exporting a value that has already been retrieved from the OS.

I'm not going to insist that this be merged, but the fact that process_threads is not a standard process metric is not a good reason against exporting it regardless.

free

comment created time in 2 months

pull request commenttikv/rust-prometheus

Export thread count from `process_collector`

Gentle nudge.

free

comment created time in 2 months

push eventfree/rust-prometheus

Alin Sinpalean

commit sha 40b4d88a46dd8f3f1db7a0f87111127e40736e6e

Actually export thread count. And fix the unit test. Signed-off-by: Alin Sinpalean <alin.sinpalean@gmail.com>

view details

push time in 3 months

push eventfree/rust-prometheus

Alin Sinpalean

commit sha ce11f255a9f978d5edc20dcc573abd40dfed31c3

Export thread count from `process_collector` This simply retrieves and exports the value of the `num_threads` field from the already populated `procfs::process::Stat` that CPU, memory and start time are sourced. Signed-off-by: Alin Sinpalean <alin.sinpalean@gmail.com>

view details

push time in 3 months

push eventfree/rust-prometheus

Alin Sinpalean

commit sha b2d63493cfed3aec4707ecc06d2a2c299f956887

Export thread count from `process_collector` This simply retrieves and exports the value of the `num_threads` field from the already populated `procfs::process::Stat` that CPU, memory and start time are sourced. Signed-off-by: Alin Sinpalean alin.sinpalean@gmail.com

view details

push time in 3 months

PR opened tikv/rust-prometheus

Export thread count from `process_collector`

This simply retrieves and exports the value of the num_threads field from the already populated procfs::process::Stat that CPU, memory and start time are sourced.

+14 -3

0 comment

1 changed file

pr created time in 3 months

create barnchfree/rust-prometheus

branch : process_collector-export-process_threads

created branch time in 3 months