読者です 読者をやめる 読者になる 読者になる

ログの可視化から始めるスマートなサービス運用 ~Log AnalyticsでWindowsパフォーマンスカウンターの情報を収集してみよう~

こんにちは。 弥生のウシオです。

今回は先日ご紹介できなかった、
Cloud Services から Windowsパフォーマンスカウンターの情報を
収集するためのテクニックをご紹介したいと思います。


おさらい

先日のブログでご紹介させていただいた
Log Analytics と Cloud Services の連携方法ですが、
みなさま覚えていらっしゃいますでしょうか?

Cloud Services のログ出力先であるストレージを
Log Analytics のデータソースとして追加してあげるだけでしたね。

その際、収集するログの種類(データ型)を指定するのですが、
選択肢のなかにWindowsパフォーマンスカウンターが存在しません。

Why!?

VMの場合は問題なく収集されますし、
ストレージには WADPerformanceCountersTable も出力されているのですが。

f:id:yayoi_ushio:20160817192950p:plain

嘆いていてもしょうがないので、Cloud Services でもなんとかして
Windowsパフォーマンスカウンターの情報を収集できるようにしよう、
というのが今回のお話です。


結論から先に

はい。結論から言いますと、
Log Analyticsエージェントをインストールすることで収集可能になります。

めでたし、めでたし。

とは、いきません。実はまだハードルがあります。

VMの場合、基本的には1回インストールして終わりですが、
Cloud Services の場合、デプロイ毎に環境が変わってしまうので
その都度インストールしてあげる必要があります。

「毎回手動でインストールを?出来らあ!!」

なんて気概のある方は極稀ですよね。私ならイヤです。


スタートアップタスクに登録しよう

Cloud Services には「スタートアップタスク」という
ロール開始前に実行するアクションが登録できるので、
今回はこの仕組みを使って、エージェントを自動インストールしたいと思います。

azure.microsoft.com

まずは、対象となるWebアプリケーションのプロジェクトに
下記の2つのファイルを追加しましょう。

  • Log Analyticsエージェントのインストーラー
  • 上記インストーラーを実行するためのバッチ

バッチのファイル名は「mma.cmd」とし、中身は以下の通りでOKです。*1

SETLOCAL EnableExtensions
    
:: Bypass installing the agent if locally emulating
IF "%EMULATED%" EQU "true" GOTO:EOF
    
for /F "usebackq tokens=1,2 delims==" %%i in (`wmic os get LocalDateTime /VALUE 2^>NUL`) do if '.%%i.'=='.LocalDateTime.' set ldt=%%j
set ldt=%ldt:~0,4%-%ldt:~4,2%-%ldt:~6,2% %ldt:~8,2%:%ldt:~10,2%:%ldt:~12,6%
    
SET MMA_ERROR_LEVEL=0
    
CALL:INSTALL_MICROSOFT_MONITORING_AGENT
    
IF %MMA_ERROR_LEVEL% EQU 0 (
    EXIT /B 0
) ELSE (
    EXIT %MMA_ERROR_LEVEL%
)
    
:: --------------
:: Functions
:: --------------
:INSTALL_MICROSOFT_MONITORING_AGENT
    ECHO %ldt% : Begin installing the Microsoft Monitoring Agent >> "%RoleRoot%\mma.log" 2>&1

    :: Current version of the installer
    SET MMA_INSTALLER_PATH="%RoleRoot%\approot\MMASetup-AMD64.exe"

    ECHO Installing the Microsoft Monitoring Agent >> "%RoleRoot%\mma.log" 2>&1
    
    %MMA_INSTALLER_PATH% /C:"setup.exe /qn ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_ID=%WORKSPACE_ID% OPINSIGHTS_WORKSPACE_KEY=%WORKSPACE_KEY% AcceptEndUserLicenseAgreement=1"
    
    ECHO Microsoft Monitoring Agent was installed successfully. >> "%RoleRoot%\mma.log" 2>&1
    
GOTO:EOF

つづいて、Azureクラウドサービスのプロジェクトにある
ServiceDefinition.csdef 内の[Startup]要素の
子要素として以下を追加します。

<Task commandLine="mma.cmd" executionContext="elevated" taskType="simple">
  <Environment>
    <Variable name="EMULATED">
      <RoleInstanceValue xpath="/RoleEnvironment/Deployment/@emulated" />
    </Variable>
    <Variable name="WORKSPACE_ID">
      <RoleInstanceValue xpath="/RoleEnvironment/CurrentInstance/ConfigurationSettings/ConfigurationSetting[@name='MicrosoftOMS.WorkSpaceID']/@value" />
    </Variable>
    <Variable name="WORKSPACE_KEY">
      <RoleInstanceValue xpath="/RoleEnvironment/CurrentInstance/ConfigurationSettings/ConfigurationSetting[@name='MicrosoftOMS.WorkSpaceKey']/@value" />
    </Variable>
  </Environment>
</Task>

同じく、Azureクラウドサービスのプロジェクトにある
ServiceConfiguration..cscfg 内の[ConfigurationSettings]要素の
子要素として以下を追加します。

<Setting name="MicrosoftOMS.WorkSpaceID" value="{インストーラーをダウンロードした画面に表示されていた WORKSPACE ID}" />
<Setting name="MicrosoftOMS.WorkSpaceKey" value="{インストーラーをダウンロードした画面に表示されていた PRIMARY KEY}" />

お疲れ様でした。
あとはプロジェクトをデプロイしてロールが開始されれば
エージェントが自動的にインストールされます。


イヤなことばかりでもないさ

なんでこんな面倒くさいことをしないといけないんだ。
素直にストレージからログを拾ってくれれば済む話じゃないか。

そうですよね。
でも、この方式にもメリットはあるんです。

それは、再デプロイしないでも収集するWindowsパフォーマンスカウンターの種類を変更できること。

エージェントで収集するWindowsパフォーマンスカウンターの種類とインターバルは
「Log Analytics」ポータルで設定できるんです。*2

f:id:yayoi_ushio:20160817191425p:plain

これはありがたいですね。

はい、許した。


今回のブログはいかがでしたでしょうか。

Cloud Services の Windowsパフォーマンスカウンターの情報を可視化したい方は
ぜひ今回ご紹介した内容を試してみてくださいね。*3


*1:x64の環境を前提としております。x86の環境の場合はMMA_INSTALLER_PATHのファイル名を適切に書き換えてください。

*2:なので、エージェントをインストールしただけでは何も収集しません。[Settings]の[DATA]ページにて、何の情報を収集するかの設定も忘れずに実施してください。

*3:本内容は弊社で検証した結果に基づいたものではございますが、これによって生じた一切の損害については、責任を負いかねますので予めご了承ください。

IT系勉強会を開催する前に知っておきたいこと(1)~Rで分析してみよう~

はじめまして、iotasです。
弥生でエンジニアをしています。

普段はC++やC#を使ってWebアプリやWindowsアプリを作るお仕事をしているのですが、ここ二年ぐらいはプライベートでRを使いながらいろいろな物事を可視化することにはまっています。

今日は、Rを使って勉強会を可視化し、弥生×Misoca主催の勉強会「もくテク#1」の準備に役立てた話をさせてください。

勉強会の怖さ

皆さん、勉強会には参加されていますか?

勉強会で一番怖いことを想像してみてください。
(参加者目線で)

  • んー、人が集まらないこと?
  • 内容がつまらない?
  • なんか勧誘される?

どれも一理あります。勧誘怖い。
ですが、(完璧にはムリでも)どれも事前に察知できること、のように思います。

私が考える一番怖いことは。

  • 自分以外の参加者がみんな主催者の身内だった

です。怖い。アウェイ感半端ないです。身内しか呼ばないのに、なぜイベントサイトで公開した。

もくテクはオープンな場にしたいので、こういう状態を避けたいと思いました。
でも、参加者が少ないとどうしても社員の知り合いとかツテを辿ったメンバーの比率が上がっていきます。
じゃあ、どうやったら参加者を増やせるんだろう。

勉強会を主催したことがないので、右も左もわからない状態からのスタートです。
しかし、ここで投げては人様に「趣味は可視化です」とはいえません。
わからないのであればわかるようにしましょう。

なにを分析したのか

まず、場所と時間ですよね。

もくテク#1は弥生本社である秋葉原で開催されることが決まっていました。

  • まず、そもそも秋葉原って人来んの?

という疑問がわきます。

  • 開催時間って何時だといいの?

というのも気になります。

収集

可視化のために必要なデータを集めます。

データの取得元は、Doorkeeperさんにしました。うれしいことにAPIが公開されているので、簡単にデータ収集できます。

開始時刻とジャンルによってプロットする

データが集まったら、プロットしていきましょう。
今回はRを使います。単純にplot関数を使ってもできますが、今回はカスタマイズ性に富むggplotを使います。

データが多すぎると大変なので、範囲は「2016年1月」の平日に絞りました。

library(ggplot2)

study_meetup <- read.csv("勉強会人数.csv", fileEncoding="shift-jis")

p <- ggplot(study_meetup, aes(x=開始時刻, y=参加者))
p + geom_point(aes(colour=分類)) +
  scale_x_continuous(breaks=seq(0,24), limits=c(10, 22)) +
  scale_y_continuous(breaks=seq(0,200, by=10), limits=c(0, 200))


