読者です 読者をやめる 読者になる 読者になる

akms道東

ITイベント,勉強会への参加記録や趣味のことが書いてあるブログです.

td-agent でログ全文は S3 へ保存しつつ、特定文字列がマッチした場合 slack に通知する方法

はじめに

タイトルままの個人的な忘備録です。 td-agentのインストールなどはたくさん記事があるのでてけとーに見てください。 slack通知に利用したプラグインは以下のようにインストールしました。

td-agent-gem install fluent-plugin-slack

今回の設定は特定ログファイルを長期保管用にS3へアップロードしつつ、特定文字列を含むログが出力された場合、slackに通知するものです。

td-agentの設定ファイル

さっそく利用したtd-agentのコンフィグ例をもとに解説していきます。 そのままでは利用できませんので、適宜必要なところは書き換えてご利用ください。

sourceの設定

まずtd-agentを利用して保存したいファイルのソースを定義します。

今回はtailプラグインを使って読み込み続けて、変更があれば追従するようにしています。 またpos_fileを利用することで、何らかの理由でファイルが読み込めなくなった場合でも続きからロードできるようにしてあります。

<source>
  @type tail
  path TAIL_TARGET_FILE_PATH
  pos_file POS_FILE_PATH
  tag log
  format none
</source>

matchの設定

次に上記sourceから、S3に保存する用と、特定文字列をフィルターするためにラベル付けをする用にsourceで得たデータを分岐させて処理しています。

まずはS3にログのメッセージをそのまま、まとめて送信する設定です。

ここでformat single_valueにしているのはsourceからmessageがkeyとなっているものだけを抜き取り、そのまま送信するためです。 要はログをそのまま保存したいのでsingle_valueを使っています。

またS3への保存形式をstore_as textとすることで、text/plainでS3へ保存するようにしています。

次に2つめの処理で、sourceから渡ってきたデータにラベルを付与して、次のフィルターをするための処理に分岐させています。

<match log>
  @type copy
  <store>
    @type s3
    buffer_type file
    buffer_path BUFFER_FILE_PATH
    flush_interval FLUSH_INTERVAL_TIME
    s3_bucket TARGET_AWS_S3_BUCKET_NAME
    s3_region TARGET_BUCKET_REGION
    path "TARGET_S3_OBJECT_PATH"
    store_as text
    format single_value
    flush_at_shutdown
    time_slice_format
  </store>

  <store>
    type relabel
    @label @rewrite
  </store>
</match>

filter

さて、前のmatch処理でlabel着けをしたものに対して、実際にフィルタリングを行って、マッチしたもののみ、slackに通知するのは下記のような設定になります。

まず、filterセクションでフィルタリングをkeyがmessageのものに対して行います。

今回はfilterという文字列が含んでいるものだけ通知するようにしたいので、regexp1 message filterという設定になります。 その後、フィルターした文字列をslackの特定チャンネルに通知するための設定をmatchセクションに書いています。

これでログ全文を保存しつつ、特定文字列がマッチした場合slackに通知することができます。

<label @rewrite>
  <filter>
    @type grep
    regexp1 message filter
  </filter>
  <match>
    @type slack
    webhook_url https://YUOUR_SLACK_API_URL
    channel CHANNEL_NAME
    username USERNAME
    icon_emoji :ICON_EMOJI:
    flush_interval FLUSH_INTERVAL_TIME
    flush_at_shutdown
  </match>
</label>

設定全文

ここまでの設定を一つにまとめたものを下記に記載しておきます。 設定の説明の最初にも記載しましたが、このままでは利用できないので適宜書き換えて利用していただければと思います。

<source>
  @type tail
  path TAIL_TARGET_FILE_PATH
  pos_file POS_FILE_PATH
  tag log
  format none
</source>

<match log>
  @type copy
  <store>
    @type s3
    buffer_type file
    buffer_path BUFFER_FILE_PATH
    flush_interval FLUSH_INTERVAL_TIME
    s3_bucket TARGET_AWS_S3_BUCKET_NAME
    s3_region TARGET_BUCKET_REGION
    path "TARGET_S3_OBJECT_PATH"
    store_as text
    format single_value
    flush_at_shutdown
    time_slice_format
  </store>

  <store>
    type relabel
    @label @rewrite
  </store>
</match>

