UbieにおけるGo言語のエラーハンドリング
背景 Ubieでは以下の記事にあるように、一昨年から新しく始めるプロジェクトにはGoとTypeScriptを積極的に採用しています。私は本来プロダクトセキュリティが主な専門領域なのですが、公私ともに普段からGoでツールやサービスの開発をしているため、社内のGo言語の普及をサポートしたりプロダクト開発に参加したりしています。 Go言語で開発したことがある方はご存知かと思いますが、Goは標準パッケージで提供されているエラーハンドリングは最低限の機能しか提供されていません。これは、CLIツールなどではエラーの内容が簡潔に表せてよいのですが、サーバサイドアプリケーションのようにエラーにまつわる情報を詳細に残してあとから調査に利用する、という場面では不向きです。特に本番環境でしか再現しないようなエラーの場合は、いかに関連情報を残せているかが、問題の解決に大きく影響します。 先日も話題になっていました
DuckDB メモ
モチベーション JSONL を読み込んで解析するツールが欲しかった ログを読み込ませたいので圧縮機能は必須 自社のパッケージ製品が出力する JSONL を読み込んで解析できる仕組み 顧客が問題解析を気軽にできるようにしたい 顧客向けツールとして提供したい つまり顧客環境で動かしたい 1 バイナリ OSS として提供したい Apache-2.0 として公開したい ログファイルは大きくても 100 GB は行かない もともと Go + SQLite + JSONB で検討していた SQL で書きたい SQLite ファイルとして書き出したい SQLite ファイルフォーマットは信頼できる S3 などにファイルを置いておくだけにしたい クラウド版に組み込みたい 顧客毎に duckdb ファイル作ればいいのでは？ duckdb ファイルダウンロードできると便利そう DuckDB https://d
OpenTelemetry 良い感じ - 誰かの役に立てばいいブログ
最初に断っておきますと、OpenTelemetry を良く知っていたり真面目に調査しようという人が読むべき内容はここにはありません。 公式ドキュメントなりをご参照ください。これは最近 OpenTelemetry を使いだした一般人の感想記事です。 さて、いけてる Web 開発者、特にバックエンド開発者の方はオブザーバビリティという言葉は聞き及んでいるかと思います。 なかでもオブザーバビリティ三種の神器と言われている（？）ログ、メトリクス、分散トレーシングをどう実装するか頭を悩ませているかもしれません。 頭を悩ませてきた、あるいは頭を悩ませている理由の一つは、これらを実装するときに特定の実装向けになりがちであったためです。 メトリクスであれば最近は Prometheus 向けに /metrics エンドポイントとして提供する実装が多いといった話です。しかしながら、 あらゆる人が Promet
Cloud Logging 構造化ログの特別な JSON フィールドまとめ
Google Cloud のログ管理サービスである Cloud Logging は JSON で出力されたログを構造化ログとして認識します。その際に特別な JSON フィールドを使うとログに特別な属性を与える事ができます。本記事ではそれらの特別な JSON フィールドを用途ごとにまとめて紹介します。 本記事の技術的な内容はほぼすべてこのドキュメント 1 ページに書いてありますが、「実際に UI でどう表示されるのか」と「その特別な JSON フィールドにどんな価値があるのか」はドキュメントにないので参考にしていただけると思います。 Cloud Logging へのログ書き込み Cloud Logging へログを書き込むには大きく 2 つの方法があります。API で LogEntry を直接書き込むか、それ以外かです。 API で直接書き込む方法の場合、メジャーな言語であれば各言語のライブ
JavaアプリケーションをOpenTelemetry（+Zipkin）で計測してみる - Qiita
はじめに JavaアプリケーションでOpenTelemetryを使って可視化してみたメモ。 APMとOpenTelemetryに関する説明は他の方の投稿を参考にしてください。 以下の投稿のOpenTelemetry（+Zipkin）版です。 JavaアプリケーションをElastic APMで計測してみる 環境 使用した環境は以下のとおり。 CentOS 7.5 OpenTelemetry(agent) 0.6.0 Zipkin Server 2.21.5 アプリケーションは測定対象のアプリケーションはWindows上で動かします。 OpenJDKのインストール まず、OpenJDK 8をインストールします。 # yum install java-1.8.0-openjdk-devel # java -version openjdk version "1.8.0_252" OpenJDK R
AWSでの法令に則ったログ設計及び実装/分析 - Adwaysエンジニアブログ
エージェンシー事業でリードアプリケーションエンジニアを行なっている大窄 直樹 (おおさこ)です. AWSのログ, サーバーのログってたくさん種類があって難しいですよね... 同じようなログがたくさんあるので, 何を取れば良いのかとか どのくらいの期間保持すれば良いのかとか またその後の, ログの実装や, 分析方法する方法も難しいですよね... 今回AWSに構築した商用アプリケーションのログを整備する機会があったので, このことについて書こうかなと思います. 概要 本題に入る前の準備 今回ログ実装するアーキテクチャ ログに関する法令 ログの取得箇所 設計 保管するログの決定 インフラのログ OSのログ アプリケーションのログ ログの保管 保管場所について 保管期間について バケット構造 アプリケーション, OSのログの転送 実装 アプリケーション, OSのログをfluentbitを用いてS3
AWS CloudWatchで体験するアプリケーション ログ/メトリクス 監視入門
ECS(Fargate)のアプリケーションから構造化ログをFluentBitでログルーティングしてCloudwatchやS3に送って、検索・統計・解析する基礎が載っています。構造化ログやメトリクスの概念について解説を入れてから、実際にAWSで構築します。 対象読者: メトリクスって何それ美味しいの？という方。 EC2やオンプレミスからECSに移行しようと思っているけどログどうしよう？という方。 APIのレスポンスタイムをアラームのトリガーにしたいな、と思っている方。 昔のCloudwatchは真っ当に統計もできずクソだったけど今はどうなん？って方。 基礎知識の要求: AWS ECS(設定はある程度載せてます), Docker(fileはサンプルを提供します), Rails(ログを送るアプリケーションというだけです) 扱うもの:CloudWatch,FireLens,Athena,Fluen
ガイド: Node.jsでログを記録する方法
製品 コミュニケーション メッセージング マルチチャネルのテキストメッセージとメディアメッセージの送受信を180か国以上で
Webアプリケーションのログに関するいくつかの考察 - Hatena Developer Blog
こんにちは、はてなでWebアプリケーションエンジニアをやっている id:polamjag です。 最近のはてなでは、若手エンジニアを中心として、いろいろな技術を見つめ直すワーキンググループをやっています。先日、id:onk も「デプロイ今昔」という記事を書きましたが、このエントリーはそのシリーズの続きで、ワーキンググループの「ログ」の回で議論したこと・話題になったことをまとめました。 Web開発におけるログを見つめ直す ログを4つの目的で分類する 目的ごとに求められる取り扱いの要求水準 いまどきのログフォーマットについて まとめ：どう実装するかを模索していく Web開発におけるログを見つめ直す Webサービス（Webアプリケーション）の運用には、多種多様なログがついてまわります。多くのミドルウェアは何もしなくてもそれなりの量のログを出力しますし、クラウド上のマネージドサービスも然りです。行
(翻訳) データエンジニアリングの未来 - satoshihirose.log
訳者まえがき 原著者の Chris Riccomini の許可を得て以下の記事を翻訳・公開しました。 riccomini.name 下記より記事翻訳本文です。 データエンジニアリングの未来 私は最近、近頃のデータエンジニアリングがこれまで来た道について、また、この分野の仕事の将来について考えてきました。考えのほとんどは、私たちのチームが WePay で実践していることを背景にしています。その一方、以下に述べる考えは普遍的で、共有する価値があるものと思っています。 データエンジニアリングの仕事は、組織におけるデータの移動と処理を支援することです。これには、一般的に、データパイプラインとデータウェアハウスという2つの異なるシステムが必要です。データパイプラインはデータの移動を担当し、データウェアハウスはデータの処理を担当します。これは、やや過度に単純化しています。バッチ処理とストリーム処理では
最新のログもすぐクエリできる速くて容量無限の最強ログ基盤をRedshift Spectrumで作る - クックパッド開発者ブログ
こんにちは。去年の今頃は Rust を書いていました。 インフラストラクチャー部データ基盤グループの id:koba789 です。 背景 クックパッドではデータ基盤の DBMS として Amazon Redshift を利用しています。 既存のデータ基盤について詳しいことは クックパッドのデータ活用基盤 - クックパッド開発者ブログ を参照してください。 今まで、ログは数時間に1度、定期実行ジョブで Redshift 内のテーブルにロードしていました。 ロードジョブの実行間隔が "数時間" と長めなのは、Redshift のトランザクションのコミットが遅いためです。 クックパッドでは数百ものログテーブルがあるため、仮に1分おきにすべてを取り込もうとすると秒間数回以上のコミットを行わなければなりません。 このような頻繁なコミットは Redshift 全体のパフォーマンスを悪化させてしまいます
cookpad storeTV の広告配信を支えるリアルタイムログ集計基盤 - クックパッド開発者ブログ
こんにちは。メディアプロダクト開発部の我妻謙樹（id:kenju）です。 サーバーサイドエンジニアとして、広告配信システムの開発・運用を担当しています。 今回は、cookpad storeTV （以下略：storeTV ）の広告商品における、リアルタイムログ集計基盤の紹介をします。 storeTV における広告開発 storeTV とは？ storeTV は、スーパーで料理動画を流すサービスで、店頭に独自の Android 端末を設置し、その売り場に適したレシピ動画を再生するサービスです。 より詳しいサービス概要にについては、弊社メンバーの Cookpad TechConf 2018 における以下の発表スライドを御覧ください。 storeTV における広告商品の概要 storeTV では、imp 保証型の広告商品を提供予定です。imp 保証型の広告商品とは、例えば「週に N 回広告を表示す
TCPパケットを解析して構造化ログでダンプするツール tcpdp を作った - Copy/Cut/Paste/Hatena
やっと形になってきました。 github.com 「データベースのクエリログを取得したい」 例えば、データベース（RDBMS）のクエリログを取得したいとき一番確実な方法は、そのRDBMSに備わっているログ機構を利用することです。 一方で、全てのクエリログを出力するとなるとそれなりにIO負荷がかかることが予想されるので、負荷状況によってはクエリログ出力（のIO負荷）を別サーバに分離したくなります。 では、どうすればよいかというと、例えば アプリケーションサーバとデータベースサーバの間にプロキシサーバを挟んでそこで記録することでIO負荷を分離する アプリケーションサーバ側で（notアプリケーションで）記録することで（大抵、サーバ台数の多い）アプリケーション側にIO負荷を分散する というような方法を思いつきます。 そこで、「もし、TCPコネクション上に流れている（例えば）クエリログを解析してログ
Fluentd 入門 〜運用に必要な基礎知識〜
最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En
クックパッドのデータ活用基盤 - クックパッド開発者ブログ
インフラ部 & 技術部の青木峰郎です。 クックパッドでは全社的にAmazon Redshiftを中心としたデータ活用基盤を構築しています。 今日はその全体像についてお話ししたいと思います。 データ活用基盤の全体像 まず、以下にクックパッドのデータ活用基盤の全体像を示します。 大きく分けると入力が2系統、内部処理が1系統、出力が3系統あります。 入力はMySQLからのインポートとログのロードがあり、どちらも独自に構築したシステムで行われています。 DB内部のデータ処理はSQLバッチのみです。 そして出力は管理画面やBIツールからのアクセスとバッチ処理によるエクスポートに大別できます。 以下1つずつ説明していきましょう。 入力その1: MySQLインポートシステム MySQLからRedshiftへのマスターテーブル取り込みにも独自のインポートシステムを使っています。 このインポート処理には、つ
Nginxで、リクエストを複製するmirrorモジュールが標準搭載された - ASnoKaze blog
[20170809追記] nginx-1.13.4に ngx_http_mirror_module は含まれました Nginxで、リクエストを複製するmirrorモジュールがコミットされ、何もせずとも使用できるようになりそうです(現状最新コミットをビルドする必要あり)。 例えば本番環境のproxyからリクエストを複製して開発環境に流すような事も出来ます。もちろん複製処理は本来のリクエスト処理をブロックしません。 例えば以下のように、mirrorに来たリクエストを複製してバックエンドサーバに投げるようにしてみます conf server { listen 80 ; server_name localhost; mirror_request_body on; log_subrequest on; location /mirror { mirror /proxy; #/proxy宛にリクエストを
Shadow Proxyのご紹介 at Quipper - Qiita
この記事はQuipperのテックブログに書いた以下の記事の日本語版での要約です。 http://quipper.github.io/2015/11/11/introducing-shadow-proxy.html Shadow Proxyとは？ 本番のHTTPリクエストから同等のリクエストをステージング環境に適用するための仕組みです。主な目的は、2年以上の運用で肥大化したMongoDBに対するindexの追加/削除/つけ忘れなどを事前に検証・検知するためです。 構成 Fluentdが大活躍しています。 Reverse Proxy Log AggregatorにNginxのアクセスログを転送する Log Aggregator S3(バックアップ),BigQuery(調査用),Shadow Proxyにアクセスログを転送する アクセスログをもとにステージングのアプリにHTTPリクエストを送信す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
秒間数万のログをいい感じにするアーキテクチャ
あんどぅ on Twitter: "本番運用するといずれ誰もがたどり着く、公式ドキュメントには書かれてないログ管理の現実解が資料化されていてすばらしい そう、CloudWatch LogsにはDev環境 or ERRORの場合のみ飛ばすFluentdの設定をすることで利便性と料金のバランスをとるのである これは公式ドキュメントにすべき https://t.co/RE4FmPCpJX"
Announcing log processing and analytics in Datadog
