続 カッコの付け方

AWSを始めとしたクラウドコンピューティング全般と、唯一神emacsにおける()の付け方についてだらだら書きます

find & xargs で ディレクトリ内一括置換、リカバリも考えて

私は考えていた。
「このままEmacsの道を歩むのか、それともatomとやらを使うべきか。。」 atom使ってみたけどいい感じ!Emacsキーバインドも使えるし、、と思ったけど、私だけにとって致命的な欠陥が、commandキーを altキーと扱ってくれない点です。もっと上からキーバインドをいじって、alt <=> command をやればいいけど、そうするとatom特有の操作が気持ち悪くなる。のでやめとこうとなった。 もともと、Emacsを使うようになったのは、実は仕方なしであって、本当はwindowsxyzzyというソフトを使っていた。今回は、そのxyzzyにある、gresregという機能と同じことをやりたいというお話。ちなみにatomは余裕で出来そう。たぶん

gresregとは?

特定のディレクトリ配下のファイルにgrepかけてreplaceもするというものです。なんとEmacsに無い機能なんです。

そんなのコマンドで楽勝でしょ!

英語だけで生きている人ならば多分大丈夫でしょうが、問題は日本語です。文字コードが混ざり、且つ日本語を置換するとなると、ワンライナーはチョットなと思う。 xyzzyの例ですが、参考に。日本語が絡むとエディタの仕事ですね。 http://xyzzy.s53.xrea.com/wiki/index.php?QuickTour%2Fgresreg

emacsにおける gresregは?

Meadowで実装があるとのことで、パッケージでは入らないですが、あります。
http://www.bookshelf.jp/soft/meadow_49.html#SEC735
githubにある奴は、日本語が化けているので注意

だけど、xyzzyとの違いは大きく、ディレクトリを指定することが出来ず、あくまで対象は開いているバッファ全てとなります。まあ、作ればいいんですが。。

しゃあないからコマンドでやる。やれて損はないし

find & xargs ですね。これも今更知りましたが、 find & xargs をやるなら、 find -print0, xargs -0 は必須と言っていいでしょう。スペースを含むファイルパス名が上手く捌けないからです。

普通にgresreg

find . -type f -name "*.txt" -print0 | xargs -0 sed -i.bak -e s/age/sage/g

-i の後にprifixをつけたら、その名前でバックアップファイルを作ります。バックアップなしだと怖いので、.bakは必須かと
そもそも、対象ディレクトリがきっちりわかってて、まるごとバックアップ可能だったら、先にバックアップ取るほうがいいですね。

変更対象を洗い出す

diff の力を借りる。

find . -type f -name "*.txt" -print0 | xargs -0 -I{} diff -u {} {}.bak

xargs -I は、実行対象のコマンドで、xargsにわたってくる引数を2回使ったり、位置を変えたりするときに使う。{}がよく使われているのは、単にバッティングしにくい名前ってだけなので、なんでもいい
diffのオプションをもう少しいじれば、情報は色々コントロールできるはず、ファイル名だけとか。sedは、置換が起ころうが起こらまいがバックアップファイルを生成するので、これでいける。

リカバリ 元に戻すとき

find . -type f -name "*.txt" -print0 | xargs -0 -I{} mv {}.bak {}

バックアップはもう要らないから消すとき

find . -type f -name "*.bak" -delete

ここはfind単体でいける

まとめ

  • インフラエンジニアは正直コマンドで十分。だけど日本語ファイルを使う人は、gresregはエディタにやらすべき。
  • find -print0 & xargs -0 は正直デフォルトでよくね?
  • こんなコマンド、年に3回叩けばいい位、だからすぐ忘れる、だから忘れないように書いておく

S3のIAM設定のハマりどころ

以前書いた記事のS3のIAM設定ですが、最近のマネジメントコンソールだと怒られるので、修正版とその他ハマりどころを書きます。 iga-ninja.hatenablog.com

StringEquals で ""は指定できないよ!

        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::<your bucket>"
            ],
            "Condition": {
                "StringEquals": {
                    "s3:prefix": [
                        ""
                    ]
                }
            }
        },

と以前書いたのですが、ポリシーエラーだと言われて通りません。修正点は StringEquals => StringLike に修正してください、これで通ります。

CloudBerry専用の対策

前回の記事の設定では、CloudBerryを利用した場合のみ、自分のディレクトリまで掘ることが出来ません。対策はコチラです。(CloudBerry-Labに問い合わせて教えてもらいました)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::<Your Backet>"
            ],
            "Condition": {
                "StringLike": { "s3:prefix": [ "" ] },
                "StringEquals": { "s3:delimiter": [ "/" ] }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::<Your Bucket>"
            ],
            "Condition": {
                "Null": { "s3:prefix": "true" },
                "StringEquals": { "s3:delimiter": [ "/" ] }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::<Resource Path>"
            ]
        }
    ]
}

StringNotLikeで複数条件したいなら

            "Condition": {
                "StringNotLike": {
                    "s3:prefix": [
                        "hoge/*",
                        "arege/*"
                    ]
                }
            }

とします。 Condition の下に StringNotLikeを2つ書くのもポリシーエラーで通りません。
自分も、すぐ忘れてしまうので、メモします。

サーモグラフィーで野鳥観察ができる時代?

世の中には同じことを考える人が何人かいると聞きます。野鳥観察で、全く同じことを考えている人がいた。

Infrared Birding: Welcome to Infrared Birding

俺が求めていたのはコレだ!
thx suan!

野鳥観察について

鳥を見ないひとにはドマイナーで、ごく一部の年寄りの暇つぶしのように思われてるかもしれませんが、結構人気があります。
白樺峠の鷹の渡りとかは、見れるかどうかもわからないのに、結構な人が東京から観光バスできてます。また、珍しい鳥が来たとかになると、twitterとかで情報拡散されて、バーダーが集中し、マナーの悪さを叩かれたりしてます。

  • 鳥用のカメラなど、ある一定のニーズがある。
  • 正直金持ちの道楽的なところもあるが、お金がなくても楽しめる(俗にリアルモンハン)。
  • 情報拡散の弊害が大きく、「何でもシェア」時代のテクノロジーとは相性が悪い。

サーモグラフィーの今

スマホにつけて使えるやつが熱いらしい

iphone-mania.jp

なんで鳥見で嬉しいか

「すごく近くで鳴いているのに、どこにいるかわからない」あるあるです。特にウグイスですが、ちゃんと見たことある人います?メジロじゃないですよ。こんなとき、 「サーモグラフィーがあったらな~」 と思ったこと、一度はあるはず。

早速ポチるか

もうじきホトトギスカッコウが来ます。こいつらも鳴き声はするがどこにいるかわからないの代名詞です。この時期なので、あまり温度差がでないかもですが、やってみるか。

Google Cloud Pub/Subと類似サービスの比較(SNS, SQS)

もう1ヶ月以上経過してしまいましたが、まだ情報が少ないみないなので、aws識者として競合との比較も含めて書きます。私は使わないと頭に入らない人間なので、ちょっと触ります。

概要

What is Google Cloud Pub/Sub? - Cloud Pub/Sub — Google Cloud Platform

の絵で大体想像がつくと思いますが、文字通り Pub/Subを実現するものです。
最初にPub/Subを見た時、AWS SNSをイメージしましたが、どうやら違うようです(一部重複の部分もある)。
じゃあSQSかとも思いまいたが、どうやらこれとも違うようです(使い方によっては一部重複する)。
Pub/Sub自体の機能については、結構言及されているので、

togetter.com

これも参考にしながら、まずはAWSとの比較から書きます。

競合比較

SNSとの違い

