I am trying to emit value every second as
Flux.just(User("A"), User("B"), User("C")).delayElements(Duration.ofSeconds(1))
but it is emitting everything at once with starting delay of 1 second. How can I introduce the delay for each element emitting?
Flux.just(User("A"), User("B"), User("C")) is just one collection of items, you probably want something like
Flux.fromIterable(listOf(User("A"), User("B"), User("C"))
.delayElements(Duration.ofSeconds(1))
Related
I want to replace a setTimeout & setInterval + counter solution with an Observable to hopefully improve the readability.
How to define a RxJs Observable that that emits x times every t seconds after an initial delay?
I got this so far:
interval(t_ms).pipe(delay(d_ms))
timer(initDelayMs,intervalMs)
.pipe(take(n))
Starts after initDelayMs then emitts n times, every intervalMs and completes.
see: https://www.learnrxjs.io/learn-rxjs/operators/creation/timer
see: https://www.learnrxjs.io/learn-rxjs/operators/filtering/take
I have CSV file which contains Mobile Number, for e.g. number.csv
1276543281
1276543282
1276543283
1276543284
1276543285
Configured CSV Data Set Config with following options
Recycle on EOF? : True
Stop Thread on EOF? : False
Sharing Mode: All Threads
Thread Group settings are given below:
Number of Threads: 5
Ramp-up: 1
Loop Count: 10
Now, when I execute it, threads take any number from CSV and on next iterations based on the thread completion takes the value from CSV.
I want to force Thread1 to take 1st row, Thread2 to take 2nd row and so on... till the loop count is reached or the duration is reached.
You won't be able to achieve the described behaviour using CSV Data Set Config, with the above configuration each thread will pick up the next value on each iteration.
There is no guarantee that 1st thread will pick 1st line and 2nd thread 2nd line.
If you want to "stick" each thread to the respective line from CSV you should use __groovy() function instead like:
${__groovy(new File('/path/to/your/number.csv').readLines().get(ctx.getThreadNum()),)}
where ctx stands for JMeterContext class instance, see Top 8 JMeter Java Classes You Should Be Using with Groovy article for more information.
you can achieve this solution by two ways
You can achieve by keeping the CSV dataset config only once in the controller
You can achieve by using Baolu CSV Data Set Config, in your scenario, set block size for each threads as 1
In these two scenarios, the value picked in first iteration those same values would be picking in next iterations.
I have a prometheus counter (spring_batch_job_seconds_count{status=~'FAILED'}) that counts job failures. I want to graph job failures over time and alert on job failures. The increase function gives me what I want except for the first occurrence. The counter is not published until a failure occurs, so there is no increase (or delta or rate) on the first failure event since there is no previous counter value of 0 to compare the first non-zero counter value to. How can I create a graph that will show the first failure occurrence (as well as subsequent failure occurrences) and a corresponding alert that will trigger on the first failure occurrence (as well as future failure occurrences)? I might be willing to settle for two alerts: one that triggers when the counter increments, and one that triggers on the first occurrence, but I would not want to have to manually shut off the alert that triggers on the first occurrence after it triggers for the first time.
I managed to do this with falco metrics.
I want to alert on any change, even the first time a metric appears.
(sum(falco_events{k8s_pod_name="runner"} or falco_events{} * 0) by (k8s_pod_name, rule) - sum(falco_events{k8s_pod_name="runner"} offset 5m or falco_events{} * 0) by (k8s_pod_name, rule))
Workaround from here: https://github.com/prometheus/prometheus/issues/1673
I am fairly new to Prometheus alertmanager and had a doubt regarding firing alerts only during a particular period
I have a microservice which receives a file and does some processing on it, which is only invoked when it gets a message through a Kafka queue. The aforementioned is supposed to come every day between 5 am and 6 am(UTC time). The microservice has a metric which is incremented by 1 every time it receives a file. I want to raise an alert if it does not receive a file in the interval. I have created a query like this :
expr : sum(increase(metric_name[1m]) and on() hour(vector(time()))==5) < 1
for: 1h
My questions:-
1) Is it correct or is there a better way to do it
2) In case of no update, will it return 0 or "datapoints not found"
3) Is increase the correct function as it tends to give results in decimals due to extrapolation, but I understand if increase is 0, it will show 0
I can't really play around with scrape_intervals, which is set at 30s.
I have not run this expression but I expect it will cause an alert to fire at 06:00 only and then go off at 06:01. It is the only time the expression would hold true for one hour.
Answering your questions
It is correct if what you want is a single fire of alert (sending a mail by example) but then no longer firing. Even with that, the schedule is a bit tight and may get hurt by alertmanager delay causing the alert to be lost.
In case of no increase, you will get the expression will evaluate to 0. It will be empty when there is an update
Increase is the right function. It even takes into account reset of the counter.
Answering if there is a better way to do it.
Regarding your expression, you can have the same result, without for clause, with:
expr: increase(metric_name[1h])==0 and on() hour()==6 and on() minute()<1
It reads a : starting at 6am and for 1 minutes, if there was no increase of metric over the lasthour.
Alerting longer
If you want the alert to last longer (say for the day and you silence it when it is solved), you can use sub-queries;
expr: increase((metric and on() hour()==5)[18h:])==0 and on() hour()>5
It reads as : starting at 6am (hour()>5), compute the increase over 5-6am for the next 18 hours. If you like having a pending, you can drop the trailing on() hour()>5 and use a for: 1h clause.
If you want to alert until a file is submitted and thus detect a resolution, simply transform the expression to evaluate the increase until now:
expr: increase((metric and on() hour()>5)[18h:])==0 and on() hour()>5
I need to collect event logs from Windows those are logged before 10 seconds. Using pull subscription I could collect already saved logs before execution of program and saving logs while program is running. I tried with the code available on MSDN:
Subscribing to Events
"I need to start to collect the event logged 10 seconds ago". Here I think I need to set value for LPWSTR pwsQuery to achieve that.
L"*[System/Level= 2]" gives the events with level equal to 2.
L"*[System/EventID= 4624]" gives events with eventID is 4624.
L"*[System/Level < 1]" gives events with level < 2.
Like that I need to set the value for pwsQuery to get event logged near 10 seconds. Can I do in the same way as above? If so how? If not what are the other ways to do it?
EvtSubscribe() gives you new events as they happen. You need to use EvtQuery() to get existing events that have already been logged.
The Consuming Events documentation shows a sample query that retrieves events beginning at a specific time:
// The following query selects all events from the channel or log file where the severity level is
// less than or equal to 3 and the event occurred in the last 24 hour period.
XPath Query: *[System[(Level <= 3) and TimeCreated[timediff(#SystemTime) <= 86400000]]]
So, you can use TimeCreated[timediff(#SystemTime) <= 10000] to get events in the last 10 seconds.
The TimeCreated element is documented here:
TimeCreated (SystemPropertiesType) Element
The timediff() function is described on the Consuming Events documentation:
The timediff function is supported. The function computes the difference between the second argument and the first argument. One of the arguments must be a literal number. The arguments must use FILETIME representation. The result is the number of milliseconds between the two times. The result is positive if the second argument represents a later time; otherwise, it is negative. When the second argument is not provided, the current system time is used.