Dela via

Operations Manager-agenter

I System Center Operations Manager är en agent en tjänst som är installerad på en dator som söker efter konfigurationsdata och proaktivt samlar in information för analys och rapportering, mäter hälsotillståndet för övervakade objekt som en SQL-databas eller logisk disk och kör uppgifter på begäran av en operatör eller som svar på ett villkor. Det gör att Operations Manager kan övervaka Windows-, Linux- och UNIX-operativsystem och komponenterna i en IT-tjänst som är installerad på dem, till exempel en webbplats eller en Active Directory-domänkontrollant.

Windows-agent

På en övervakad Windows-dator visas Operations Manager-agenten som MMA-tjänsten (Microsoft Monitoring Agent). Tjänsten Microsoft Monitoring Agent samlar in händelse- och prestandadata, kör uppgifter och andra arbetsflöden som definierats i ett hanteringspaket. Även om tjänsten inte kan kommunicera med hanteringsservern som den rapporterar till fortsätter tjänsten att köras och köar insamlade data och händelser på disken på den övervakade datorn. När anslutningen återställs skickar Microsoft Monitoring Agent-tjänsten insamlade data och händelser till hanteringsservern.

Not

  • Tjänsten Microsoft Monitoring Agent kallas ibland för hälsotjänsten.

Tjänsten Microsoft Monitoring Agent körs också på hanteringsservrar. På en hanteringsserver kör tjänsten övervakningsarbetsflöden och hanterar autentiseringsuppgifter. För att köra arbetsflöden initierar tjänsten MonitoringHost.exe processer med angivna autentiseringsuppgifter. Dessa processer övervakar och samlar in händelseloggdata, prestandaräknardata, WMI-data (Windows Management Instrumentation) och kör åtgärder som skript.

Kommunikation mellan agenter och hanteringsservrar

Operations Manager-agenten skickar aviserings- och identifieringsdata till den tilldelade primära hanteringsservern, som skriver data till driftdatabasen. Agenten skickar även händelser, prestanda och tillståndsdata till den primära hanteringsservern för agenten, som skriver data till drift- och informationslagerdatabaserna samtidigt.

Agenten skickar data enligt schemaparametrarna för varje regel och övervakning. För optimerade insamlingsregler överförs data endast om ett exempel på en räknare skiljer sig från föregående exempel med en angiven tolerans, till exempel 10%. Detta bidrar till att minska nätverkstrafiken och mängden data som lagras i driftdatabasen.

Dessutom skickar alla agenter ett paket med data, kallat ett pulsslag, till hanteringsservern enligt ett regelbundet schema, som standard var 60:e sekund. Syftet med pulsslag är att verifiera tillgängligheten för agenten och kommunikationen mellan agenten och hanteringsservern. Mer information om pulsslag finns i Hur pulsslag fungerar i Operations Manager.

För varje agent kör Operations Manager en hälsotjänstövervakare, som övervakar tillståndet för fjärrhälsotjänsten ur hanteringsserverns perspektiv. Agenten kommunicerar med en hanteringsserver via TCP-port 5723.

Illustration av kommunikation från agent till hanteringsserver.

Linux/UNIX-agent

Arkitekturen för UNIX- och Linux-agenten skiljer sig avsevärt från en Windows-agent. Windows-agenten har en hälsotjänst som ansvarar för att utvärdera hälsotillståndet för den övervakade datorn. UNIX- och Linux-agenten kör ingen hälsotjänst. i stället skickas information till hälsotjänsten på en hanteringsserver som ska utvärderas. Hanteringsservern kör alla arbetsflöden för att övervaka hälsotillståndet för operativsystemet som definieras i vår implementering av UNIX- och Linux-hanteringspaketen:

  • Skiva
  • Processor
  • Minne
  • Nätverkskort
  • Operativsystem
  • Processer
  • Loggfiler

UNIX- och Linux-agenterna för Operations Manager består av en CIM Object Manager (d.v.s. CIM Server) och en uppsättning CIM-providers. CIM Object Manager är komponenten server som implementerar WS-Management kommunikation, autentisering, auktorisering och sändning av begäranden till leverantörerna. Leverantörerna är nyckeln till CIM-implementeringen i agenten, definierar CIM-klasserna och egenskaperna, samverkar med kernel-API:erna för att hämta rådata, formaterar data (till exempel beräkning av delta och medelvärden) och underhåller begäranden som skickas från CIM Object Manager. Från System Center Operations Manager 2007 R2 till System Center 2012 SP1 är CIM Object Manager som används i Operations Manager UNIX- och Linux-agenterna OpenPegasus-servern. De leverantörer som används för att samla in och rapportera övervakningsdata utvecklas av Microsoft och har öppen källkod på CodePlex.com.

