Nu laver Microsoft Linux-udgaver af Sysinternals-værktøjerne

Microsoft er kommet med en Linux-version af Sysinternals-værktøjet Procdump. Illustration: Microsoft
Sysinternals er en samling værktøjer, der gør det relativt enkelt at administrere, overvåge og fejlsøge i Windows-baserede systemer.

Microsoft kom for nylig med en Linux-udgave af ProcDump-værktøjet fra den klassiske Sysinternals-samling med systemværktøjer til Windows.

Der er tale om et værktøj, som først og fremmest skal afdække store peaks i brugen af CPU under kørslen af applikationer. I den slags tilfælde genererer værktøjet såkaldte crash dumps, når disse peaks opstår, noget systemadministratorer og udviklere kan bruge til at afgøre, hvad der er årsag til den store stigning i brugen af CPU.

Meget populær

Sysinternals var i sin tid noget af den mest lovpriste software, man kunne få til Windows. Der er tale om en samling med værktøjer, der gør det relativt enkelt at administrere, overvåge og fejlsøge i Windows-baserede systemer. Bag værktøjerne stod primært Mark Russinovich, som i dag er teknologidirektør for Microsoft Azure.

Russinovich etablerede Sysinternals-websitet i 1996 og udvidede det med stadigt nye værktøjer. Microsoft købte Sysinternals i 2006 og ansatte samtidig Russinovich som en teknisk ressource.

Læs også: Her forsvinder dine Windows-ressourcer hen

Sysinternals kom på et tidspunkt, hvor Windows i betydelig mindre grad end i dag havde den type værktøjer indbygget. I hvor høj grad der er det samme behov for nutidens Linux-distributioner, kan nok diskuteres.

Procesmonitor

Foreløbig er kun ProcDump udgivet, men det er allerede bekræftet, at Microsoft nu er i færd med at lave en Linux-version af Procmon (Process Monitor). Windows-udgaven af dette værktøj kombinerer de klassiske Sysinternals-værktøjer Filemon og Regmon, som i realtid viser ændringer i henholdsvis filsystemet og Windows-registeret, sammen med proces- og coreaktivitet.

Hvad Linux-versionen præcist vil tilbyde, er foreløbig ikke meldt ud.

Windows-udgaven af Process Monitor fra Sysinternals viser al aktivitet fra processerne i filsystemet og registeret. Illustration: Screendump fra digi.no

Hvorvidt Microsoft har konkrete planer for yderligere Linux-kloner af Sysinternals-værktøjene, er uklart. Men i Twitter-tråden nedenfor afvises det på ingen måde, at der vil komme flere.

Tværtimod ønsker Microsoft-repræsentanterne at få at vide, hvilke af værktøjerne der er mest interessante for brugerne.

Artiklen er fra digi.no

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Morten Jensen

Det er sjovt at se Microsoft gå fra Steve Ballmer's "Linux is a cancer"-holdning[1] til så bredt at omfavne teknologien.

Satya Nadella ser ud til at få vendt skuden hos MS, bl.a. ved at omfavne open source, i stedet for at anse det som tyvagtig kommunisme :)

[1] Citatet lyder: "Linux is not in the public domain. Linux is a cancer that attaches itself in an intellectual property sense to everything it touches. That's the way that the license works."

  • 7
  • 1
Casper Pedersen

Hvorfor ikke lære de arme Windows Agnostic mennesker at bruge de værktøjer der allerede findes i til Unix/Linux. Bare fordi Azur understøtter Linux, betyder ikke at Linux pludselig skal opføre sig som en Windows box.

  • 8
  • 2
Sune Marcher

ProcDump er vel ikke mere speciel end hvad gdb/(gcore) allerede kan?


Nu er gdb lidt af en schweiserkniv, så måske kan den anvendes til det samme :) - men når jeg tænker gdb, tænker jeg at man har en (ofte interaktiv) debugging session.

Idéen med Procdump er at du har et (ret lightweight) tool der kan monitorere en proces, og lave (serier af) core dumps fx når processen falder udenfor angivne performance-kriterier.

Dvs. du kan bruge det til at indsamle debug-data for problemer hvor du ikke kan gennemskue noget mønster, og derfor ikke ved hvornår det ville give mening at attache en debugger.

  • 2
  • 2
Sune Marcher

