Identifying nodes in the NR metrics log?

I need to understand what is driving the load on my NR server. The metrics log (set metrics = true in the logging section of settings.js) seems to contain the data that I need-- essentially which nodes are being run, when, how often, how long do they take, etc. However, I've been unable to figure out how to tie the nodeids identified in the log to the actual nodes in the project. Could anyone offer any insight?

More information: While many of the nodeids surfaced in the log can be found in my project, there are many nodeids in the log to which various events are attributed, but which don't exist in the project-- not when I search using the editor, nor when I grep through the .json.

After doubting my sanity a few times and a few hours of investigation and experimentation, I feel fairly certain that NR instantiating subflows is the source (or perhaps a contributing source) of these "ephemeral" nodeids. I suspect that while the subflow "definition" contains nodes with ids that are hard-coded into the flow JSON, the instances of that subflow are created by NR at runtime thus also creates nodeids for these subflow instances on the fly.

Does anyone know if that is basically what is going on? If so, how does one tie the nodeids in the log to the nodes in the project?

Thanks in advance!

Yes, that is a correct description of what is happening.

I think this is something we need to improve - the metrics log needs to make it easier to identify the source node in the case of subflows.

At the moment, the only solution is to enable the 'trace' level of logging and you'll get information about the internal mapping of node ids when the flows start.

I see. So the trace mode log will give me a "Rosetta Stone" to understand subflows in the metrics log. I'll give it a shot. Thank you for the help!

Is there a way to change NR logging behavior without a restart? For example, is there a way to start or stop a logging module I've defined in settings.js? Or is there a way for the runtime to change the log level on the fly, or engage/disengage metrics or audit logging? Thanks.

Yes. Even something as simple as having the subflow instance nodeids derive from the source nodeids in an easily reversible way (just tacking on a prefix or suffix to the source nodeid, for example) would make the value of the metrics log so much more accessible.

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