BlankTar

about | blog | works | photo

最近自宅サーバの環境をモダンにする作業を進めています。
直接ホストで動かしてたデーモンをdockerに載せたり、ログを準リアルタイム的に解析出来るようにしたり。で、この記事はこのログの部分のメモです。

docker-comopseで立ち上げたコンテナのログを、fluentd経由でelasticsearchに流し込みます。
本当はこの先kibanaで解析するのだけれど、この記事では扱いません。一応立てるだけ。

なお、ここで使ったファイル一式はgithubにあります。

fluentdのイメージを用意する

Docker Hubにfluentdのイメージがあるにはあるのですが、このままだとelasticsearchにoutputするためのプラグインが入っていません。
なので、ドキュメントを参考にしてDockerfileを作ります。

FROM fluent/fluentd

RUN apk add --update --virtual .build-deps sudo build-base ruby-dev \
 && sudo gem install fluent-plugin-elasticsearch \
 && sudo gem sources --clear-all \
 && apk del .build-deps \
 && rm -rf /var/cache/apk/* /home/fluent/.gem/ruby/2.4.0/cache/*.gem

こんな感じでおっけー。ファイル名は./fluentd/Dockerfileにしました。

fluentdの設定ファイルを書く

イベージが出来たら、それ用の設定ファイルを書きます。コンテナイメージの中にCOPYしなかったのはちょこちょこ弄りたいから。
ここでは、elasticsearchのコンテナの名前はそのまんまelasticsearchということにしておきます。

最小限の内容だと以下のような感じ。受け取った内容をそのまんまfluentdに流すだけ。
githubのやつは標準出力にも出すようにしてあります。お好みで。

<source>
  @type forward
  port 24224
</source>

<match **>
  @type elasticsearch
  host elasticsearch
  port 9200
  logstash_format true
  logstash_prefix fluent.${tag}
</match>

どこに置いても良いのですが、とりあえず./fluentd/fluentd.confにしました。

ひと通り立ち上げてみる

elasticsearchkibanaについてはオフィシャルのリポジトリをそのまま使えるので使います。バージョン古いっぽいけど、まあ良いでしょう。

とりあえず立ち上げるだけのdocker-composeは以下のような感じになります。ファイル名は./docker-compose.ymlで。

version: '3'

services:
  fluentd:
	build: ./fluentd

	volumes:
	  - ./fluentd/fluentd.conf:/fluentd/etc/fluentd.conf:ro

	ports:
	  - 24224:24224

	environment:
	  FLUENTD_CONF: fluentd.conf

  elasticsearch:
	image: elasticsearch

	depends_on:
	  - fluentd

  kibana:
	image: kibana

	ports:
	  - 5601:5601

	depends_on:
	  - elasticsearch

ファイルが出来たら、普通に起動します。

$ docker-compose up -d

この状態でlocalhost:5601にアクセスするとkibanaが開いて色々見れるはず。
ただ、このままだとログも何も流れてこないのでさびしい。

コンテナのログをfluentdに流す

いよいよ本題。コンテナが吐き出すログを全部fluentdに流して、elasticsearchに保存します。

./docker-compose.ymlを書き換えて、以下のような感じに。

version: '3.4'

x-logging:
  &default-logging
  driver: fluentd
  options:
	fluentd-address: localhost:24224
	tag: "log.{{.Name}}"

services:
  fluentd:
	build: ./fluentd

	volumes:
	  - ./fluentd/fluentd.conf:/fluentd/etc/fluentd.conf:ro

	ports:
	  - 24224:24224

	environment:
	  FLUENTD_CONF: fluentd.conf

  elasticsearch:
	image: elasticsearch

	depends_on:
	  - fluentd
	logging: *default-logging

  kibana:
	image: kibana

	ports:
	  - 5601:5601

	depends_on:
	  - elasticsearch
	logging: *default-logging

変更は以下の三点です。

1. versionが3から3.4になった
2. x-loggingってのが増えた
3. elasticsearchとkibanaのサービスにlogging: *default-loggingが増えた。

実際のところ3番だけでよくて、1と2は何度も同じことを書かなくてよくするためにやっています。Extension Fieldと言うらしい。
versionを変えたくない場合はlogging:以下にx-loggingの内容(&default-logging以外)を書けばおっけーです。

ちなみに、x-logging.options.tagの部分に.Name(コンテナの名前が入る)とかいうのを使ってますが、この部分は他にも色々使えるみたいです。dockerのドキュメントにtagに使える変数のリストが載ってるので参考にどうぞ。

この状態でもう一回起動すると、elasticsearchにがしがしログが追記されていくはずです。
ログのタグはfluent.log.(コンテナ名)-YYYY-MM-DDになっているはず。

このままだとメッセージが全てテキストとして入ってしまって使い勝手が悪いのですが、上手くフィルタ(?)を書いてあげればパースすることも出来るみたいです。

きちんと設定してあげるとかなり快適かつ漏れ無くに監視出来るようになりそうな気がします。素敵。

参考:
docker fluentd logging driver の基礎的な設定 - Qiita
docker-compose 3.4から追加されたExtension Fieldを使ってdocker-compose.yml でアンカー エイリアスを使う - Qiita

あらためまして、あけましておめでとうございます。
年末年始暇だった(ということにしたかった)ので、自作の言語的なものを作っていました。なんとなく動くような動かないようなな代物です。

一般的に、コンパイラやインタプリタなるものは 1. 字句解析 2. 構文解析 3. コンパイルor実行 という感じの流れで実行されているそうです。
実際は最適化とか色々挟まったり1と2が一緒に実行されたりするのでしょうけれど、ここでは3ステップということにしておきます。

字句解析というのは、雰囲気としては形態素解析みたいな感じです。日本語の文章を「日本語」「の」「文章」に分割するやつ。
これをするやつの事をトークナイザーとかレキシカルアナライザーとか呼ぶらしいです。
自作言語では元々go標準のtext/scannerを使っていたのですが、いまいちな感じがしたので自作しました。この記事でも自作のやつを使います。

で、構文解析というやつが係り受け解析に相当するやつで、さっきの例なら「の(日本語, 文章)」みたいな感じにツリー構造を作るイメージです。ASTってやつですね、たぶん。
これをするやつをパーサと言い、パーサを作るやつをパーサジェネレータと言います。yaccが有名。
この記事では、yaccのGO言語版であるgoyaccを使います。

完成版のプログラムはちょっと長いので、gistに上げてあるものを見てください。
この記事で書くプログラムよりもちょこっとだけ高度になってます。

必要なものを入れる

とりあえず、必要になるgoyaccを入れましょう。

$ go get golang.org/x/tools/cmd/goyacc

この記事のプログラム通りにやるのならgithub.com/macrat/simplexerも入れてください。

$ go get github.com/macrat/simplexer

使うものを定義する

この記事では、簡単な計算機を作ってみることにします。
数値は実数型だけで、演算子は四則演算だけ。複雑になっても作り方は変わらないので、多分これだけで十分です。

というわけで、ここで作るプログラミング言語(?)にある要素は、数値と演算子の二つだけです。
この要素のことを、トークンと呼びます。トークナイザーでソースコードからトークンを切り出して、パーサでトークン同士を繋ぐ感じ。

で、二種類のトークンを入れるための構造体は以下のような感じにしてみました。
ちなみに、このプログラムの拡張子は .y とか .go.y にすると良いようです。純粋なgoではないので注意。

%{
package main

import (
	"fmt"
	"io"
	"os"
	"strconv"
	"strings"

	"github.com/macrat/simplexer"
)

type Expression interface {
	Calc() float64
}

type Number float64

func (n Number) Calc() float64 {
	return float64(n)
}

type Operator struct {
	Left     Expression
	Operator string
	Right    Expression
}

func (s Operator) Calc() float64 {
	switch s.Operator {
	case "+":
		return s.Left.Calc() + s.Right.Calc()
	case "-":
		return s.Left.Calc() - s.Right.Calc()
	case "*":
		return s.Left.Calc() * s.Right.Calc()
	case "/":
		return s.Left.Calc() / s.Right.Calc()
	}
	return 0
}

%}

最初と最後に %{ %} が付いていることに注意してください。yaccのおまじないらしいです。
これで囲われた範囲は生のC言語とかgo言語として扱われ、それ以降はyaccのルールを記述してある場所だと認識されます。なので、忘れずに入れておいてください。

構造体の方ですが、 Number が数値を入れるやつ、 Operator が演算子を入れるやつです。
それぞれ Expression インターフェースを実装してあって、計算出来るようになってます。

Operator Expression を内部に持つことで、ツリーのような構造が出来上がることがお分かり頂けるかと思います。

ちなみに面倒臭かったので構文木を構成する構造体をそのまま計算出来るようにしていますが、実際コンパイラを作るときはそうじゃない方が扱いやすいのかもしれません? あんまり自信がありません。

トークンのタイプを定義する

トークンを入れる構造体は作りましたが、肝心のトークンにはどんなものがあるのかをyaccにまだ伝えていません。というわけで、その部分を作ります。

%union{
	token *simplexer.Token
	expr  Expression
}

%type<expr> program expression operator
%token<token> NUMBER L1_OPERATOR L2_OPERATOR

%left L1_OPERATOR
%left L2_OPERATOR

なんとなくこん感じ。

%union というやつで、トークン置き場としてどんな型を使うかを構造体のような雰囲気で指定します。雰囲気というか内部的にもそのものらしいです。
トークナイザが取得したトークンは、この構造体の中のどれかの変数に入れられてゆきます。

で、どのトークンをどの変数に入れれば良いかという定義が %type というやつで行なわれています。
今回は変数の型を気にする必要が無かったので、全部 expr 変数に突っ込んでいます。

次の行の %token というのは、トークンに割り振るためのIDを決めるためのものです。
%type で定義したトークンはyaccの中でしか使わなかったのですが、 %token で定義したものはトークナイザから送られてくるトークンになります。
ここでは、数字を意味する NUMBER と、足し算引き算の L1_OPERATOR 、かけ算割り算の L2_OPERATOR を定義しています。
三つともそのままでは計算出来ないので、expr変数ではなく token 変数に入れるようにしてあります。

次のブロックの %left というやつは、演算子の優先順位と結合規則を定義しています。
ここで定義しているのは、L2_OPERATORはL1_OPERATORよりも優先されることと、どちらも左結合であるということです。
左結合というのは、 1 + 2 + 3 (1 + 2) + 3 として処理されるということです。 %right にすると右結合である 1 + (2 + 3) な感じに処理されます。

構文を定義する

いよいよyaccの本体(?)、構文の定義をします。
先ほど定義したトークンがどんな順番で繋がるのかを、なんとなくBNFっぽい記法で書いていきます。

こんな感じ。

%%

program
	: expression
	{
		$$ = $1
		yylex.(*Lexer).result = $$
	}

expression
	: NUMBER
	{
		f, _ := strconv.ParseFloat($1.Literal, 64)
		$$ = Number(f)
	}
	| operator
	{
		$$ = $1
	}

operator
	: expression L2_OPERATOR expression
	{
		$$ = Operator{
			Left: $1,
			Operator: $2.Literal,
			Right: $3,
		}
	}
	| expression L1_OPERATOR expression
	{
		$$ = Operator{
			Left: $1,
			Operator: $2.Literal,
			Right: $3,
		}
	}

%%

今回は %% で始まって %% で終わっていることに注意してください。この範囲が構文定義ですよ、という感じです。
ちなみに、最後の %% の後はまたCとかgoとかの普通のプログラミング言語のエリアに戻ります。

さて、定義を上から順に見ていきます。
最初のブロックは、 programm は1つの expression ですよ、みたいな感じです。
続く波括弧の中で、ルールが適用されたときの動作を定義しています。
ここでは、1番目のトークン( $1 )をそのまんま戻り値( $$ )に入れて、あとLexer(あとで作ります)のresult変数に結果をセットする。という感じ。

次のブロックで、 expression NUMBER operator のどちらかであるということを定義しています。
NUMBERは *simplexer.Token の変数であるということを先ほど定義してあるので、そのメンバである Literal を取り出すことが出来ます。中身はトークンの生の文字列です。
これをParseFloatして、 Number 型に変換しています。

最後のブロックは operator の定義。これまでと同じ、見たまんまです。

これで、パーサ部分の定義は完了です。

トークナイザの準備

次に、パーサにトークンを流し込む部分を作ります。流し込みつつ、ついでに結果を受け取る部分も持たせてしまいます。
さっき出てきた Lexer というやつがそれです。

type Lexer struct {
	lexer        *simplexer.Lexer
	result       Expression
}

func NewLexer(reader io.Reader) *Lexer {
	l := simplexer.NewLexer(reader)

	l.TokenTypes = []simplexer.TokenType{
		simplexer.NewRegexpTokenType(NUMBER, `-?[0-9]+(\.[0-9]+)?`),
		simplexer.NewRegexpTokenType(L1_OPERATOR, `[-+]`),
		simplexer.NewRegexpTokenType(L2_OPERATOR, `[*/]`),
	}

	return &Lexer{ lexer: l }
}

func (l *Lexer) Lex(lval *yySymType) int {
	token, err := l.lexer.Scan()
	if err != nil {
		fmt.Fprintln(os.Stderr, err.Error())
		os.Exit(1)
	}
	if token == nil {
		return -1
	}

	lval.token = token

	return int(token.Type.GetID())
}

こんな感じです。

全体の流れとしては、 NewLexer 関数で Lexer の準備をして、 Lex 関数でトークンを一つずつ取り出しながら構文解析をするという感じ。
Lex 関数は戻り値でトークンのIDを返しつつ、引数で渡ってきたポインタの先(さっき %union で定義した構造体)にトークンの中身を入れます。

simplexer.Lexer をほぼそのまま使うので、あんまり複雑な部分は無いと思います。
強いていえば、 simplexer.NewRegexpTokenType に先ほど定義したNUMBERとかL1_OPERATORとかの定数を渡していることに注意してください。
先ほどの定義はyaccに使うトークンの種類を伝えると共に、int型の定数を定義する機能も持っています。
simplexerはが返すトークンはintで識別子を持てるので、yaccが生成したIDをそのまんま渡してあります。

p.s. 2018-01-10

本日の更新で、 simplexer.NewTokenType simplexer.NewRegexpTokenType に、 Token.Type.ID Token.Type.GetID() に変更になりました。
サンプルは全て修正後のものになってます。

正規表現使うやつだけじゃなくて、完全一致しかさせないやつとかも作ったのでちょっと効率が良くなったりする、はず。たぶん。

で、あともう一個。エラー処理の関数を作ります。

func (l *Lexer) Error(e string) {
	fmt.Fprintln(os.Stderr, e)
}

Lex の中にあるエラー処理はトークン解析中のエラー、こっちはパース中のエラーです。
1 + abc に反応するのが前者で、 1 + + 2 に反応するのが後者な感じ。
ここで定義したものは行番号と何文字目かが出るだけですが、gist版ではもうちょっと綺麗な表示をさせています。

実行!

ここまでで、(多分)計算機が完成しました。
というわけで、メイン関数を書いて実行します。

func main() {
	lexer := NewLexer(strings.NewReader("1 + 2 * 3 - 4 / 5"))

	yyParse(lexer)

	if lexer.result != nil {
		fmt.Println(lexer.result)
		fmt.Println("=", lexer.result.Calc())
	}
}

こんな。
yyParse という関数がgoyaccのエントリーポイントになります。

コンパイルする時は、 goyacc コマンドでソースコードを生成してから、 go コマンドでコンパイルします。

$ goyacc test.go.y
$ go build y.go

$ ./y
{{1 + {2 * 3}} - {4 / 5}}
= 6.2

それっぽいパース結果と共に、良い感じの計算結果が表示されました。やったね!

ちなみに、goyaccの -o オプションに出力先のファイル名を渡せば y.go 以外の名前で出力出来ます。

計算が出来るということは、頑張れば代入したり関数定義したりも出来ます。
というわけで、自分の好きな言語を作れるようになった、はずです。私の言語は言語仕様が雑すぎて詰みつつありますが…。
結構簡単かつかなり楽しいので、わりとおすすめです。オレオレ言語、たのしいよ。

参考: goyaccで構文解析を行う - Qiita

あけましておめでとうございます

keyword: 謹賀新年
[ << ] [ 2 ] [ 4 ] [ >> ]