2019/03/15TweetPocket以前ランサーズエンジニアブログ(https://engineer.blog.lancers.jp/2018/12/lancers-capybara/)にて分析基盤について書きましたが、各サーバ(App)ログをLogサーバへ収集、S3にシンクする方法があまりにも画期的だったのでブログします。#イベントログを送信するときのタイムアウト時間。#サーバー障害回復を受け入れるまでの待機時間。#ハートビートパッカーの間隔。#サーバー障害を検出するために使用されるしきい値パラメーター。#サーバーの障害を検出するために使用されるハードタイムアウト。#イベントログを送信するときのタイムアウト時間。#サーバー障害回復を受け入れるまでの待機時間。#ハートビートパッカーの間隔。#サーバー障害を検出するために使用されるしきい値パラメーター。#サーバーの障害を検出するために使用されるハードタイムアウト。@backup</store></match></label>今回対象のログはnginxのアクセスログとエラーログが対象となります。Logサーバへ集約している理由としてはログ欠損がないようにfluentdで5秒ごとに転送しています。formatはltsv必須。Queueに存在できるchunkの最大数、これに達するとログを受け取れなくなる</template></match></label>1行目のリソース監視している部分では、fluentdにはin_monitor_agentというfluentdの内部状態を監視するための標準組み込みインプットプラグインがあります。上記のように指定したIPアドレスとポートでWebサーバーが稼働し、fluentdの内部情報を参照できるようになります。pluginだけではプレースホルダに対応できないので、fluent-plugin-forestプラグインを使ってあたかも対応できるようにしています。75行目のpathでも日時で全ての対象ログを引っ張ってきているので対象のログ指定することはなく、短いコードで書けます。AWSfluentdadachin1989年生まれのSRE。ホスティングから大規模なアドテクなどのインフラエンジニアとして携わり、AnsibleやTerraformでのインフラコード化を推進。副業では数社サーバー保守、未経験によるエンジニアのメンターなども実施している。「脆弱性スキャナVuls」のOSS活動もしており、自称エバンジェリスト/技術広報/テクニカルサポート/コントリビュータでもある。レイテンシ、パフォーマンス、モニタリング、緊急対応、インフラコード化、リファクタリング、セキュリティ強化、新技術の検証、Docker開発環境の提供、AWSでのインフラ構築、ECS(Fargate)、Wordpressによるコーポレートサイトの修正、メンター、分析基盤の運用を担当している。コメントデータの処理方法の詳細はこちらをご覧ください。