-
Notifications
You must be signed in to change notification settings - Fork 294
Plugin Wanted: Publisher for Prometheus #1196
Comments
@mjbrender I also think that Prometheus publisher would be very useful. Alternatively - What do you think about having a processor plugin to format snap metrics Prometheus way? For features like this one: https://github.com/kubernetes/heapster/blob/master/docs/proposals/push-metrics.md instead of file publisher we could then use REST publisher. |
+1 |
Will 3rd option (i.e.here ?) have to include its own scheduler, same in case of node exporter ? At least the push gateway feature can use Snap scheduler. Snap Prometheus processor will require Push Gateways anyways , right ? |
@irom77 one way to deal with it might be to just buffer metrics in memory until the Prometheus scraper comes along to collect them, using the Snap scheduler to push them onto the buffer. Metrics would be dropped from the buffer based on age or buffer size, whether they've been collected or not to avoid memory blow-out. Obviously this comes with some resource overhead, but performance will be better than the file-backed option. |
Hey, I created an initial version that pushes the metrics to the Push Gateway (option 2) (as the least resistance initial path), it can be found here: https://github.com/hstack/snap-plugin-publisher-prometheus |
That's a great news @adragomir - thank you for your contribution! |
This issue will be resolved by the next running on pluginsync with |
@adragomir - thank you for your contribution! Your plugin will be added to plugin catalog in PR #1663, so I close this issue. |
I'd like to get a publisher that can play well with Prometheus. Given Prometheus has a pull model and Snap is designed for a push model, I could see a couple routes forward:
I think a distant 3rd option would be an endpoint service which we publish to and then use the Prometheus client library to consume it. That has the benefit of more efficient traffic using protobuffs, but adds complexity given it will be a long-running service.
Whatever the approach, it would be best to focus on a cloud native architecture given Prometheus' emphasis there, which means Snap is running in a container.
The text was updated successfully, but these errors were encountered: