プラグイン開発者から見るfluentd v1.0の活用法

TD Tech Talk 2018 OSS Day

Transcript

1. プラグイン開発者から見るv1.0
   の活用法
   @joker1007 (Tomohiro Hashidate)
   

   View Slide

2. self.inspect
   @joker1007
   Repro inc. CTO
   やってること
   DB
   のスキーマ改善、データ仕様の変更
   fluentd
   を中心にしたデータフローの設計構築
   Bigquery
   やhive, presto
   を使ったバッチフローの設計構築
   インフラのコード化とメンテ
   Docker, ECS
   の利用環境を整備
   外向きの技術発表
   最近、ハンター業が忙しい
   

   View Slide

3. fluentd
   との関わり
   一昨年ぐらいから社内でデータフローを構築する基盤として
   採用
   それまでは余り触ってなかった
   ちょうど0.14
   が出たぐらいの時期
   主にアプリデータをBQ
   とS3
   に転送するために利用している
   0.14
   には比較的早めにアップデートして利用を開始
   現在1.0.2
   、そろそろ上げたい
   docker
   で運用している
   

   View Slide

4. プラグイン開発とメンテナ業
   使い始めると色々と不満が出てくるので、PR
   を出したり自分で作
   ったりすることになる。
   割とメンテを諦めているプラグインがいくつかあるようなので、
   PR
   を何度か出した上で、話をしてコミット権を頂くことになった
   ものがいくつか。
   fluent­plugin­cloudwatch­put (
   作者)
   fluent­plugin­filter­single_key (
   作者)
   fluent­plugin­bigquery (
   メンテナ)
   fluent­plugin­remote_syslog (
   メンテナ)
   fluent­plugin­dd (
   メンテナ)
   その他、PR
   出したりしたものがいくつか。
   

   View Slide

5. fluent­plugin­bigquery
   メインで触る人が転々と移り変わって、今私が良く弄っている。
   いかつい
   複雑
   総ダウンロード数が多い
   開発する上で知見をいくつか獲得したので、その辺を元に話を。
   そういえば、さっきv1.2.0
   の話でretry
   方法の改善案が上がってて期
   待している。
   現在、 r
   e
   t
   r
   y
   _
   s
   t
   a
   t
   e
   _
   c
   r
   e
   a
   t
   e
   という内部API
   を読んで強制中断して
   いるケースがある。
   

   View Slide

6. プラグイン開発者から見たv1.0
   の利点
   parser, formatter, buffer
   が明確に分離され、
   config
   セクションとして独立したこと
   今迄、input
   やoutput
   プラグインの中でフラットに設定が記述され
   ていて、標準的なやり方が無かった。
   v1.0
   になることで、それらを選択設定する方法の標準ができたの
   で、各プラグインに対するポータビリティがめっちゃ向上した。
   filter
   で頑張って加工したりmixin
   を突っ込まなくても、データの入
   出力に任意のフォーマットを利用できる。
   

   View Slide

7. プラグイン開発者がやるべきこと
   独自のパース処理やフォーマット処理ではなくplugin helper
   を利用
   する
   f
   o
   r
   m
   a
   t
   t
   e
   r
   _
   c
   o
   n
   f
   i
   g = c
   o
   n
   f
   .
   e
   l
   e
   m
   e
   n
   t
   s
   (
   "
   f
   o
   r
   m
   a
   t
   "
   )
   [
   0
   ]
   @
   f
   o
   r
   m
   a
   t
   t
   e
   r = f
   o
   r
   m
   a
   t
   t
   e
   r
   _
   c
   r
   e
   a
   t
   e
   (
   u
   s
   a
   g
   e
   : '
   o
   u
   t
   _
   b
   i
   g
   q
   u
   e
   r
   y
   _
   f
   o
   r
   _
   l
   o
   a
   d
   '
   ,
   c
   o
   n
   f
   : f
   o
   r
   m
   a
   t
   t
   e
   r
   _
   c
   o
   n
   f
   i
   g
   ,
   d
   e
   f
   a
   u
   l
   t
   _
   t
   y
   p
   e
   : '
   j
   s
   o
   n
   '
   )
   d
   e
   f f
   o
   r
   m
   a
   t
   (
   t
   a
   g
   , t
   i
   m
   e
   , r
   e
   c
   o
   r
   d
   )
   @
   f
   o
   r
   m
   a
   t
   t
   e
   r
   .
   f
   o
   r
   m
   a
   t
   (
   t
   a
   g
   , t
   i
   m
   e
   , r
   o
   w
   )
   e
   n
   d
   

   View Slide

8. v1.0
   のoutput
   プラグイン開発
   最も大きく機能が変わったのがoutput
   プラグインのAPI
   metadata
   を利用したchunk
   をサポート
   これによりTimeSliced
   の区別が無くなる
   delay commit
   のサポート
   chunk_limit_records
   のサポート
   加えて各種プラグインヘルパーにより開発がとても楽になった。
   

   View Slide

9. chunk with metadata
   v1.0
   からmetadata
   をキーにしてbuffer chunk
   を分けられる様になっ
   た。
   metadata
   とは以下のものを差す。
   tag
   time
   record
   のproperty
   そして、キーに利用したメタデータはconfig
   上でplaceholder
   として
   利用可能になる。
   

   View Slide

