diff --git a/README.md b/README.md
index c76406c..5eef96a 100644
--- a/README.md
+++ b/README.md
@@ -86,8 +86,8 @@ Because the `github.com/prometheus/client_golang` is too complex and is hard to
 #### Why the `metrics.WritePrometheus` doesn't expose documentation for each metric?
 
 Because this documentation is ignored by Prometheus. The documentation is for users.
-Just add comments in the source code or in other suitable place explaining each metric
-exposed from your application.
+Just give meaningful names to the exported metrics or add comments in the source code
+or in other suitable place explaining each metric exposed from your application.
 
 
 #### How to implement [CounterVec](https://godoc.org/github.com/prometheus/client_golang/prometheus#CounterVec) in `metrics`?
@@ -98,7 +98,7 @@ instead of `CounterVec.With`. See [this example](https://pkg.go.dev/github.com/V
 
 #### Why [Histogram](http://godoc.org/github.com/VictoriaMetrics/metrics#Histogram) buckets contain `vmrange` labels instead of `le` labels like in Prometheus histograms?
 
-Buckets with `vmrange` labels occupy less disk space comparing to Promethes-style buckets with `le` labels,
+Buckets with `vmrange` labels occupy less disk space compared to Promethes-style buckets with `le` labels,
 because `vmrange` buckets don't include counters for the previous ranges. [VictoriaMetrics](https://github.com/VictoriaMetrics/VictoriaMetrics) provides `prometheus_buckets`
 function, which converts `vmrange` buckets to Prometheus-style buckets with `le` labels. This is useful for building heatmaps in Grafana.
 Additionally, its' `histogram_quantile` function transparently handles histogram buckets with `vmrange` labels.
diff --git a/metrics.go b/metrics.go
index bda1cb9..a6ef879 100644
--- a/metrics.go
+++ b/metrics.go
@@ -47,8 +47,30 @@ func WritePrometheus(w io.Writer, exposeProcessMetrics bool) {
 
 // WriteProcessMetrics writes additional process metrics in Prometheus format to w.
 //
-// Various `go_*` and `process_*` metrics are exposed for the currently
-// running process.
+// The following `go_*` and `process_*` metrics are exposed for the currently
+// running process. Below is a short description for the exposed `process_*` metrics:
+//
+//     - process_cpu_seconds_system_total - CPU time spent in syscalls
+//     - process_cpu_seconds_user_total - CPU time spent in userspace
+//     - process_cpu_seconds_total - CPU time spent by the process
+//     - process_major_pagefaults_total - page faults resulted in disk IO
+//     - process_minor_pagefaults_total - page faults resolved without disk IO
+//     - process_resident_memory_bytes - recently accessed memory (aka RSS or resident memory)
+//     - process_resident_memory_peak_bytes - the maximum RSS memory usage
+//     - process_resident_memory_anon_bytes - RSS for memory-mapped files
+//     - process_resident_memory_file_bytes - RSS for memory allocated by the process
+//     - process_resident_memory_shared_bytes - RSS for memory shared between multiple processes
+//     - process_virtual_memory_bytes - virtual memory usage
+//     - process_virtual_memory_peak_bytes - the maximum virtual memory usage
+//     - process_num_threads - the number of threads
+//     - process_start_time_seconds - process start time as unix timestamp
+//
+//     - process_io_read_bytes_total - the number of bytes read via syscalls
+//     - process_io_written_bytes_total - the number of bytes written via syscalls
+//     - process_io_read_syscalls_total - the number of read syscalls
+//     - process_io_write_syscalls_total - the number of write syscalls
+//     - process_io_storage_read_bytes_total - the number of bytes actually read from disk
+//     - process_io_storage_written_bytes_total - the number of bytes actually written to disk
 //
 // The WriteProcessMetrics func is usually called in combination with writing Set metrics
 // inside "/metrics" handler: