Dela via

Operations Manager-agenter

  • Artikel

Viktigt

Den här versionen av Operations Manager har nått slutet av supporten. Vi rekommenderar att du uppgraderar till Operations Manager 2022.

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 Tjänsten Microsoft Monitoring Agent (MMA). Tjänsten Microsoft Monitoring Agent samlar in händelse- och prestandadata och kör uppgifter och andra arbetsflöden som definierats i ett hanteringspaket. Även när tjänsten inte kan kommunicera med hanteringsservern den rapporterar till kan tjänsten fortsätta köras och den placerar insamlade data och händelser i kö på den övervakade datorns disk. När anslutningen återupprättas skickar tjänsten Microsoft Monitoring Agent insamlade data och händelser till hanteringsservern.

Anteckning

  • Microsoft Monitoring Agent-tjänsten kallas ibland för hälsotillståndstjänsten.

Microsoft Monitoring Agent-tjänsten körs även på hanteringsservrar. På en hanteringsserver kör tjänsten övervakningsarbetsflöden och hanterar autentiseringsuppgifter. Tjänsten kör arbetsflöden genom att starta MonitoringHost.exe-processer med angivna autentiseringsuppgifter. De här processerna övervakar och samlar in händelseloggdata, prestandaräknardata och WMI-data (Windows Management Instrumentation) samt kör åtgärder, till exempel skript.

Kommunikation mellan agenter och hanteringsservrar

Operations Manager-agenten skickar aviserings- och identifieringsdata till sin tilldelade primära hanteringsserver som skriver dessa data till den operativa (använda) databasen. Agenter skickar även information om händelser, prestanda och tillstånd till den primära hanteringsservern för den agenten, som skriver informationen till den använda databasen och informationslagerdatabasen på samma gång.

Agenten skickar data enligt schemaparametrarna för varje regel och övervakare. Med reglerna för optimerad insamling överförs bara data om en insamling från en räknare skiljer sig från den tidigare insamlingen med ett visst toleransvärde, till exempel 10 %. På så vis minskas nätverkstrafiken och den lagrade datavolymen i den använda databasen.

Alla agenter skickar dessutom regelbundet ett datapaket, som kallas pulsslag, till hanteringsservern, som standard var 60:e sekund. Pulsslagets uppgift är att verifiera agentens tillgänglighet och kommunikationen mellan agenten och hanterigsservern. Mer information om pulsslag finns i How Heartbeats Work in Operations Manager (Så här fungerar pulsslag i Operations Manager).

Operations Manager kör en hälsotillståndsbevakare för varje agent, som övervakar hälsotillståndet på fjärrhälsotillståndstjänsten ur hanteringsserverns perspektiv. Agenten kommunicerar med en hanteringsserver via TCP-port 5723.

Bild av kommunikation mellan agent och 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 den övervakade datorns hälsotillstånd. 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 definierats i vår implementering av UNIX- och Linux-hanteringspaketen:

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

