Best approach for potential telemetry library

General
1

Over the last week I have been working on a rough set of telemetry functions that would expose RTEMS metrics to Scrutiny (as part of my GSoC '26 project). As of now it’s rough code sitting in my test directory as a local library that doesn’t follow any RTEMS software conventions at the moment.

For reference, these are the metrics I’m currently working on exposing right now: CPU usage per task/system, memory usage, network packet counts, interrupt counts. They need to be exposed in a matter where Scrutiny can hook onto them asynchronously, for example:

task_100hz() {
// potential function from my telemetry lib
   rtems_telemetry_get_interrupt_count(); // get a simple incrementing count
   scrutiny_c_loop_handler_fixed_freq_process(task_100hz_lh, 10000U); // scrutiny processes the data 
}

I have two questions.

1, Is there a specific location within the RTEMS repository where this library would be located? I had the plan to make this Scrutiny-agnostic, so I was looking at cpukit/libmisc/

2, Are there any other libraries of similar function that I can reference to get more specifics about naming conventions, struct conventions, and anything else beneficial in general? I’m a bit lost on the specifics and the best possible way to approach the architectural design.

2

You need clear or unique reason to add a library or a new directory to libmisc. There needs to be a defined interface or API.

I see the integration of Scrutiny as an iterative approach that converges towards a functioning solution. To get there you need a base set of features to start this effort and get Scrutiny connected.

  1. Do you have a set of operations or functions you want Scrutiny to initially show?
  2. How many of those operations and functions are present in RTEMS?
  3. Should you look at using some features that exist in RTEMS so the effort is directed to the integration of Scrutiny before you look at adding new features to RTEMS?
3
  1. Yes. At the current moment I want to handle CPU usage system & per task, Memory usage system & per task, and interrupt count. Later on, networking, device I/O.
  2. From what I can see, only stackchk.h provides memory metrics numerically, but not in a way that can directly tie to Scrutiny, the information it provides isn’t a constantly readable value
  3. I have, all existing metrics from RTEMS only expose information as formatted outputs. Scrutiny needs a constantly updating raw numeric value which nothing in RTEMS (as far as I have looked) provides
4

I have a MR out there that needs more work.
but it exposes functions to get cpu usage per task.

There was another MR out there also that does this also

stack use would need to follow a similar process.

Otherwise you need to use the rtems printer and convert the ascii back to numerics.

5

Thanks. This is useful.

6

@gedare @amar @wmthornton-dev Do you have any potential insight for how I should approach this? I’ve written about my work trying to expose interrupt count as a metric here: Exposing Metrics from RTEMS to Scrutiny: Interrupts | Abdullah’s Blog. (unfinished)

My main concern is pretty much how all this ‘glue code’ is going to be added to RTEMS. Honestly it doesn’t matter to me how, whether it’s a library or not, I just don’t really know at the moment.

With the UART transport & other integration efforts, all it takes is documentation and testsuites to describe the process to potential users. But I think metrics should definitely have added support in the form of some sort of library or glue.