psTerminalPerfCounter

Im vorherigen Artikel habe ich einen kurzen Abriss in die Geschichte und Funktionsweise der Windows Performance Counter gemacht, jetzt folgt das Hands-on. Grundlage ist Release 0.4.1, das ganz im Zeichen von Visualisierung und Datenexport steht. Neu dabei: CSV-Export, eine Terminal GUI als Ablösung der textbasierten Ansicht und der HTML-Export via PSWriteHTML. Klingt spannend… ist es auch 🙂 Ich denke das siehst du genau so, sonst würdest du nicht mehr lesen. 🙂

Installation

Installation eines PowerShell Moduls, nichts besonderes

# Install psTerminalPerfcounter
Install-Module psTerminalPerfCounter

# List Cmdlets
Get-Command -Module psTerminalPerfCounter

# Install PSWriteHtml, required for HTML Export
Install-Module PSWriteHtml

Grundlegender Aufbau, Counterconfigs

psTerminalPerfCounter arbeitet mit Konfigurationsdateien, in denen die Counter-Sets und deren Konfiguration beschrieben sind: Counter-IDs, Instanzen (ob zum Beispiel alle CPU-Cores oder nur Core 3 und 4 überwacht werden sollen), Wertkonvertierung, Units und die farbliche Kodierung der Graphen über die sogenannte ColorMap, die allerdings nur die Legacy-Visualisierung unterstützt.

Counterconfigs können in beliebigen Pfaden gespeichert und von dort aufgerufen werden. Alternativ lassen sich Pfade registrieren, was den Aufruf einfach über denConfignamen ermöglicht. Der Default-Pfad ist der Config-Ordner im Modul selbst, der bereits einige vordefinierte Configs mitbringt.

# List all registered paths
Get-tpcConfigPaths

# Add custom path
Add-tpcConfigPath -Path 'C:\tpcConfig'

# List all Counterconfigs and details in all paths
Test-tpcAvailableCounterConfig

Single Server Monitoring

Die schnellste Methode ist ein einzelner Server, lokal oder remote.

# Use CPU Config locally
Start-tpcMonitor -Configname CPU
Start-tpcMonitor -Confipath 'C:\Users\labadmin\Documents\PowerShell\Modules\psterminalperfcounter\0.4.0\Config\tpc_CPU.json'

# Use CPU Config remote
Start-tpcMonitor -Computername 'dev-node1' -Configname CPU
Start-tpcMonitor -Computername 'dev-node1' -Confipath 'C:\Users\labadmin\Documents\PowerShell\Modules\psterminalperfcounter\0.4.0\Config\tpc_CPU.json'

# Use CPU Config rmeote with different credentials
Start-tpcMonitor -Computername 'dev-node1' -Credentials $(Get-Credential) -Configname CPU

Da die Legacy-Visualisierung spätestens bei Multiserver-Umgebungen an ihre Grenzen kommt, nutze ich für dieses Hands-on den -TUI Switch.

# Use CPU Config locally with TUI
Start-tpcMonitor -Configname CPU -TUI

Multi Server Monitoring

Das Multiserver-Monitoring funktioniert ebenfalls über Konfigurationsdateien, wobei mir beim Schreiben dieser Zeilen auffällt: Warum habe ich nie daran gedacht, einfach eine Counterconfig gegen eine Serverliste laufen zu lassen? Ab ins Backlog damit. Wie auch immer, in der Environment-Konfiguration lassen sich beliebig viele Server mit verschiedenen Configs definieren. Da ich zuletzt noch Probleme hatte, die Sparklines in der TUI scrollbar zu machen, sind diese in der Multiserver-Ansicht deaktiviert.

# Start multi server monitoring
Start-tpcEnvironmentMonitor -EnvConfigPath 'C:\tpcConfig\ENV_SERVER_EXAMPLE.json' -TUI

LAB-NODE03 ist in dem Fall ein deutsche Installation

Die Spalte Duration zeigt die Zeit, die die Funktion auf dem jeweiligen Server gebraucht hat, um alle Werte einzusammeln. Den finalen Timestamp des gesamten Datensatzes definiert immer der langsamste Server, nur so ist eine homogene Zeitreihe möglich. Eine Varianz von in diesem Fall 1,3 Sekunden lässt sich dabei nicht vermeiden.

Das wars auch schon zur Auführung, da dieses Modul nur das Framework bereitstellt. Das eigentliche Leben kommt mit den Counterconfigs. Wie diese erstellt werden schauen wir uns jetzt an.

Erstellung von Counterconfigs

Am Anfang ist der Performance Counter. Bevor wir die Konfiguration schreiben können, brauchen wir die Counter-IDs statt der lokalisierten Namen. Dafür gibt es Get-tpcPerformanceCounterInfo, das in beide Richtungen funktioniert: Counterpath zu ID und umgekehrt.

# List all counter and counter objects containing 'processor time'
Get-tpcPerformanceCounterInfo -ComputerName 'dev-node1' -SearchTerm 'processor time'

Wichtig sind die letzten beiden Spalten. Es gibt Single-Instance-Counter mit nur einem Wert, aber auch Multi-Instance-Counter wie das Processor-Counterset, bei dem jede Instanz einem Core entspricht, oder halt gesamt (_Total).

Genauso lässt sich mit dem Cmdlet herausfinden, welcher Counter sich hinter einer Composite-ID verbirgt.

# Show counter name of composite ID
Get-tpcPerformanceCounterInfo -ComputerName 'dev-node1' -SearchTerm '238-6'

Oder auf einem deutschen System

