You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just pass a new number as the argument to change it.
866
866
867
-
## Prometheus Support
867
+
## Prometheus support
868
868
869
-
Vegeta has a built-in Prometheus Exporter that may be enabled during attacks so that you can point any Prometheus instance to Vegeta instances and get some metrics about http requests performance and about the Vegeta process itself.
869
+
Vegeta has a built-in Prometheus Exporter that may be enabled during attacks so that you can point any Prometheus instance to Vegeta attack processes and monitor attack metrics.
870
870
871
-
To enable the Prometheus Exporter on the command line, use the "prometheus-addr" flag.
871
+
To enable the Prometheus Exporter on the command line, set the "prometheus-addr" flag.
872
872
873
873
A Prometheus HTTP endpoint will be available only during the lifespan of an attack and will be closed right after the attack is finished.
874
874
@@ -877,53 +877,22 @@ The following metrics are exposed:
877
877
*`request_bytes_in` - bytes count received from targeted servers by "url", "method" and "status"
878
878
*`request_bytes_out` - bytes count sent to targeted server by "url", "method" and "status"
879
879
*`request_seconds` - histogram with request latency and counters by "url", "method" and "status"
880
+
*`request_fail_count` - count of failed requests by "url", "method", "status" and "message"
Check file [lib/prom/grafana.json](lib/prom/grafana.json) with the source of this sample dashboard in Grafana.
884
885
885
-
### Samples
886
+
### Limitations
886
887
887
-
If you want to query P90 quantiles, for example, use "histogram_quantile(0.90, sum(rate(request_seconds_bucket[1m])) by (le, status))"
888
+
1. Prometheus scrapes metrics from a running vegeta attack process and assigns timestamps to samples on its server. This means result timestamps aren't accurate (i.e. they're scraping time, not result time).
889
+
2. Configuring Prometheus to scrape vegeta needs to happen out-of-band. That's a hassle!
890
+
3. Since there's no coordination between a vegeta attack process and a Prometheus server, an attack process will finish before Prometheus has the chance to scrape the latest observations.
888
891
889
-
### Prometheus Exporter example
890
892
891
-
* Create a docker-compose.yml
893
+
Why aren't we using pushgateway instead? See [this comment](https://github.com/tsenart/vegeta/pull/534#issuecomment-1629943731).
* Run `curl localhost:8880` to see plain Prometheus Exporter endpoint contents
915
-
916
-
* Open Prometheus server instance with your browser at http://localhost:9090
917
-
918
-
* Go to "Graph" and execute query `rate(request_seconds_sum[1m])` and then select the "Graph" tab to see a graph with latency over time
919
-
920
-
#### More resources
921
-
922
-
* See https://prometheus.io/docs/prometheus/latest/querying/basics/ for query details
923
-
924
-
* Use Grafana for creating stateful dashboards. Get a sample dashboard for Vegeta [here](grafana.json)
925
-
926
-
* For more elaborated scenarios, see https://github.com/flaviostutz/promster so that you can automatically register new Vegeta Prometheus Exporter instances to Prometheus in elastic scenarios.
895
+
There's [an issue](https://github.com/tsenart/vegeta/issues/637) tracking the proper solution to all these limitations which is a remote write integration.
0 commit comments