<label @rewrite>
  <filter>
    @type grep
    regexp1 message filter
  </filter>
  <match>
    @type slack
    webhook_url https://YUOUR_SLACK_API_URL
    channel CHANNEL_NAME
    username USERNAME
    icon_emoji :ICON_EMOJI:
    flush_interval FLUSH_INTERVAL_TIME
    flush_at_shutdown
  </match>
</label>

おわりに

簡単ですが、タイトル通りの用途の設定をまとめました。

td-agent簡単に設定できて、便利なのでこれからもどんどん使っていきたい。

インフラチームでペア作業始めてみて3週間たったので3回目のふりかえりをした

はじめに

前回の最後に月末のふりかえりをまとめると書きましたが、今週のふりかえりで思った以上にネタがあったのでその記録です。

前回までのあらすじ

ふりかえり

良かったこと

  • 技術に関して新しい知見がたまった
  • ペア作業のペースが掴めてきた

    悪かったこと

  • 作業時間の見積もりがあまい
  • 作業途中で集中力が切れる
  • 丸一日ペア作業の場合1時間に1回10分の休憩でも疲れる

    改善したいこと

  • 作業途中で集中力が切れた場合はペアに一声かけて都度リフレッシュする
  • 調査系(ペアのお互いに知識がない項目)の作業についてはタイムボックスを切って、各々で調査をする
  • 悩んでいることは一人で黙って熟慮しないで声にだす

感想

今回は1週目、2週目と比べて大幅に作業時間が長かったこともあり、ふりかえりのネタも増えています。

特に、ペア作業中の集中力の継続やリフレッシュするタイミングについては今後もいろいろ試して改善していければなと考えています。

また実際に作業している中で1人でやっている場合とペアでやる場合は作業のペース配分が変わるので、そこで普段ではない疲労感の増加などが影響しているのかなと思いました。

調査する必要があるものについては5分から10分程度でタイムボックスを切って各々調査し、設計などの議論を行うなどがスムーズに進めれる方法ではないかということになりました。

作業で手が止まってお互いに考えていることを言わずに各々で考えてしまっていることもあるので、そこも改善しようということになりました。

今週は長めに時間が確保できましたが、1週間で取れる時間は短いことが多いので、今後はその中でさらに効率的にタスクを遂行するには何が必要か、どういう進め方がチームに合っているかを見れるようにしていきたいと考えています。

おわりに

3週目ということと、いつも以上に長い時間ペア作業していたことで良いペースでタスクを進めることができました。

次回こそは月次のふりかえりの内容を書く予定です。

インフラチームでペア作業始めてみて2週間たったので2回目のふりかえりをした

はじめに

前回は1週間目のふりかえりだったのでさらに2週間目の終わった時点でのふりかえりです。

ふりかえり

前回と同様に良かったこと、悪かったこと、改善したいことで上げてみました。

良かったこと

  • AWS慣れてきた

悪かったこと

  • とくに無し

改善したいこと

  • とくに無し

感想

作業内容的に1週目の作業の続きだったので特にこれといって悪かったこと、改善したいことは出なかったという感じです。

ふりかえり方法が簡易なものなので、このふりかえり自体を改善する必要はありそうだなと思いました。

現在の作業では主にAWSを利用した仕組みの構築を行っているのですが、その中で「AWSが意外と複雑だった(認証権限やサービス間の連携など)」や「いきなり応用編のような使い方だったのでついていくのがギリギリだった」などの感想もいただきました。

AWSの基礎知識についてもこのペア作業で、できる限り共有しているつもりだったのですが、まだまだのようなのでこれは個人的には改善していきたいことだなと思いました。

またインフラチームではプログラミング能力の差が大きくコードを書く必要がある箇所に関して、現状ペアで進めるのは難しいということもあります。

時間があれば最初から最後まですべてペアで進めたいところですが、まだまだ検証期間であり確保できる時間が少ないので上記のようなコードを書くなど部分的には個人タスクになってしまっています。

今後は別施策として、チームのプログラミング能力が上がるような施策を実施していこうと考えています。

おわりに

チーム全体で始めて2週間が終わり、まだペア作業をやめたペアもないのでこのままチームに定着していくと良いなと思っています。

また月末にはチーム全体でのふりかえりがあるので次回はそのふりかえり実施後にブログにまとめようと思います。

DataPipelineでTaskRunnerを利用したい場合の忘備録

はじめに

AWSのDataPipelineでTaskRunnerを利用したい場合に必要なセットアップについて自分用メモ。