Nehmen wir noch Counter, die nicht standardmäßig auf einem Windows-System vorhanden sind: SQL Server. DEV22A ist in diesem Fall die erste Instanz auf dem System.

# "Out-String -Stream" converts PowerShell's internal formatting objects into actual strings line by 
# line, enabling string operations like `Select-String` to work on them.

Get-tpcPerformanceCounterInfo -ComputerName 'dev-node1' -SearchTerm 'dev22a' | 
		Out-String -Stream | 
		Select-String "lookup"

Nehmen wir zum Testen Page lookups/sec –> 12222-12272

Get-tpcPerformanceCounterInfo -ComputerName 'dev-node1' -SearchTerm 'dev22a' | 
		Out-String -Stream | 
		Select-String "log flushes"

Und log flush/sec auf der Instanz TempDB –> 12352-12446

Die minimale Config sieht dann so aus. Bei den SQL-Server-Countern fehlen einige Werte, das ist aber nicht SQL-Server-spezifisch, sondern zeigt, dass die meisten Felder Defaults bekommen. Details dazu finden sich in der Doku im Repo. Erwähnenswert noch: bei CPU nutze ich "counterInstance": "1|2", wodurch automatisch zwei Counter erstellt werden, und bei den Page Lookups die Konvertierung durch 1000, damit die Zahlen lesbar bleiben.\

{
	"name": "CPU and Sql Server Page Usage",
	"description": "CPU Usage",
	"counters": [
		{
			"title": "CPU Usage",
			"unit": "%",
			"conversionFactor": 1,
			"conversionExponent": 1,
			"conversionType": "D",
			"format": "table",
			"counterID": "238-6",
			"counterSetType": "MultiInstance",
			"counterInstance": "0|1",
			"colorMap": {
				"20": "Green",
				"50": "Yellow",
				"70": "RED"
			}
		},
		{
			"title": "Sql DEV22A Page Lookups/s",
			"unit": "#K",
			"conversionFactor": 1000,
			"conversionExponent": 1,
			"conversionType": "D",
			"counterID": "12222-12272",
			"counterSetType": "SingleInstance",
			"counterInstance": ""
		},
		{
			"title": "Sql DEV22A TempDB Log Flushes/s",
			"unit": "#",
			"counterID": "12352-12446",
			"counterSetType": "MultiInstance",
			"counterInstance": "tempdb"
		}

	]
}

Das Ganze dann in einem registrierten Pfad speichern mit dem Präfix tpc_NAME.json und los geht’s.

Monitoring einer Umgebung mit Environment File

Auch hier keine Magic. Es können Confignamen oder Pfade angegeben werden. Eine noch nicht vollständig dokumentierte Funktion ist die Nutzung von SecretVaults: Über die PowerShell-Konnektoren lassen sich Credentials aus fast allen gängigen Lösungen laden, womit auch Nicht-Admins die Möglichkeit gegeben werden kann, Systeme zu überwachen.

[
    {
        "name": "SQL_ENVIRONMENT_001",
        "description": "SQL Server Environment Production",
        "interval": 2,
        "secretvaultname": "SecretStore",
        "credentialname": "integrated",
        "servers": [
            {
                "computername": "DEV-NODE1",
                "comment": "Sql Server Node A Production",
                "counterConfig": [
                    "SQLDEMO"
                ]
            },
            {
                "computername": "DEV-NODE2",
                "comment": "Sql Server Node B Production",
                "counterConfig": [
                    "C:\Users\devadmin\Desktop\tpc_SQLDEMO.json"
                ]
            }
        ]
    }
]

# without TUI
Start-tpcEnvironmentMonitor -EnvConfigPath "C:\Users\devadmin\Desktop\ENV_SERVER_EXAMPLE2.json"

Datenexport

CSV

Um die Zeitreihen weiterzuverwenden, kann nach CSV exportiert werden. Achtung, aktuell noch ein bekannter Bug: der Export ist kommasepariert, Werte mit Komma werden dadurch ebenfalls getrennt, in 0.4.1 gefixt.

# -CsvPath is default desktop
	Start-tpcEnvironmentMonitor -EnvConfigPath "C:\Users\devadmin\Desktop\ENV_SERVER_EXAMPLE2.json" -ExportCsv

HTML Report

Eine alternative Visualisierung als HTML, nützlich wenn ich eine Zeitreihe weitergeben möchte ohne Excel oder weitere Tools zu bemühen. Gruppiert werden kann nach Counter oder nach Server, je nachdem ob ich bei mehreren Servern alle Counter eines Servers in einem Diagramm sehen möchte, oder einen bestimmten Counter über mehrere Server hinweg. Details dazu finden sich in den Docs im Repo.

Zu beachten: das HTML enthält ein rollendes Datenset, das an die maximale Sample-Anzahl gebunden ist. Je mehr Samples, desto träger wird das HTML. Für große Zeitreihen lieber CSV nutzen.

# -HTMLPath is default desktop
	Start-tpcEnvironmentMonitor -EnvConfigPath "C:\Users\devadmin\Desktop\ENV_SERVER_EXAMPLE2.json" -ExportHTML

Das war’s als Schnelleinstieg, mehr Details zu den einzelnen Funktionen finden sich wie immer in den Docs und der README im Repository.

The post psTerminalPerfCounter – Performance Counter im Terminal – HowTo first appeared on DBA von Nebenan.

psTerminalPerfCounter

In the previous article I gave a quick rundown of the history and inner workings of Windows Performance Counters, now comes the hands-on part. The basis is release 0.4.1, which is all about visualization and data export. New additions: CSV export, a terminal GUI replacing the text-based view, and HTML export via PSWriteHTML. Sounds exciting… and it is 🙂 I figure you see it the same way, otherwise you wouldn’t still be reading. 🙂

Installation

Installing a PowerShell module, nothing special

# Install psTerminalPerfcounter
Install-Module psTerminalPerfCounter

# List Cmdlets
Get-Command -Module psTerminalPerfCounter

# Install PSWriteHtml, required for HTML Export
Install-Module PSWriteHtml

Basic Structure, Counter Configs

psTerminalPerfCounter works with configuration files that describe the counter sets and their configuration: counter IDs, instances (whether, for example, all CPU cores or only core 3 and 4 should be monitored), value conversion, units, and the color coding of the graphs via the so-called ColorMap, which however is only supported by the legacy visualization.

Counter configs can be stored in any path and called from there. Alternatively, paths can be registered, which allows calling them simply by the config name. The default path is the config folder within the module itself, which already ships with a few predefined configs.

# List all registered paths
Get-tpcConfigPaths

# Add custom path
Add-tpcConfigPath -Path 'C:\tpcConfig'

# List all Counterconfigs and details in all paths
Test-tpcAvailableCounterConfig

Single Server Monitoring

The fastest method is a single server, local or remote.

# Use CPU Config locally
Start-tpcMonitor -Configname CPU
Start-tpcMonitor -Confipath 'C:\Users\labadmin\Documents\PowerShell\Modules\psterminalperfcounter\0.4.0\Config\tpc_CPU.json'

# Use CPU Config remote
Start-tpcMonitor -Computername 'dev-node1' -Configname CPU
Start-tpcMonitor -Computername 'dev-node1' -Confipath 'C:\Users\labadmin\Documents\PowerShell\Modules\psterminalperfcounter\0.4.0\Config\tpc_CPU.json'

# Use CPU Config rmeote with different credentials
Start-tpcMonitor -Computername 'dev-node1' -Credentials $(Get-Credential) -Configname CPU

Since the legacy visualization reaches its limits at the latest with multi-server environments, I use the -TUI switch for this hands-on.

# Use CPU Config locally with TUI
Start-tpcMonitor -Configname CPU -TUI

Multi Server Monitoring

Multi-server monitoring also works via configuration files, although while writing these lines it occurs to me: why did I never think of simply running a counter config against a server list? Onto the backlog with that. Anyway, in the environment configuration you can define any number of servers with different configs. Since I recently still had trouble making the sparklines in the TUI scrollable, they are disabled in the multi-server view.

# Start multi server monitoring
Start-tpcEnvironmentMonitor -EnvConfigPath 'C:\tpcConfig\ENV_SERVER_EXAMPLE.json' -TUI

LAB-NODE03 is a German installation in this case

The Duration column shows the time the function needed on each server to collect all values. The final timestamp of the entire data set is always defined by the slowest server, as only this way is a homogeneous time series possible. A variance of, in this case, 1.3 seconds cannot be avoided here.

That’s all there is to running it, since this module only provides the framework. The actual life comes with the counter configs. Let’s now take a look at how these are created.

Creating Counter Configs

In the beginning there is the performance counter. Before we can write the configuration, we need the counter IDs instead of the localized names. For that there is Get-tpcPerformanceCounterInfo, which works in both directions: counter path to ID and vice versa.

# List all counter and counter objects containing 'processor time'
Get-tpcPerformanceCounterInfo -ComputerName 'dev-node1' -SearchTerm 'processor time'

The last two columns are important. There are single-instance counters with only one value, but also multi-instance counters like the Processor counter set, where each instance corresponds to a core, or the total (_Total).

In the same way you can use the cmdlet to find out which counter is hidden behind a composite ID.

# Show counter name of composite ID
Get-tpcPerformanceCounterInfo -ComputerName 'dev-node1' -SearchTerm '238-6'

Or on a German system

Let’s also take counters that are not present by default on a Windows system: SQL Server. DEV22A in this case is the first instance on the system.

# "Out-String -Stream" converts PowerShell's internal formatting objects into actual strings line by 
# line, enabling string operations like `Select-String` to work on them.

Get-tpcPerformanceCounterInfo -ComputerName 'dev-node1' -SearchTerm 'dev22a' | 
		Out-String -Stream | 
		Select-String "lookup"

Let’s take Page lookups/sec for testing –> 12222-12272

Get-tpcPerformanceCounterInfo -ComputerName 'dev-node1' -SearchTerm 'dev22a' | 
		Out-String -Stream | 
		Select-String "log flushes"

And log flush/sec on the TempDB instance –> 12352-12446

The minimal config then looks like this. Some values are missing for the SQL Server counters, but that is not SQL Server specific, it shows that most fields receive defaults. Details on this can be found in the docs in the repo. Also worth mentioning: for CPU I use "counterInstance": "1|2", which automatically creates two counters, and for the page lookups the conversion by 1000 so that the numbers stay readable.\

{
	"name": "CPU and Sql Server Page Usage",
	"description": "CPU Usage",
	"counters": [
		{
			"title": "CPU Usage",
			"unit": "%",
			"conversionFactor": 1,
			"conversionExponent": 1,
			"conversionType": "D",
			"format": "table",
			"counterID": "238-6",
			"counterSetType": "MultiInstance",
			"counterInstance": "0|1",
			"colorMap": {
				"20": "Green",
				"50": "Yellow",
				"70": "RED"
			}
		},
		{
			"title": "Sql DEV22A Page Lookups/s",
			"unit": "#K",
			"conversionFactor": 1000,
			"conversionExponent": 1,
			"conversionType": "D",
			"counterID": "12222-12272",
			"counterSetType": "SingleInstance",
			"counterInstance": ""
		},
		{
			"title": "Sql DEV22A TempDB Log Flushes/s",
			"unit": "#",
			"counterID": "12352-12446",
			"counterSetType": "MultiInstance",
			"counterInstance": "tempdb"
		}

	]
}