bild av programvaruarkitekturen för Operations Manager UNIX/Linux-agenten.

Detta ändrades i System Center 2012 R2 Operations Manager, där UNIX- och Linux-agenter nu baseras på en helt konsekvent implementering av Open Management Infrastructure (OMI) som CIM Object Manager. När det gäller Operations Manager UNIX/Linux-agenter ersätter OMI OpenPegasus. Precis som OpenPegasus är OMI en implementering med öppen källkod, enkel och bärbar CIM Object Manager – även om den är lättare i vikt och mer portabel än OpenPegasus. Den här implementeringen fortsätter att tillämpas i System Center 2016 – Operations Manager och senare.

diagram över den uppdaterade programvaruarkitekturen för Operations Manager UNIX/Linux-agenten.

Kommunikationen mellan hanteringsservern och UNIX- och Linux-agenten är uppdelad i två kategorier: agentunderhåll och hälsoövervakning. Hanteringsservern använder två protokoll för att kommunicera med UNIX- eller Linux-datorn:

  • Secure Shell (SSH) och Secure Shell File Transfer Protocol (SFTP)

    Används för agentunderhållsuppgifter som att installera, uppgradera och ta bort agenter.

  • Webbservicetjänster för hantering (WS-Management)

    Används för alla övervakningsåtgärder och inkluderar identifiering av agenter som redan har installerats.

Kommunikationen mellan Operations Manager-hanteringsservern och UNIX- och Linux-agenten använder WS-Man via HTTPS och WinRM-gränssnittet. Alla agentunderhållsuppgifter utförs via SSH på port 22. All hälsoövervakning utförs över WS-MAN på port 1270. Hanteringsservern begär prestanda- och konfigurationsdata via WS-MAN innan data utvärderas för att tillhandahålla hälsostatus. Alla åtgärder, till exempel agentunderhåll, övervakare, regler, uppgifter och återställningar, är konfigurerade att använda fördefinierade profiler enligt deras behov av ett oprivilegierat eller privilegierat konto.

Not

Alla autentiseringsuppgifter som anges i den här artikeln gäller konton som har upprättats på UNIX- eller Linux-datorn, inte de Operations Manager-konton som konfigureras under installationen av Operations Manager. Kontakta systemadministratören om du vill ha autentiseringsuppgifter och autentiseringsinformation.

För att stödja de nya skalbarhetsförbättringarna med antalet UNIX- och Linux-system System Center 2016 – Operations Manager och senare kan övervaka per hanteringsserver är de nya API:erna för Async Windows Management Infrastructure (MI) tillgängliga i stället för WSMAN Sync API:er, som används som standard. Om du vill aktivera den här ändringen måste du skapa den nya registernyckeln UseMIAPI- för att göra det möjligt för Operations Manager att använda de nya Async MI-API:erna på hanteringsservrar som övervakar Linux/Unix-system.

  1. Öppna Registereditorn från en upphöjd kommandotolk.
  2. Skapa registernyckeln UseMIAPI- under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup.

Om du behöver återställa den ursprungliga konfigurationen med hjälp av API:erna för WSMAN-synkronisering kan du ta bort UseMIAPI- registernyckel.

Agentsäkerhet

Autentisering på UNIX/Linux-dator

I Operations Manager behöver systemadministratören inte längre ange rotlösenordet för UNIX- eller Linux-datorn till hanteringsservern. Nu kan ett icke-privilegierat konto låtsas vara ett privilegierat konto på UNIX- eller Linux-datorn. Höjningsprocessen utförs av UNIX su-program (superanvändare) och sudo-program som använder de autentiseringsuppgifter som hanteringsservern tillhandahåller. För privilegierade agentunderhållsåtgärder som använder SSH (till exempel identifiering, distribution, uppgraderingar, avinstallation och agentåterställning), tillhandahålls stöd för su, sudo elevation och stöd för SSH-nyckelautentisering (med eller utan lösenfras). För privilegierade WS-Management åtgärder (till exempel visning av säkra loggfiler) läggs stöd för sudo-höjning (utan lösenord) till.