SNSは原則Push型です。Pub/Subは Push or Pull ですので、一部機能は重複しています。この辺りをまとめると
- SNSはPub/Subだが、Pushしか出来ない
- SNSはPush先が豊富 Mail, HTTP(s), SQS(AWS内のサービス連携), モバイルプッシュ など、かなりアプリケーションに突っ込んだところまで実装している。
- Pub/Sub が対応している Pushは HTTPSのみ(2015/04/29)

SQSとの違い

SQS自体にPub/Subの機能はありません。SQSと競合するサービスは、Google Task Queue です。両方古くからあるサービスなので、最初 Pub/Subと聞いての競合はSNSだと思いました。
- SQSはそもそもPub/Subではない
- SNSとSQSは連携できるので、組み合わせればPub/Sub & Pull型は一応できる(管理が大変そう)
- Cloud Pub/Sub の Pullは SQSそのものだが、単純にキューを使いたいならTask Queueで十分

総合的にみて

現状 Cloud Pub/Sub は Pull主体です。Pushは HTTPSに限定されているので、Push型のsubscriberはそんなに増やせない。よって、Pull型のSNS(Queue付きのSNS) = Cloud Pub/Sub というイメージ。互いに似て非なるものです。

Cloud Pub/Sub (subscriber視点)

こちらをご一読。

Subscriber Guide - Cloud Pub/Sub — Google Cloud Platform

  • Pullならポーリング当たり前だけどリアルタイム性はさがるよ
  • Pullなら通信費かさむよ
  • Pushなら HTTPSのエンドポイント用意して!
  • PushのエンドポイントはGAE(App Engine)ほぼ一択、DNS通さないとダメみたい

GAEか、勉強するぞ!いつか。

実践

サンプル動かす

GAEのサンプルは書かれている方がおりますので、GCEというかローカルPCで動かします。よってsubscriberはpullです。

github.com

Googleといえばpythonなので、python一択
READMEに従い、venvに必要なpipをぶち込みます。
オプション無しで叩くと、使い方が出ます。

$ python pubsub_sample.py
Available arguments are:
  PROJ list_topics
  PROJ create_topic TOPIC
  PROJ delete_topic TOPIC
  PROJ list_subscriptions
  PROJ list_subscriptions_in_topic TOPIC
  PROJ create_subscription SUBSCRIPTION LINKED_TOPIC [PUSH_ENDPOINT]
  PROJ delete_subscription SUBSCRIPTION
  PROJ connect_irc TOPIC SERVER CHANNEL
  PROJ publish_message TOPIC MESSAGE
  PROJ pull_messages SUBSCRIPTION

コマンドは叩いてもらうとわかるとして、気になる実装connect_ircをみてみます。ircの特定チャネルの情報を流すらしいですが、実装は単純に

    while True:
        readbuffer = readbuffer + irc.recv(1024)
        temp = readbuffer.split('\n')
        readbuffer = temp.pop()
        for line in temp:
            line = line.rstrip()
            parts = line.split()
            if parts[0] == "PING":
                irc.send("PONG {}\r\n".format(parts[1]))
            else:
                i = line.find(priv_mark)
                if i == -1:
                    continue
                line = line[i + len(priv_mark):]
                m = p.match(line)
                if m:
                    line = "Title: {}, Diff: {}".format(m.group(1), m.group(2))
                body = {
                    'messages': [{'data': base64.b64encode(str(line))}]
                }
                client.projects().topics().publish(
                    topic=topic, body=body).execute(num_retries=NUM_RETRIES)

ircのチャネルをポーリングしてpubしているだけです。サンプルとしてはひと通り動かせばよく分かり、どう実装するかも余計な部分がほとんど無いので、コードを読めばすぐわかる感じです。

まとめ

  1. pull主体
  2. pushやるならGAE
  3. Cloud Loggingとの連携、pushでスマートにやるならGAE一択
  4. 単純なキューなら、Task Queue使ったほうがいい(多分)

Google Cloud Logging + Big Queryでアクセスログ解析 (リアルタイム風味) 後編