Then save the whole thing in a registered path with the prefix tpc_NAME.json and off we go.

Monitoring an Environment with an Environment File

No magic here either. Config names or paths can be specified. A function that is not yet fully documented is the use of SecretVaults: via the PowerShell connectors, credentials can be loaded from almost all common solutions, which also gives non-admins the ability to monitor systems.

[
    {
        "name": "SQL_ENVIRONMENT_001",
        "description": "SQL Server Environment Production",
        "interval": 2,
        "secretvaultname": "SecretStore",
        "credentialname": "integrated",
        "servers": [
            {
                "computername": "DEV-NODE1",
                "comment": "Sql Server Node A Production",
                "counterConfig": [
                    "SQLDEMO"
                ]
            },
            {
                "computername": "DEV-NODE2",
                "comment": "Sql Server Node B Production",
                "counterConfig": [
                    "C:\Users\devadmin\Desktop\tpc_SQLDEMO.json"
                ]
            }
        ]
    }
]

# without TUI
Start-tpcEnvironmentMonitor -EnvConfigPath "C:\Users\devadmin\Desktop\ENV_SERVER_EXAMPLE2.json"

Data Export

CSV

To reuse the time series, you can export to CSV. Caution, currently still a known bug: the export is comma-separated, so values containing a comma get split as well, fixed in 0.4.1.

# -CsvPath is default desktop
	Start-tpcEnvironmentMonitor -EnvConfigPath "C:\Users\devadmin\Desktop\ENV_SERVER_EXAMPLE2.json" -ExportCsv

HTML Report

An alternative visualization as HTML, useful when I want to pass on a time series without bothering with Excel or other tools. Grouping can be done by counter or by server, depending on whether, with multiple servers, I want to see all counters of one server in a single chart, or one specific counter across multiple servers. Details on this can be found in the docs in the repo.

To note: the HTML contains a rolling data set bound to the maximum number of samples. The more samples, the more sluggish the HTML becomes. For large time series, better use CSV.

# -HTMLPath is default desktop
	Start-tpcEnvironmentMonitor -EnvConfigPath "C:\Users\devadmin\Desktop\ENV_SERVER_EXAMPLE2.json" -ExportHTML

That’s it as a quick start, more details on the individual functions can be found, as always, in the docs and the README in the repository.

The post psTerminalPerfCounter – Performance Counter in Terminal – HowTo first appeared on DBA von Nebenan.

psTerminalPerfCounter

Knapp ein Jahr ist es nun her, dass ich mit der Entwicklung von psTerminalPerfCounter begann. Stolz auf die „grafische“ Implementierung, Sprachunabhängigkeit mittels 3rd-Party-Lib und den damaligen heiligen Gral: Klassen in PowerShell.

Nichts davon ist geblieben:

• Grafische Implementierung? Schön bunt aber…
  • Bei Multiserver Umgebungen träge wie ein Stein
  • Dynamisch und Skalierbar, Fehlanzeige
  • Neuimplementierung in TUI (BETA)
    
• Multilanguage per 3rd Party Lib
  • Geht alles direkt per Windows Registry, durch Zufall darüber gestolpert
    
• Klassen in PowerShell? Sehr schlechte Entscheidung.
  • Nicht praktikabel, Instanzen nicht ohne weiteres serialisierbar, Methoden gehen verloren, Parallel Remoting mit Runspaces kaum umsetzbar
  • Rebuild in C#

Mit dem aktuellen Release 0.4.1 sind erst mal alle Funktionen implementiert, welche ich im Backlog hatte. Da mir die nächsten Monate dazu die Zeit für dieses Projekt fehlen wird, ist dies ein guter Moment ein HandsOn zu schreiben, da die README.md im Repo doch manchmal herausfordernd ist… wie es scheint 🙂 Bevor es zum HandsOn geht, aber erst mal ein wenig zur Technik und Geschichte der Performance Counter.

Geschichte

Windows Performance Counter gibt es in Windows seit NT 3.1 (1993), da hatte ich noch nicht mal einen Computer. Microsoft brauchte damals eine standardisierte Methode, um Systemzustände anzeigbar zu machen, ohne dass jede Anwendung eigene Monitoring-Mechanismen implementieren musste. Das hieẞ aber auch Messwerte aus der Registry kratzen und Deltas berechnen.

Mit Windows 2000 kam der Performance Data Helper (PDH) als komfortable High-Level-API dazu, die den Zugriff auf Performance Counter so gestaltet, wie wir ihn heute kennen. Gleichzeitig wurde WMI eingeführt, das Performance-Daten über eine objektorientierte Schnittstelle zugänglich machte. CIM war ja nicht proprietär und zu kompatibel 😛

Windows Vista brachte das überarbeitete Provider V2-Modell: Statt einer DLL, die vom System in einen fremden Prozess geladen wurde (fehleranfällig, Absturz des Providers = Absturz des abfragenden Prozesses), registrieren sich Provider seitdem als eigenständige ausführbare Dateien oder Dienste. Das ist das heute noch gültige Modell.

Aufbau und Funktion

Metadaten in der Registry