10. fluent­plugin­bigquery
    の例
    <
    m
    a
    t
    c
    h b
    q
    .
    {
    h
    t
    t
    p
    _
    l
    o
    g
    s
    ,
    a
    p
    p
    _
    l
    o
    g
    s
    }
    >
    @
    t
    y
    p
    e b
    i
    g
    q
    u
    e
    r
    y
    t
    a
    b
    l
    e $
    {
    t
    a
    g
    [
    1
    ]
    }
    $
    %
    Y
    %
    m
    %
    d
    s
    c
    h
    e
    m
    a
    _
    p
    a
    t
    h s
    c
    h
    e
    m
    a
    s
    /
    $
    {
    t
    a
    g
    [
    1
    ]
    }
    .
    j
    s
    o
    n
    <
    b
    u
    f
    f
    e
    r t
    a
    g
    , t
    i
    m
    e
    >
    t
    i
    m
    e
    k
    e
    y 1
    d
    <
    /
    b
    u
    f
    f
    e
    r
    >
    <
    /
    m
    a
    t
    c
    h
    >
    

    View Slide

11. プラグイン側の対応方法
    p
    l
    a
    c
    e
    h
    o
    l
    d
    e
    r
    _
    v
    a
    l
    i
    d
    a
    t
    e
    !
    と e
    x
    t
    r
    a
    c
    t
    _
    p
    l
    a
    c
    e
    h
    o
    l
    d
    e
    r
    s
    を利用する
    p
    l
    a
    c
    e
    h
    o
    l
    d
    e
    r
    _
    p
    a
    r
    a
    m
    s =
    "
    p
    r
    o
    j
    e
    c
    t
    =
    #
    {
    @
    p
    r
    o
    j
    e
    c
    t
    }
    /
    d
    a
    t
    a
    s
    e
    t
    =
    #
    {
    @
    d
    a
    t
    a
    s
    e
    t
    }
    /
    .
    .
    .
    省略"
    p
    l
    a
    c
    e
    h
    o
    l
    d
    e
    r
    _
    v
    a
    l
    i
    d
    a
    t
    e
    !
    (
    :
    b
    i
    g
    q
    u
    e
    r
    y
    , p
    l
    a
    c
    e
    h
    o
    l
    d
    e
    r
    _
    p
    a
    r
    a
    m
    s
    )
    p
    r
    o
    j
    e
    c
    t = e
    x
    t
    r
    a
    c
    t
    _
    p
    l
    a
    c
    e
    h
    o
    l
    d
    e
    r
    s
    (
    @
    p
    r
    o
    j
    e
    c
    t
    ,
    c
    h
    u
    n
    k
    .
    m
    e
    t
    a
    d
    a
    t
    a
    )
    d
    a
    t
    a
    s
    e
    t = e
    x
    t
    r
    a
    c
    t
    _
    p
    l
    a
    c
    e
    h
    o
    l
    d
    e
    r
    s
    (
    @
    d
    a
    t
    a
    s
    e
    t
    ,
    c
    h
    u
    n
    k
    .
    m
    e
    t
    a
    d
    a
    t
    a
    )
    

    View Slide

12. metadata
    とplaceholder
    によりforest
    プラグインが
    不要になる
    ただし、どの項目でplaceholder
    が利用できるかは
    プラグインの対応状況によって変わる
    プラグイン開発者は使えそうな所にガンガン
    placeholder
    サポートを追加して欲しい
    

    View Slide

13. helper
    によるデータ加工方法の共通化
    よく利用する処理がplugin helper
    として再利用可能になり、config
    の項目も標準化されたため、プラグインでのデータ加工が簡単に
    なった。
    利用しやすいものは以下。
    extract (
    レコードからタグや時間として利用するものを抽出す
    る)
    inject (
    レコードにタグやタイムスタンプ等のメタデータを注
    入する)
    record_accessor (
    レコードの中のデータを文字列のフォーマ
    ットを利用して取得する)
    これらを利用することで、プラグイン独自に対応しなければいけ
    ない範囲はかなり少なくなる
    

    View Slide

14. 新しいプラグインのAPI
    を利用することで、かつて
    利用されていたmixin
    モジュールの大半は不要にな
    ったり、似た設定や実装が氾濫することがなくなる
    

    View Slide

15. その他プラグイン開発で意識すること
    多機能化はダメ絶対！
    fluent­plugin­bigquery
    は悪い例
    私がload
    とか追加してしまったので、整理したい……
    組込のhelper
    やその組み合わせで解決できないか考える
    thread
    や子プロセスを利用する場合のハンドリング等
    大分便利になってるので、plugin_helpers
    以下は一通り読
    んでおくと良い
    無理にマルチバージョンサポートをしない
    0.12
    系はそろそろ機能追加等を打ち切って良いと思う
    設定の互換性は維持できても、同一のコードベースでは
    placeholder
    等が使えない
    どうにもメンテできない場合は、人に譲る
    

    View Slide

16. まとめ
    v1.0
    は開発者にとってめっちゃ便利になってる！
    まだ0.12
    系を利用しているなら、頑張って上げる価
    値がある
    特にプラグイン自体の構造をシンプルに維持したま
    ま柔軟性を上げられる点が大きい
    自分のプラグインの改修や、PR
    を出すチャンスも
    

    View Slide