早速後編です。実は筆者もBigQueryをガチで使うのは初めてです。使ってみてわかったのは、結構普通のSQL(私の普通はOracle基準、つまりMySQLから見たらコテコテの機能モリモリのSQL)が通るということです。UDFもPreview?で通るらしいですが、今回はUDFまでは行きませんでした。

BQ予備知識

BQの予備知識としては
- SQLで問い合わせる
- Updateが出来ない
- Deleteが出来ない

まずは、これだけ知ってれば十分だと思います。BQの紹介で gcpja-night でも言われてたことですが。
SQLがエンジニアだけのものだと言うのは間違いで、非エンジニアでもSQLぐらい叩けるひとはザラに居るので、1から10までエンジニアが面倒見なくていい。
とのことです。エンジニアのくせにSQLが出来ないという人は、、、反省して勉強して下さい。
それてしまいましたが、SQLはやっぱり偉大だということです。英語が話せれば世界中のひととry 的な話です。
UpdateおよびDeleteが出来ない点ですが、前編でも出しましたが、列ベースのDBとしては仕方がないそうです。まあ、UpDateはインラインビューでどうとでもなるとして、Deleteについてはどうするかというと、テーブルの末尾に日付をつけるなどして、別テーブル扱いにします。古くて要らないデータはテーブルごと殺します。
じゃあ、テーブルが割れるじゃないか!ということですが、それも想定の範囲内。テーブルの末尾に日付がつくのですが、このテーブル名に対して Where句が掛けられます。さすがよく出来てる、歴史も長いしね。

Access Logの解析

さて、いよいよ解析するぞ-

BQに届く頻度(リアルタイム性)

テーブル名は日付で割れますが、1日1回というほどズボラではありません。Cloud Loggingをかましているので、どう考えても Fluentd BigQuery Pluginには負けると思いますが、だいたい5-10分位のインターバルかと。

BQに届いたデータ

前編の設定がちゃんと行き届いていれば、下記のようになっていると思います。
f:id:iga-ninja:20150429160733p:plain
Fluentのtag = Cloud Loggingのログ名 = BQのテーブルPrefix となります。日付が変わる毎に新しいテーブルが生成されます。

では、中身を確認します。
f:id:iga-ninja:20150429160808p:plain
f:id:iga-ninja:20150429160844p:plain
textPayloadに生ログが入っています。これをパースして使える状態にしなければいけません。

textPayloadの分解

今回の例は apache combimed形式です。パースのことを考えればaccess_logの時点でTSV(LTSVのLの部分はいらないかもしれない)が良さそうですが、みんなが欲しがるcombinedで。

やり方ですが、まあ、正規表現ですよね。BQの正規表現ってどうなってるのかな?と調べたら

https://cloud.google.com/bigquery/query-reference#regularexpressionfunctions

REGEXP_EXTRACTで後方参照ですね。楽勝楽勝!あとはcombinedの正規表現など、ググればすく出てくるのでそいつをアレンジすればOK。

SELECT 
REGEXP_EXTRACT(textPayload,r'^(\S*) \S* \S* \[[^]]*\] ".*?" \S* \S* ".*?" ".*?"') AS host,
REGEXP_EXTRACT(textPayload,r'^\S* (\S*) \S* \[[^]]*\] ".*?" \S* \S* ".*?" ".*?"') AS identify,
REGEXP_EXTRACT(textPayload,r'^\S* \S* (\S*) \[[^]]*\] ".*?" \S* \S* ".*?" ".*?"') AS user,
REGEXP_EXTRACT(textPayload,r'^\S* \S* \S* \[([^]]*)\] ".*?" \S* \S* ".*?" ".*?"') AS time,
REGEXP_EXTRACT(textPayload,r'^\S* \S* \S* \[[^]]*\] "(.*?)" \S* \S* ".*?" ".*?"') AS request,
REGEXP_EXTRACT(textPayload,r'^\S* \S* \S* \[[^]]*\] ".*?" (\S*) \S* ".*?" ".*?"') AS status,
REGEXP_EXTRACT(textPayload,r'^\S* \S* \S* \[[^]]*\] ".*?" \S* (\S*) ".*?" ".*?"') AS bytes,
REGEXP_EXTRACT(textPayload,r'^\S* \S* \S* \[[^]]*\] ".*?" \S* \S* "(.*?)" ".*?"') AS referer,
REGEXP_EXTRACT(textPayload,r'^\S* \S* \S* \[[^]]*\] ".*?" \S* \S* ".*?" "(.*?)"') AS agent
FROM [all_logs.apache_access_20150428]