読み込ませたCSVファイルはこんな感じです。

開始時刻,終了時刻,種別,分類,参加者,定員
14,18,R,データ分析・機械学習,2,10
16,19,もくもく会,もくもく会,0,8
18.5,21.5,もくもく会,もくもく会,11,12
19,21,もくもく会,もくもく会,6,10
19.5,21.5,マネタイズ,ビジネス,30,30

ちなみに勉強会のジャンルは私が適当に決めました。イベントサイトによっては「iOS」「機械学習」のようなタグがつけられるところもあるので、そちらを利用しても良いかも知れません。

下がプロットした図。
f:id:iotas:20160726083911p:plain
拡大しないと見づらいかもしれませんが、x軸が開始時刻、y軸が参加者数になっています。

こうしてみると、19:00~20:00の間に勉強会の開始が集中していることが見て取れます。
朝方にもぽつぽつありますが、フリーランスや専業主婦の方向けのイベントのようでした。

20:00になると数がだいぶ数が減るので、特に意図が無ければ開催時刻は19:00か19:30あたりに設定するのが無難でしょう。

一応ジャンルで色分けしてみましたが、そこまで顕著な傾向は出ていなさそう。
(交流会だと人が多くなりがち、って程度?)

線形回帰分析も一応試してみましたが、「勉強会の定員数が多い」と「参加者も多くなる」というような当たり前の相関しか確認できませんでした。

開催場所をプロットする

開催場所をプロットしてみます。最初に勉強会が開催されている場所の緯度と経度を含んだcsvファイルを作成します。

「緯度と経度なんてデータに無いよ」って場合は、住所をGoogleのGoogle Maps Geocoding APIで変換しましょう。

今回取得したデータにも緯度・経度の情報がなかったため、Pythonのコードを書いて変換しました。

import requests
import json
import csv
import codecs

class GoogleGeoCodingAccessor:
    def __init__(self):
        self.__ApiKey = #ここにgoogle apiのAPI KEYを設定
    
    def convertToLatLng(self, address):
        url = "https://maps.googleapis.com/maps/api/geocode/json?"
        url += "address=" + address
        url += "&"
        url += "key=" + self.__ApiKey
        
        res = requests.get(url)
        print(res.json())
        
        return res.json()
        
accessor = GoogleGeoCodingAccessor()

# 使い方サンプル
result = accessor.convertToLatLng('東京都千代田区外神田 4-14-1 秋葉原 UDX 21F')
position = result['results'][0]['geometry']['location']

以下のようなファイルを作ればOK。

lng,lat
139.7489739,35.606938
139.7489739,35.606938
139.7781072,35.6184039
139.7758712,35.6210896

使用する地図はGoogleMapとし、ggmapで取得します。(今回は、データの範囲を東京23区に絞りました)

library(ggplot2)
library(ggmap)
library(scales)

# ファイルをロードする
study_landscape  <- read.csv("###ここに座標を示した.csvファイルのパスを入れる###",
                             fileEncoding="shift-jis")

# 座標の緯度経度の最小値・最大値をそれぞれ計算する
loc <- c(min(study_landscape$lng), min(study_landscape$lat), max(study_landscape$lng),
        max(study_landscape$lat))

# 範囲指定してGoogleMapから地図を取得する
Map <- ggmap(get_map(location=loc, zoom=12,
                    source="google"))+xlab("")+ylab("")

# 地図を描画する
study_p <- Map +
  stat_density2d(data=study_landscape, aes(fill=..level.., x=lng, y=lat, alpha=0.1), geom="polygon") +
  scale_fill_continuous(low="green", high = "red")  +
  geom_point(data=study_landscape, aes(x=lng, y=lat), color="black")+
  scale_alpha_continuous(guide="none", range=c(0,.2))


study_p

これを実行すると、以下のような密度マップが出力されます。
f:id:iotas:20160726084030p:plain
勉強会が密集しているところほど色が赤っぽくなります。

見てみると、勉強会の開催地点はだいたい三つのエリアに集中しているようです。
1つめは言わずとしれた渋谷
2つめは新宿
そして3つめが秋葉原です。

だいたいなんとなく「IT系勉強会」と聞いたときにイメージする場所とも合致しているように思いますが、いかがでしょうか。

やっぱり渋谷は強い!
と見える反面、やや飽和気味のようにも感じます。

単純に考えれば、「IT企業の数が多い場所ほど、IT系勉強会の開催も多い」、という相関が考えられますが、実際にその通りになっているかはデータを見比べてみる必要があります。

