Simon Skog

Is this implemented or is it just a idea how to solve the issue? Because i have a processor i only want to run on the subscription named interface_state To...

@karimra so docs says condition or one of the regular expressions under tags, tag-names, values or value-names. so the way i used condition in my example above is not meant...

I use version 0.26 of gnmic.

#647 pull request verified working in my env. ``` [ { "name": "interface_state", "timestamp": 1663692516962334193, "tags": { "component_name": "FPC5", "source": "junos-mx-960", "subscription-name": "interface_state" }, "values": { "/components/component/state/software-version": "Version 19.4R3-S7.3 by...

Scrape based was 15s intervals, scraped around 140-170k metrics each time. Remote write i tried alot. intervals i tried 0.5,1,5,10s buffer-size: 1000,10000,30000,100000,400000 max-time-series-per-write: 500,1500,150000,200000 Debug log is full of this...

My grpc_client_msg_received_total metric says between 10-12k msg every 15s I compiled the fixed version and i have been running it now stable for 2h+. A little bump in memory usage...

We hit another issue as you can see in the picture above, our interface is only a 1Gb interface. Will comeback with our final configuration when we solve that. Our...

Only been trying prometheus_write. Memory bump seems to be around 4-6Gb. We are still seeing [prometheus_write_output:prom-remote] writing expired after 20s. Waiting for our monitor team help us troubleshoot there side...

Ye that's what i thought also. How are the workers working internally? e.g Are they working independently or working together to process and write messages?

Can that single goroutine that drains the buffer be a bottleneck? Just setting a low interval e.g 1s or even sub-second i dont feel is enough to drain the buffer...