Pipeline rule to convert microsec to millisec

Hi! I want to create a widget that tells me the average response time of a Apache server but since the official Red Hat version only allows you to show those times in microseconds (us) i want a way to create another field with those times in milliseconds (response_time_us / 1000). I created a stream and them a pipeline rule, this is the rule:

rule “Convertir us a ms”
let response_us = to_long($message.response_us);
set_field(“response_ms”, response_us / 1000);

response_us is a field created by a grok extractor from the message field, and response_ms is the field that i want to create with this rule that should contain the time in milliseconds
What am i doing wrong? Can i do that?

Perhaps try the calculation outside of the set_field()

let response_us = to_long($message.response_us) / 1000 ;
set_field(“response_ms”, response_us);

when you are extracting the field using your GROK, are you casting it to a type? are you extracting the entire time or are you extracting only the part after the decimal? is it including the decimal? Valid for a string, not for an int or long. Have you tried a float?

are you getting any errors?

Made the change but i see no new field

Yes, i am casting it to a type: %{NUMBER:response_time_us;int}, had to do it in order to make an average graph
I am extracting the entire field from the apache log event/line. I am receiving it like this
200 1576 “-” “-” 0/957158
(there is more information before this, i am only showing you what it matters), and the value that i extract are the 0 and the 957158 for instance
There is no decimal in this case, maybe because is a very small ammount of time is that precise
I didn’t, should i change int for float on the grok pattern?
Nop, no errores, the info that i am getting from the apache log is being extracted correctly and the pipeline is giving me no error, just no messages in that rule when it should have the same amount of messages than the stream at the very least.
Hope this helps

Just in case, my Message Procesors Configuration is:
1_Pipeline Procesor
2_Message filter chain

Hi! Can someone give me a hand? Maybe is not posible to do what i am asking but it would be nice to know it.
Hope someone can shed some light in this.

use debug() in your pipeline rule to figure out what you have in $message.response_us… also, don’t confuse things creating a variable with the name of the thing you are working on (personal pref)

rule "Convertir us a ms"
    let the_response = to_long($message.response_us);
    let peek = concat("This is the contents of respones_us: ", to_string(the_response));
    set_field("response_ms", the_response  / 1000);

You can watch your graylog log file for the results of debug()

tail -f /var/log/graylog-server/server.log

On another note - my quotes in my other code post were the wrong kind…

These don't work “ but these do "

Can’t tell you how many times pasting code has caught me that way. Check the whole rule, just one can F it up.

1 Like

Great! I knew about the debug option but i didn’t know about assigning a value to show so thanks for that extra piece of information.
So, i fixed 2 things: the rule wasn’t assign to the pipeline stage because sometimes i am an idiot (insert facepalm gif here) and second i changed the Message Processor Config and Message filter chain is first then pipeline processor.
But i am getting the “the_response” variable is 0. I am thinking on making some changes on the stream, i may have a lead now.
Thanks again for all the support @tmacgbay

1 Like

It works! I made some changes and realized that the name of the field was response_time_us and not response_us, so double face palm for me i guess. Made some trial and error on our test environment and it started to work, made the same thing on production and is working like a charm, i even changed my graph to take the value in ms of the new field instead of the one in us =D. I am marking your answer as Solution and i will make another reply later today with the step-by-step in case it can help someone else in the future.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.