これで変換は完了。.* にこだわる理由は何?的な質問もあろうかと思いますが、"-" が "" となるケースもあるらしく、この道の著名人もcombinedの正規表現には結構しくじってます。これが正解かはわかりませんので、使うときは要確認で。解析の前に、とりあえずこいつをViewにしちゃいます。
f:id:iga-ninja:20150429161031p:plain
f:id:iga-ninja:20150429161232p:plain

集計する

たいして面白くない集計ですがとりあえずできた。

SELECT host, sum(integer(bytes))  FROM [all_logs.parced_view] group by host

結果はこんな感じ
f:id:iga-ninja:20150429161053p:plain

複数日付(テーブル)にまたがる場合

table wildcard functions とやらを使えば良さそうです。
https://cloud.google.com/bigquery/query-reference#tablewildcardfunctions

早速試してみましょう。1日たたないとこのテスト出来ないので、翌日にでもどうぞー

SELECT
REGEXP_EXTRACT(textPayload,r'^(\S*) \S* \S* \[[^]]*\] ".*?" \S* \S* ".*?" ".*?"') AS host,
REGEXP_EXTRACT(textPayload,r'^\S* (\S*) \S* \[[^]]*\] ".*?" \S* \S* ".*?" ".*?"') AS identify,
REGEXP_EXTRACT(textPayload,r'^\S* \S* (\S*) \[[^]]*\] ".*?" \S* \S* ".*?" ".*?"') AS user,
REGEXP_EXTRACT(textPayload,r'^\S* \S* \S* \[([^]]*)\] ".*?" \S* \S* ".*?" ".*?"') AS time,
REGEXP_EXTRACT(textPayload,r'^\S* \S* \S* \[[^]]*\] "(.*?)" \S* \S* ".*?" ".*?"') AS request,
REGEXP_EXTRACT(textPayload,r'^\S* \S* \S* \[[^]]*\] ".*?" (\S*) \S* ".*?" ".*?"') AS status,
REGEXP_EXTRACT(textPayload,r'^\S* \S* \S* \[[^]]*\] ".*?" \S* (\S*) ".*?" ".*?"') AS bytes,
REGEXP_EXTRACT(textPayload,r'^\S* \S* \S* \[[^]]*\] ".*?" \S* \S* "(.*?)" ".*?"') AS referer,
REGEXP_EXTRACT(textPayload,r'^\S* \S* \S* \[[^]]*\] ".*?" \S* \S* ".*?" "(.*?)"') AS agent
FROM
(TABLE_DATE_RANGE(
    all_logs.apache_access_,
    TIMESTAMP('2015-04-27'),
    TIMESTAMP('2015-04-29')))

ちゃんと3日分のデータが引けるはずです。いちいち日付を指定するのが面倒であれば、Now()とか使えばOKだし、逆に存在するテーブル全部とかも日付の幅を広げれば可能。

まとめ

  1. Cloud Loggingから出てくるデータは textPayloadに生のまま入っている
  2. textPayloadを分割するView(インラインビュー)を作成すると色々楽
  3. 日付で割れたテーブルも table wildcard functions で楽勝!

リファレンス眺めてるだけでも楽しい!JDBCもいけるし、GASでGoogleスプレッドシートとかとも連携できる。手軽にこんなシステムが使えるなんていい時代。

Google Cloud Logging + Big Queryでアクセスログ解析 (リアルタイム風味) 前編

