ログ解析(データ解析)のプラットフォームに関して
エンジニアとして、様々な形式のログを扱うことがあるかと思います。
システムログしかり、データ分析しかり。
それこそ、Webサーバのアクセスログは膨大な量になりますし、
上手に取り扱わないと結構面倒です。
昨今は、データサイエンティストの需要というのも大きく
今まで以上にデータの解析という仕事をする人が増えていると思います。
私はインフラエンジニアなので、データ解析というよりはログ解析の目線ではあるのですが、
基本的に類似点が多いと思います。
システムログにはタイムスタンプがあり、各時刻ごとのデータが記載されています。
データ解析でいる時系列データ解析に近いです。
そんなログ解析・データ解析ですが、皆様はどのようなプラットフォームで作業していますか。
SIerなんかだと、Excelでピボットテーブル使っているよというエンジニアいると思います。
ピボットテーブルは便利ですが、Excelには扱える行数に限りがあります。
大量のアクセスを受け付けるWebサーバのアクセスログ解析ではどうしましょう?
他に、集計用のスクリプト作っている方もいると思います。
SQLが得意なので、一度DBにインポートしてからSQLで解析していますという人もいるかと思います。
または、R、Pythonなりデータ解析に特化したライブラリを有する環境を利用するという人もいるかと。
というわけで、目標は同じですが様々な手段があるかと思います。
自分も、ケースバイケースで使い分けています。
今回は、様々な方法に関して紹介していこうかと思います。
※一つ一つの細かい内容に関しては後日の記事にします。
今回はサマリを。
■Excelを利用してログ解析・データ解析
こちらは定番中の定番です。
どのような方にも抵抗なく?入れる方法かと思います。
Excelのピボットテーブルしかり、統計解析用の関数然り非常に高機能です。
私もExcelにはお世話になっており、便利で素晴らしいソフトウェアです。
ですが、やはり大量のデータの解析には向かないですね。そこが最大の欠点でしょうか。
■UNIX・Linuxコマンドを利用
サーバエンジニアたるもの、有事の際にはサーバにあるソフトウェアだけで戦える必要があります。
普段からこのようにする必要はないとも思いますが、
sort,awk,nkf,grep,wc,uniq etc..
を利用してコマンドライン上で集計できるのがインフラエンジニアとしては望ましいです。
この方法のいいことは、繰り返し処理が容易なこと、
バッチ処理化可能なことです。
つまり大量のデータ解析にも向いています。
※運用中のサーバでドカンと動かして、負荷かけないようにね。
■SQLを利用してログ解析・データ解析
基本的に、業界標準の規格が定まっている技術というのが好きです。
なぜなら、どのようなソフトウェア、環境に移行しても基本概念が変わることはありませんから。
そういう方にはSQLでの解析がオススメです。
SQLというエンジニアの共通言語で、どこでも利用できるとうのが最大の利点でしょう。
サーバからアクセスログを取得してきて、
ローカルのDB(SQLITEなり、PostgreSQLなり)にインポートして、
SQLで集計するということを私はよくやります。
一度インポートするし、面倒くさくない?ということを思う人もいるかと思いますが、
その一度をやってしまえば、大量のデータに対して繰り返し施行錯誤できます。
そして繰り返しますが、どのようなデータでもSQLの知識があれば戦えるという利点が大きいです。
以下、私がよく利用するプラットフォームの紹介です。
■SQLITE
言わずもがな。簡易DBとして便利ですね。
SQLite Home Page
■PostgreSQL
こちらも有名です。私はローカルのPCにインストールしてありますw
PostgreSQLは分析関数が強力なのがいいですね。
データ解析に向いているDBだと思います。
PostgreSQLの分析関数の衝撃1 (モードとメジアン) (1/3):CodeZine(コードジン)
Download PostgreSQL | EnterpriseDB
■LogParser
Microsoftが提供するログ解析要のツールです。
Windowsのイベント・ログの解析や、IISのログ解析では非常に強力です。
一度解析用のSQL分を作成してしまえば、それを使い回せば良いので業務も効率化できます。
また、一度に複数のログ・ファイルを指定して解析かけられるのも便利です。
Log Parser 2.2 日本語版
概要: Log Parser Studio - (旧) Exchange Team Blog 日本語版 - Site Home - TechNet Blogs
Log Parserでログを統合的に扱い運用保守に役立てる(基本編) (1/4):CodeZine(コードジン)
■q - Text as Data
先ほど一度、ログをDBにインポートすると言いました。
人によってはめんどくさいと思うかもとも言いました。
それなら、直接テキストファイルに対して
SQL打てるようにすればいいじゃないかというわけですね。
皆様、似たようなこと考えているのかもしれませんね。
というわけで、テキストファイル、CSVファイルに対して直接SQLを発行できるツールです。
Run SQL directly on CSV files | Text as Data | q
■統計、データ解析専用のプラットフォーム
こちらは説明するほどではないのですが、
統計を扱う方には定番のソフトウェアたち。
こちらに関してはサラッと解説するのも難しい上、
情報も多くインターネット上にあるので今回は名前の羅列だけ。
※もちろんここに紹介した以外のソフトウェアもあるとは思います。
あくまで私が利用したことあるものだけです。
■R
R: The R Project for Statistical Computing
■Python
O'Reilly Japan - Pythonによるデータ分析入門
■Splunk
皆様しっています?Splunkというソフトウェア。
もしかしたら、Kibana+ElasticSearch+Fluentdとかいう構成なら
知っている方がいるかもしれません。それに近いです。
http://www.splunk.com/ja_jp
http://eure.jp/blog/fluentd_elasticsearch_kibana/
Splunkというのはあらゆるマシンデータをドカンと突っ込んで、
データをラベリングし、分析可能な状態にしてくれるログ解析プラットフォームです。
データの収集・分析・解析をこれ一つでできます。
Web画面を通じて、Splunkに突っ込んだデータを閲覧でき、
SDL言語というのを通じて、データの集計を実施できます。
SPLというのがSQLとまたちょっと違う言語でなれが必要です。
ですが、SQL・SPLの対応表があるのでこちらを参考にしてみてください。
Splunk for SQL users - Splunk Knowledgebase
以上、簡単ですが一覧を記載してみました。
今後、少しづつ詳細に関して記載していこうと思います。
競技プログラミング
実は去年の年末から少し競技プログラミングを再開しました。
一応初めてではなくて、学生の頃にちょこっと(ほぼ遊び感覚で)やっていましたが、
PyCon Japan 2015の講演で競技プログラミングに関しての発表がありまして、
久々に興味が出てきた次第です。
ちなみに、昔はTopCoderとかしか知らなかったのですが、
たくさんあるんですね。。
www.slideshare.net
しかしいきなり突撃するのもあれなので、、
また、久々ということもあり普段と違った言語で、
アルゴリズムとデータ構造の復習をかねてはじめようと思いました。
言語は、Pythonです。いつもC++ばかりですのでLLを採用。
まったくの初めてではないですが、それほどがりがり書いた経験もありませんので、
機械学習とかちょこっとやるくらいしか使わないので、言語の勉強もかねてです。
また、アルゴリズムとデータ構造の復習は、実際に手を動かして書くことが一番だと思います。
そこで、下記サイトを利用しています。
AIZU ONLINE JUDGE: Programming Challenge
国内のサービスで、様々なプログラミングの問題が掲載されています。
この中の「Introduction」-「Introduction to algorithm and data structures」
がちょうど自分の目的に合っています。
このカテゴリはアルゴリズムとデータ構造にちなんだ課題が集められています。
ソートから、連結リスト、再帰処理などを利用して解く問題が収録されており、
練習にちょうどいいです。
まだ初めてちょっとですが、週末など時間があるときにちょこちょこ進めています。
ExcelからDBのレコードを参照・更新したい
早速ですが、タイトルのようなことなんてあるのか?と言われるかもですが、
たまにあるのですよ。
どちらかと言うと、
元々Excelで管理していたものをDBへ突っ込みたいとかが多いのですが。
普通にDBに接続して、Insert文つくって流しましょうというのはそうなんですが、
度々やっていると一発でExcelシートの内容をDBのテーブルに突っ込めるアドオンがあれば
効率いいなという思考に行き着きまして。
なければ隙間時間に作成しようかなとも思ったのですが、
既にあるのですね。本当に素晴らしい世の中ですね。
詳細はマニュアルがしっかり整備されていますのでそちらを参照のこと。
便利だ。。
ExcelDBTool - エクセルでデータ作成、DB接続、データ取得更新
また、同サイトで紹介されている「ExcelDevTool」も大変便利です。
データの生成から、比較、テンプレートの作成等々ありがたいです。
今まで、Excelの便利アドオンとしては、RelaxToolしか知りませんでしたが、
「ExcelDevTool」も試してみようと思います。
RelaxTools Addin for Excel 2007/2010/2013/2016 | Excelを便利にする250以上の機能を体系化したアドインはこちらです。
なんだかんだExcelを利用している方は多いと思いますので、参考に。
WSUSサーバのメンテナンス(管理コンソールに繋がらない等)
以前、WSUSのクリーンアップについて記事を書いたのですが、
そのほかにもWSUSというとちょこちょこ不思議な動作をすることがあります。
たまにですが、WSUSの管理コンソールに接続不可能という現象が発生することがあるのですが、
それらの自称に対して、MSのWSUSチームのBlogにてコメントが公開されていましたので。
自分が体験したのは、上記Blogでいうところのケース2.「たまに接続ができない」になるのですが
下記で解決することが多いとのこと。
・インデックス再構築
→確かに、パッチが増えてくると遅くなるんですよね。。パッチの選定にとてつもない時間が。。
・WSUSサーバのクリーンアップ
→容量問題でもそうですが、不要なパッチは処理時間増を招きますからね。
前回記事にしたのはここですね。
WSUSサーバのクリーンアップ - Infrastructure Engineer`s Notes
・WSUS管理コンソールのキャッシュ削除
→これは知りませんでした。効果はちょっとあるかもくらいみたいですが。
・不要な更新プログラムは「拒否」にする
→これはWSUSの運用上非常に大事かと。
パッチは積み上げていくので、どんどん必要なパッチの選定に要する時間が増加していきます。
・WsusPoolのメモリ引き上げ
→なるほど。利用できる容量を増やそうと。
ここまでやったことはないですが、ありかもですね。
・SQLサーバの最小メモリ・最大メモリの設定値を変更
→上記と同様の考えですね。
これも試したことはないですね。
簡単ですがMSサポートチームのノウハウだそうです。
こういうの大事ですよね。
ソフトウェア開発時の見積もりに関して
少し今回はインフラぽくない話を。
普段機会がないのですが、ソフトウェア開発における見積もり技法に関して
触れる機会があったので、その際の情報をまとめておく。
普段サーバ構築等しかしないので、実はとても新鮮という。。。だめだとは思いますが。
■見積もり技法
■類似法
過去の類似Prjを参考にして見積もる方法。
ちゃんと類似のPrjを参考にすれば、実績と見積もりの差が乖離はしにくい。
ただし、客観性が乏しい。
■積み上げ法
開発しなければならない成果物の構成要素を洗い出し、
それぞれの作成に必要な工数を積み上げる方法。
ソースコードの行数や、各工程の工数を足してくのがこれに該当。
■パラメトリックス法
必要工数を目的変数として、入力値に開発規模や特性をいれることで
数式的に算出する方法。
例としてSLIMとか。
今回は、定番である積み上げ法に関して。
■LOC(Lines of Code)
開発モジュールのステップ数を算出
一人当たりの生産性ステップ数/月で割り算してコスト・必要人数を算出。
ただしソースコードのカウントの仕方(コメント、ヘッダ含めるか)とかは事前に
どのようにカウントするか決めること。
また、人によりステップ数のカウントの仕方はことなると思うので、
そのあたりの統一も難しい。
当然、要件が未確定の段階ではソースコードの行数など正確にだすのは難しいので、
見積もり制度としても低くなることがよくある。
LOC法はこのあたりがあいまいなので、規模尺度法の要件を満たしていない。
※規模尺度法・・・ISOがソフトウエアの規模の測定尺度のために策定
参考にソフトウエアの生産性は、1MMで1000ステップ前後と言われているとかどうとか。
参考:
http://monoist.atmarkit.co.jp/mn/articles/1108/23/news003.html
http://monoist.atmarkit.co.jp/mn/articles/1109/14/news011.html
■FP法
FP(ファンクションポイント)・・・仕様をベースにして、言語や設計方式に依存せず、
開発対象となるシステムの機能規模をFPという単位で計測する。
FPはデータ要素をもとに計算するので、内部のロジックの複雑性は考慮していない。
なので数値計算プログラムなどには不向きでビジネス系のシステム向け。
また、FP法には複数の種類がある。
■IFPUG法
これが全部入りのフルバージョン。
システムの扱うデータ、入出力データ、参照データすべてが計算対象
■FP概算法
IFPUGの簡略版。
■FP試算法
最も簡易版。概算の見積もりの時はこの手法が利用される。
以下、FP試算法の計算方法をざっくりメモする。
FPとはデータの種類・数から開発規模を推定している。
よって、対象システムのデータとファイルを決めれば見積もりが可能。
アルゴリズムとかは一切関係ない。
流れは下記の通り。
内部ファイルの数をカウントして、x35
外部インターフェースファイルの数をカウントして、x15
上記2つを合計したものが総FP数となる。
総FP数から使用する言語のステップ数に換算が可能。
参考:
http://monoist.atmarkit.co.jp/mn/articles/1110/13/news007.html
http://monoist.atmarkit.co.jp/mn/articles/1111/16/news008.html
■最後に
IPAがSEC BOOKSとして、事業成果をまとめています。
その中に、ソフトウェア開発データ白書というのがあるのですが、
様々なPrjとの見積もり等、実績が載っているので参考にしてみるのがいいかと。
PythonでWMIの内部を覗く
Windowsといえば、ブラックボックスだのと言われることも多いかと思いますが、
その中でもとりわけ見えてこない項目としてWMIがあります。
なにせMS最大の秘密とも言われるようですので。
WMI(Windows Management Instrumention)の詳細な説明は下記のサイトに譲りますが、
WBEMのMS実装版で、Windowsの管理情報にアクセスして情報を取得したり
変更することが可能なインターフェイスを提供してくれます。
Windows Management Instrumentation (WMI) の概要
WMI スクリプト入門 : 第 1 部
突き詰めると、WMIを通してWindowsの様々な情報を取得することが可能であり、
管理者としてはお世話になることもあるかと思います。
ですが、WMIでどのような情報を取得できるのか?
というところが漠然としていたので、
Pythonで覗いてみましたというのが今回のお題です。
具体的に今回やったことは、
PythonからWMIを叩いて取得したオブジェクトの中身を見ることで、
どのような情報を取得できるのかを確認したところまでです。
Pythonには様々なモジュールがありますが、下記を利用しています。
下記のようにコマンドを発行することで、WMIインターフェイスへの入り口を作れます。
import wmi c = wmi.WMI()
この「c」の中にWMIの情報が詰まっているのですが、
それを覗くのにPythonのinspectモジュールを利用してみました。
これは、モジュール内のクラスの一覧などを出力してくれるモジュールです。
これにより「c」の内部を覗いてみます。
inspectモジュールを使って、モジュール内のクラス一覧を得る - Mattari Diary
import inspect inspect.getmembers(c)
記載しませんが、大量に出力されます。
_classesの部分が、我々としては大事です。
どのclassの値を参照すれば、我々が望んでいる情報を取得できるかが決まりますので。
例えば、「Win32_Service」というclassがあるかと思います。
このclassからどんな情報が取れるのかと気になったら、
更にこのclassの内部を検索してやればよいのです。
inspect.getmembers(c.win32_service)
こうやっていけば、どの情報を取得できそうかあたりがつけられるかと思います。
このレイヤーまで掘れば、変数名からどのような情報が得られそうかというのが想像できます。
参考:
WMI Fun !! 〜 WMI (Windows Management Instrumentation) に興味がある方・システム管理者必見! 〜
https://msdn.microsoft.com/en-us/library/windows/desktop/aa394582(v=vs.85).aspx
この本が気になる。WMIというとあんまり情報がなく。。
SphinxでWord(docx)文書を出力してみた
自分はあまり、Office製品が好きではありません。
(Office365契約しているけど。。。)
便利なのですよ。便利なのだけど、お節介が過ぎるところがあるので。MSのOffice製品は。
そこで今回は依然から気になっていたSphinxを使ってみることにしました。
特に、Sphinxからdocxを吐き出せないかと試していたのですが、はまりポイントがあったのでご紹介。
環境は以下の通り。
・Python 2.7 (32bit)
・Sphinx 1.3.5
・sphinx-docxbuilder(コミット 83a8d13 2012-06-05)
haraisao / sphinx-docxbuilder — Bitbucket
Sphinxでdocxを出力する際に利用するモジュールは、
「sphinx-docxbuilder」というものを利用しているのですが、
見ての通り、更新日が4年前になります。
自分の環境では、コンパイル中にエラーが出力されました。
tree = inline_all_toctrees(self, set(), master, tree, darkgreen) TypeError: inline_all_toctrees() takes exactly 6 arguments (5 given)
明らかに関数の型がおかしいとのことで、
ちょっと調べてみると、Sphinxが提供している
「inline_all_toctrees」関数の型が変更されているのが原因に見えます。
取り急ぎ、下記のように変更すればコンパイルは通ります。
sphinx-docbuilder/builder.py 60行目
・Before
tree = inline_all_toctrees(self, set(), master, tree, darkgreen)
・After
tree = inline_all_toctrees(self, set(), master, tree, darkgreen, [])
参考:
futurismo.biz