Hi,
I've been creating EXE/Script Advanced sensors for PRTG in C# for some months now and I'm having trouble whenever I need to get Performance Counters values within my code.
The strange thing is that most of the times everything works fine, but sometimes some weird exceptions occur, such as:
System.InvalidOperationException: The Counter layout for the Category specified is invalid, a counter of the type: AverageCount64, AverageTimer32, CounterMultiTimer, CounterMultiTimerInverse, CounterMultiTimer100Ns, CounterMultiTimer100NsInverse, RawFraction, or SampleFraction has to be immediately followed by any of the base counter types: AverageBase, CounterMultiBase, RawBase or SampleBase.
at System.Diagnostics.CategorySample.GetCounterDefinitionSample(String counter)
at System.Diagnostics.PerformanceCounter.NextSample()
at System.Diagnostics.PerformanceCounter.NextValue()
A code example: https://pastebin.com/s4b7p1JA
These sensors run simultaneously on different PRTG devices (i.e. different host IPs/names).
Is this something you can help me with?
Thanks in advance.
Article Comments
After looking the code example you linked in your request, I can tell you that you definitively should add try-catch phrases to
- a) be able to determine where the error happens and
- b) get actual control over your code and react in such situations
Once you have such try-catch statements (you can cascade them as well) you will be able to determine where exactly this happens.. if you implement a error-handler procedure in the code, you might get even more information.. in any case, you can then react to errors in the code and determine what you give back to PRTG - the result of the EXE should always be PRTG readable, no matter if the execution raised and error or not - if the error is just temp. because of what ever issues - then you might instruct PRTG to notify only after X minutes of error state.. meaning you might just lose temporary data.
Btw. - it looks like you use a EXE that PRTG is executing in short intervals to collect system counter data. Why don't you just create a EXE that initiates one time a connection to those counters and then e.g. in 30 second intervals (or what you want) re-read them (keep the session/objects alive) and fire them back to PRTG API - sensors like HTTP Push Data Advanced would help you here - you can inject information rather then have PRTG pulling them... push instead of pull more or less..
From what I see, the issue is likely more in the code then in PRTG - and if I understand it right the issue is intermittent and not constant.
Regards
Florian Rossmark
www.it-admins.com
Jan, 2019 - Permalink
Thank you for your reply, Florian.
I'll follow your advice.
Unfortunately I don't think that last option fits my scenario, but I'll look further into it.
Jan, 2019 - Permalink
After looking the code example you linked in your request, I can tell you that you definitively should add try-catch phrases to
Once you have such try-catch statements (you can cascade them as well) you will be able to determine where exactly this happens.. if you implement a error-handler procedure in the code, you might get even more information.. in any case, you can then react to errors in the code and determine what you give back to PRTG - the result of the EXE should always be PRTG readable, no matter if the execution raised and error or not - if the error is just temp. because of what ever issues - then you might instruct PRTG to notify only after X minutes of error state.. meaning you might just lose temporary data.
Btw. - it looks like you use a EXE that PRTG is executing in short intervals to collect system counter data. Why don't you just create a EXE that initiates one time a connection to those counters and then e.g. in 30 second intervals (or what you want) re-read them (keep the session/objects alive) and fire them back to PRTG API - sensors like HTTP Push Data Advanced would help you here - you can inject information rather then have PRTG pulling them... push instead of pull more or less..
From what I see, the issue is likely more in the code then in PRTG - and if I understand it right the issue is intermittent and not constant.
Regards
Florian Rossmark
www.it-admins.com
Jan, 2019 - Permalink