Alle bekannten Counter sind unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib registriert. Dort liegen Name, Beschreibung und eine numerische Index-Nummer pro Counter, getrennt nach Sprache (Unterkey 009 für Englisch, 007 für Deutsch usw.).

# List available language packs (counter IDs)
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib"

Provider liefern die Rohdaten

Jede Komponente (Kernel, Treiber, Dienste wie IIS oder SQL Server, die .NET-Runtime) kann eigene Counter registrieren. Der Provider wartet passiv und liefert Daten erst dann, wenn sie jemand abfragt. Es gibt keinen dauerhaften Sammeldienst im Hintergrund.

# List all services that have a Performance subkey

Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\Services" |
    Where-Object { Test-Path "$($_.PSPath)\Performance" } |
    ForEach-Object {
        $perf = Get-ItemProperty "$($_.PSPath)\Performance"
        [PSCustomObject]@{
            Service      = $_.PSChildName
            FirstCounter = $perf.'First Counter'
            LastCounter  = $perf.'Last Counter'
            Library      = $perf.Library
        }
    } | Format-Table -AutoSize

APIs für Anwendungen (CONSUMER)

• PDH (Performance Data Helper): Die bequeme API, die Werte bereits formatiert (z. B. Prozentwerte berechnet, Intervalle berücksichtigt). Get-Counter in PowerShell nutzt PDH.
• PerfLib / Registry direkt: Schneller, aber roh. WMI nutzt diesen Weg intern.

Aufbau

\Prozessor(_Total)\Prozessorzeit (%)
└─ Objekt: „Prozessor“
└─ Instanz: „_Total“ (Summe aller Kerne)
└─ Counter: „Prozessorzeit (%)“

Microsofts Tools

Der Großvater PerfMon

Der Performance Monitor ist seit NT-Zeiten das offizielle Werkzeug von Microsoft und für das, wofür er gebaut wurde, nach wie vor ausgezeichnet: interaktive, grafische Tiefenanalyse einzelner Systeme, mit Aufzeichnung über Data Collector Sets, CSV-Export via relog und grundlegendem Remoting. Die Grenzen zeigen sich, sobald man skalieren, automatisieren oder schlicht im Terminal arbeiten will. Portable Konfigurationsdateien, mehrere Server gleichzeitig im Blick oder ein strukturierter Konsolenworkflow sind nicht seine Stärken.

Der NewComer Windows Admin Center

Microsofts browserbasierte Verwaltungsoberfläche bringt ebenfalls eine Performance-Ansicht mit, übersichtlicher als Perfmon und ohne lokale Installation auf dem verwalteten System. Für einen schnellen Blick auf CPU, Speicher und Netzwerk reicht das völlig aus. Zwei Punkte schränken den praktischen Nutzen jedoch ein: Erstens setzt WAC eine zentrale Installation voraus, mal eben auf einem Client oder beim Kunden starten geht nicht. Zweitens basiert die Counter-Auswahl wie überall auf der lokalisierten PDH-API, was Workspaces nicht wirklich transportabel macht.

Das Evergreen – Get-Counter

Get-Counter ist das PowerShell-Äquivalent für den Konsolenbetrieb und damit das flexibelste der drei Werkzeuge, solange man frickeln möchte bereit ist, selbst Hand anzulegen. Counter lassen sich direkt abfragen, per Schleife wiederholen und in die Pipeline schicken. Remoting funktioniert über den -ComputerName-Parameter. Das Problem ist dasselbe wie überall: Die Counter-Pfade sind sprachabhängig, ein auf einem deutschen System geschriebenes Skript schlägt auf einem englischen fehl. Hinzu kommt, dass Get-Counter Rohdaten liefert. Formatierung, Schwellenwerte, Verlaufsdarstellung und strukturierte Ausgabe sind vollständig Handarbeit. Für Einmalabfragen und schnelle Checks ist es ideal, für reproduzierbare, mehrsprachige Umgebungen stößt es schnell an seine Grenzen.

# Query CPU, memory and disk counters every 5 seconds, format output as table
$counters = @(
    '\Processor(_Total)\% Processor Time',
    '\Memory\Available MBytes',
    '\PhysicalDisk(_Total)\Disk Bytes/sec'
)

# German Counternames
# $counters = @( 
#	'\Processor(_Total)\% Processor Time', 
#	'\Memory\Available MBytes', 
#	'\PhysicalDisk(_Total)\Disk Bytes/sec' 
# )

Get-Counter -Counter $counters -SampleInterval 5 -Continuous | ForEach-Object {
    $sample = $_.CounterSamples

    [PSCustomObject]@{
        Timestamp       = $_.Timestamp
        'CPU %'         = [math]::Round(($sample | Where-Object Path -like '*processor*').CookedValue, 1)
        'RAM frei (MB)' = [math]::Round(($sample | Where-Object Path -like '*available*').CookedValue, 0)
        'Disk B/s'      = [math]::Round(($sample | Where-Object Path -like '*disk bytes*').CookedValue, 0)
    } | Format-Table -AutoSize
}

Der Weg in die Sprachunabhängigkeit

Wie ihr seht, ist die Sprachabhängigkeit bei allen Implementierungen ein großes Problem. Dabei ist das gar nicht nötig. Unter der Haube hat jedes Counterobjekt und jeder Counter eine eindeutige ID. Schaut mal oben in den Screenshots, da steht immer First und Last Counter. Somit wird aus \Processor(_Total)\Processor Time (%) –> \238(_Total)\6 .

# Read counter ID/name mapping from registry (English - key 009, German - key 007)
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009' -Name Counter |
		Select-Object -ExpandProperty Counter | Select-Object -First 20

