ログに残したくない情報 Webアプリケーションを開発していると時々生のままではログに残したくない情報ってありますよね。 パスワード、クレジットカード番号やCVCなんかは残したくないものの代表じゃないかと思います。 よくやる方法 initializersの中でこういうコードを入れるか、 Rails.application.config.filter_parameters += ['password', 'card_number']
こんにちは、Яeiです。 今回は現役エンジニアである私がFluent Bitって何だという話についてまとめたいと思います。 最近巷で良く聞くFluent Bitと呼ばれるものがありますが、そもそもこれって何なのか調査しましたのでシェア致します。 最後はdocker-composeを用いたサンプルも用意しましたので見てみて下さい。 Fluent Bit 概要は公式サイトに分かりやすく書かれておりますので興味のある方は一読しておくとよいでしょう。 参考 fluentbitfluentbit また、各種ドキュメントは以下公式資料に詳しく書かれておりますのでこちらを参考にしてもらえればと思います。 参考 Fluent Bit ドキュメント 概要 Fluent Bitとは、 アプリケーションから出力されたログファイルや標準出力ログなどのデータを収集し、フィルタリングして複数の宛先に送信できるツールと
こんにちは。未だに競馬で当たったことがないホシイです。 今日も、クラウド機能をお手軽に使ってみるお試しネタをひとつお届けします。 オンプレでも Cloud Logging を使いたい… ふだん GCE や GKE を使っていると、非常にすんなり Cloud Logging に log が入ってくれるので、オンプレサーバーを扱っているときにもこれが欲しくなります。というか、なんで無いんだ!という気持ちになります。 たとえば httpd の log を Cloud Logging で見たい!だけなのに、一直線のサンプルが見つからなかったのでつくってみました。 container でお試しセットをつくる いつも思うんですが、目的の最小構成がすぐに確認できる container image があると便利だと思うんです。 ということで、container でやってみます。 今回はオンプレで使っている
Fluent Bit情報 Fluent Bitとは 主な特徴 動作環境 Fluent Bitのライセンス 参考情報 オープンソース年間サポートサービス Fluent Bitとは Fluent Bit(フルエントビット)は、C言語で書かれたクラウド及びコンテナ環境に適した、ログの収集、配布を行うオープンソースのログプロセッサツールです。 Fluent BitはFluentd傘下のCNCFサブプロジェクトで、2014年に組み込みLinuxやゲートウェイなどの制約のある環境向け軽量ログプロセッサとしてTreasure Data社のFluentdチームにより開発され、Fluentdエコシステムの一部として、Fluent Bitと名付けられました。 主な特徴 Fluent Bitは軽量で高速、パフォーマンスを重視したアーキテクチャになっており、以下のような特徴があります。
1[INPUT] 2 Name tail 3 Tag tail.01 4 Path /var/log/system.log 5[OUTPUT] 6 Name s3 7 Match * 8 bucket your-bucket 9 region us-east-1 10 store_dir /home/ec2-user/buffer 11 total_file_size 50M 12 upload_timeout 10m 13[OUTPUT] 14 Name splunk Fluent Bit enables you to collect logs and metrics from multiple sources, enrich them with filters, and distribute them to any defined destination. Optimized data
CloudWatch Logs に保存したログに特定の文言が出力されていたら通知する方法を調べていたら、CloudWatch Logs のサブスクリプションフィルタという機能を使えば実現できることが分かったので、メモとして残しておきたいと思います。 構成 構成としては、CloudWatch Logs のサブスクリプションフィルタという機能を使い、サブスクリプションフィルタで検知したログの内容を Lambda に送り、Lambda から SNS トピックにパブリッシュするという構成になっています。 ロググループごとに、最大2つのサブスクリプションフィルタを設定することができるようです。 また、今回は、Lambda に送っていますが、Amazon Kinesis や Amazon KinesisData Firehose などへ送ることもできるようです。 サブスクリプションを使用したログデータ
■はじめに CloudWatch、SNSトピックを利用してログに特定文字列が出力されたらアラーム発報し、メールを送信するところまで試しに構築してみたので手順をまとめました。 ■対象者 本記事はAWS初学者向けの情報共有として構築手順をまとめています。 また、自分用の手順メモでもあります。 ■構成図 EC2からCloudWatch logsへ/var/log/messagesを送信し監視対象とする。 CloudWatchは"ERROR"文字列を検知した場合、アラーム発報する。 アラーム発報すると関連付けられたSNSトピックは指定の宛先にメール通知を行う。 ■作業内容 大まかに以下。 EC2にCloudWatchエージェントのインストール EC2にCloudWatch logsへログを送信するための権限を付与 CloudWatchメトリクス作成 CloudWatchアラーム作成 検知、メール送
とすればいいわけです。 ためしてみる GETの場合 GET /posts?password=abc123 を叩いた場合ログに Started GET "/posts?password=[FILTERED]" for 127.0.0.1 at 2012-09-20 05:16:44 +0900 Processing by PostsController#index as HTML Parameters: {"password"=>"[FILTERED]"} とURLもパラメータも [FILTERED] に変えられて出力されます。 POSTの場合 POST /posts data: password=abc123 を叩いた場合ログは Started POST "/posts" for 127.0.0.1 at 2012-09-20 05:18:12 +0900 Processing by Po
ELBのヘルスチェックをRailsのログに出したくなくて、Rails::Rack::Loggerを継承したRackミドルウェアでenvの中身を見てRails.logger.silenceするみたいなミドルウェアを作り、Rails::Rack::Loggerとswapするのを試したんですが、log_tagsが効かなくなってしまいました。 class CustomRailsRackLogger < Rails::Rack::Logger def call(env) if ['/healthcheck'].include?(env['PATH_INFO']) Rails.logger.silence { super } else super end end end
Railsは便利。 本番サービスを稼働させている時、ヘルスチェックパスなど特定のパスへのリクエストのログはいらない、なんてことはよくある。 ALBを使うとヘルスチェックは必須だし、Zabbixなどでヘルスチェックを組み込む場合も同様である。 今回は、特定のパスに関するログを出力しないようにする方法の書き溜め。 私の場合、Railsのログをcloudwatch logsに出力している都合、 1秒に1回リクエストされるヘルスチェックパスのログは正直不要で、費用がかさむだけだから消したかった。 Rails loggerでログを出力させない方法 やり方は色々あるだろうけど、今回の方法をざっくりいうと、Rails::Rack::Loggerを継承したクラスを作成する。 Rails.logger.silence で特定のパスならログ出さないよー、ってやっている。 パス情報はenv["REQUEST_P
Ruby2.1.4, Rails4.1.7で確認。 ELB使用時にRails上にヘルスチェック用のアクションを作って、Railsアプリの状態チェックをするようにした場合、アプリケーションログにヘルスチェックのログが残ってしまいます。 ヘルスチェック用のアクションをつくることに関しては以前の記事を参照ください。 [[rails]ELB使用時にヘルスチェック用のアクションを作成する](http://blog.hello-world.jp.net/ruby/2104/)上記記事に沿ってアクションを作成した場合は、以下のように /health へのアクセスがアプリケーションログに記録されます。 # log/production.log I, [2014-12-15T19:59:54.149846 #7459] INFO -- : Started GET "/health" for 127.0.0.
にゃんぱすー ロードバランサのヘルスチェックで log/production.log が埋め尽くされるのが辛いので、特定の条件でログ出力を抑止する方法を調べたよ。 ロガークラスを作成する まず、Rails::Rack::Loggerを継承したCustomLoggerを作成する。 class CustomLogger < Rails::Rack::Logger def call(env) if env["REMOTE_ADDR"] =~ Moe::Application.config.action_dispatch.trusted_proxies and !env["HTTP_X_FORWARDED_FOR"] Rails.logger.silence do super end else super end end end ここでは、ロードバランサのIPアドレスはtrusted_proxie
【結論】 scriptコマンドでターミナル操作をログに残せる。 dateコマンドでタイムスタンプを取得できる。 ターミナルには、起動時にコマンドを自動実行する機能がある。 上記3つを用いることで、ターミナル操作のログを自動で残せる。 ただし、Mac標準のscriptコマンドは-f(即時反映)非対応なので、バツアイコンでターミナル終了するとログが残らないので使いづらい。 【目次】 ターミナル操作をファイルに残す方法 タイムスタンプを取得する方法 ターミナル起動時にコマンドを実行する方法 ログを保存するためのコマンドの例 おまけ 参考情報 最後に ターミナル操作をファイルに残す方法 scriptコマンドを実行することで、以降のターミナル操作をファイルに残すことができます。 $ script "ファイル名" 書き出し中はbash-3.2$と表示されます。(※1) 書き出し中にexitコマンド実行
Logrotate の正体はコマンドと cronログローテートとは、ログファイルのサイズが大きくならないように、1 日、または 1 週、または 1 か月といった期間でファイル名を変更し、設定次第では古いファイルを gzip で圧縮したり、もっと古いファイルを削除したりすることができる仕組みのことです。 Logrotate はデーモンとして動作していると勘違いされることも多いようですが、その実体は /usr/sbin/logrotate というコマンドと cron.daily の組合せです。つまり、crond によってlogrotate コマンドが毎日実行されているのです。 Logrotate の Statusなお、以下の cron 設定を見れば分かる通り、logrotate コマンドには引数として『前回の実行時刻』を保存した logrotate.status と『設定ファイル』である lo
目次 1. 構築要件 2. logrotate と cron のインストール 2.1 logrotate のインストール 2.2 cron のインストール 3. cron ジョブで logrotate の実行設定 3.1 crontab の設定 3.2 /etc/cron.weekly の設定 3.3 ログローテーションの設定ファイル /etc/logrotate.conf の設定 3.4 cronサービスの再起動 4.ログローテーションの動作確認 1. 構築要件 /opt/aem/author/crx-quickstart/logs 配下のログファイル stdout.log がずっとサイズが増えていくため、定期的にログローテーションする方法を紹介します。 実行頻度:毎日 02:00 に実行します。 実行内容(その1):ログファイルを前日の日付付けてリネームします。(例:stdout.lo
Certbotで取得したSSL/TLS証明書の更新を自動化していました。 いや、そのつもりだったのですが、cronがうまく実行していないことに気づいたため、調査することにしました。 というわけでcronジョブのログ調査方法についてメモします。 cronの実行状況の確認cronで指定したジョブが実行されているか確認するには、 /var/log/ 配下にある cron ファイルを見ます。 less /var/log/cron しかしこのファイルには実行ログしか残っていません。 ジョブの実行結果を確認するには別途ファイルに出力されるよう設定する必要があります。 cronの実行結果を保存する方法cronで設定したジョブの実行結果を、指定したファイル名で出力させます。 crontab -e で開き、次のような感じで設定します。 0 * * * * /usr/local/bin/myjob > /va
アプリケーションにとってログファイルはイベントやエラーなどを記録しておく重要なファイルです。しかし、同じファイルにログを書き込み続けていくとログファイルはどんどん肥大化していくことになります。 ログが肥大化すると次のような不都合があります。 ディスク領域を圧迫する ログを確認するとき、ファイルを読み込むのも特定の場所を探すのも大変 そのためログファイルが肥大化しないように適切なログのローテーションが必要です。 Linuxではシステムにある多くのログファイルをローテートするために設計されたlogrotateプログラム(コマンド)が用意されています。 この記事ではLinuxでlogrotateがどのように設定され使われているのか、その仕組みを紐解いていきます。 なおlogrotateについては「logrotateのテスト方法」という記事も書きましたので参照いただけると幸いです。 logrota
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く