akms道東

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

RDS for PostgreSQL のスロークエリログのファイルから開始時間、実行時間、終了時間を出すワンライナー

はじめに

タイトル通りの短い内容です。 また自分用の備忘メモです。

RDS for PostgreSQL でスロークエリログのファイルから開始時間、実行時間、終了時間を出すワンライナー

RDSでPostgreSQLを利用している中で、slowqueryのログをダウンロードして処理にどれくらい時間が掛かっているか出力します。

またログの時刻がUTCなのでJSTに変換するのと、durationから終了時刻を算出するところまで行います。

利用しているのは awkdate です。

macを利用している人は GNU date をインストールして利用してください。

awk '$1 ~/^[0-9]*-/ && $4 == "duration:" {a = $1" "$2; b=int($5 / 1000);"gdate --date \""a" 9hours\" \"+%Y-%m-%d %H:%M:%S\""|getline var; "gdate --date \""var" "b"seconds ago\" \"+%Y-%m-%d %H:%M:%S\""|getline val; print "start: "val" "$4" "$5" end: "var;close("gdate --date \""a" 9hours\" \"+%Y-%m-%d %H:%M:%S\"");close("gdate --date \""var" "b"seconds ago\" \"+%Y-%m-%d %H:%M:%S\"")}' postgresql_logfile_name
  • 実行結果
start: 2017-11-12 07:58:03 duration: 3230.013 end: 2017-11-12 07:58:06
以下略

start,end,durationのcsv形式で出す場合は以下のようにする

awk '$1 ~/^[0-9]*-/ && $4 == "duration:" {a = $1" "$2; b=int($5 / 1000);"gdate --date \""a" 9hours\" \"+%Y-%m-%d %H:%M:%S\""|getline var; "gdate --date \""var" "b"seconds ago\" \"+%Y-%m-%d %H:%M:%S\""|getline val; print val","var","$5; close("gdate --date \""a" 9hours\" \"+%Y-%m-%d %H:%M:%S\"");close("gdate --date \""var" "b"seconds ago\" \"+%Y-%m-%d %H:%M:%S\"")}' postgresql_logfile_name
  • 実行結果
2017-11-11 19:15:00,2017-11-11 19:15:09,9322.90
以下略

出力された結果を元にdurationの値をファイルでgrepすればクエリを確認することができます。

おわりに

RDS for PostgreSQLのスロークエリログ整形に使うワンライナーでした。

単純に解析するだけならツールなどはOSSなどでもあるようなので、そちらを使った方が早いかも。

エラーの原因解明にモブ調査してみた

はじめに

タイトル通りです。

最近話題になっている、モブプログラミングを取り入れて開発をしているチームのモブに混ざってエラーの原因調査を実施しました。

モブプログラミング自体についての説明はとくにしません。

今回は30分程度の作業だったので、短い感想の記録です。

背景としては開発チームがモブプログラミングで開発を進めており、インフラ絡みのエラーが発生していたのでインフラチームがそのモブに参加して原因調査を実施しました。

メンバーは全体で5名で開発3名、インフラ2名という構成でした。

やってみた感想

事前に私と開発チームの3名は下記リンクのようにモブプログラミングを体験しており、さらに開発チームは現在の作業もモブプロで進めており、経験があるという状態でしたがもう1名のインフラメンバーはモブ経験がありませんでした。

しかしながら、ペア作業の経験があったからかドライバーをしてもらいましたが問題なく作業を完了まで進めることができました。

感想を聴いたところ、最初の10分くらいは緊張したがあとはペア作業と同様で問題なく作業できたそうです。

モブ作業をしていて、良かったところとして、インフラ系の調査では一人が実際にサーバに入り、別の人が必要に応じてLBからの切り離しなどのオペを平行で進めることができるなど、 検証で必要な作業がよりスムーズに進めることができたなと思いました。

またアプリの挙動に合わせて検証が必要だったので、インフラメンバーだけでは検証の前にアプリ自体の挙動を正しく把握する必要があるなど、より時間がかかることも考えられましたが、開発チームとのモブ作業ではその部分が不要でディスカッションしつつ必要な動作確認ができるのでこの点もスムーズでいいなと思いました。

今回は実作業時間が短く、大きな課題となるような点は出てきませんでしたが、今後インフラチームでもモブプログラミングのようにモブオペレーションであったりモブ設計であったりといろいろ試してみて、向き不向きの検証をしていければなと思いました。

おわりに

今回は短いですが、モブプログラミングを実施しているチームにまざり、モブ調査を実施したという内容のまとめでした。

現在はインフラチームでペア作業でタスクを進めることを試していますが、さらに次のステップとしてモブオペレーションやモブ設計などタスクをモブで進めるのも良さそうだなと感じました。

インフラチームでペア作業始めてみて1ヵ月経過したので全体のふりかえりをした

はじめに

ペア作業を始めて2か月ほど経過し、ようやくチームでふりかえりの時間ができたので、その記録です。

チームのふりかえりとしてはとくにふりかえりフォーマットを利用せず、またあまり時間もとれなかったので感想ベースのふりかえりになりました。

また前提として定常業務ではなく、チームの施策として進めている作業についてペアで行っていました。

前回までのあらすじ

ふりかえり

以下は今回のチームでのふりかえりで出た感想です

  • チームの施策の進捗がさらに良くなった
  • 知識の共有ができた
  • やらなきゃだめというモチベーションにもなった
  • 単純に作業に関する知識だけでなく考え方にも影響があった
  • 作業内容によってはペア作業が向かないものもあるので、そういったとこでは無理にペアで行わない

上記のように前向きな意見が多かったので、このまま継続してペア作業は続けていくつもりです。

ただし、あくまでも現在のチームにあっているだけで、今後また何か状況が変わるとペア作業もなくなるという前提で進めています。

感想

今回のペア作業中に個人的に良かった点としてはスクリプトペアプログラミングからミドルウェアの選定、設定、ドキュメントの作成など幅広くペアで作業することができたのがとても良かったです。

とくにインフラとして行う作業はコードとして形に残るものが少ないのでドキュメント化などが重要ですが、それをペアで行うことでレビューの時間を短縮し、まとまったドキュメントを用意できたことなどが良かったです。

おわりに

全体でのふりかえり実施まで少し時間が経ってしまいましたが、実施できたのでまとめました。

現状は良い状態で続けていけそうなので、このまま継続していきますが、先述のとおり今後の状況次第ではペア作業もなくなります。

こういった実験とふりかえりができるのはとても良いことなので、今後はペア作業以外にも小さく試して、ふりかえるというのをチームの文化として定着させていけたらなと考えています。

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を使うケースは今後ほとんどないかもですが、念のための忘備録でした。