Interessant med downvotes, men ingen kommentarer der enten forklarer hvordan de ville løse opgaven med standard tools, eller diskuterer hvorfor de ikke synes det er en god metode, og foreslår alternative debugging-metoder.

Skal der hades på værktøjet blot fordi det er fra Microsoft, eller er der nogle gode argumenter? :-)

  • 4
  • 0
Leonhard Printz

Til CPU monitorering er der allerede et suite af værktøjer fra top, htop, atop, etc, der alle sammen præsenterer den information som linux kernen allerede giver om memory og cpu usage.

Til coredumps er der mange måder at gøre det på. Værktøjet gdb er allerede nævnt og er fuldt ud istand til at lave memory dumps, memory disassembly. Du behøver ikke kun at bruge det til standard debugging.

Derudover er der systemd-coredump, hvor du kan bruge systemd (hvis formål er at starte og overvåge processer) til at lave periodiske coredumps.

Sjovt at du nævner at gdb i den er sammenhæng, for Microsofts udgave af procdump på Linux er sådan set bare en wrapper rundt om gdb. Du kan selv kigge på deres source kode, og en af deres dependencies er gdb som bliver brugt. Uden at have kigget hele source koden igennem er det ihvertfald mit førstehånds indtryk.

Der er som sådan ikke noget ivejen med at Microsoft gør værktøjer der er tilgængelige på Windows, tilgængelige på Linux.

Men os der kender Microsofts lidt blakkede historie, så er ordene "Embrace, Extend, Extinguish" velkendte. Microsoft har en tildens til at incorporerer outside værktøjer, udvide dem, for derefter at gøre udvidelserne utilgængelige for andre.

Så jeg ser på det med en tøvende positiv holdning. Godt gjort at dem. Jeg kommer nok bare fortsæt til at bruge linux værktøjer. Jeg tror ikke noget af det bliver standard i Linux miljøet. Og så længe det giver en større diversitet så er det sådan set godt nok.

  • 0
  • 0
Sune Marcher

Til CPU monitorering er der allerede et suite af værktøjer fra top, htop, atop, etc, der alle sammen præsenterer den information som linux kernen allerede giver om memory og cpu usage.

Til coredumps er der mange måder at gøre det på. Værktøjet gdb er allerede nævnt og er fuldt ud istand til at lave memory dumps, memory disassembly. Du behøver ikke kun at bruge det til standard debugging.


*top værktøjerne er til interaktiv monitoring/fejlsøgning. Du har en box der opfører sig mærkeligt, du ssh'er til den og starter top for at se om der er nogle processer der er kørt i hegnet.

At lave et coredump er ikke i sig selv magisk, det er et Solved Problem. Procdump tilføjer ikke noget nyt til selve mekanikken, og det ville være fjollet ikke at benytte sig af eksisterende kode til selve coredump genereringen.

Pointen med værktøjet er just-in-time generering af core dumps "under særlige omstændigheder" - tidspunkter du ikke regner med / kan forudsige - så du har et snapshot du senere kan inspicere, sandsynligvis med gdb.

Så i stedet for faste periodiske dumps, som risikerer at fylde din diskplads ud samtidig med at et interessant event måske sker mellem to dumps, så får du genereret dumps ud fra dine kriterier.

Hvis der allerede er tooling der kan gøre dette, er Procdump måske lidt overflødigt - og det er derfor jeg spørger hvordan man med standard Linux tools ville udføre opgaven.

Men os der kender Microsofts lidt blakkede historie, så er ordene "Embrace, Extend, Extinguish" velkendte. Microsoft har en tildens til at incorporerer outside værktøjer, udvide dem, for derefter at gøre udvidelserne utilgængelige for andre.


Microsoft har gjort en rigtigt masse gode og rigtige ting de seneste år, men jeg er stadig skeptisk. Selv hvis de ikke har gang i en EEE men "mener det" med hensyn til åbenhed (og det hælder jeg til godt kunne være tilfældet), så er de et privatejet firma der skal skabe overskud til aktionærerne, og så kan holdninger hurtigt ændre sig igen.

Jeg kan ikke spå om fremtiden, så jeg må forholde mig til facts. Som fx at de udgiver ting under opensource licenser der binder dem lovmæssigt, og at de er gået med i Open Invention Network. Det betyder ikke at de ikke kan fucke os alle sammen over i fremtiden, men de har gjort det sværere for sig selv at gøre det.

  • 0
  • 0
Log ind eller Opret konto for at kommentere