Detaljerade anvisningar för att ange autentiseringsuppgifter och konfigurera konton finns i Ange autentiseringsuppgifter för åtkomst till UNIX- och Linux-datorer.

Autentisering med gatewayserver

Gatewayservrar används för att aktivera agenthantering av datorer som ligger utanför Kerberos-förtroendegränsen för en hanteringsgrupp. Eftersom gatewayservern finns i en domän som inte är betrodd av den domän som hanteringsgruppen finns i, måste certifikat användas för att upprätta varje dators identitet, agent, gatewayserver och hanteringsserver. Det här arrangemanget uppfyller kraven från Operations Manager för ömsesidig autentisering.

Detta kräver att du begär certifikat för varje agent som rapporterar till en gatewayserver och importerar certifikaten till måldatorn med hjälp av MOMCertImport.exe-verktyget, som finns i installationsmediets SupportTools\-katalog (amd64 eller x86). Du måste ha åtkomst till en certifikatutfärdare (CA), som kan vara en offentlig certifikatutfärdare som VeriSign, eller så kan du använda Microsoft Certificate Services.

Agentdistribution

System Center Operations Manager-agenter kan installeras med någon av följande tre metoder. De flesta installationer använder en kombination av dessa metoder för att installera olika uppsättningar datorer efter behov.

Not

  • Du kan inte installera MMA på en dator där Operations Manager-hanteringsservern, gatewayservern, driftkonsolen, driftdatabasen, webbkonsolen, System Center Essentials eller System Center Service Manager är installerad – eftersom de redan har sin inbyggda version av MMA installerad.
  • Du kan bara använda antingen MMA- eller Log Analytics-agenten (VM-tilläggsversion).
  • Identifiering och installation av en eller flera agenter från driftkonsolen. Det här är den vanligaste installationsformen. En hanteringsserver måste kunna ansluta datorn till RPC och antingen hanteringsserverns åtgärdskonto eller andra angivna autentiseringsuppgifter måste ha administrativ åtkomst till måldatorn.
  • Medtagande i installationsbilden. Det här är en manuell installation av en basavbildning som används som förberedelse för andra datorer. I det här fallet kan Active Directory-integrering användas för att automatiskt tilldela datorn till en hanteringsserver vid den första starten.
  • Manuell installation. Den här metoden används när agenten inte kan installeras med någon av de andra metoderna, till exempel när fjärrproceduranrop (RPC) inte är tillgängligt på grund av en brandvägg. Installationen körs manuellt på agenten eller distribueras via ett befintligt programdistributionsverktyg.

Agenter som installeras med identifieringsguiden kan hanteras från driftkonsolen, till exempel uppdatera agentversioner, tillämpa korrigeringar och konfigurera hanteringsservern som agenten rapporterar till.

När du installerar agenten med en manuell metod måste även uppdateringar av agenten utföras manuellt. Du kommer att kunna använda Active Directory-integrering för att tilldela agenter till hanteringsgrupper. För mer information, se Integrera Active Directory med Operations Manager.

Välj fliken som krävs för att veta mer om agentdistribution till Windows- och UNIX- och LINUX-system:

Identifiering av ett Windows-system kräver att portarna TCP 135 (RPC), RPC-intervall och TCP 445 (SMB) förblir öppna och att SMB-tjänsten är aktiverad på agentdatorn.

  • När en målenhet har identifierats kan en agent distribueras till den. Agentinstallation kräver:
  • Öppna RPC-portar som börjar med slutpunktsmapparen TCP 135 och SMB-porten (Server Message Block) TCP/UDP 445.
  • Aktivera fil- och skrivardelning för Microsoft Networks och klient för Microsoft Networks-tjänster. (Detta säkerställer att SMB-porten är aktiv.)
  • Om det är aktiverat måste grupprincipinställningarna för Windows-brandväggen för Tillåt undantag för fjärradministration och Tillåt undantag för fil- och skrivardelning anges till att tillåta oönskade inkommande meddelanden från IP-adressen och undernäten för agentens primära och sekundära hanteringsservrar.
  • Ett konto som har lokal administratörsbehörighet på måldatorn.
  • Windows Installer 3.1. Information om hur du installerar finns i artikeln 893803 i Microsoft Knowledge Base https://go.microsoft.com/fwlink/?LinkId=86322
  • Microsoft Core XML Services (MSXML) 6 på Operations Manager-produktinstallationsmediet i underkatalogen \msxml. Installation av push-agent installerar MSXML 6 på målenheten om den inte redan är installerad.

