[PATCH v1 0/1] Add an option to stop blktrace based on events recorded

[PATCH v1 0/1] Add an option to stop blktrace based on events recorded

[Stephen Bates]

Hi

I am exploring the idea of tying blktrace to a prometheus exporter to
gather more precise block layer activity across a fleet of servers. As
part of that I thought it might be useful to be able to run blktrace
until a user-specified number of events are recorded.

So the following patch adds a new option to do that. I also updated
the relevant documentation.

I'd appreciate feedback or comments on this!

Cheers

Stephen

Stephen Bates (1):
  blktrace/events: Add an option to stop blktrace upon a number of
    events

 README           |  3 ++-
 blktrace.c       | 49 +++++++++++++++++++++++++++++++++++++++++++++++-
 doc/blktrace.8   | 15 +++++++++++++--
 doc/blktrace.tex |  7 ++++++-
 4 files changed, 69 insertions(+), 5 deletions(-)

-- 
2.43.0

Re: [PATCH v1 0/1] Add an option to stop blktrace based on events recorded

[Jeff Moyer]

Hi, Stephen,

Stephen Bates <sbates@raithlin.com> writes:

> Hi
>
> I am exploring the idea of tying blktrace to a prometheus exporter to
> gather more precise block layer activity across a fleet of servers. As
> part of that I thought it might be useful to be able to run blktrace
> until a user-specified number of events are recorded.
>
> So the following patch adds a new option to do that. I also updated
> the relevant documentation.
>
> I'd appreciate feedback or comments on this!

Can you expand on the use case?  Why is the number of events a useful
parameter?

Thanks,
Jeff

Re: [PATCH v1 0/1] Add an option to stop blktrace based on events recorded

[Stephen Bates]

Hi Jeff

> Can you expand on the use case?  Why is the number of events a useful
> parameter?
>
> Thanks,
> Jeff

I am working on tying blktrace into a prometheus exporter so I can
monitor block-level activity across a fleet of storage servers. I
don't want to overload either the storage server CPUs or the exporter
itself when the server is under high load so I want to avoid using the
time-based argument for blktrace.

If I have access to an events based option I can run this knowing that
in high-load situations I will not be capturing many, many IO and
perhaps slowing down the server in the process.

Does that make sense?

Cheers

Stephen

The 01/14/2025 09:29, Jeff Moyer wrote:
> Hi, Stephen,
> 
> Stephen Bates <sbates@raithlin.com> writes:
> 
> > Hi
> >
> > I am exploring the idea of tying blktrace to a prometheus exporter to
> > gather more precise block layer activity across a fleet of servers. As
> > part of that I thought it might be useful to be able to run blktrace
> > until a user-specified number of events are recorded.
> >
> > So the following patch adds a new option to do that. I also updated
> > the relevant documentation.
> >
> > I'd appreciate feedback or comments on this!
> 
> Can you expand on the use case?  Why is the number of events a useful
> parameter?
> 
> Thanks,
> Jeff
> 

-- 

Cheers

Stephen Bates, PhD.

Re: [PATCH v1 0/1] Add an option to stop blktrace based on events recorded

[Jeff Moyer]

Stephen Bates <sbates@raithlin.com> writes:

> Hi Jeff
>
>> Can you expand on the use case?  Why is the number of events a useful
>> parameter?
>>
>> Thanks,
>> Jeff
>
> I am working on tying blktrace into a prometheus exporter so I can
> monitor block-level activity across a fleet of storage servers. I
> don't want to overload either the storage server CPUs or the exporter
> itself when the server is under high load so I want to avoid using the
> time-based argument for blktrace.
>
> If I have access to an events based option I can run this knowing that
> in high-load situations I will not be capturing many, many IO and
> perhaps slowing down the server in the process.
>
> Does that make sense?

Yes, thanks for the clarification.  Originally I thought you might be
using the number of events as a proxy for the size of data collected.
I'm still not sure how a user would reason about how many events is too
many (or enough), but that's a not a problem for blktrace to figure out.

I'll reply to the patch with my comments.

Cheers,
Jeff