ignore the template.
I worked on the graphics
http://instr.de/PSPerf/v1/#
http://instr.de/PSPerf/v1/data/test.json
I worked on the graphics
http://instr.de/PSPerf/v1/#
http://instr.de/PSPerf/v1/data/test.json
I know this is not the common wisdom, but I feel that %processor time is a nearly useless number. The processor can be at 99% and still be servicing all threads as rapidly as if it were at 30%. CPU queue measures how many threads are waiting for service and is thus a true measure of whether the CPU is a bottleneck.
All of the metrics I choose are based on this concept. See the concept page in the project wiki.
Your http://instr.de/PSPerf/v1/# is interesting to me but it is very large. My focus is on a sysadmin (or group) who have multiple servers to monitor, and want a "big board" that can give them an at-a-glance understanding of which of those systems are healthy, and which ones are wallowing.
Events. I'm not sure yet but I think I will probably collect the number of new error/warning events in the System and Application logs, and graph that. I have a hazy methodology in mind for this, not nailed down yet. It will probably be the next thing I work on, after I kill a bug I seem to have created in last night's code additions.
(line 439)
Or do you mean I should be using div rather than td?
Don't know why gitter sent it
But I also don't like the idea adding a new row for each disk
And restricting to 2 disks is a lazy fix :-P
We will figure something out
Tomorrow I will have a few hours to code. Looking forward to it
or, maybe just collect queue lengths for all disks, and only show the one with the worst looking graph
no. in fact I've researched this a bit and no one seems clear on exactly how get-counter works. I know it does not use wsman. see https://github.com/bklockwood/PSPerf/wiki/Retrieving-Perfmon-Counters-Remotely
I am big on docs, always have been. I doc as I go because I know that if I don't, there won;t be docs.
also I have never had great memory
Because doc-in-code is usually kinda crappy. Forcing a document that actually talks to the user is important, imo.
I wrote a PsADManagement module for which I invested a lot of time for the function helpers
yours, btw, is exemplary from what I have seen so far.
I started refactoring your data gathering for JSON output.
I added a functionality which always delivers $maxEntries (default 50) values. So the LineGraphs don't flatline while the is no history.
and it adds value 0 when computer is offline
https://github.com/lipkau/PSPerf
I didn't make any of the changes I wanted to the HTML. I didn't touch the HTML and it outputs like this to the generated JSON:
http://instr.de/PSPerf/v2/
(not much going on in the graphs, as it is real data from my server which is not overloaded)
I added a functionality which always delivers $maxEntries (default 50) values. So the LineGraphs don't flatline while the is no history.
and it adds value 0 when computer is offline
https://github.com/lipkau/PSPerf
I didn't make any of the changes I wanted to the HTML. I didn't touch the HTML and it outputs like this to the generated JSON:
http://instr.de/PSPerf/v2/
(not much going on in the graphs, as it is real data from my server which is not overloaded)
(psperf I mean). I will Very likely use your ideas for storing as json, and refactoring the data collection a bit. But not quite yet, I still want to get a couple of other things done in the codebase I have.
Have you tested your existing code for gathering data from other systems?
I don't have a setup which allows me to do so. I must first setup a domain in hyper-v