That’s it. Nun müssen einmal das Counter-Objekt und der Pfad übersetzt werden und schon habe ich meinen sprachunabhängigen CounterPfad. Vor dem Ausführen wird er auf dem Zielsystem übersetzt und dann Get-Counter -Counter <TRANSLATION> ausgeführt. Das übernimmt in psTerminalPerfcounter das CMDLET get-tpcPerformanceCounterInfo

https://dbavonnebenan.de/psterminalperfcounter-counter-in-terminal-handson_de/

The post Windows Performance Counter: Wie sich das OS selbst überwacht first appeared on DBA von Nebenan.

psTerminalPerfCounter

It has been almost a year now since I started developing psTerminalPerfCounter. Proud of the „graphical“ implementation, language independence via a 3rd-party lib and the holy grail of the time: classes in PowerShell.

None of it survived:

• Graphical implementation? Nice and colorful, but…
  • Sluggish as a rock in multi-server environments
  • Dynamic and scalable? Nope
  • Reimplemented as a TUI (BETA)
    
• Multi-language via 3rd-party lib
  • Turns out it all works directly through the Windows registry, stumbled across it by accident
    
• Classes in PowerShell? Very bad decision.
  • Not practical, instances aren’t easily serializable, methods get lost, parallel remoting with runspaces barely doable
  • Rebuild in C#

With the current release 0.4.1, all the features I had in my backlog are implemented for now. Since I will be lacking the time for this project over the next few months, this is a good moment to write a HowTo, because the README.md in the repo can be a bit challenging at times… as it seems 🙂 But before we get to the hands-on, let’s first talk a little about the technology and history of performance counters.

History

Windows performance counters have been around since NT 3.1 (1993), back then I didn’t even own a computer. At the time, Microsoft needed a standardized way to expose system states without every application having to implement its own monitoring mechanisms. But that also meant scraping measurement values out of the registry and calculating deltas yourself.

Windows 2000 added the Performance Data Helper (PDH) as a convenient high-level API, which shaped access to performance counters the way we know it today. At the same time, WMI was introduced, making performance data accessible through an object-oriented interface. CIM just wasn’t proprietary enough and a bit too compatible 😛

Windows Vista brought the revised Provider V2 model: instead of a DLL that was loaded by the system into a foreign process (error-prone, provider crash = crash of the querying process), providers now register as standalone executables or services. That is the model still in use today.

Structure and Function

Metadata in the registry

All known counters are registered under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib. That’s where the name, description and a numeric index number per counter live, separated by language (subkey 009 for English, 007 for German, etc.).

# List available language packs (counter IDs)
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib"

Providers deliver the raw data

Every component (kernel, drivers, services like IIS or SQL Server, the .NET runtime) can register its own counters. The provider waits passively and only delivers data once someone queries it. There is no permanent collection service running in the background.

# List all services that have a Performance subkey

Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\Services" |
    Where-Object { Test-Path "$($_.PSPath)\Performance" } |
    ForEach-Object {
        $perf = Get-ItemProperty "$($_.PSPath)\Performance"
        [PSCustomObject]@{
            Service      = $_.PSChildName
            FirstCounter = $perf.'First Counter'
            LastCounter  = $perf.'Last Counter'
            Library      = $perf.Library
        }
    } | Format-Table -AutoSize

APIs for applications (CONSUMER)

• PDH (Performance Data Helper): The convenient API that returns values already formatted (e.g. percentages calculated, intervals taken into account). Get-Counter in PowerShell uses PDH.
• PerfLib / registry directly: Faster, but raw. WMI uses this path internally.

Structure

\Processor(_Total)\% Processor Time
└─ Object: „Processor“
└─ Instance: „_Total“ (sum of all cores)
└─ Counter: „% Processor Time“

Microsoft’s Tools

The grandfather: PerfMon

The Performance Monitor has been Microsoft’s official tool since the NT days and, for what it was built for, it is still excellent: interactive, graphical deep-dive analysis of individual systems, with recording via Data Collector Sets, CSV export via relog and basic remoting. The limits show up the moment you want to scale, automate or simply work in the terminal. Portable configuration files, keeping an eye on multiple servers at once or a structured console workflow are not its strengths.

The newcomer: Windows Admin Center

Microsoft’s browser-based management interface also comes with a performance view, cleaner than Perfmon and without a local installation on the managed system. For a quick look at CPU, memory and network that’s perfectly fine. Two things limit its practical value though: first, WAC requires a central installation, just quickly firing it up on a client or at a customer’s site isn’t an option. Second, the counter selection is based, as everywhere, on the localized PDH API, which makes workspaces not really portable.

The evergreen: Get-Counter

Get-Counter is the PowerShell equivalent for console use and therefore the most flexible of the three tools, as long as you’re up for some fiddling willing to get your hands dirty. Counters can be queried directly, repeated in a loop and sent down the pipeline. Remoting works via the -ComputerName parameter. The problem is the same as everywhere: the counter paths are language-dependent, a script written on a German system fails on an English one. On top of that, Get-Counter returns raw data. Formatting, thresholds, history visualization and structured output are entirely manual work. For one-off queries and quick checks it’s ideal, for reproducible, multi-language environments it quickly hits its limits.

# Query CPU, memory and disk counters every 5 seconds, format output as table
$counters = @(
    '\Processor(_Total)\% Processor Time',
    '\Memory\Available MBytes',
    '\PhysicalDisk(_Total)\Disk Bytes/sec'
)

