QSDT(1)

📦 version 11.74, in epel 9

💅 QSDT(1) — the qsdt man page, bestie edition ✨

okay so real talk: qsdt is that girl who times how long stuff takes between two related log messages. she's in the qsdt man page, she's iconic, let's go 🎀

✨ NAME ✨

qsdt calculates the elapsed time between two related log messages. that's it. that's the whole vibe check. 🕐

🌸 SYNOPSIS 🌸

qsdt [-t <regex>] -i <regex> -s <regex> -e <regex> [-v] [<path>]

💖 DESCRIPTION 💖

qsdt is a simple little tool (humble queen 💅) that searches for two different messages inside a log file and then calculates the elapsed time between those two lines.

here's the catch tho — the two log messages need a common identifier to link them. think an unique request id (UNIQUE_ID), a thread id, or a transaction code. no shared id, no match, no math. periodt. 🫶

🦋 OPTIONS 🦋

  • -t <regex> — defines a pattern (a regular expression) that matches the log line's timestamp. this pattern must include two sub-expressions: one matching hours, minutes and seconds, and the other matching the milliseconds. the default pattern is ([0-9]{2}:[0-9]{2}:[0-9]{2})[.,]([0-9]{3}) ✨
  • -i <regex> — the pattern (regular expression) matching the identifier that the two messages have in common. the sub-expression defines the part that needs to be extracted from the matching string. 📌 note: you can also use the start (-s) and end (-e) pattern to define the sub-expression matching this identifier 👀
  • -s <regex> — defines the pattern (regular expression or literal string) identifying the first (start) of the two messages 🚀
  • -e <regex> — defines the pattern (regular expression or literal string) identifying the second (end) of the two messages 🏁
  • -v — verbose mode. she talks more. 💬
  • <path> — defines the input file to process. if you omit this parameter, qsdt reads from standard input. (yes, the original page really does say "from from" — we don't gatekeep typos around here, we just love her 🙈)

🎀 EXAMPLE 🎀

sample command line arguments, bestie:

-i ' ([a-z0-9]+) [A-Z]+ ' -s 'Received Request' -e 'Received Response'

and these are the sample log messages they'd be matching against:

 2018-03-12 16:34:08.653 threadid23 INFO Received Request
 2018-03-13 16:35:09.891 threadid23 DEBUG MessageHandler Received Response

see how threadid23 is doing the whole linking thing? that's the identifier carrying the whole relationship. main character energy, honestly 👑

🔥 NOTE 🔥

the four patterns (t,i,s,e) get concatenated into two search patterns:

 first (start): [t (HH:MM:SS)(SSS) ].*[i (id) ].*[s ]
 second (end):  [t (HH:MM:SS)(SSS) ].*[i (id) ].*[e ]

and the three sub-expressions are used to extract the timestamp and the unique identifier that the start and end message have in common. 💡

which means: you could specify the sub-expression for the unique identifier in the start (-s) or the end (-e) pattern alternatively — for example, in case the identifier is at the end of the log line. flexible queen 🌈

👀 SEE ALSO 👀

qsexec(1), qsfilter2(1), qsgeo(1), qsgrep(1), qshead(1), qslog(1), qslogger(1), qspng(1), qsre(1), qsrespeed(1), qsrotate(1), qssign(1), qstail(1)

the whole friend group, fr fr 🫶✨

💜 AUTHOR 💜

Pascal Buchbinder, http://mod-qos.sourceforge.net/ — ty for your service, king 🫡

and that's a wrap, bestie 🎀 this little tour was brought to you by mod_qos utilities 11.74, dated May 2023. go time some logs, you absolute icon 💅✨

📦 where this page comes from