はじめに RailsログをJSON形式にしたいだけなんですが、解決方法が意外とめんどくさかったので、ググってたどり着いた誰かのためにメモを残しておきます。 「Railsログ JSON」で雑にググるとlogrageというgemをいれるとよさそうな感じです。 https://github.com/roidrage/lograge gem入れるだけでバーンといいかんじのJSONになることを期待したのですが、以下の記事に書いてあるとおり、このgemはコントローラのアクセスログや例外しかJSON形式で出ません。 https://qiita.com/amanekey/items/b921ef73d871dac299eb おもむろに Rails.logger.info("foo") とかしてもJSONにならなくてそのまま出力されちゃう。 つまりこんなかんじ。 {"method":"GET","path"
Firelens の発表 – コンテナログの新たな管理方法 | Amazon Web Services
Amazon Web Services ブログ Firelens の発表 – コンテナログの新たな管理方法 本日、AWS でコンテナサービスを構築した素晴らしいチームが、従来に比べて非常に簡単にログを取り扱うことを可能にする AWS FireLens と呼ばれる新たな優れたツールを立ち上げました。 FireLens を使用することで、顧客は、デプロイメントスクリプトを修正したり、手動で追加のソフトウェアをインストールしたり、追加コードを書き込んだりすることなく、コンテナログをストレージや分析ツールに直接追加できます。Amazon ECS または AWS Fargate の設定をいくつか更新することにより、必要な場所にコンテナログを送信することを FireLens に指示するため、宛先を選択し、オプションでフィルターを定義します。 FireLens は Fluent Bit または Flue
ECS/Fargateタスクのログ出力先をカスタマイズ (ルーティング) できる「FireLens」機能が正式リリースされましたので、試してみました。 みなさん、こんにちは！ AWS事業本部の青柳＠福岡オフィスです。 ECS/Fargateタスクのログ出力先をカスタマイズ(ルーティング)できる「FireLens」機能が AWS Containers Roadmap の リポジトリ でプレビューされていましたが、先日、正式リリースされました。 まだドキュメントが日本語化されていませんが、英語版ドキュメントの内容に沿って試してみました。 Custom Log Routing - Amazon ECS 従来の「CloudWatch Logs」へのログ出力 まず、従来の「CloudWatch Logs」へのログ出力を行ってみます。 全体の構成は下図のようになります。 ECSクラスターやALBの設定
![[アップデート] ECS/Fargateでログ出力先をカスタマイズできる「FireLens」機能がリリースされました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/f10e4b6d55aa4fe987e9584f7b2febd50e43f158/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Famazon-elastic-container-service.png)
はじめに こんにちは。SRE部の板谷(@SItaya5)です。 Gunosyでは様々なプロダクトでECS(Amazon Elastic Container Service)を使用してタスクを実行しています。 ECSの起動タイプにはEC2とFargateの2種類がありますが、どちらのタイプも混在しています。 ログの送信先としては、主にPapertrailというサービスを使用しています。 しかし、Fargateで実行しているタスクに関しては、ログの送信先(Log Driver)に選択の余地がなく、Cloudwatch Logs一択でした。 そのため、EC2で実行しているタスクのログはPapertrailに送信されていましたが、一方のFargateで実行しているタスクはCloudwatch Logsに送信せざるを得ませんでした。 このように起動タイプ毎にログの送信先が分かれており、管理が煩雑にな
Application Load Balancer の CloudWatch メトリクス - エラスティックロードバランシング
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Application Load Balancer の CloudWatch メトリクス Elastic Load Balancing は、ロードバランサーとターゲットのデータポイントを Amazon CloudWatch に発行します。CloudWatch では、それらのデータポイントについての統計を、(メトリクスと呼ばれる) 順序付けられた時系列データのセットとして取得できます。メトリクスは監視対象の変数、データポイントは時間の経過と共に変わる変数の値と考えることができます。たとえば、指定した期間中のロードバランサーの正常なターゲットの合計数を監視することができます。各データポイントには、タイムスタンプと、オプションの測定単位が関連付けられています。 メトリクス
API Gateway (REST API) では、開発やトラシューに役立つ実行ログ (Execution Logs) を出力することができます。 AWS サポートに問い合わせる際にも、この実行ログがあるとスムーズです。 実行ログは、ステージから設定できます。 設定後、API Gateway にリクエストを投げると、CloudWatch Logs に出力されます。 ロググループ名は、API-Gateway-Execution-Logs_<API ID>/<ステージ名> です。 こちらの実行ログの内容を解説していきます。 リクエスト/レスポンス API Gateway に Postman から以下のようにリクエストを投げます。 パスパラメータ groupId=111、クエリパラメータ userId=222、本文に name=hoge を指定しています。 API Gateway はこのリクエス
CX事業本部@大阪の岩田です。 先日のブログでPythonのライブラリLambda Powertoolsについてご紹介しました。今日はNode.jsのLambda向けに色々な便利機能を提供してくれるDAZN Lambda Powertoolsについてご紹介します。 環境 今回利用した環境です ランタイム: Node.js 12.x dazn-lambda-powertools-layer: 1.15.6 DAZN Lambda Powertoolsとは？ Node.jsで利用できるAWS Lambda用のミドルウェアを集めたライブラリです。GitHubのリポジトリはこちらです。 https://github.com/getndazn/dazn-lambda-powertools 概要についてはREADMEに貼られている以下の画像を見て頂くのが分かり良いですが、 構造化ログ(JSONログ)の
AWS CloudTrail ログをクエリする - Amazon Athena
AWS CloudTrail は、Amazon Web Services アカウントの AWS API コールとイベントを記録するサービスです。 CloudTrail ログには、コンソールを含めた AWS のサービス に対して発行された、あらゆる API コールの詳細が記載されます。CloudTrail は暗号化されたログファイルを生成して、それらを Amazon S3 に保存します。詳細については、AWS CloudTrail ユーザーガイドを参照してください。 アカウント、リージョン、および日付にわたって CloudTrail イベント情報に対して SQL クエリを実行する場合は、CloudTrail Lake の使用を検討してください。CloudTrail Lakeは、企業からの情報を単一の検索可能なイベントデータストアに集約するトレイルを作成する AWS の代替です。Amazon
CloudTrail ログファイルの整合性の検証 - AWS CloudTrail
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 CloudTrail ログファイルの整合性の検証 CloudTrail が配信した後でログファイルが変更、削除、または変更されなかったかどうかを判断するには、CloudTrail ログファイルの整合性の検証を使用することができます。この機能は、業界標準のアルゴリズムを使用して構築されています。ハッシュ用の SHA-256 とデジタル署名用の RSA を備えた SHA-256。これにより、CloudTrail ログファイルを検出せずに変更、削除、または偽造することは計算上実行不可能になります。AWS CLI を使用して CloudTrail が配信した場所のファイルを検証することができます。 使用する理由 検証されたログファイルは、セキュリティおよびフォレンシック調査
今、時代は監視からオブザーバビリティへと移り変わりつつあります。様々なツールの登場により可視化する方法は増えましたが、監視という１つの運用だけでなく、日々の作業を改善しつづけられる “仕組み” をシステムに持たせることが求められています。それこそがまさにオブザーバビリティのもつ重要な目的です。 オブザーバビリティプラットフォームである New Relic は、監視という運用の殻を破り、エンジニアが本来費やすべき”日々の改善”という本来の目的へと変化させていくことができます。最新のマイクロサービス分散トレーシングや“育つAIops”による運用改善、既存のCNCF OSSツールとの連携など、New Relic で日々の改善を実現する方法をご紹介します。 清水 毅 New Relic Senior Solutions Consultant パッケージベンダーにてecommerceシステムのソフト
2020/08/31開催の、Infra Study Meetup #5「企業に必要とされているインフラ技術とこれから」のLTでお話した内容です。 https://forkwell.connpass.com/event/183909/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon ECSにおけるコンテナレベルメトリクス収集を正式サポートしました