# German Counternames
# $counters = @( 
#	'\Processor(_Total)\% Processor Time', 
#	'\Memory\Available MBytes', 
#	'\PhysicalDisk(_Total)\Disk Bytes/sec' 
# )

Get-Counter -Counter $counters -SampleInterval 5 -Continuous | ForEach-Object {
    $sample = $_.CounterSamples

    [PSCustomObject]@{
        Timestamp       = $_.Timestamp
        'CPU %'         = [math]::Round(($sample | Where-Object Path -like '*processor*').CookedValue, 1)
        'RAM frei (MB)' = [math]::Round(($sample | Where-Object Path -like '*available*').CookedValue, 0)
        'Disk B/s'      = [math]::Round(($sample | Where-Object Path -like '*disk bytes*').CookedValue, 0)
    } | Format-Table -AutoSize
}

The path to language independence

As you can see, language dependence is a big problem across all implementations. And it’s not even necessary. Under the hood, every counter object and every counter has a unique ID. Take a look at the screenshots above, there’s always a First and Last Counter. So \Processor(_Total)\Processor Time (%) –> \238(_Total)\6 .

# Read counter ID/name mapping from registry (English - key 009, German - key 007)
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009' -Name Counter |
		Select-Object -ExpandProperty Counter | Select-Object -First 20

That’s it. The counter object and the path just need to be translated once and I’ve got my language-independent counter path. Before execution it gets translated on the target system and then Get-Counter -Counter <TRANSLATION> is run. In psTerminalPerfCounter this is handled by the cmdlet get-tpcPerformanceCounterInfo

https://dbavonnebenan.de/psterminalperfcounter-counter-in-terminal-handson_en/

The post Windows Performance Counters: How the OS Monitors Itself first appeared on DBA von Nebenan.

• Changelog
• Documentation

Intro

Windows Performance Counters are absolutely powerful, but when I need something quick or monitoring tailored to a specific problem, I get frustrated fast. Usually I fall back on other options – PowerShell native Get-Counter, CIM, or existing monitoring solutions at my clients. But that’s never truly ad-hoc either, and I’ve accepted it.

Recently I had the chance to join Uwe Ricken’s Performance Tuning Workshop at DataSaturday, and he clearly named Performance Counters as a must-have in every DBA’s toolkit. What I didn’t know until then: SQL Server creates individual counters like Compile/sec, AdHoc Queries/sec, etc.

The possibilities to visualize dependencies directly – endless. But how long should I sit there configuring that in Windows Performance Monitor, especially ad-hoc at a client site?

Uwe showed the capabilities in Windows Admin Center, which enables templates you can use flexibly across servers. For systems or environments where Admin Center is used strategically, definitely a great choice.
But two problems remain: As a consultant, I can’t install software at every client, and if Admin Center happens to be running, my English templates fail on German systems.

Still, I was so incredibly hooked by the template idea and the SQL Server possibilities that 4 weeks of after-work crunchtime were spinning in my head. So let me introduce my first module in the PowerShell Gallery:

psTerminalPerfCounter 0.1.0-preview A PowerShell module for displaying real-time graphs of Windows Performance Counters directly in the terminal console. This module provides an easy way to visualize system performance metrics without requiring external graphing tools or GUI applications by using templates and multilanguage support.

You’ll find all technical details and development status in the repository – I just want to show the different possibilities here.

Main Features

100% PowerShell

• no external dependencies

Terminal Graphics

• obviously it’s not a real engine, the more counters the choppier it gets, but it’s sufficient
• The foundation comes from Prateek Singh solution. Without finding this, I would have had to solve this problem first, for which I probably wouldn’t have had time. THANKS!!!

Configuration Templates

• every output element is controlled via configuration files
• flexible, portable

Data Output Customization

• each counter in the configuration file can use its own output
  • Table, Graph, or Both
• arbitrary axis scaling in steps and max values
• arbitrary value coloring based on user-defined ColorMap per counter
• value conversion via configuration file (Byte -> KB -> MB -> GB)

Language Independent

• configuration files are based on counter IDs, not paths
  • portable, regardless of system language translation from ID to counter path happens at runtime
  • no external dependencies
• I had no idea this was possible with Windows built-in tools. Here too I stumbled across a blog at PowerShell.ONE by chance. Again, a big THANKS!!! My original solution had multiple language variants (DE, EN, FR, ES) which would be set by reading system locale.

Demo with CPU Configuration

# Install module with required dependency (GripDevJsonSchemaValidator)
Install-Module -Name psTerminalPerfCounter -AllowPrerelease

# Import the module
Import-Module psTerminalPerfCounter

# Start Default Cpu Configuration
Start-tpcMonitor -ConfigName CPU

When loading the configuration, counter IDs are translated to counter paths and tested

If successful, the first samples are collected so a graph can be displayed

Thats IT!

Within 10 seconds, 2 Performance Counters running, no installation, no language issues.

Demo Counter Translation

# Translate ID -> Path
Get-tpcPerformanceCounterInfo 238-6

# Search Counter -> Including ID
Get-tpcPerformanceCounterInfo "Queue"

Output is heavily truncated since the ResultSet is enormous

# Search Counter -> Including ID
Get-tpcPerformanceCounterInfo "Processor Queue"

What’s next?

The foundation works, the planned feature list is long, and what I really need for SQL Server is still far off. I hope I haven’t solved a problem that doesn’t exist, but this module simply addresses all the issues I’ve always had with Performance Counters, as mentioned above.

Furthermore, this is my first larger project that I’m developing publicly, so GitHub might not always meet expected standards. I’m always happy about feedback and suggestions.

