PushConfig represents a struct package uses for pushing
metrics to remote destination. Having a structure
helps to extend functionality in the future, without
touching the signature of existing functions.
For example, `PushConfig` supports custom HTTP headers
via `Headers` param.
Updates https://github.com/VictoriaMetrics/metrics/issues/52
Updates https://github.com/VictoriaMetrics/metrics/issues/36
Co-authored-by: hagen1778 <roman@victoriametrics.com>
It is unclear how and when to reset summary - it is smoothed during the Go app uptime.
On the other hand, histogram buckets can be wrapped into increase() or rate() in order
to calculate the histogram distribution on arbitrary time range.
Limit the number of buckets per Go runtime histogram to 30 in order to prevent from high cardinality issues.
- Expose Go runtime histograms as summaries, since they have too many buckets,
which may lead to high cardinality issues at scraper side.
- Expose go_gc_pauses_seconds summary
- Document exposed go_* metrics
* go_metrics: adds new runtime metrics
go_sched_latency_seconds - Distribution of the time goroutines have spent in the scheduler in a runnable state before actually running
go_mutex_wait_total_seconds - Approximate cumulative time goroutines have spent blocked on a sync.Mutex or sync.RWMutex
https://github.com/VictoriaMetrics/metrics/issues/54
* fixes data race
* add tests
* wip
* wip
---------
Co-authored-by: Aliaksandr Valialkin <valyala@victoriametrics.com>
* process_metrics: adds metrics for windows OS
* windows: fixes build constraints
* bumps github ci go to 1.20 version
* bumps go version at go.mod
* go mod vendor
It is better to just log the error once if /proc/self/io cannot be opened,
without exposing additional counters.
The error message should contain directions on how to fix the error.
Updates https://github.com/VictoriaMetrics/metrics/issues/42
* linux process metrics: add error handling for metrics from `/proc/self/io`
* linux process metrics: address review feedback
* linux process metrics: restore error handling for self/stat metrics
* linux process metrics: implement self/io error check with `init` function
This is needed in order to support `net/url.URL.Redacted()` method used in push.go
This method appeared in Go1.15 - see https://tip.golang.org/doc/go1.15
This should guarantee that metrics are pushed regularly with the provided interval.
If the remote storage cannot keep up with push frequency, then timeout errors will be logged.
This reverts commit 55d5027c97e2484d3e2b63ec6eb54845a8f69227.
Reason for revert: the process_resident_memory_anonymous_bytes and process_resident_memory_pagecache_bytes metrics have been substituted
by more complete set of metrics in the commit 5a49bb8e88e070e43cbffaa68776259f11f6c053:
* process_resident_memory_anon_bytes
* process_resident_memory_file_bytes
* process_resident_memory_shared_bytes
Metrics are:
process_io_read_bytes_total - the number of bytes read via io syscalls such as read and pread
process_io_written_bytes_total - the number of bytes written via io syscalls such as write and pwrite
process_io_read_syscalls_total - the number of read syscalls such as read and pread
process_io_write_syscalls_total - the number of write syscalls such as write and pwrite
process_io_storage_read_bytes_total - the number of bytes read from storage layer
process_io_storage_written_bytes_total - the number of bytes written to storage layer
Log-based histograms provide lower estimation error for the same number of buckets compared to log-linear histograms.
For example, the current Histogram implementation splits each decimal range (10^n .. 10^(n+1)] into 18 buckets.
These buckets have the following bounds:
- for log-linear histogram: (1 .. 1.5], (1.5 .. 2], (2 .. 2.5], ... (9.5 .. 10]
- for log-based histogram: (1 .. 1.136], (1.136 .. 1.292], ... (8.799 ... 10]
The maximum estimated error for log-linear histogram is reached in the first bucket per each decimal range and equals to 1.5-1=0.5 or 50%.
The maximum estimated error for log-based histogram is constant across buckets and equals to 1.136-1=0.136 or 13.6%.
This means that log-based histogram improves histogram accuracy by up to 50%/13.6% = 3.6 times when using the same number of buckets.
Further reading - https://linuxczar.net/blog/2020/08/13/histogram-error/