TaskRunnerを実行するインスタンスはOSがubuntuだったので今回はubuntuで設定した内容です。

ubuntu環境へのTaskRunnerの設定

  • Javaのインストール
    • sudo apt install default-jre
  • インストールされたjavaのバージョン確認(open jdk が1.6以降か確認)
    • java -version
  • taskrunnerをダウンロードする
    • wget https://s3.amazonaws.com/datapipeline-us-east-1/us-east-1/software/latest/TaskRunner/TaskRunner-1.0.jar
  • mysql-connerctor-java-bin.jarをダウンロードする
    • wget https://s3.amazonaws.com/datapipeline-prod-us-east-1/software/latest/TaskRunner/mysql-connector-java-bin.jar
  • taskrunnerを実行するインスタンスに対してIAMロールを付与する
    • IAMロールに着けるポリシーは下記のAWSが用意しているものを付与
      • AmazonEC2RoleforDataPipelineRole
      • 他に必要なものは適宜付与
  • datapipeline側の設定変更
    • Activityの設定で、runsOnの設定ではなくworkerGroupを設定する。runsOnの設定がある場合、workerGroupの設定があっても無視される
    • workerGroupの値はstringであれば rds-to-s3やwg-123dafasfdの形式で問題ない
  • DataNodeの設定でも同様にworkerGroupを設定する
  • 設定完了後はアクティベートせずに先に下記を実施する
    • taskrunnerを起動する
      • java -jar TaskRunner-1.0.jar --workerGroup=先に指定したworkerGroup名 --region=実行するタスクをプルする対象のサービスリージョン(基本的に日本だと思うのでap-northeast-1) --logUri=s3://taskrunnerの実行ログを置くpath &
    • 行末につけた&はあってもなくても大丈夫。ただバックグラウンドで起動しておきたかったのでつけただけ
  • 最後にdatapipelineをアクティベートして動作していることを確認した

注意点

今回はホームディレクトリに直接両方ともダウンロードして試したが問題なく実行できた。 ただし公式のドキュメントの環境設定手順をみるとディレクトリを作成して、ファイルをダウンロードする必要があるらしい。

バックグラウンドでTaskRunnerを起動しておいて、1時間に1回実行するDataPipelineの検証していると3回目の実行時点でTaskRunnerのプロセスがいなくなっていたので、ここら辺はプロセスのデーモン化やプロセスの監視など何かしら対策が必要そう。

おわりに

基本的はこちらの公式ドキュメントを参考に実施しました。

ただし必要なファイルのダウンロード元のリンクについては変更されていた模様。

公式ドキュメントのリンク先飛んでもリダイレクトされて目的のページにたどり着けなかった。。。 DataPipelineを使うケースは今後ほとんどないかもですが、念のための忘備録でした。

インフラチームでペア作業始めてみて1週間たったのでふりかえりをした

はじめに

前回のあらすじは下記リンクの通り

始めて1週間たったのでふりかえりをしてみました。 今回は私とペアだった人と2人での振り返りでした。 チーム全体での振り返りは月一回のふりかえり会で実施予定です。

ふりかえり

今回はとくにふりかえり手法などを取らずに、良かったこと、悪かったこと、改善したいことをお互いに話し合っていきました。 その中でいくつかピックアップして下記にまとめました。

良かったこと
  • タスクに必要な技術の知識で足りないところを補えた
  • ペアで作業をするコミュニケーションについて負担はとくになかった
悪かったこと
  • 図を描いたりして視覚的に共有できるツールが最初はなかった
改善したいこと
  • 長い時間で作業する場合は適度に休憩をとる
    • 1時間に1回10分のペースで休憩をとる

感想

振り返りからの個人的な感想ですが、ペア作業でコミュニケーションを取りながら進めることが負担だと思う人もいるので不安でした。しかし今回ペアを組んだメンバーにはそれがなかった点が一番ホッとしました。 また図を描くなどの視覚的に共有することについては現在、ノートとペンで解消しましたが、今後はnuboardを導入してみるのもありかなと思っています。

また現在は知識量に差があるので、ドライバーは生徒、ナビは教師のような役割で作業になってしまっているので、今後進むにつれてこれもタイムボックスなどで交代するようにしてみるなど試したいと思います。

おわりに

まだまだ始めて1週間ですが、ふりかえり含めて無事に進めているので週次での振り返りや月次でのチーム全体での振り返りなどを参考にしながらどんどん改善して進めていければと考えています。

