2014memorycraft更新とか絶対忘れるから。2014年2月24日月曜日Dockerってなんじゃ?(docker+nginxで複数コンテナにWEBサーバーをたてる)dockerを使って複数のWEBサーバーを立ててみたいと思います。複数の外部ポートを使うため、プロキシとしてnginxと併用してみます。apache、もう一つは素のnginxを入れてみます。コンテナにはそれぞれmemorycrat.cloudpack.jptenkaippin.cloudpack.jpというドメインを割り当てます。sshも立ちあげます。今回はDockerfileを使ってイメージを構築します。それぞれのコンテナのDockerfileとsupervisorの設定ファイルテンプレートは以下の様にホスト側に配置しておきます。supervisor.confwordpressコンテナの設定memorycraftコンテナでは、httpdとsshのサービスを立ちあげます。wordpressをダウンロードし、RDSに接続するように設定ファイルを書き換えます。./templates/memorycraft/conf/Dockerfile./templates/memorycraft/conf/supervisor.confコンテナをビルドします。templates/memorycraft/conf/できたら、起動します。/usr/bin/supervisordnginxコンテナの設定tenkaippinコンテナでは、nginxとsshのサービスを立ちあげます。./templates/tenkaippin/conf/Dockerfile./templates/tenkaippin/conf/supervisor.confコンテナをビルドします。templates/tenkaippin/conf/できたら、起動します。/usr/bin/supervisordホスト側nginxの設定まず、プロキシ用にnginxをインストールします。-yここで一度コンテナの起動状況を調べてみます。49186というマッピングになっているのが分かります。(起動時にホスト側のIPを指定することも出来ます。)次に、仮想サーバごとにプロキシ設定します。プロキシの基本設定です。/etc/nginx/conf.d/proxy.conf次に、仮想サーバーで、memorycraft.cloudpack.jpとtenkaippin.cloudpack.jpの設定をします。プロキシの転送先ポートとして、先ほど調べたポートを指定します。次にRoute53で、2つのサブドメインでこのサーバーに向けたAレコードを登録します。これで作業は完了です。確認それでは、SSH確認してみます。memorycraft.cloudpack.jpまずは、ホストサーバでssh接続してみます。~]$接続出来ました。次に、ブラウザを確認します。おお!接続出来ました!tenkaippin.cloudpack.jpssh接続してみます。~]$接続出来ました。ブラウザを見てみます。表示されています!このように、サーバー資源が限られていてユーザースペースを確実に分離したい場合などには、複数コンテナをつかうと便利かもしれません。nginx2014年2月18日火曜日Dockerってなんじゃ?(S3プライベートレジストリ)前回に引き続き、プライベートレジストリです。前回の方法では、レジストリのコンテナを載せたサーバー自体が落ちてしまったときに登録されたコンテナイメージが全てなくなってしまいます。dockerのregistryコンテナには、設定ファイルが存在し、永続化のオプションとしてバックエンドにS3を使うことができます。それでは早速試してみます。レジストリ側の設定レジストリのコンテナをbashで起動します。/bin/bashレジストリに入ったら設定ファイルがある/docker-registry/config/フォルダに移動します。S3用のサンプルがあるのでそれをconfig.ymlとして使います。dockerのレジストリでは設定ファイルに_env:VARIABLENAMEとなっている部分があり、環境変数をセットしている部分です。起動時に-eオプションでその環境変数をコンテナに渡すことが出来ます。このS3用のファイルは、AWSキーやバケット名などに環境変数をセットできるようになっているので起動時にパラメータ渡しが可能です。今回はそのまま変更なしで使います。/images接続を終了し、コミットします。memorycraft/registryコミットしたS3用のレジストリイメージを起動します。その際前述のように、-eオプションでAWSキーやバケット名などを環境変数として渡します。SETTINGS_FLAVOR環境変数は、config.ymlのprodと対応しています。これによって設定ファイルの各モードを起動時に選択することができます。prickly_davinciこれで、S3対応のレジストリができました。S3レジストリへの登録それではクライアント側からこのレジストリにpushしてみます。流れは前回の記事と同じです。{http://176.34.16.242:5000/v1/repositories/memorycraft/centos/tags/latest}無事にpushできたようです。それではS3バケットを覗いてみると、リポジトリのメタデータやイメージなどがアップされているのがわかります。レジストリを消してみるここで、一度、レジストリ側のサーバーが壊れてしまった。インスタンスが消えてしまった場合を想定して、0から別のサーバーにレジストリを立てて見たいと思います。/docker-registry/run.shS3からpull念のためクライアント側もイメージもコンテナも消した状態で、S3レジストリを指定してrunしてみます。completebash-4.1#ちゃんと取得できて、コンテナを立ち上げることが出来ました。これで、S3の高い堅牢性可用性をバックエンドにしたレジストリができました。Indexというパブリックレジストリについて書きましたが、プライベートなレジストリを作ることも出来ます。それによって社外に出したくない資産などを管理することが出来ます。Indexには、プライベートレジストリ用のリポジトリが提供されていて、それをpullしてコンテナとしてプライベートレジストリとして使うことが出来るようになっています。それでは、早速試してみたいと思います。localhostでも構いませんが、今回はレジストリ専用のサーバーを用意してみます。最初の記事のようにレジストリサーバー上で、Dockerをインストールしておきます。Indexのregistoryというリポジトリからpullしてきいます。registryあとはこれを立ち上げるだけです。レジストリの内部ポートは5000番が使用されます。今回は外部ポートも5000番で指定します。registrycommitそしていままでのコンテナサーバー側で、コンテナをコミットしますが、指定の仕方が異なります。<レジストリサーバーIP>:<レジストリポート>/<リポジトリ名>のようにします。176.34.16.242:5000/memorycrafta2a360e08ee87d8fd3c98f08701ce0e4d681164e50432ff032890108eded996cすると以下のようにタグ付けされたイメージが保存されます。MBpushそしてこれをpushしてみます。pushもコミットと同様の指定の仕方になります。{http://176.34.16.242:5000/v1/repositories/memorycraft/tags/latest}うまく自前のレジストリにむけてpushされたようです。次に、ローカルのイメージを削除してみます。SIZE改めて、自前のレジストリから起動してみます。completebash-4.1#bash-4.1#おお!無事起動しました。このように、自前のレジストリを用意すると、公開したくないコンテナイメージを社内やシステム内に限定して共有することができます。レジストリ)いままでのDockerの記事にも登場してきましたが、Dockerにはリポジトリという概念があります。repogistryリポジトリリポジトリというのはコンテナのファイルシステム(AUFS)を構成するタグ付けされたイメージのホストされた集合です。リポジトリ名は、例えば作成者とオリジナルコピーがどこにあるかなど、リポジトリの由来となるようなタグとして利用します。レジストリリポジトリはレジストリ上に存在します。IndexというDockerがホストしているパブリックレジストリになります。Docker自身が提供しているトップレベルリポジトリもアカウント上に作られるユーザーリポジトリもあります。IndexはgitでいうところのGithubのようなものになります。Indexを使うにはアカウントを作成してみます。Dockerのサイトを開きます。upのローカルナビのリンクをクリックするとサインアップ画面が表示されるので、情報を入力して登録します。確認メールが届くのでアクティベーションすると、登録完了します。application」をクリックします。Index画面が開くので、ログインします。Indexの画面が表示され、自分のリポジトリ一覧画面が開かれますが、最初はなにもありません。これからここにリポジトリをアップしてみたいと思います。Indexにログインします。ユーザー名、Eメール、パスワードを聞かれるので、先ほど登録したアカウントの情報を入力します。Succeededこれでdockerのコマンドラインとアカウントが紐付きました。search最初のDocker記事で使用したcentosというリポジトリは公式のリポジトリです。Indexレジストリ上にある公式または任意のユーザーの公開リポジトリを使用してコンテナを作っていきます。レジストリからリポジトリを探す場合は以下のようにします。0.......このようにリポジトリ名などが出てきます。RepositoryというGitHubのリポジトリと連携してホストされている特殊なリポジトリです。これについてはまたの機会に触れてみたいと思います。pullsearchで目的のリポジトリが見つかったらこれを手元に持ってきて使います。centosとすると、Dockerのレジストリからcentosリポジトリをローカルイメージとしてpullしてきます。/bin/bashとすると、ローカルにある場合はローカルのcentosのイメージを、なければDockerのレジストリからcentosのリポジトリからイメージをpullして、そのままコンテナを起動します。commitいままでの記事にあったように、コンテナでいろいろ作業をしていくうちに、作業内容をコミットする場合があります。コミットはコンテナをイメージに変換して保存します。その場合イメージ名は"ユーザー名/イメージ名"のようにつけます。Indexのレジストリに登録するときにわかりやすいです。<username>/<imagename>pushpushをするとイメージをリポジトリに保存することができます。gitのpushと同じイメージです。Indexを見てみます。先ほどのリポジトリ一覧に、pushしたリポジトリが1つ表示されるようになりました!レジストリを使用することで、dockerのサーバが壊れた時の復旧や、環境を移行したり増やしたりする場合などに便利です。docker2014年2月13日木曜日Dockerってなんじゃ?(Dockerfileでビルド)DockerにはDockerfileというものがあります。buildを行うと、指定したパスからDockerfileを探し、コンテナを新規作成し記述されたステップを実行した後、コミットをしてコンテナイメージの作成までを自動で行います。/path/to/contxt/とすると、/path/to/contxt/ディレクトリにあるDockerfileを元にステップ実行したコンテナをhoge/mogeというリポジトリ名で保存するところまでを自動で行ってくれます。引数という形式で記載します。命令には以下のものがあります。paramEXPOSE指定されたポートを開放します。[INSTRUCTION]以上、これらの命令を組み合わせて、コンテナの中身を組み上げていきます。前回の記事でつくったsshdとhttpdをsupervisordで起動するコンテナを、上記の命令を組み合わせてDockerfileを記述して作ってみると以下のようになります。["/usr/bin/supervisord"]ビルドの実行それでは、このDockerfileをビルドしてコンテナイメージを作成します。ポイントは--rmです。デフォルトでは1つの命令が実行されるごとにコミットが行われ、沢山のコンテナが出来てしまいますがこのオプションをつけることで、ビルドが成功した後に中間コンテナを全て消してくれます。MB作成には成功しているようです。続けて、このイメージでコンテナを起動してみます。0確認それでは、このコンテナに前回同様アクセスしてみたいと思います。sshのユーザー/パスワードはDockerfileで指定したものを使います。~]$無事接続出来ました!また、ブラウザにもアクセスしてみます。表示されてます!これで、Dockerfileのコーディングによるインフラ管理ができるようになります。dockerDockerってなんじゃ?(Supervisorで複数のサービス起動)Dockerネタです。前回の記事で、DockerでSSHサーバとして起動しましたが、通常いろいろなサービスを起動したコンテナを使うことの方が多いと思います。Dockerでは起動時に1つのCMDしか指定できないようで、前回のやり方では1つのサービスしか起動できません。このような場合は、Supervisorを利用するといいようです。sshdとhttpdをサービス起動したコンテナの場合、コンテナ内のsupervisordがsshdとhttpdを管理し、dockerがsupervisordを使ってサービス起動するというイメージです。それでは早速試してみます。コンテナは前回と同じcentosをつかいます。コンテナの起動コンテナを立ちあげてコンソールにアクセスします。/bin/bashsshとhttpdのインストールコンテナに入ったらまず、必要なsshdやhttpd、supervisorインストール用のeasy?installなどのプログラムを準備します。-ysshdの設定をします。yesrootユーザのパスワードを設定します。passwdhttpdのインデックスページを用意します。/var/www/html/index.htmlSupervisorのインストールsupervisorをインストールします。supervisorsupervisorの起動スクリプトを用意します。/etc/init.d/supervisordSupervisorの設定supervisorの設定ファイルを用意します。/etc/supervisord/conf/設定を記載します。ここでポイントは、supervisord自身のnodaemon=trueという項目です。これによって、supervisordがフォアグラウンド起動します。-DFOREGROUNDredirect_stderr=trueここで、コンテナを抜けます。exitコンテナイメージの作成ホスト側で、一度コミットします。memorycraft/centosコンテナの起動それでは、コミットしたイメージで新しいコンテナを起動してみます。このとき、起動するコマンドに/usr/bin/supervisordを指定し、開放ポートに22と80を2つ指定します。/usr/bin/supervisord確認それではコンテナに対してsshとhttpでアクセスしてみます。-aで、ポートマッピングの状況がわかります。sad_torvaldsマッピングされたポートをつかってsshアクセスしてみます。password:アクセスできました!続けて、httpです。マッピングされたポートをつかってブラウザアクセスしてみます。おお!確認できました!これで複数のサービスが起動したコンテナを作れます。supervisor2014年2月11日火曜日Node.jsってなんじゃ?(gm:GraphicsMagickで画像合成)今回はnode.jsを利用して、画像合成をしてみたいと思います。この手の画像生成にはImageMagickがよく使われますが、ImageMagickから派生したGraphicMagickがImageMagickよりもパフォーマンスが優れているのでこちらの方を利用します。node.js内からは、GraphicMagick/ImageMagickを使用できるgmというモジュールを利用します。今回node.jsは久しぶりなので、nodeのインストールから始めてみたいと思います。他のLL言語などでもそうですが、nvmやenv系などインストール環境管理ツールが乱立しているようです。今回はnodebrewが便利そうなので、nodebrewを使ってみました。GraphickMagickのインストールyumでインストールします。-ynodebrewを使ったnode.jsとモジュールのインストールnodebrewでは、インストール実行した場所だけにファイルが作られるようで環境を汚さず、rootでなくともインストールが可能なことが特徴のようです。インストールを行い、PATHを通すだけで完了なので、とても簡単です。argv実装image.js画像合成のメイン処理です。引数の画像URLをダウンロードして画像合成します。gmcomposite.js合成を子プロセスで実行する箇所をモジュール化したものです。今回の合成ではfacebookのプロフィール写真がどうにも無愛想なので、かわいくしてみたいと思います。合成素材用のディレクトリ、合成後の出力先のディレクトリを作成します。tmpまた、httpdサーバのドキュメントルートから出力先ディレクトリにリンクします。rsltassetsディレクトリにマスク素材を配置します。frame.png実行それでは実行します。ID(画像名につかうだけなので何でも良い)を渡します。!無事出力できたようです。確認それでは出力された画像をブラウザで確認してみます。思った感じと違いますが、とりあえず合成できたのでよしとします。行えるログ解析の基盤サービスで、fluentdを使ってデータを収集し、hadoopで解析を行います。kibanaや、splunkなどの部分がサービス化されているようなイメージです。Dataについては、中の人が非常に詳しくブログで書かれています。それでは実際に触ってみます。ユーザー登録&ログインhttp://www.treasuredata.com/jp/products/try-it-now.phpにアクセスして、サインアップのリンクをクリックします。サインアップ画面が表示されるので、必要な情報を入力して登録します。登録が終わると、確認メールが送られてくるので、確認リンクをクリックして登録完了です。ログインする場合は、以下のような画面でログインすることになります。Dataに送信するように設定します。accountコマンドを使って先ほど登録したメールアドレスとパスワードを設定して、アカウントを紐付けます。apikey:showコマンドを実行します。(APIキーは伏せてあります。apikey:showXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX次に、/etc/td-agent/td-agent.confで、sourceをapacheアクセスログのtailを、matchで今のAPIキーを使ったtdlogを設定します。Dataにログを送信するためのプラグインになります。Data側に用意されます。</match>設定したら、td-agentを起動します。startログ収集対象のサーバーの設定は以上です。Data側で作成されたテーブルの一覧が表示されます。Dataのアカウントを作成すると、デフォルトでsample_dbというデータベースが用意されていますが、ログが保存され始めると、apacheデータベースのaccessテーブルというのが作られています。DB名、テーブル名はsourceのtagを元に作成されます。Dataの管理画面のDatabasesにも、apacheデータベースが追加されていることがわかります。ドリルダウンしていくと、登録されているログデータが構造化されているのを見ることができます。Queryで集計の設定をおこないます。typeはHiveを選択します。Queryに集計するためのHiveクエリを書き、あとはそのままで「Submit」をクリックすると、Jobの実行が開始されます。Job実行はスケジューリングすることもできます。toでMySQLやS3など結果を保存する先を指定することもできます。Jobの実行が終わると、Jobリストとして結果が表示されます。今回は、結果の保存先を特に指定していないので、この結果画面にそのまま結果が表示されます。Dataの管理コンソールでのログの確認、集計をさらってみました。fluentd)ずんぶん前にKibanaの記事を書きましたが、時がたちKibana3がとても感じがよいと巷で評判なので、再入門してみます。準備インデックスサーバー側のポートは80,22の他に、fluent用に9200番ポートを開けておきます。インデックスは最終的に大きくなるので、容量の大きなストレージに入れておきます。/mnt/ebs/0Kibana3のインストールKibanaはv3になってから、rubyではなくhtmlになりました。DocumentRoot下に置いてhttpdを起動するだけでOKです。startこれで、インデックスサーバー側は準備ができました。ログ送信サーバー側apacheのログを送信するとして、ここではfluentdの設定はin:tailとout:elasticsearchプラグインを使います。startこれでログの送信設定は完了です。確認ここまで設定できたらkibanaの画面を見てみます。これがデフォルトのトップ画面です。Dashboard]というリンクをクリックすると、ダッシュボード画面に遷移します。ダッシュボードでは、fluentdから送られてきたログがひな形のダッシュボードに表示されていることがわかります。クエリの追加クエリフィールドはフィールドの「+」ボタンでいくつも登録できます。クエリの書式はluceneの書式が基本となっているようです。パネルの追加ダッシュボードはグリッド上にできており、基本的に行(ROW)にパネルを追加していきます。パネルはひとつまたは複数のクエリを使用します。Panel」ボタンでパネルを追加します。パネル追加画面では、パネルのタイプや使用するクエリや、その他パネル固有のパラメータを設定します。いくつかのクエリとパネルを組み合わせて目的に会ったダッシュボードを造ります。作成したら、名前をつけてダッシュボードを保存することで、リロードしても保持されるようになります。以前と比べてかなりいろいろなデータを表示できるようになってきました。細かいところはまた今度。kibana2014年2月5日水曜日EMRってなんじゃ?(ImpalaでCloudfrontの爆速ログ集計)EMRがImpalaをサポートするようになりました。ImpalaはClouderaが提供するオープンソースのクエリエンジンで、Hiveより断然速いそうです。例として、Cloudfrontのログを、タイムスタンプをJSTに直して1時間ごとのアクセス数の集計をしてみます。ログバケットの確認まずCloudFrontのログが以下のS3にたまっているとします。次に、EMRクラスタを起動します。Cluster」をクリックし、新規クラスタ作成画面を表示します。nameに適当なクラスタ名を入力します。今回はEMRのログは出力しないのでLoggingのチェックはOFFなんかにしておきます。起動したインスタンスの名前をつける場合は、TagsのNameとしてインスタンス名をつけておきます。ConfigurationHadoopのバージョンとアプリケーションのリストを設定します。applicationsのドロップダウンでImpalaが選択できるようになります。add」をクリックして追加します。ConfigurationここでVPCやゾーンやインスタンス数を設定します。ここでは、EC2-Classicで、ゾーンはA、インスタンス数はデフォルトにしてみます。pairで、hadoopインスタンスに接続するときのキーペア名を設定します。ここが未定義だと、インスタンスに接続できないので注意が必要です。Stepsここでは、起動した後の挙動や起動パラメータなどを定義します。今回は未設定のままでOKです。cluster」ボタンをクリックして、クラスタを作成します。DNSに、マスタインスタンスのPublicDNSが表示されます。そのPublicDNSに対して、先ほど選択した鍵を使ってhadoopユーザーでSSH接続します。http://localhost:9101/--------------------------------------------------------------------------------$接続が完了しました。現状、ImpalaでExternalテーブルにS3のパスを直接指定するとエラーになってしまいました。方法がわからなかったため、S3DistCpでHDFS上の/input/にコピーしてきます。hdfs:/tmp/8f7379de-1ebf-4f31-be50-bd17aa54f2d5/tempspaceコピーの実行が終わりました。HDFSの内容を見ると、コピーされているのが分かります。/input/E2KNLXPGJLJRRQ.2014-01-30-07.MIAnZGc4.....Impalaの実行Impalaはimpala-shellというコマンドで専用のプロンプトを起動して使います。hiveのhiveコマンドと同じようなものです。>まずは、入力テーブルをつくります。ファイルの場所はS3DistCpのコピー先に指定した/input/を指定します。'/input/';それでは、クエリを実行してみます。0.88s1秒かかりませんでした。Hiveとの速度比較これと同じ集計をHiveで行ってみます。row(s)40秒も掛かりました。Impalaが速いかがわかります。8億レコードでやってみた上と全く同じ内容のクエリを使って、8億レコードのCloudFrontログ解析をImpala上で実行してみました。想像していたより全然速いです。ちなみに、特定のURIに絞ってクエリを実行したら15分ほどで終わってしまいました。852.34s今回はHiveで8億レコードは試せませんでしたが、いままでHiveを使用していた感覚からするとImpalaは異常なほどの速さです。これからEMRでクエリを使用する場合はImpala一択になりそうです。impala2014年2月4日火曜日Dockerってなんじゃ?またまた今更ですが、Dockerを触ってみました。Dockerについてはこのスライドがこれ以上ないくらいに、わかりやすく説明してくれています。今回は、Docker内にCentOSを立ちあげて、SSH接続するまでをやってみます。いうリポジトリからインストールします。searchコマンドでcentosのベースイメージを探します。23.......centosというのが一般的なものらしいので、それを使ってコンテナを起動します。/bin/bashすると、起動したコンテナ内のbashコンソールに自動的に接続されます。ここからはゲストOSの世界です。あとで、sshでログインするために、rootのパスワードを設定します。passwdここで、まずコンテナ内にopensshをインストールします。-y次に、sshd_configで、PAMを使用しないように設定します。yesここまで設定したら、いったんコンテナを抜けてホストOSの世界に戻ってきました。-aで、現在起動しているゲストOSの一覧を確認します。centosのコンテナが1つあります。コンテナには一意のID(9c4fd33c4786)がついていて、状態はExitになっています。commitコマンドで、イメージ化します。イメージのリポジトリ名はsshd/centosとします。sshd/centos4e3f5f7e23b22900df3d3752ba4644f2282a5d07176b472b03753bf4ed1bd191そして、SSH用に、いま作ったsshd/centosのイメージで改めて起動しますが、先ほどとは違い、-dオプションでデーモン化し、sshのポート番号と起動フォアグラウンドプロセスを指定します。それによってsshが起動した状態でコンテナが起動します。起動したSSH用のコンテナは、docker内部では22番ポートですが、ホストOSに対しては別のポートで開いています。コマンドで、コンテナの22番ポートに接続するためのポート番号を調べます。220.0.0.0:49158どうやら49158ポートにフォワードされるようです。ifconfigをみると、docker0というインターフェースでアクセス先のipが分かります。MiB)これで、このコンテナは172.17.42.1の49158でSSHに接続できることが分かりました。password:-bash-4.1#うまくつながりました!とりあえず今回は以上です。docker2014年2月3日月曜日Splunkってなんじゃ?(IISのログをSplunkで解析)久しぶりのsplunkです。WindowsのIISのアクセスログをsplunkで解析してみました。Forwarderを使います。これはSplunkが提供している専用の送信ツールです。Forwarderのインストール&設定を行ってみます。IISのインストールまずはWindowsを立ちあげます。起動したらRDPで接続し、サーバーマネージャーをクリックします。枠割の追加をクリックします。「開始する前に」は「次へ」をクリックします。「サーバーの役割の選択」では「Webサーバー(IIS)」を選択して、「次へ」をクリックします。「Webサーバー(IIS)」では「次へ」をクリックします。「役割サービス」でASPなどを使用する場合は、ここで選択します。確認ダイアログでは「必要な役割サービスを追加」をクリックします「確認」では「インストール」をクリックします。これで、IISがインストールされ、サービスが起動したようです。ローカルのブラウザからWindowsインスタンスのIPアドレスでアクセスしてみます。80番は開放しています。正常にアクセスすることが出来ました。Forwarderのインストールです。ホーム画面で、「データの追加」をクリックします。「IISログ」を選択します。「他のサーバーからログを転送する」のリンクを開き、URLをコピーします。Windows側でURLを開きます。Forwarderのダウンロード画面が表示されます。その際、このsplunkサイトでログインしている必要があります。Windowsの環境に合わせてリンクをクリックして、ダウンロード、実行します。するとインストーラが立ち上がるので、「Next」をクリックします。ライセンスに同意し次に進みます。インストール場所はそのままでOKです。Server」は空欄のまま進みます。Indexer」では、splunkのインデックスサーバーのIPを入力し、ポートは「9997」とします。SSLに関しては、今回はそのままです。Only」を選択します。monitor」で、「Directory」をクリックして、「C:¥inetpub¥logs¥LogFiles¥W3SVC1」を選択します。Tecnology」では、上のラジオを選択します。最後に「Install」をクリックします。すると、完了画面になるので、「Finish」で閉じます。Forwarderの設定これだけではログの送信ができません。splunkのサーバーにセキュリティグループで9997ポートにアクセスできるようにしておきます。Forwarderの設定です。いまのところIISのログの場所を指定しただけで、IISのログフォーマットなどを指定していません。Files¥S@lunkUniversalForwarder¥etc¥system¥local¥inputs.confに以下の記述を追記するだけで済むようになりました。[monitor://C:\inetpub\logs\LogFiles\W3SVC1]sourcetype=iisそして、SplunkForwarderを再起動します。Splunkのインデックスサーバーでは先ほどForwarderで設定した9997番ポートを受け付けるように設定する必要があります。転送と受信」を選択します。新規追加」をクリックします。新規追加画面で、9997を入力して「保存」をクリックします。Forwarderの9997からデータを受信することができるようになりました。待ってから、splunkのサーチ画面でデータサマリーを見てみると、、、おお、「WIN-SEL3V5P943V」というホスト名のデータが新たに登録されてきているのがわかります。そのままホスト名のリンクをクリックして、中身を見てみると、投入されたログデータが表示されており、左のフィールド欄をみると、正しくスプリットされていることが分かります。そこで、フィールド欄で、アクセスログによくあるフィールドを表示選択して、一覧の項目を整理すると以下のようにそれらしくなります。これを簡単なクエリをいくつか使ってダッシュボードを作ってみると以下のようになります。このような感じで、IISのログも統計をとることができました。途中のダイアログにもありましたが、IISだけではなく、Windowsのイベントログなども取得可能です。