また、今回のもくテク#1の会場である「秋葉原」もなかなか有望なように見えますが、こちらも勉強会の数が飽和している恐れはないでしょうか。

そういったわけで、次回はIT企業の分布を調べてみたいと思います。

ログの可視化から始めるスマートなサービス運用 ~Log Analyticsのご紹介~

みなさま、はじめまして。
弥生のウシオと申します。

前回のブログで告知させていただきました通り
先日、無事にもくテク#1を開催することができました。

ご参加いただいたみなさま、誠にありがとうございました。

これからも定期的に開催していこうと思っておりますので、
今回ご参加いただけなかった方も是非次回はご参加くださいませ。

お待ちしております。


はじめに

さて、当ブログですが「開発者ブログ」と銘打ってることから
おそらく読者のみなさまもエンジニアの方が多いのではないかと思います。
(もちろん、エンジニア以外の方もウェルカムですよ!)

そこで質問ですが、みなさまはどんな業務を主としたエンジニアなのでしょうか?

  • Webアプリ
  • Windowsネイティブアプリ
  • データベース
  • インフラ系
  • フルスタック(!!)

ここ最近は特に色々な技術が登場しておりますので、様々かと思いますが、
何かしらのかたちでサーバー運用に携わってる方も少なくないかと思います。

では、そんなみなさまにもう一つ質問です!

「ログ、収集していますか?」

当然、収集されていますよね。(収集してないと怒られるし

では、「収集したログ、活用していますか?」

・・・はい、大人なので空気を読みました。

「カツヨウ?なにそれ美味しいの?」という感じで、
せっかく集めたログを十分に活かしきれていないケースも多いですよね。

今回は活用のための第一歩。
ログの可視化について、弥生で実践している方法をご紹介させて頂こうと思います。


環境を問わず使用できるログ可視化サービス

最初にネタバレをしてしまうと、
弥生では「Log Analytics(旧名 Operational Insights)」という
Microsoft Azureのサービスを使用してログの可視化を行っております。

「なんだ、Azure(Windows)かよ。。。」
「AWSで運用してるから、関係ない話だな。」
「うちなんかオンプレだぜ!!」

心配ご無用!!
実はこのサービス、Microsoft以外のクラウドサービスやオンプレにも対応。
さらには、Windowsだけでなく、Linuxにも対応しているんです!


Log Analytics 紹介

「Log Analytics」で可視化できるログの種類は以下の通りです。

  • Windowsイベントログ
  • Windowsパフォーマンスカウンター
  • ETWログ
  • IISログ
  • Linux Syslog
  • etc...


例えば、エラーや警告が出ているイベントログだけを抽出したり
f:id:yayoi_ushio:20160701155241p:plain

マシン毎にCPUの使用率をグラフ化したりすることができます。
f:id:yayoi_ushio:20160701155256p:plain

サービスを使用するために必要な手順は
Azureポータルからいくつかの情報を入力するだけです。*1
f:id:yayoi_ushio:20160701154247p:plain

可視化の対象がAzureなら、連携方法も簡単!
全部、Azureポータルから行えます。

VMの場合は、対象となるVMを選んで接続するだけ!
f:id:yayoi_ushio:20160701155148p:plain

Cloud Serviceの場合は、ログの出力先であるストレージを選んで追加するだけ!*2
f:id:yayoi_ushio:20160701154254p:plain


AWSやオンプレでも、「Log Analytics」ポータルからエージェントをダウンロードして
インストールするだけで可視化されます!
f:id:yayoi_ushio:20160701155209p:plain


無償プランあり〼

いやいや、でもお高いサービスなんでしょう?

たしかに、決して安くはないです。
本格的に利用しようとしたら、それなりに費用は掛かります。*3

ただ、下記条件であれば全ての機能が無償で使えちゃうんです!
試用期限もありません。*4

  • データの保有期間が7日
  • 1日あたりのデータ量制限が500MB

とりあえず、お試しで使ってみても損はないかと思いますよ。


どうでしょうか?
ちょっと試してみようかなという気持ちになりましたでしょうか。

「Log Analytics」の細かいテクニックや、PowerBIを用いたグラフ化などについては
弥生での具体的な活用事例を交えて、また近日中にご紹介させていただきます。

乞うご期待!!


*1:「Log Analytics」はMicrosoft OMSというソリューションに包括されるため、AzureポータルではMicrosoft OMSのワークスペースを作成します。

*2:Cloud Service から Windowsパフォーマンスカウンターを収集するためには、もう一工夫必要です。詳細はまた別の機会に。

*3:サービスの価格は右記ページを参照して下さい。https://azure.microsoft.com/ja-jp/pricing/details/log-analytics/

*4:サービスの価格や内容については、予告なく変更になる可能性があります。