UNIX- och Linux-agenterna för Operations Manager består av en CIM Object Manager (det vill säga CIM Server) och en uppsättning CIM-providers. CIM Object Manager är den serverkomponent 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 och med System Center 2012 SP1 är CIM-objekthanteraren som används i UNIX- och Linux-agenter för Operations Manager OpenPegasus-servern. De providers som används för att samla in och rapportera övervakningsdata utvecklas av Microsoft och finns tillgängliga som ö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. OMI ersätter OpenPegasus för UNIX-/Linux-agenterna för Operations Manager. Precis som OpenPegasus är OMI en CIM Object Manager-implementering med öppen källkod, enkel och portabel – ä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 en UNIX- eller Linux-dator:

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

    Används för agentunderhållsaktiviteter, till exempel installation, uppgradering och borttagning av agenter.

  • WS-Management (Web Services for 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ållsaktiviteter 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 utvärderingen av data för att visa hälsostatusen. Alla åtgärder, till exempel agentunderhåll, övervakare, regler, uppgifter och återställningar, konfigureras med fördefinierade profiler enligt kraven för ett konto med eller utan privilegier.

Anteckning

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 -information.

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. För att aktivera den här ändringen måste du skapa den nya registernyckeln UseMIAPI så att Operations Manager kan använda de nya Async MI-API:erna på hanteringsservrar som övervakar Linux/Unix-system.

  1. Öppna registry Editor 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 WSMAN Sync-API:erna kan du ta bort registernyckeln UseMIAPI .

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 konto utan privilegier få utökade privilegier och anta identiteten av ett privilegierat konto på UNIX- eller Linux-datorn. Processen med utökade privilegier utförs av UNIX-programmen su (superuser) och sudo, som använder autentiseringsuppgifterna som hanteringsservern tillhandahåller. För privilegierade agentunderhållsåtgärder som använder SSH (till exempel identifiering, distribuering, uppgraderingar, avinstallation och agentåterställning) finns det stöd för su- och sudo-höjning samt 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 hur du anger autentiseringsuppgifter och konfigurerar konton finns i Ange autentiseringsuppgifter för åtkomst till UNIX- och Linux-datorer.

Autentisering med gateway-server

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 uppfyller Operations Managers krav på ö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.

Anteckning

  • 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 installationsmetoden. En hanteringsserver måste kunna ansluta till datorn med RPC, och åtgärdskontot för hanteringsservern eller andra angivna autentiseringsuppgifter måste ha administrativ åtkomst till måldatorn.
  • Inkludering i installationsavbildningen. Det här är en manuell installation med en basavbildning som används för att förbereda 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 av någon av de andra metoderna, till exempel när RPC (Remote Procedure Call) inte är tillgänglig på grund av en brandvägg. Installationen körs på agenten eller distribueras med ett befintligt programdistributionsverktyg manuellt.

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 skötas manuellt. Du kommer att kunna använda Active Directory-integrering för att tilldela agenter till hanteringsgrupper. Mer information finns i Integrera Active Directory och Operations Manager.

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

Identifieringen av ett Windows-system kräver att portarna TCP 135 (RPC), RPC-intervallet och TCP 445 (SMB) hålls öppna, samt att SMB-tjänsten är aktiverad på agentdatorn.

  • När en målenhet har identifierats kan en agent distribueras till den. Agentinstallationen kräver att du:
  • Öppnar RPC-portar som börjar med slutpunktsavbildaren TCP 135 och SMB-port (Server Message Block) TCP/UDP 445.
  • Aktiverar fil- och skrivardelning för Microsoft Networks och klienten för Microsoft Networks-tjänster. (Det säkerställer att SMB-porten är aktiv.)
  • Om de är aktiverade 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 konfigureras att tillåta obeställda inkommande meddelanden från IP-adressen och undernäten för primära och sekundära hanteringsservrar för agenten.
  • Ett konto som har lokala administratörsrättigheter 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å installationsmediet för Operations Manager-produkten i underkatalogen \msxml. Push-agentinstallation installerar MSXML 6 på målenheten om den inte redan är installerad.

Active Directory-agenttilldelning

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. Första gången datorn ansluter frågar Operations Manager-agenten Active Directory efter dess tilldelade primära- och redundans-hanteringsserver och börjar automatiskt att övervaka datorn.

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

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

Anteckning

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 inaktiverat 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 medför en säkerhetsrisk.

Agenttilldelningen utförs med hjälp av en tjänstanslutningspunkt (SCP), vilket är ett Active Directory-objekt för publiceringsinformation som klientprogram kan använda för att binda till en tjänst. Detta skapas av en domänadministratör som kör kommandoradsverktygetMOMADAdmin.exe för att skapa en AD DS-container för en Operations Manager-hanteringsgrupp i domänerna för de datorer som den hanterar. Den AD DS-säkerhetsgrupp som anges när MOMADAdmin.exe körs beviljas läs- och ta bort underordnade behörigheter till containern. SCP innehåller anslutningsinformation till hanteringsservern, inklusive serverns FQDN och portnummer. Operations Manager-agenter kan automatiskt identifiera hanteringsservrar genom att fråga efter tjänstanslutningspunkter (SCP). Arv är inte inaktiverat, och eftersom en agent kan läsa integrationsinformationen som registrerats i AD, om du tvingar arv för gruppen Alla att läsa alla objekt på rotnivå i Active Directory, påverkar detta allvarligt och i huvudsak avbryter AD-integreringsfunktionerna. Om du uttryckligen framtvingar arv i hela katalogen genom att ge gruppen Alla läsbehörigheter måste du blockera arvet i ad-integreringscontainern på den översta nivån med namnet OperationsManager och alla underordnade objekt.  Om du inte gör detta fungerar INTE AD-integreringen som den är utformad och du har ingen tillförlitlig och konsekvent primär tilldelning och redundanstilldelning för distribuerade agenter. Dessutom får alla agenter i båda hanteringsgrupperna fler IP-adresser om du har fler än en hanteringsgrupp. 

Den här funktionen fungerar bra för att styra agenttilldelningen i en distribuerad hanteringsgruppsdistribution och förhindrar att agenterna rapporterar till hanteringsservrar som är dedikerade för resurspooler eller hanteringsservrar i ett sekundärt datacenter i en konfiguration för varmt vänteläge så att agenten inte redundansväxlar under normal drift.

Konfiguration av en agenttilldelning hanteras av en Operations Manager-administratör som använder guiden Agenttilldelning och redundans för att tilldela datorer till en primär respektive sekundär hanteringsserver.

Anteckning

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

Nästa steg