今更ビックデータ という言葉を使うとちょっと恥ずかしいぐらいの時代になりましたが、身近にあるビックデータ(になりうるもの)として、Apacheアクセスログ解析をやってみたいと思います。リアルタイムに解析できるのが良いですが、リアルタイム性を追求してしまうと、色々大掛かりになるので、そこまで頑張らなくてもできる(大半をGCPにおまかせ)ということで、リアルタイム風味 とします。

部品の説明

  • Google Cloud Logging
  • Big Query

この2つを使います。Big Query に直接流し込む fluent plugin もありますが、色々狙いがあってGoogle Cloud Logging + Big Query連携とします。

Google Cloud Logging

AWSのCloud Watch Logs に似ていますが、現状では Watch = 監視機能は持っていません。かわりにExport として GCS(gs) もしくは Big Query に出力します。
また、Cloud Loggingにデータを投げるには、 google-fluent を使います。「結局 fluentじゃねーか!」ですが、ちょっとカスタマイズされていて、普通のfluentと同じ設定だとまずいので、細かい話をあとで書きます。

Big Query

日本での知名度はイマイチですが、結構古くからあるサービスで、データ容量とクエリに対して課金となり、いかにもクラウドなサービスです。AWSのredshiftに似ていますが、ターゲットは別と言って良いと思います。
元々は、止まったデータ(過去ログとか)を解析するものでしたが、最近は動いているデータ(ストリームデータ)のインポートも容易になりました。この機能により、くどいですが リアルタイム風味です。

Google Cloud Logging へログインポート

インスタンスの準備

VMインスタンスからgoogle-fluentで投げ込みます。それには前提条件があります。

  • VMインスタンス起動時にのみ指定できる scope = AWSでいう EC2-IAM-Role を指定する必要がある。
    f:id:iga-ninja:20150429142352p:plain
  • プロジェクト単位でのAPI有効化
    f:id:iga-ninja:20150429142344p:plain

この状態でgoogle-fluentをインストールします。ドキュメントのとおりです。 $ curl -sSO "https://storage.googleapis.com/signals-agents/logging/google-fluentd-install.sh"

google-fluent の設定

インストールしただけでかなりの設定済みfluent.confファイルが仕込まれていますが、不要なものを取り除き、access-logの設定をします。ここで注意点と、今回の設計意図を述べます。

原則 fluentの format = none とする

通常のfluentであれば、fluent クライアント(ログの生産者)がログをjsonにパース、もしくは生の状態でログコレクタ(別サーバ)に投げつけてパースさせるかの違いはあれど。
どこかでパースしてjsonにする
のが普通です。しかしoutput先がCloud Logging なので、他のESなどに突っ込んでいたのと同じjsonにしても、Cloud Loggingには突っ込めません。厳密には Cloud Loggingに対して json化して突っ込むメリットはあるには有ります、がとにかく他のoutput plugin と同じようにパースしても使えないとだけ認識してください。

上記について、多分、並のエンジニアならこう思います

「パース出来ないならBig Queryに行った時もカラムにならないから使えねーじゃねーか!」

私もBig Queryの予備知識がなければ多分そう考えてます。しかしこう切り返します

「Big Query なんでカラムなんてどうでもいいんです!あんなものは飾りです、偉い人には..ry」

詳しくは後編で書きますが、Big Query はそもそもインデックスが無い、データ総なめ(Full Scan)のデザインになってます。カラムに高速化の意味は薄いです(少なくとも行ベースのRDBにおけるインデックスの重要性とはまるで違います、列ベースは列ベースで別の意味でのカラム分割メリットはありますが)よって、カラムなんてクエリで作ればいいんです。

もう少し大きく考えれば、ETLを何処でやるかです。Cloud Loggingと組む場合は、原則ETLもBigQueryの仕事となります。これにより、ログの生産者たるWebサーバは楽できる。Webサーバが楽した分、Big Queryが頑張ることになりますが、Big Queryは全然余裕でETLもこなしつつ集計もできます。このETLをfluentにやらせるのであれば、fluent の BigQuery プラグインを使うのが良いです。

