これからのZOZOを支える ログ収集基盤を設計した話 / Log collection infrastructure to support ZOZO in the future
これからのZOZOを支える ログ収集基盤を設計した話 / Log collection infrastructure to support ZOZO in the future
これからのZOZOを支える ログ収集基盤を設計した話 / Log collection infrastructure to support ZOZO in the future
コミット履歴を綺麗にするときの`git commit --fixup`と`git rebase --autosquash` - 理系学生日記
Pull Request(PR)やMerge Request(MR)を作る中で、コミット履歴はできるだけ綺麗にしておきたいものです。 プルリクエストについて - GitHub Docs Merge requests | GitLab ぼくはあまりコミット履歴の綺麗さを気にしない方でした。 しかし大きめのPRやMRをレビューする側に回ると、「変更のまとまり」が追えないと「なぜこの変更をしたのか」が非常に追いにくくなります。 だからこそ最近は、コミット履歴をかなり意識するようになりました。 その時に活躍しているのが、タイトルの通りgit commit --fixupとgit rebase --autosquashです。 git commit --fixup git rebase --autosquash そのほかおすすめ git commit --fixup git commit --fixu
コンテナログ処理の技術的なベストプラクティス：Dockerのケーススタディ - Qiita
この記事では、Dockerを例に、コンテナログ処理の一般的な方法やベストプラクティスをいくつか紹介しています。 背景 Docker, Inc. 旧社名：dotCloud, Inc）は、2013年にDockerをオープンソースプロジェクトとしてリリースしました。その後、Dockerに代表されるコンテナ製品は、分離性能の良さ、移植性の高さ、リソース消費の少なさ、起動の早さなど複数の特徴から、瞬く間に世界中で人気を博しました。下図は2013年からのDockerとOpenStackの検索傾向を示しています。 コンテナ技術は、アプリケーションの展開や配信など、多くの便利さをもたらします。また、以下のようなログ処理のための多くの課題ももたらします。 1、コンテナの中にログを保存した場合、コンテナが取り外されるとログは消えてしまいます。コンテナは頻繁に作成・削除されるため、コンテナのライフサイクルは仮想
ECS タスクメタデータエンドポイントを使ったバッチ処理コンテナのリソースモニタリングツール kobanzame を作りました - ようへいの日々精進XP
追記 (2020/06/15) Container Insights は GA しています！ tl;dr kobanzame 作ったもの 仕組み なんちゃってプラグインアーキテクチャ 使い方 設定ファイル 実行 Example 参考 それ, Container Insights で良いんじゃないのか おっしゃるとおり じゃあ, なぜ, 俺は kobanzame を作ったのか 以上 追記 (2020/06/15) Container Insights は GA しています！ 2020/06/14 現在はベータ版として提供されていますが この記述は誤りで Container Insights は 2019 年 11 月には既に GA されておりますので, ここで訂正させて頂きます. aws.amazon.com 確認不足で誤った情報を記述してしまい大変申し訳ございませんでした. tl;dr 以
大規模システムにおける5つのログ転送パターン
成功者がどのようにNew Relicを使用してKubernetesのパフォーマンスを4倍に向上させ、拡張性とスループットを改善したかをご覧ください。
AWS for Fluent Bit による Kubernetes ロギング | Amazon Web Services
Amazon Web Services ブログ AWS for Fluent Bit による Kubernetes ロギング 集中ログは、Kubernetes クラスターを大規模に実行および管理するための重要なコンポーネントです。開発者はアプリケーションのデバッグとモニタリングのために、運用チームはアプリケーションのモニタリングのために、セキュリティはモニタリングのために、それぞれログにアクセスする必要があります。これらのチームには、ログの処理と保存に関する異なる要求事項があります。このブログ記事では、Amazon CloudWatch と組み合わせた AWS for Fluent Bit を使用してログを集中管理するソリューションを紹介します。 AWS for Fluent Bit は Fluent Bit 上に構築されたコンテナであり、ログフィルター、パーサー、およびさまざまな出力
Splitting an application’s logs into multiple streams: a Fluent tutorial | Amazon Web Services
AWS Open Source Blog Splitting an application’s logs into multiple streams: a Fluent tutorial Not all logs are of equal importance. Some require real-time analytics, others simply need to be stored long term so that they can be analyzed if needed. In this tutorial, I will show three different methods by which you can “fork” a single application’s stream of logs into multiple streams which can be p
JavaScript/TypeScriptの例外ハンドリング戦略を考える - Qiita
PySpa統合思念体です。あと、 @yosuke_furukawa にも協力いただきました。 基本的に、あまりエラーの種別を細かく判定してあげることはJavaScriptでは今までやってこなかったのですが、ちょっとしたメタデータを乗っけてあげるとか（例えばリトライ回数）、何か凝ったことをしたくなったらこういう方針でやればいいのでは、という試行錯誤録です。 エラーと例外の区別が必要か この手の話になると、エラーと例外の違いとか、こっちはハンドリングするもの、こっちはOSにそのまま流すものとかいろんな議論が出てきます。このエントリーではエラーも例外も差をつけずに、全部例外とひっくるめて説明します。 例外というのはすべて、何かしらのリカバリーを考える必要があります。 ちょっとしたネットワークのエラーなので、3回ぐらいはリトライしてみる 原因: ネットワークエラー リカバリー: リトライ サーバー
Building a scalable log solution aggregator with AWS Fargate, Fluentd, and Amazon Kinesis Data Firehose | Amazon Web Services
AWS Compute Blog Building a scalable log solution aggregator with AWS Fargate, Fluentd, and Amazon Kinesis Data Firehose September 8, 2021: Amazon Elasticsearch Service has been renamed to Amazon OpenSearch Service. See details. This post is contributed by Wesley Pettit, Software Dev Engineer, and a maintainer of the Amazon ECS CLI. Modern distributed applications can produce gigabytes of log data
EC2インスタンス内のログをCloudWatch LogsとS3バケットに保存してみた | DevelopersIO
はじめに おはようございます､加藤です｡EC2の上で動くアプリケーションログを一時的にCloudWatch Logsに保管､長期的にS3バケットに保存というアーキテクチャを試してみました｡ こちらが概要図です｡ EC2インスタンスでCloudWatchエージェントを動かし､ログをCloudWatch Logsに転送します｡CloudWatch LogsのロググループからKinesis Data Firehose→S3と転送します｡ Kinesisエージェントをインスタンスにインストールすれば直接Kinesis Data Firehoseにログを転送できますが､CloudWatch Logsに短期間はログを保存して置きたい・CloudWatch Logsで任意の文字列を検出した場合はアラートを上げたいというシチュエーションを想定し､このようなアーキテクチャになりました｡ 永続的に保存したい要
AWS CloudWatch Logsを見やすくするツールを作った - Qiita
概要 AWS CloudWatch Logsの表示が見にくすぎるというのは全人類が抱える問題だと思いますが、それを見やすくするCLIツールを作りました。 既にawslogsというツールがあり、こちらも便利なのですがロググループをまたいでtailすることが出来なかったので自分で作りました。 あと個人的にはPythonのCLIツールをグローバルに入れたくな... 他にもいくつかツールあり、そちらと比べて機能的に大きく異なるわけではないので、今困ってない人は良いと思います。色合いが良い感じとかふわっとした部分は結構違うと思います。 Utern 以下に置いてあります。 https://github.com/knqyf263/utern sternというKubernetesでログを表示するのに使われる便利なツールがあるのですが、それを参考に作ったのでuternというツール名にしました。意味は特にない
tail -Fなどの標準出力を一定時間ごとに指定のコマンドに渡し、その実行結果をシーケンシャルに出力するコマンド evry を作った - Copy/Cut/Paste/Hatena
ログの流量やサマリを、カジュアルに、そしてリアルタイムに確認したかったので作ってみました。 github.com これはなに 標準入力の内容を、一定時間ごと（もしくは一定行ごと）にまとめて指定のコマンドに渡し、その実行結果をシーケンシャルに出力するコマンドです。 使い方 例えば、「NGINXの10秒あたりのリクエスト数を確認する」には、以下のように evry で10秒ごとにまとめた標準入力を wc -l に渡します。 $ tail -F /var/log/nginx/access.log | evry -s 10 -c 'wc -l' 8700 1260 8580 6430 [...] 例えば、「Apacheの1000リクエストあたりのアクセス先ランキング上位5を確認する」には、以下のように書けます（GNU sedを使用）。 $ tail -F /var/log/httpd/access.
AWS S3に蓄積したlogをGoogleのBigQueryに投入する仕組み作り~概要編~ - BizReach Tech Blog
BizReachプロダクト開発部、SREグループの久保木です。5月頃に中途で入ってきて、今はinfrastructure中心に開発に従事しています。 最近はlog生成周りをいじっていった結果、生成元であるapplicationもいじれるようになってきた気がします。あとはfrontendいじれば制覇かな！（＜どこに行く気なの？） ところで、元々僕は何かを作る時に延々とmemoがてら作業進捗を書いていく癖があります。 それで作業が一区切りしたところで、 「あれ、これ記事のネタになるんじゃない？」 と思ったので書いてみることにしました。ボリュームがあるので連載にてお送りします。 どうぞよろしくお願いします。 前編: 概要 中編: 技術調査・設計 後編: 七転八倒ログ 何があったのか まず、前提。 BizReachのapplicationはlogをS3に飛ばして、そこからなんやかんやあって(後述)
S3に保存したログファイルをストリーム処理するサーバーレスアプリケーションの紹介 - クックパッド開発者ブログ
インフラストラクチャー部セキュリティグループの水谷(@m_mizutani)です。 クックパッドでは現在セキュリティ監視の高度化に取り組んでおり、その一環としてセキュリティ関連のログ収集およびその分析に力を入れています。ログ収集の部分では可用性などの観点からAWSのオブジェクトストレージサービスであるS3に一部のサービスやサーバのログをまず保存し、後から保存されたファイルを読み込んで分析などに利用しています。分析のためにS3に保存したファイルを前処理する方法としてAWS Glueなどを用いたバッチ処理がありますが、到着したログをなるべくストリームデータのように扱いたい場合もあります。特にセキュリティ関連のログでは以下のようなユースケースで利用しています。 アラートの検出: ログを検査してその中から危険度の高いと考えられるログを探し出し、アラートとして発報します。アラートの具体的な例としては
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
サイボウズのログ基盤 2018年版 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。アプリケーション基盤チームの @ueokande です。 今日は、サイボウズの新しくなったログ基盤についてお話しします。 サイボウズのログ基盤の進化 リプレイス前のログ基盤 サイボウズのログ基盤はサービスの成長に合わせて、常に進化し続けてます。 そんななか2017年の夏に大きなリプレイス作業がありました。 サイボウズのサービスを支えるログ基盤 from Shin'ya Ueoka 以前のログ基盤は、ログを収集するホストがあり、各ホストからログを収集してました。 しかしログの転送システムが単一障害点であったり、スケーラビリティに欠けるのでサービスの成長に追いつかず、性能的にも限界に達してました。 また以前のログ基盤では、ログの解析がしにくく、ログはあるけどビジネスに役立てにくい状況でした。 そのため今後のサービスの成長や、より安定したログ基盤を運用できるように、ゼロから刷新するこ
ええっ！？ 文字列で書くの！？ ログレベル付きロガーhashicorp/logutilsのご紹介 - Qiita
全世界100万人のコンパイルエラーラバーの皆さんこんばんは、この記事はGo Advent Calendar 2017の18日目の記事です。 標準パッケージのlog Goで作るものはミドルウェアだったり、Webアプリケーションだったり、CLIツールだったり様々だと思いますが、ちょっと凝ったことをするとついてくるものといえばロギングですよね。Goにはlogという標準のログライブラリがありますが、 標準パッケージなのでimport "log"だけで使える インターフェイスがシンプル。だいたいfmt 複数goroutineから扱っても混ざらない そのまま使っても時間が出る などなど、最低限の実用性があります。ただ、他の言語のロガーと比べると、 ログレベル 構造付きログ などの機能が不足していると言えます。 よく使われているロガー そもそもこの記事を書くきっかけとなったのが、Go Conferenc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - webpod/red: Terminal log analysis tools
AWSのログ管理ベストプラクティス
ウェブサービスにおける行動ログ活用基盤を通したデータ駆動マーケティングの実践 / Practice of data driven marketing using behavior log foundation system on web service
