Blogg

Migrering till Azure Log Analytics

Nyligen var vi på Approved involverade i ett projekt med en av våra kunder där målet var att ansluta ett stort antal servrar till Azure Log Analytics. De hade tidigare försökt sig på detta genom att koppla upp servrarna genom SCOM, men då de gjorde en s.k multi-home på servrarna mot flera management groups slutade kopplingen att fungera. Detta var ett stort problem då den data de skickar till Log Analytics är väldigt viktig för dem, och vi funderade då på hur vi kunde lösa det på bästa sätt. Vi kom efter en del diskussioner fram till att rätt väg att gå i det här fallet var en direktkoppling mot Log Analytics, istället för som tidigare via SCOM. Det här var en mycket spännande uppgift som vi mer än gärna tog på oss. Det finns ett flertal olika metoder att göra själva kopplingen mot Log Analytics, men det finns också ett stort antal saker att tänka på under resans gång, allt för att inte springa på några otrevliga överraskningar.

Problemställningen

I det här fallet hade majoriteten av servrarna en gammal agentversion, från SCOM 2012. Denna agent kan inte kopplas direkt mot Log Analytics då den funktionaliteten saknas, den kom först i senare versioner. Det enklaste sättet att se om en server kan kopplas direkt mot Log Analytics är att titta på egenskaperna för ”Microsoft Monitoring Agent” i kontrollpanelen. Om fliken “Azure Log Analytics (OMS)” saknas kan servern inte kopplas direkt mot Log Analytics, och kräver därför en uppgradering.

 1-2

Servrarna rapporterade redan till Log Analytics genom SCOM, men i det här fallet valde vi att gå på en direktanslutning istället. En av anledningarna till detta var för att få bättre kontroll över vilka servrar som anslöt mot Log Analytics, men också för att komma ifrån scenariot där SCOM används som en mellanhand. Skulle SCOM fallera hade ingen av servrarna kunnat rapportera, men genom att gå på en direktanslutning fick vi bort beroendet på mellanhanden, i det här fallet SCOM.

Att hålla koll på agentuppgraderingarna

Uppgraderingen som sådan kan göras på en rad olika sätt, den kan skjutas ut genom SCOM-konsolen, genom Configuration Manager och ett flertal andra metoder. I det här specifika fallet valde vi att använda Configuration Manager som distributionssätt då alla nödvändiga portöppningar redan fanns på plats. Utmaningen som vi såg med att skjuta ut den via Configuration Manager var att uppgraderingen skjuts ut till en kollektion av servrar. Det kan vara svårt att följa processen på ett bra sätt då den skjuts ut till olika servrar i en oregelbunden följd, i motsats till om det hade gjorts via exempelvis PowerShell då man hade gjort det i följd.

Huvudsaken här var att hålla koll på att agenterna uppgraderades till den nya versionen, men också att de fortsätter kommunicera med Log Analytics, även efter uppgraderingen. För att få koll på detta skrev jag en fråga (query) för att köras i Log Analytics som tittar på följande aspekter;

  • Servrar som rapporterar och som är av en given version
  • Servrar som rapporterar och som inte är av versionen som angavs ovan

I praktiken är det två frågor kombinerade till en, där två fält fått nya namn för att göra det enklare att följa, men även för att göra en snyggare presentation. En bra sak är att frågan inte visar något resultat förrän åtminstone en agent har börjat kommunicera med Log Analytics och som även tidigare gjort det, men då med en äldre version av agenten.

2-2

 

Som du kan se i bilden ovan finns det ett gäng olika versioner som kommunicerat med Log Analytics, men kolumnen ”NewVersion” visar alltid den högsta versionen samtidigt som kolumnen ”OldVersion” visar vilken version agenten uppgraderats från.

Eftersom jag använt “distinct”-kommandot i frågan kommer aldrig mer än en rad visas per server och agentversion. Inga dubbletter med andra ord, och listan blir lätt att följa.

Frågan ser du nedan, redo att kopieras och klistras in i Log Analytics. Se bara till att uppdatera versionsnumren enligt anvisningarna i frågan. Radera även eventuella nya rader som bildas när du klistrar in frågan, inga radbrytningar får finnas med i frågan när den körs.

// Use this query to find out which servers have been upgraded from the earlier version of the agent to the new one.

// All that needs to be done is to replace the version number in the query with the version you´re upgrading to.

let old = Heartbeat

| where TimeGenerated > now(-1h)

| where Version in ("10.19.13515.0") // Update with the version number of the agent you´re upgrading to, SCOM 1807 for example

| project-rename NewVersion = Version

| project Computer, NewVersion, TimeGenerated;

let new = Heartbeat

| where TimeGenerated > now(-1h)

| where Version !in ("10.19.13515.0") //Update with the version number of the agent you´re upgrading to, SCOM 1807 for example

| project-rename OldVersion = Version

| project Computer, OldVersion, TimeGenerated;

old | join (new) on Computer

| sort by TimeGenerated desc nulls last

| distinct Computer, NewVersion, OldVersion, TimeGenerated

Kontrollera alla servrar som rapporterar, gamla som nya

Om du enbart vill titta på vilka servrar som rapporterar till Log Analytics, även sådana som inte gjort det tidigare kan du använda frågan nedan istället.

3-2

 

Den här väldigt enkla frågan finns nedan. Kopiera den bara till Log Analytics och få en översikt över vilka servrar som rapporterar, samt vilken version de ligger på. Radera även eventuella nya rader som bildas när du klistrar in frågan, inga radbrytningar får finnas med i frågan när den körs.

Heartbeat

| where TimeGenerated > now(-15m)

| distinct Computer, Version

| sort by Computer desc nulls last

Sammanfattning

Det här var en snabbtitt på några av sakerna vi var tvungna att hålla koll på, och hur vi valde att göra det. Med frågorna som visats här är det väldigt lätt att hålla koll på både det nya versionsnumret och det gamla versionsnumret av agenten. Det är intressant hur mycket man faktiskt kan göra med den information som finns i Log Analytics, och hur man kan presentera informationen på så många olika sätt. Det här var ett riktigt kul och intressant projekt där vi fick möjligheten att hjälpa kunden på deras väg mot en lyckad migrering av deras servrar till Log Analytics.

Om du tycker detta var intressant rekommenderar jag att hålla koll på bloggen framöver då vi har mycket mer information att dela med oss av inom området.

Funderar du kanske också på hur man på ett bra sätt kan lyfta servrar till att kommunicera med Log Analytics? Kontakta mig direkt på min mail så pratar vi mer om hur vi kan hjälpa dig med rådgivning och utförande.

Ämnen: Azure Log Analytics Azure Monitor Log Analytics Azure