コンテナログ処理の技術的なベストプラクティス：Dockerのケーススタディ - Qiita
この記事では、Dockerを例に、コンテナログ処理の一般的な方法やベストプラクティスをいくつか紹介しています。 背景 Docker, Inc. 旧社名：dotCloud, Inc）は、2013年にDockerをオープンソースプロジェクトとしてリリースしました。その後、Dockerに代表されるコンテナ製品は、分離性能の良さ、移植性の高さ、リソース消費の少なさ、起動の早さなど複数の特徴から、瞬く間に世界中で人気を博しました。下図は2013年からのDockerとOpenStackの検索傾向を示しています。 コンテナ技術は、アプリケーションの展開や配信など、多くの便利さをもたらします。また、以下のようなログ処理のための多くの課題ももたらします。 1、コンテナの中にログを保存した場合、コンテナが取り外されるとログは消えてしまいます。コンテナは頻繁に作成・削除されるため、コンテナのライフサイクルは仮想
AWSに集まったログをどう分析するか NTTドコモのエンジニアが教えるサーバーレスなログ分析基盤
ログ分析勉強会では、「ログ分析」に関わるすべての技術、事例、知見を共有し、日々の業務に役立てられる情報交換ができる場所を目的として活動。初のオンライン開催となった今回、NTTドコモサービスイノベーション部の千田拓矢氏が、AWS純正サーバーレスなログ分析基盤を構築する方法を解説しました。関連資料はこちら。 AWSのサーバーレスサービスでセキュリティのログ分析 千田拓矢氏：それでは始めたいと思います。AWSのサーバーレスサービスでセキュリティのログ分析をしようという話です。 簡単に自己紹介します。千田と申します。NTTドコモのサービスイノベーション部というR&Dの部署に所属していて、5年目社員です。 基本的に普段の業務では、クラウド、AWS、GCP、Azureのセキュリティに関わる仕事をしています。機械学習もちょっとわかるくらいに勉強していて、その関連でFPGAとかGPUみたいなハードウェアの
次世代のログ基盤 Grafana Lokiを始めよう! / prometheus-meetup-tokyo-3-lets-start-the-loki
次世代のログ基盤 Grafana Lokiを始めよう! / prometheus-meetup-tokyo-3-lets-start-the-loki
Fluentd&Kinesis&Lambdaによる柔軟で高可用性なログ収集基盤の構築 - Qiita
概要 Fluentdによるログ収集基盤を、Lambda&Kinesisを利用した形で構成を変更したので、その時のメモ。 先に一言で感想を述べるのであれば、巷の噂通り、Kinesis&Lambdaは素敵でした。 Fluentd Aggregatorが抱える問題点 ログデータをFluentdのForwarder & Aggregatorを経由し、S3とRedshiftに保存するような構成でしたが、Aggregatorは冗長化しづらくボトルネックとなっていました。 ログ収集に求める要件 ログ収集の構成を改善するにあたり、先に挙げた目の前の問題点を解決するのは勿論ですが、他にも様々な要件があり、大別すると以下4つ。 信頼性: データをロスなく収集することができる。 安定性: ログ量に関係なく安定的なパフォーマンスを維持できる。 冗長性: 安全かつ簡単にスケーリングが可能 汎用性: 複数ログを複数サ
ERRORログが多すぎるWebアプリに出会ったら - GMOインターネットグループ グループ研究開発本部
次世代システム研究室のDevOpsネタ担当（最近は運用寄り）のM. Y.です。 最近仕事で、あるWebアプリのログファイルを解析する機会がありました。そのログファイルはERRORレベルのエラーログが非常に多く、それらのERRORログから実際に注意しなければならないログを発見する、というのがそのときの目的でした。 アプリを作り始めたときはログ形式に注意を払っていたのに、そのアプリが歴史を重ねるうちにルールが曖昧になったり、開発者が変わってルールが失伝しまうというのは良くあることだと思います。逆に、大したことないアプリだと思って適当なログ形式にして作ったら、思った以上に長年使われて後悔するというパターンもありますよね。私も、そういう経験が何度かあります。 そこで今回は、ありがちな事例を描画して、そういうWebアプリに出会ってしまったときの対処方法について考えてみます。また、後半ではログ解析の分
ログ収集ライブラリ Puree の iOS 版をリリースしました - クックパッド開発者ブログ
モバイルファースト室の @slightair です。 先日、モバイルアプリのログ収集ライブラリ「Puree」をリリースしました という記事で Puree というログ収集ライブラリを紹介しました。 Android 版につづき iOS 版もリリースしたので紹介したいと思います。 puree-ios : https://github.com/cookpad/puree-ios モバイルアプリのログ記録の難しさや、それを解決するための Puree の思想についての説明は前回の記事におまかせします。 iOS 版の Puree も Android 版と同じようにフィルタリング、バッファリング、バッチ、リトライの機能を備えています。 ログのフィルタリングや出力の振る舞いをプラグインとして定義し、それらを組み合わせることで効率的なログ収集を実現します。 Puree iOS の使い方 Puree の導入方法
CentOS 7のログ管理「journald」
今回は、CentOS 7で採用されている新しいログ管理の仕組み「journald」を取り上げます。またjournaldとrsyslogとの連携やシステム全体に渡って様々なログを収集するsosreportについても簡単に触れます。 CentOS 7におけるログ機構「Systemd Journal」を使いこなす CentOS 7は、ログの管理を行う新しい仕組みが導入されています。従来のCentOS 6系では、長年親しまれてきたsyslogがベースのログ管理手法が採用されていましたが、CentOS 7からは、ログに関するより細かい指定や操作を行うことができるようになっています。CentOS 7でのログ管理は、systemdが担当しています。サービス名は、「systemd-journald.service」です。一般的には、「journald」と呼ばれています。CentOS 6までのsyslogで
ログをカラフルにしてもっと見やすく！『ccze tool』 | 俺的備忘録 〜なんかいろいろ〜
今回は、catやtailと組み合わせてログをカラフルに色分けし見やすくする『ccze tool』を紹介する。 1.インストール まずはインストール。 以下のコマンドを実行する。 sudo yum install ccze --enablerepo=epel (CentOSの場合) sudo apt-get install ccze (Debian/Ubuntuの場合) 2.コマンドの実行 さて、それでは実際にコマンドを実行してみよう。 tailコマンドで、「/var/log/messages」を確認する。 tail /var/log/messages | ccze -A 上半分はcczeを利用していない状態。 下半分でcczeを用いている。 うーむ、確かに見やすい… むろん、「tail -F」でも閲覧可能だ。 tail -F /var/log/messages | ccze -A ちなみ
たった6個のsedを通せば、Apacheログは驚くほど扱いやすくなる - Qiita
Q. awk '{print $9}'とかでUser-Agent丸ごと取り出したい とか思ったことない? Apacheのログ解析で。でもできないじゃない。例えば 192.168.0.1 - - [17/Apr/2014:11:22:33 +0900] "GET /index.html HTTP/1.1" 200 43206 "https://www.google.co.jp/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36"
Fluentdとログ収集のパターン - Go ahead!
「ログを集めて保存する」と言うのは簡単だけど，ログ収集の構成にはいくつか方法があり，勉強会などでちょくちょく聞かれるので，いくつかのパターンについて書く． 「俺はもうバリバリログ収集やってるぜ！」という人は多分すでに知っていることが書かれているので，タブを閉じて良い． ここではログコレクタにFluentdを想定しているが，他のログ収集プロダクトにも適用出来るはず． ただ，Fluentdはタグベースのルーティングを持ち，単体でもキューのように動作させることが可能で，既存のものより複雑な問題を解決しようとしているので，少し工夫が必要かもしれない． Fluentdそのものについては公式ドキュメントや，Fluentdとはどのようなソフトウェアなのかを参考に． クライアントから直接保存する いきなりFluentdを使わないパターン．JavaScript SDKを提供している解析サービスやモバイル端末
PostgreSQLのログをFluentdで収集する - Tech-Sketch
PostgreSQLの運用管理にログの情報は不可欠ですが、PostgreSQLが出力するログは直接取り扱うのに適した形式とは言えません。ここではFluentdを使って運用管理に活用しやすい形にPostgreSQLのログを加工する方法を紹介します。 PostgreSQLの運用管理とログ データベースの運用管理には 死活監視、リソース監視 性能分析、チューニング バックアップ、リストア といったものが考えられますが、現状を把握しなければ何も対策できないので、まずは必要な監視を正しく行うことが重要です。PostgreSQLで監視に使える機能には稼働統計情報とログがありますが、今回はログに注目してみます。 PostgreSQLのログからわかること PostgreSQLが出力するログからは以下の様なことがわかります。 何らかの異常(エラー)が発生したこと 処理されたSQL チェックポイント、自動VA
ログ収集や可視化で話題のFluentd、Elasticsearch、Kibanaを徹底解説したムック本が発売となります - Y-Ken Studio
2014年8月8日、ログ収集や可視化を始めたいエンジニア必携の書籍が技術評論社より刊行されます。 本邦初公開となる、全編書き下ろしの特集で構成された本書を読むことで、ログ解析の有用性からログ収集、保存、可視化手法を習得できます。 私はこの第2特集「ログ収集ミドルウェアFluentd徹底攻略」の執筆を担当しました。 サーバ/インフラエンジニア養成読本 ログ収集~可視化編 [現場主導のデータ分析環境を構築!] (Software Design plus) それでは、それぞれの特集について簡単に紹介したいと思います。 サーバ/インフラエンジニア養成読本 ログ収集〜可視化編 特集1 ログ解析からはじめるサービス改善 (鈴木 健太) 第1特集では、ログを蓄積して解析する意義とは何か、コーヒーショップのECサイトを例に、データ分析のケーススタディと共に解説されています。 第1章 はじめに 第2章 サー
ログ分析環境を少しづつ作ってる - wyukawa's diary
まだ本格的な運用は始まっていないけどログ分析環境を少しづつ作ってるのでメモっておく。 ETL処理は既存資産の活用を考慮してPython 2.7でやっています。 hiveserver2との接続はpythonからhiveserver2につなごうとしていろいろハマったのでメモっておく - wyukawa’s blogに書いた通りだいぶ苦労したけど独自にpatchあてて対応した。 sqoop imortもやりつつある。最初はsqoop2を使おうかなと思ったけどhiveとの連携がまだみたいなのと、既存資産の活用もあって古いsqoopのまま処理を進めている。 Hiveからselectして結果をMySQLへinsertする部分はMySQL-Python使っています。この辺も既存資産があるからですね。 Python 3は使っていないので下記にあるような事情は今回特に関係ないです。とはいえPython 3も
doing – 今何をしているかを記録
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました 作業ログを残していきましょう！ Todo管理の重要性は皆さんが知るところでしょう。しかし個人的にはToDid、つまりやったことのリストも大事だと思っています。これからやるべきこと、やっていること、やったこと…その3つが蓄積されてこそ成長があるのではないでしょうか。 ということで紹介したいのがdoingです。今何をしているかを記録していくというToDoingを管理するソフトウェアです。 doingのインストール Rubygemsで配布されていますのでインストールは簡単です。 $ gem install doing doingの使い方 例えば次のようなコマンドを打ちます。 $ doing now "Research for MOONGIFT" これで記録完了です。他にもサブコマンドはた
fluentdの効果的な活用例と安定運用のポイント
fluentdの効果的な活用例と安定運用のポイント：今さら聞けないfluentd～クラウド時代のログ管理入門（3）（1/3 ページ） 効率良く、意味のあるログ管理を実現するツールとして注目されている「fluentd」。最終回では、実際の利用シーンを想定し、より効果的なfluentdの利用法を紹介します。 第1回、第2回でfluentdを使って基本的なログ管理が実現できるようになったのではないでしょうか。fluentdはプラグインの組み合わせにより更に効果を発揮します。最終回では、実際の利用シーンを想定し、より効果的な利用法を紹介します。 fluentdの具体的な活用例 実際の利用シーンを想定した2つのfluentdの活用例を紹介します。 大量のログを分析し、「意味のある情報」として管理する タグデータを効果的に活用し、ログデータのフィルタリング管理を行う 1.大量のログを分析し、「意味のあ
エンジニアでもターミナル作業ログを残したい!! - 目の前に僕らの道がある
今まで下記のようにexecで標準出力と標準エラー出力を作業ログに残すという事をしてたんですが、実際に打ったコマンドは出力されないので、ちょっと不便だなーと思ってました。 exec > >(tee --append /tmp/$(date +"%Y.%m.%d")_$(id --user).work.log) 2>&1 ちょっと調べて見るとscriptコマンドを使うとコマンドを含めて出力できることを知りました。 これで作業ログを残すのがはかどる! script --append --flush /tmp/$(date +"%Y.%m.%d")_$(id --user).work.log チームメンバーにこのログをtailさせておけば、画面共有も出来たりもします。 (その用途ならホントはwemuxとか使った方が良いんでしょうけどね。。 tail -F /tmp/$(date +"%Y.%m.%
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
サービス改善はログデータ分析から
MacのキーボードやマウスのログをKibanaで可視化する - Qiita
main
