Hi all!
Hope not too late for the discussion. I would like to revive it as I find
it really useful for Knative and any serverless framework. As a Knative
contributor, working also on the monitoring side of the project, here is my
pov:
a) OpenFaas as an example (mentioned earlier above)
Just to throw my 2c in, we've been battling with this problem at (company)
as we move more services to a serverless model for our customer facing
things. Chiefly the issue of metrics aggregation for services that can't
easily track their own state across multiple requests. For us, there's just
too
What properties would an ideal OpenMetrics push receiver have? In
particular, I am wondering:
- What tradeoff would it make when metric ingestion is slower than metric
production? Backpressure or drop data?
- What are the semantics of pushing a counter?
- Where would the data move from there, and
Here’s the documentation for using M3 coordinator (with it without M3
aggregator) with a backend that has a Prometheus Remote Write receiver:
https://m3db.io/docs/how_to/any_remote_storage/
Would be more than happy to do a call some time on this topic, the more
we’ve looked at this it’s a client
FWIW we have been experimenting with users pushing OpenMetrics protobuf
payloads quite successfully, but only sophisticated exporters that can
guarantee no collisions of time series and generate their own monotonic
counters, etc are using this at this time.
If you're looking for a solution that
With respect to OpenMetrics push, we had something very similar at $prevco
that pushed something that looked very similar to the protobuf payload of
OpenMetrics (but was Thrift snapshot of an aggregated set of metrics from
in process) that was used by short running tasks (for Jenkins, Flink jobs,
On 22.06.21 11:26, Tobias Schmidt wrote:
>
> Last night I was wondering if there are any other common interfaces
> available in serverless environments and noticed that all products by AWS
> (Lambda) and GCP (Functions, Run) at least provide the option to handle log
> streams, sometimes even log
On Tue, Jun 22, 2021 at 12:09 PM Richard Hartmann <
richih.mailingl...@gmail.com> wrote:
> This has come up in the context of OM, OTel, and TAG Observability. My
> own thinking largely mirrors beorn's & grobie's: In a perfect world
> the orchestration layer has all the information and interfaces
This has come up in the context of OM, OTel, and TAG Observability. My
own thinking largely mirrors beorn's & grobie's: In a perfect world
the orchestration layer has all the information and interfaces
required and billing knows about the required datapaths, NB:
Monitoring usually has higher speed
Thanks for bringing up this topic Bartek and your great insights Björn!
On Sat, Jun 19, 2021 at 12:16 AM Bjoern Rabenstein
wrote:
> On 15.06.21 20:59, Bartłomiej Płotka wrote:
> >
> > Let's now talk about FaaS/Serverless.
>
> Excellent! That's my 2nd favorite topic after histograms. (And while
On 15.06.21 20:59, Bartłomiej Płotka wrote:
>
> Let's now talk about FaaS/Serverless.
Excellent! That's my 2nd favorite topic after histograms. (And while I
provably talked about histograms as my favorite topic since early
2015, I have only started to talk about FaaS/Serverless as an
important
Hi All,
Prometheus has seen the fashion shifting from on-premise to clouds,
monoliths to microservices, virtual machines to containers etc. Prometheus
has proven to be successful for users in all those scenarios. Let's
now talk about FaaS/Serverless. (Let's leave other buzzwords -
blockchain/AI
12 matches
Mail list logo