Active Directory-agent-tilldelning

Med System Center Operations Manager kan du dra nytta av din investering i Active Directory Domain Services (AD DS) genom att låta dig använda den för att tilldela agenthanterade datorer till hanteringsgrupper. Den här funktionen används ofta med agenten som distribueras som en del av en utvecklingsprocess för serverdistribution. När datorn är online för första gången frågar Operations Manager-agenten Active Directory om dess primära servertilldelning och redundanshanteringsservertilldelning och börjar automatiskt övervaka datorn.

Så här tilldelar du datorer till hanteringsgrupper med hjälp av AD DS:

  • Funktionsnivån för AD DS-domäner måste vara inbyggd i Windows 2008 eller senare
  • Agenthanterade datorer och alla hanteringsservrar måste finnas i samma domän eller i dubbelriktade betrodda domäner.

Not

En agent som fastställer att den är installerad på en domänkontrollant frågar inte Active Directory om konfigurationsinformation. Detta är av säkerhetsskäl. Active Directory-integrering är inaktiverad som standard på domänkontrollanter eftersom agenten körs under det lokala systemkontot. Det lokala systemkontot på en domänkontrollant har domänadministratörsbehörighet. Därför identifieras alla anslutningspunkter för hanteringsservertjänsten som är registrerade i Active Directory, oavsett domänkontrollantens medlemskap i säkerhetsgruppen. Därför försöker agenten ansluta till alla hanteringsservrar i alla hanteringsgrupper. Resultatet kan vara oförutsägbart, vilket innebär en säkerhetsrisk.

Agenttilldelning utförs med hjälp av en tjänstanslutningspunkt (SCP), som är ett Active Directory-objekt för publicering av information som klientprogram kan använda för att binda till en tjänst. Detta skapas av en domänadministratör som kör kommandoradsverktyget MOMADAdmin.exe för att skapa en AD DS-container för en Operations Manager-hanteringsgrupp i domänerna för de datorer som hanteras. Den AD DS-säkerhetsgrupp som anges när MOMADAdmin.exe körs beviljas rättigheter att läsa och ta bort underordnade objekt i containern. SCP innehåller anslutningsinformation till hanteringsservern, inklusive serverns fullständiga domännamn och portnummer. Operations Manager-agenter kan automatiskt identifiera hanteringsservrar genom att fråga efter SCP:er. Arv är inte inaktiverat, och eftersom en agent kan läsa integreringsinformationen som registrerats i AD, om du tvingar arv för Alla-gruppen att läsa alla objekt på rotnivå i Active Directory, kommer detta att allvarligt påverka och i princip störa AD-integrationen. Om du uttryckligen framtvingar arv i hela katalogen genom att ge gruppen Alla läsbehörighet måste du blockera det här arvet i ad-integreringscontainern på den översta nivån med namnet OperationsManageroch alla underordnade objekt.  Om du inte gör det fungerar INTE AD-integreringen som den är utformad och du har inte tillförlitlig och konsekvent primär tilldelning och redundanstilldelning för agenter som distribueras. Om du råkar ha fler än en hanteringsgrupp kommer även alla agenter i båda hanteringsgrupperna att ha flera hem. 

Den här funktionen fungerar bra för att kontrollera agenttilldelningen i en distribuerad hanteringsgruppsdistribution, för att förhindra agenter från att rapportera till hanteringsservrar som är dedikerade till resurspooler eller hanteringsservrar i ett sekundärt datacenter i en konfiguration med varmt vänteläge för att förhindra agentredundans under normal drift.

Konfigurationen av agenttilldelning hanteras av en Operations Manager-administratör med hjälp av guiden Agenttilldelning och redundans för att tilldela datorer till en primär hanteringsserver och sekundär hanteringsserver.

Not

Active Directory-integrering är inaktiverat för agenter som har installerats från driftkonsolen. Som standard är Active Directory-integrering aktiverat för agenter som installeras manuellt med hjälp av MOMAgent.msi.

Nästa steg