能書きが長くなりましたが、設定ファイルです

centos用です。tag名が Cloud Logging上のログ名 -> Big Query上のテーブル名Prefixとなるので、ここをアプリごとに分割したい人は別名で指定することをオススメします。

<source>
  type tail
  format none
  path /var/log/httpd/access_log
  pos_file /var/tmp/fluentd.apache-access.pos
  read_from_head true
  tag apache-access
</source>

<source>
  type tail
  format none
  path /var/log/httpd/error_log
  pos_file /var/tmp/fluentd.apache-error.pos
  read_from_head true
  tag apache-error
</source>

sink設定 (Big QueryへのExport)

Export設定は、プロジェクトオーナー権限が必要ですが、Developers Console 上からもExport設定は出来ます。が、これをやってしまうとCloud Logging にたまっているデータを根こそぎBig Queryにぶち込むので嫌です。
特定のログのみBigQueryに入れるには、gcloudコマンドを使います。こちらもドキュメント通りですが
1. プロジェクトのBigQueryにユーザー追加
BQ側に適当なデータセットを作成し、
- Group by Email
- cloud-logs@google.com
- Can Edit
でユーザーを追加します。こんな感じです。

f:id:iga-ninja:20150429142357p:plain
2. gcloud コマンドを叩く

# cloud logging 上でのLog名を調べる
gcloud preview logging --project <project-id> logs list

# sink登録
gcloud preview logging --project <project-id> sinks create <sink名 適当でいい> \
bigquery.googleapis.com/projects/<project-number>/datasets/access_logs \
--log <cloud logging上のでLog名>

# sink 確認
gcloud preview logging --project <project-id> sinks list

ここまでの手順どうりに進めていたら、cloud logging上でのLog名は apache-accessになります。これで完了です。

まとめ

まだ前半しか終わってないですが。

  1. Google Cloud Loggingに入れるためには、fluent の format は原則 None
  2. sink を使わずにExportした場合、データ根こそぎ Big Query (or GCS)に飛ぶ。多分、嫌だとおもうので、gcloudコマンドでsink設定。
  3. Big Qeury の力を信じて、ログ生産者側でごちゃごちゃしない。ETLなど集計と同時にやればいい。

今、ドキュメントをみて気づいたのですが Cloud Logging -> Pub/Subがいけるようになったみたいです。夢が広がりんぐ。

nagios pulgin互換 icinga2 インストールしてみた

日本では(世界でも?)あんまり話題になっていない nagios互換の統合監視ツール icinga2 をインストールしてみた。icinga(読みは wikipediaより アイシンガ or イッティンガ)はもともとは nagios の forkらしく、icinga 1は互換性を重視、 icinga 2はそこまで互換性重視じゃないけど、nagios plugin は使いまわせるそうです。

Icinga | Open Source Monitoring

この記事はわかってらっしゃる方向けです。

なんでそんなもの使うの?

僕の趣味だからですw 今 OSSでこの手のソフトウェアは

とかありますが、全部一長一短があります。各種の長短は置いといて、nagiosの長短について書くと

  • イケてるところ
    軽い!
    歴史が長い、pluginが多く(個人の印象)、安定している

  • イケてないところ
    UIがダサい!
    監視ノードを追加するのに、いちいち設定ファイルの書き直し&restartとか、クラウド時代にありえない!
    きょうびAPIとか無いとかありえない!
    なんでAgent型じゃないの? NAT超えとか考えてないの?

「安定してて軽いのはいいが、古すぎて最近の情勢に合っていない。」
ってことです。ココらへんのイケてないところを何とかしてやろうというのがicingaの理念らしい。nagiosのいいところはそのままに

インストールする

正直言って、結構面倒です。zabbixよりも面倒と感じました。