The post psTerminalPerfCounter – SpeedUp your Performance Counters in Terminal first appeared on DBA von Nebenan.

• Changelog
• Documentation

Intro

Die Windows Performance Counter sind absolut mächtig, aber wenn es mal schnell gehen muss oder ich genau passend zu einem Problem ein Monitoring benötige, bin ich schnell genervt. Meistens nutze ich dann doch andere Möglichkeiten, PowerShell Native Get-Counter, CIM oder greife auf vorhandene Monitoring-Lösungen bei meinen Kunden zurück. Aber auch das geht nie AdHoc aber ich habe es akzeptiert.

Nun habe ich beim letzten DataSaturday Uwe Ricken beim Performance Tuning Workshop begleiten dürfen und auch er hat die Performance Counter noch mal klar als Musthave im Werkzeugkoffer eines jeden DBA benannt. Was mir bis dahin nicht bewusst war: SQL Server legt individuelle Counter wie Compile/sec, AdHoc Queries/sec usw. an.

Die Möglichkeiten, Abhängigkeiten direkt zu visualisieren – endlos. Aber wie lange soll ich da sitzen, bis ich das im Windows Performance Monitor abgebildet habe, am besten Adhoc bei einem Kunden?

Uwe zeigte die Möglichkeiten im Windows Admin Center auf, welches Templates ermöglicht, die man flexibel auf Servern nutzen kann. Für System oder Umgebungen, in denen das Admin Center strategisch genutzt wird, definitiv eine sehr gut Wahl.

Aber zwei Probleme bleiben: Als Berater kann ich nicht bei jedem Kunden erst Software installieren und wenn das Admin Center doch läuft, scheitern meine englischen Templates an deutschen Systemen.

Nun war ich trotzdem so unglaublich angefixt von der Template-Idee und den Sql Server Möglichkeiten, dass nach Feierabend 4 Wochen Crunchtime im Kopf waren. Somit möchte ich euch an dieser Stelle mein erstes Modul in der PowerShell Gallery vorstellen

Die technischen Details, Entwicklungsstand findet ihr alle im Repository, ich möchte hier einfach die verschiedenen Möglichkeiten zeigen.

Main Features

100% PowerShell

• keine externen Abhängigkeiten

Terminal-Grafiken

• natürlich ist es keine richtige Engine, je mehr Counter desto Hakeliger wird es, aber es reicht
• Als Basis dient die Lösung von Prateek Singh. Ohne diesen Fund hätte ich wohl dieses Problem erst lösen müssen, wofür ich vermutlich keine Zeit gehabt hätte. DANKE!!!

Configuration Templates

• jedes Element der Ausgabe wird über Configuration Files gesteuert
• flexibel, transportabel

Individualisierung der Datenausgaben

• für jeden Counter im Configuration-File kann eine eigene Ausgabe genutzt werden
  • Table, Graph oder Beide
• beliebige Skalierungen der Achsen in Steps und Max
• beliebige Einfärbung der Values auf Basis einer benutzerdefinierten ColorMap per Counter
• Konvertierung der Values per Configuration-File ( Byte -> KB -> MB -> GB )

Sprachunabhängig

• Configuration Files basieren nicht auf den Counter-Pfaden sondern IDs
• immer noch transportabel, egal welche Systemsprache
• Translation von ID zu Counterpfad erfolgt erst zur Laufzeit

• keine externen Abhängigkeiten
• Ich wusste gar nicht, dass dies möglich ist mit Windows Bordmitteln. Auch hier bin ich durch Zufall über einen Blog gestolpert bei PowerShell.ONE. Auch hier ein dickes DANKE!!! Meine eigentliche Lösung sah mehrere Sprachvarianten ( DE, EN, FR, ES) vor, welche dann per auslesen der Systemlokalen gesetzt wurden.

Demo mit CPU Configuration

# Install module with required dependency (GripDevJsonSchemaValidator)
Install-Module -Name psTerminalPerfCounter -AllowPrerelease

# Import the module
Import-Module psTerminalPerfCounter

# Start Default Cpu Configuration
Start-tpcMonitor -ConfigName CPU

Beim Laden der Konfiguration werden die Counter IDs zu Counterpfaden übersetzt und getestet

Wenn das erfolgreich war, werden die ersten Samples gesammelt, damit ein Graph angezeigt werden kann

Thats IT!

Innerhalb von 10 Sekunden 2 Performance Counter am Laufen, ohne Installation, ohne Sprachprobleme.

Demo Counter Translation

# Translate ID -> Path
Get-tpcPerformanceCounterInfo 238-6

# Search Counter -> Including ID
Get-tpcPerformanceCounterInfo "Queue"

Die Ausgabe ist stark beschnitten, da das ResultSet enorm ist

# Search Counter -> Including ID
Get-tpcPerformanceCounterInfo "Processor Queue"

Wie geht’s weiter?

Die Basis läuft, die planned Feature Liste ist lang und das, was ich wirklich brauche bezüglich Sql Server ist noch in weiter Ferne. Ich hoffe ich habe nicht ein Problem bedient, was es gar nicht gibt, aber dieses Modul adressiert einfach alle Probleme, die ich schon immer mit den Performance Countern hatte, siehe oben.

Weiterhin ist das mein erstes größeres Projekt, was ich Public entwickle, somit könnte Github nicht immer den erwarteten Standards entsprechen. Über Feedback und Hinweise freue ich mich immer.

The post psTerminalPerfCounter – SpeedUp your Performance Counters in Terminal first appeared on DBA von Nebenan.