docs/vmagent.md: mention that sample_limit option has no sense when stream parsing is enabled

app/vmagent/README.md

@@ -277,6 +277,9 @@ It may be useful for performing `vmagent` rolling update without scrape loss.
       'match[]': ['{__name__!=""}']
   ```
 
+  Note that `sample_limit` option doesn't work if stream parsing is enabled, since the pearsed data is pushed to remote storage as soon as it is parsed. So `sample_limit` option
+  has no sense during stream parsing.
+
 * It is recommended to increase `-remoteWrite.queues` if `vmagent_remotewrite_pending_data_bytes` metric exported at `http://vmagent-host:8429/metrics` page constantly grows.
 
 * If you see gaps on the data pushed by `vmagent` to remote storage when `-remoteWrite.maxDiskUsagePerURL` is set, then try increasing `-remoteWrite.queues`.

docs/vmagent.md

@@ -277,6 +277,9 @@ It may be useful for performing `vmagent` rolling update without scrape loss.
       'match[]': ['{__name__!=""}']
   ```
 
+  Note that `sample_limit` option doesn't work if stream parsing is enabled, since the pearsed data is pushed to remote storage as soon as it is parsed. So `sample_limit` option
+  has no sense during stream parsing.
+
 * It is recommended to increase `-remoteWrite.queues` if `vmagent_remotewrite_pending_data_bytes` metric exported at `http://vmagent-host:8429/metrics` page constantly grows.
 
 * If you see gaps on the data pushed by `vmagent` to remote storage when `-remoteWrite.maxDiskUsagePerURL` is set, then try increasing `-remoteWrite.queues`.

docs/vmalert.md

@@ -21,7 +21,6 @@ may fail;
 * by default, rules execution is sequential within one group, but persisting of execution results to remote
 storage is asynchronous. Hence, user shouldn't rely on recording rules chaining when result of previous
 recording rule is reused in next one;
-* there is no `query` function support in templates yet;
 * `vmalert` has no UI, just an API for getting groups and rules statuses.
 
 ### QuickStart