http://docs.icinga.org/icinga2/latest/doc/module/icinga2/toc#!/icinga2/latest/doc/module/icinga2/chapter/getting-started#installing-icinga2

ドキュメントはしっかりしています。ので、読みましょう。
ある程度わかってらっしゃる方向けに書きますと

  • パッケージはyumでいける
  • mysqlかpostgres など、バックエンドにDBは必要
  • webインターフェースは別途入れる (gitでcloneのみ)
  • phpが要る
  • 機能毎に rpmが分かれている

zabbixのように一枚岩のてんこ盛りを想像していると、若干だるいです。それでも初見でも30分ぐらいで、サーバは立てられるはず!一部マニュアルどおりでうまく行かなかったのは

# mysql -u root -p icinga < /usr/share/icinga2-ido-mysql/schema/mysql.sql

ここは -u icinga で -D icingaとする必要がありそう。

icingaweb2のインストール

gitからのコピーと実行ユーザーの追加を行うと、ブラウザで初期設定が行えます。Imagemagicの拡張がないとWarningと言ってくるので yum install php-pecl-imagick 全部通らないと最後にちゃんとコケるので、安心

インストール直後

なんということでしょう~。あんなにダサかったnagiosの画面がこんなに今風のデザインに! f:id:iga-ninja:20150321124515p:plain 正直なところ、UIはちょっと癖があって使いにくいかも?それでもzabbixよりマシかなー。

Notificationのトグルが効かないトラブルシュート

Notificationだけ飛ばさないとか、Webからやるとエラーになる。/var/run/icinga2/cmd/icinga2.cmdパーミッションが無いとかでてるので、付けてやる。centosの場合は apacheユーザーで実行となるから、vigrで icingacmdグループにapacheも突っ込んでやる。コマンドでやる方法でもいいはず。ubuntuだけど、動作確認方法とかもここにあるので、参照してね。

dev.icinga.org

監視対象ノードの追加

ここからが本番。と言ってもマニュアルどおりですが、これもわかってらっしゃる方向けに概要だけ。

http://docs.icinga.org/icinga2/snapshot/doc/module/icinga2/chapter/icinga2-client#certificates-manual-creation

  • マスターサーバとして建てるなら、それ専用の設定が必要で、ここでAPIを有効化する
  • クライアント側のもiciga2が必要。(普通の動かし方としては)
  • そこら辺の細々した設定は、cli のウィザードがあり、そいつに従えば結構楽にできる。(けど、自動化は,,)
  • ノードの登録は、クライアント側からマスターに投げつける。でも、投げつけて終わりじゃない
  • クライアントから投げつけられた状態のままだと、反映されない。マスター側での設定更新が必要
  • 設定ファイルをマスターのレポジトリ(ただのディレクトリ)に溜め込んでいるっぽい。こいつを起動時やサーバリロード時にDBに同期してるっぽい
  • 設定ファイル自体は、nagiosのそれに酷似しているが、互換性はなさ気。変換スクリプトで一発行けそうだけど。

正直、思ってたのと違う。結局のところ、nagiosの思想がベースなので、設定ファイル自体は確かにDB保存だが、ノード側の処理一切なしで登録と思ってたんだけど、そうではないみたい。ただ、クライアントから設定ファイルを投げつけられた状態は多分拾えるのではないかと思うので、マスター側が自動でクライアント登録分を処理することは可能ではないかと踏んでいる。

まとめ

  • サイトがしゃれオツで(流行ってなくても)使ってみようという気にさせてくれる <- ここ重要 Icinga | Open Source Monitoring
  • ドキュメントが秀逸、この内容であれば、インストール手法とかを日本語で誰かが書くより、和訳するほうがよっぽど建設的
  • 思ったより煩雑
  • 安定性は正直分からないが、nagiosの設定ファイルがDBに変わっただけと思えば比較的安心
  • その他、触れてない機能多数。クラスタ化? zabbixのproxyぽいやつとか。
  • icingaって最初は打ちにくかったけどスグ慣れるよ。