インフラチームでペア作業を始めてみた

はじめに

現在Joy,Incという書籍の読書会を社内で開催しています。 読書会の内容については下記記事にまとまっています。 takubon.hatenablog.com

この書籍の中でプログラム以外もペアで作業して進めているということの紹介があり、読書会でディスカッションをしている中でインフラチームで試してみるとよいのではないかとなりました。

課題

業務内容によってはペアで作業を行うこともありましたが、普段はメンバー各々がタスクを取ってやるという進め方です。 進め方としては特に問題はなかったのですが、各メンバーの得意なことや知識領域についてばらつきがあり、それを補うためにもチーム内での知見の共有も月一で行っていました。 しかしどちらかというと話を聴くだけの会になってしまっています。

そこでJoy,Incの中であるようにより学習のスピードをあげて、手を動かしながらお互いの知見を共有しあいながら、タスクを進めることができれば個人の成長もそうですが、もっとチームとして成果を出せるようになるのではと考えてチームに提案してみました。

進め方

現在はまだ始めたばかりなので、今後さらに改善が必要だと考えていますが、現在は以下のように進めています。

  • ペアは固定せず、タスク毎
  • タスクは1週間単位で計画して進める
  • まず担当するタスクを決める
  • お互いに1週間でタスクに出せる時間を決める
    • 出せる時間が少ない方に合わせる
  • それぞれタスクを細分化して、どれくらい時間が必要か見積もる
  • 見積もった時間から1週間にタスクに出せる時間分を取る
  • スケジュールにタスクを登録して実際にペアで作業を進める
  • 1週間終了後の振り返り(現在はまだはじめて1週間たっていないので予定)

始めてみて

まだまだ始めて1週間もたっていませんが、感覚としては良さそうな空気感なので継続してできるのではと感じています。 個人的にはペアプロで学びながらタスクを進めていくことも体験しているので、この方法で続けていければと考えています。 もちろんまだすべてのタスクをペアでやっているわけではありません。進めていくなかでタスクの種類によって向き不向きがあるのかなとも思っています。

おわりに

今回は始めてみたということで記録に残しておこうと思い書いています。 今後、途中でやめたになるか、継続しているかここで報告できればと思います。

新装版 達人プログラマーとアジャイルプラクティスを読んだ

はじめに

約10か月ぶりの更新です。ラズパイのやってみたネタも更新する時間を見つけて書きたいのですが(下書きには保存してある)今回は最近読んだ本、読んでいる本についてです。

新装版 達人プログラマー

まずは新装版が出た「達人プログラマー」、技術書の歩き方勉強会でも取り上げられていました。

今まで読んだことがなかったのですが、新装版が出たということで購入しました。 内容については色々なブログに書かれていると思うので割愛しますが、普段コードをあまり書かない私でも仕事の中で実践することで改善できそうな事があってとても勉強になりました。

また上記勉強会にも参加して、学びを深めました。

アジャイルプラクティス

上述の技術書の歩き方勉強会での帰り際にいただいたので早速読みました。

開発プロセスへのXPやスクラムなどの導入というよりはスタンドアップミーティング等の具体的なプラクティスの導入について勉強になる一冊でした。 達人プログラマーと合わせて読むことで内容の理解が深まります。

またアジャイルプラクティスではそのプラクティスを導入したときにどのような気持ちになれるかや、導入したときに気をつけなければいけない点などが各プラクティスの最後に記載されています。

実際にプラクティスを導入した場合はその部分を参考にすることができます。

プロダクティブ・プログラマ

アジャイルプラクティスの次に何を読むか探していたところでこの一冊を見つけました。

監訳されたのが技術書の歩き方勉強会「達人プログラマー」編を開催された島田 浩二さんです。 監訳者あとがきでアジャイルプラクティスをおすすめ書籍として挙げられていたのもあり購入しました。

この本はまだあまり読めていないのですが効率的に開発を進めるための具体的な手法が各テーマ毎に記載されており、より手を動かす作業の効率化に特化した一冊になっている印象を受けました。

おわりに

最近読んだ、もしくは読んでいる本についてまとめました。 今年もそれなりに本は読んでいましたがあまり感想などは書けなかったので月末などに改めて今年読んだ本の感想など書きます。 ただその前に下書きのラズパイ記事を公開できるようにします。