docs: fix broken links (#2303)

Signed-off-by: hagen1778 <roman@victoriametrics.com>

app/vmalert/README.md

@@ -3,7 +3,7 @@
 `vmalert` executes a list of the given [alerting](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)
 or [recording](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/)
 rules against configured `-datasource.url`. For sending alerting notifications
-vmalert relies on [Alertmanager]((https://github.com/prometheus/alertmanager)) configured via `-notifier.url` flag.
+vmalert relies on [Alertmanager](https://github.com/prometheus/alertmanager) configured via `-notifier.url` flag.
 Recording rules results are persisted via [remote write](https://prometheus.io/docs/prometheus/latest/storage/#remote-storage-integrations)
 protocol and require `-remoteWrite.url` to be configured.
 Vmalert is heavily inspired by [Prometheus](https://prometheus.io/docs/alerting/latest/overview/)

docs/CHANGELOG.md

@@ -439,7 +439,7 @@ Released at 25-06-2021
 * FEATURE: vmstorage: reduce memory usage on a system with many CPU cores under high ingestion rate.
 
 * BUGFIX: prevent from adding new samples to deleted time series after the rotation of the inverted index (the rotation is performed once per `-retentionPeriod`). See [this comment](https://github.com/VictoriaMetrics/VictoriaMetrics/issues/1347#issuecomment-861232136) for details.
-* BUGFIX: vmstorage: reduce high disk write IO usage on systems with big number of CPU cores. The issue has been introduced in the release [v1.59.0](#v1590). See [this commit](aa9b56a046b6ae8083fa659df35dd5e994bf9115) and [this comment](https://github.com/VictoriaMetrics/VictoriaMetrics/issues/1338#issuecomment-863046999) for details.
+* BUGFIX: vmstorage: reduce high disk write IO usage on systems with big number of CPU cores. The issue has been introduced in the release [v1.59.0](#v1590). See [this commit](https://github.com/VictoriaMetrics/VictoriaMetrics/commit/aa9b56a046b6ae8083fa659df35dd5e994bf9115) and [this comment](https://github.com/VictoriaMetrics/VictoriaMetrics/issues/1338#issuecomment-863046999) for details.
 * BUGFIX: vmstorage: prevent from incorrect stats collection when multiple concurrent queries execute the same tag filter. This may help reducing CPU usage under certain workloads. See [this issue](https://github.com/VictoriaMetrics/VictoriaMetrics/issues/1338).
 * BUGFIX: vmselect: return the last timestamp for the max / min value from `tmax_over_time(m[d])` and `tmin_over_time(m[d])` [MetricsQL functions](https://docs.victoriametrics.com/MetricsQL.html) as most users expect. See also [this issue](https://github.com/prometheus/prometheus/issues/8966).
 * BUGFIX: vmselect: return the expected value for `increase_pure()` [MetricsQL function](https://docs.victoriametrics.com/MetricsQL.html) after a gap in a time series. Previously incorrect too big value could be returned after the gap from `increase_pure()`.

docs/Cluster-VictoriaMetrics.md

@@ -840,7 +840,7 @@ Below is the output for `/path/to/vmstorage -help`:
 
 ## VictoriaMetrics Logo
 
-[Zip](VM_logo.zip) contains three folders with different image orientation (main color and inverted version).
+[Zip](https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/VM_logo.zip) contains three folders with different image orientation (main color and inverted version).
 
 Files included in each folder:
 

docs/README.md

@@ -1455,6 +1455,27 @@ See the full description of flags [here](#list-of-command-line-flags).
 
 ## Data migration
 
+### From VictoriaMetrics
+
+The simplest way to migrate data from one single-node (source) to another (destination), or from one vmstorage node 
+to another do the following:
+1. Stop the VictoriaMetrics (source) with `kill -INT`;
+2. Copy (via [rsync](https://en.wikipedia.org/wiki/Rsync) or any other tool) the entire folder specified 
+via `-storageDataPath` from the source node to the empty folder at the destination node.
+3. Once copy is done, stop the VictoriaMetrics (destination) with `kill -INT` and verify that 
+its `-storageDataPath` points to the copied folder from p.2;
+4. Start the VictoriaMetrics (destination). The copied data should be now available.
+
+Things to consider when copying data:
+1. Data formats between single-node and vmstorage node aren't compatible and can't be copied.
+2. Copying data folder means complete replacement of the previous data on destination VictoriaMetrics.
+
+For more complex scenarios like single-to-cluster, cluster-to-single, re-sharding or migrating only a fraction
+of data - see [vmctl. Migrating data from VictoriaMetrics](https://docs.victoriametrics.com/vmctl.html#migrating-data-from-victoriametrics).
+
+
+### From other systems
+
 Use [vmctl](https://docs.victoriametrics.com/vmctl.html) for data migration. It supports the following data migration types:
 
 * From Prometheus to VictoriaMetrics

docs/Single-server-VictoriaMetrics.md

@@ -1459,6 +1459,27 @@ See the full description of flags [here](#list-of-command-line-flags).
 
 ## Data migration
 
+### From VictoriaMetrics
+
+The simplest way to migrate data from one single-node (source) to another (destination), or from one vmstorage node 
+to another do the following:
+1. Stop the VictoriaMetrics (source) with `kill -INT`;
+2. Copy (via [rsync](https://en.wikipedia.org/wiki/Rsync) or any other tool) the entire folder specified 
+via `-storageDataPath` from the source node to the empty folder at the destination node.
+3. Once copy is done, stop the VictoriaMetrics (destination) with `kill -INT` and verify that 
+its `-storageDataPath` points to the copied folder from p.2;
+4. Start the VictoriaMetrics (destination). The copied data should be now available.
+
+Things to consider when copying data:
+1. Data formats between single-node and vmstorage node aren't compatible and can't be copied.
+2. Copying data folder means complete replacement of the previous data on destination VictoriaMetrics.
+
+For more complex scenarios like single-to-cluster, cluster-to-single, re-sharding or migrating only a fraction
+of data - see [vmctl. Migrating data from VictoriaMetrics](https://docs.victoriametrics.com/vmctl.html#migrating-data-from-victoriametrics).
+
+
+### From other systems
+
 Use [vmctl](https://docs.victoriametrics.com/vmctl.html) for data migration. It supports the following data migration types:
 
 * From Prometheus to VictoriaMetrics

docs/operator/VictoriaMetrics-Operator.md

@@ -13,12 +13,12 @@ So you can use familiar CRD objects: `ServiceMonitor`, `PodMonitor`, `Prometheus
 - `VMRule` - defines alerting or recording rules.
 - `VMProbe` - defines a probing configuration for targets with blackbox exporter.
 
-Besides, operator allows you to manage VictoriaMetrics applications inside kubernetes cluster and simplifies this process [quick-start](/Operator/quick-start.html) 
-With CRD (Custom Resource Definition) you can define application configuration and apply it to your cluster [crd-objects](/Operator/api.html). 
+Besides, operator allows you to manage VictoriaMetrics applications inside kubernetes cluster and simplifies this process [quick-start](https://docs.victoriametrics.com/operator/quick-start.html) 
+With CRD (Custom Resource Definition) you can define application configuration and apply it to your cluster [crd-objects](https://docs.victoriametrics.com/operator/api.html). 
 
 Operator simplifies VictoriaMetrics cluster installation, upgrading and managing.
  
- It has integration with VictoriaMetrics `vmbackupmanager` - advanced tools for making backups. Check backup [docs](/Operator/backups.html)
+It has integration with VictoriaMetrics `vmbackupmanager` - advanced tools for making backups. Check backup [docs](https://docs.victoriametrics.com/operator/backups.html)
 
 ## Use cases
 
@@ -33,17 +33,16 @@ VictoriaMetrics provides [helm charts](https://github.com/VictoriaMetrics/helm-c
 
 ## Configuration
 
- Operator configured by env variables, list of it can be found at [link](/vars.html)
+Operator configured by env variables, list of it can be found at [link](https://docs.victoriametrics.com/operator/vars.html)
 
 It defines default configuration options, like images for components, timeouts, features.
 
 
 ## Kubernetes' compatibility versions
 
-operator tested at kubernetes versions 
-from 1.16 to 1.22
+Operator tested at kubernetes versions from 1.16 to 1.22.
 
- For clusters version below 1.16 you must use legacy CRDs from [path](config/crd/legacy) 
+For clusters version below 1.16 you must use legacy CRDs from [path](https://github.com/VictoriaMetrics/operator/tree/master/config/crd/legacy) 
 and disable CRD controller with flag: `--controller.disableCRDOwnership=true`
 
 ## Troubleshooting
@@ -58,7 +57,7 @@ Error from server (Invalid): error when creating "release/crds/crd.yaml": Custom
 
 ## Development
 
-- operator-sdk verson v1.0.0 +  [https://github.com/operator-framework/operator-sdk]
+- [operator-sdk](https://github.com/operator-framework/operator-sdk) version v1.0.0+  
 - golang 1.15 +
 - minikube or kind
 

docs/operator/auth.MD

@@ -142,7 +142,7 @@ EOF
 
 ## Basic auth for targets
 
-To authenticate a `VMServiceScrape`s over a metrics endpoint use [`basicAuth`](../api.html#basicauth)
+To authenticate a `VMServiceScrape`s over a metrics endpoint use [`basicAuth`](https://docs.victoriametrics.com/operator/api.html#basicauth)
 
 ```yaml
 cat <<EOF | kubectl apply -f -

docs/operator/backups.MD

@@ -71,7 +71,7 @@ It's needed to make consistent backups for each storage node.
 
  You can read more about backup configuration options and mechanics [here](https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmbackup)
  
- Possible configuration options for backup crd can be found at [link](/docs/api.html#vmbackup)
+ Possible configuration options for backup crd can be found at [link](https://docs.victoriametrics.com/operator/api.html#vmbackup)
  
  
 ## Restoring backups

docs/vmalert.md

@@ -7,7 +7,7 @@ sort: 4
 `vmalert` executes a list of the given [alerting](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)
 or [recording](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/)
 rules against configured `-datasource.url`. For sending alerting notifications
-vmalert relies on [Alertmanager]((https://github.com/prometheus/alertmanager)) configured via `-notifier.url` flag.
+vmalert relies on [Alertmanager](https://github.com/prometheus/alertmanager) configured via `-notifier.url` flag.
 Recording rules results are persisted via [remote write](https://prometheus.io/docs/prometheus/latest/storage/#remote-storage-integrations)
 protocol and require `-remoteWrite.url` to be configured.
 Vmalert is heavily inspired by [Prometheus](https://prometheus.io/docs/alerting/latest/overview/)