タグ

ログに関するtuneのブックマーク (7)

  • ロギングベストプラクティス - kawasima

    #翻訳 https://www.scalyr.com/blog/the-10-commandments-of-logging/ CC BY 4.0 @Brice Figureau 1.自分でログの書き出しをしない printfをつかったり、ログエントリを自分でファイルに書き出したり、ログローテションを自分でやったりしてはいけない。運用担当者にお願いして、標準ライブラリやシステムAPIコールを使うようにしよう。そうすれば、実行中のアプリケーションが他のシステムコンポーネントと適切に連携して、特別なシステム設定なしに適切な場所またはネットワークサービスにログを記録できるようになる。 ロギングライブラリを使いたければ、特にJavaの世界にはLog4j, JCL, slf4j, logbackなど多くのものが存在する。私はslf4jとlogbackを組み合わせて使うのが好きだ。とてもパワフルで、設

    ロギングベストプラクティス - kawasima
    tune
    tune 2020/01/18
    これは良いまとめ
  • アプリケーション動作ログ、ERRORで出すか? WARNで出すか? 〜 岡山城で話してきました #cmdevio2019 | DevelopersIO

    旬の生魚おじさん、都元です。旬かどうかは分かりませんが、最新数週間連続でマテ貝を売っているのにお目にかかりました。これはもう、酒蒸しですよ。最高ですよ。あ、魚じゃなかった。生でもなかった…。 さて先週末。2019-04-06 にDevelopers.IO 2019 at 岡山城を開催し、そこで「アプリケーション動作ログ、ERRORで出すか? WARNで出すか?」と題しましてお話をさせていただきました。そのレポートをお送りします。 スライドとセッション概要 アプリケーションのログ、出してますか? 欲しい情報が出てますか? 要らない情報いっぱい出てませんか? 出すか出さないかの判断は、何に基づいて決めていますか? そもそも何のためにログ出してますか? そこでログが出るのは正しいですか? ここでログが出ないのは正しいですか? そのログは INFO で出すべきものですか? それとも DEBUG で

    アプリケーション動作ログ、ERRORで出すか? WARNで出すか? 〜 岡山城で話してきました #cmdevio2019 | DevelopersIO
    tune
    tune 2019/04/13
    こんな感じで運用していた
  • ロギングにおける十戒 | Yakst

    どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。アプリケーションのログを拡張する手助けとなるのがこの「十戒」だ。 新年の私のブログにようこそ。監視とログのモニタリングについてのParisのdevopsメーリングリストでのスレッドに返信を書いた後、長らく心に留めていたブログ記事を思い出した。 このブログ記事は、私のOpsとしての顔をもって、主に開発者向けに書いた。 どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。多くの場合、これは予言をするのと同じようなことだからだ。トラブルシューティング中にどんな情報が必要かを知るのはとても難しい。それが、Opsエンジニアの大きな助けとなるよう、あなたのアプリケーションのログを拡張する手助けとなるこの「十戒」を望んだ理由だ。 1. 自分でログを書くべ

    ロギングにおける十戒 | Yakst
    tune
    tune 2018/10/27
    基本だけどなかなかまとまった情報もないので有用
  • WinlogbeatでWindowsログモニタリング | DevelopersIO

    はじめに 藤です。 日2目です。日(現地時間は昨日)、Elasticで多くのProductの新バージョンがリリースされました。 Elasticsearch 2.2.0, 2.1.2, and 1.7.5 released Kibana 4.4.0 is eye meltingly colorful Beats 1.1.0 & Winlogbeat released Logstash 2.2.0 and 2.1.2 released Elasticsearch for Apache Hadoop 2.2.0 and 2.1.3 released 昼頃に【新機能】ShieldがKibanaに対応しましたをエントリしました。 今回はWinlogbeatを試してみましたのでご紹介します。 概要 Elasticが提供するOfficial BeatsファミリーにWinlogbeatが加わりまし

    WinlogbeatでWindowsログモニタリング | DevelopersIO
  • なぜ私たちはSumo Logicを捨ててBigQueryを選んだのか - tech.guitarrapc.cóm

    ログ分析サービスはアプリケーションのインフラであり、サービス開発/運用の中で重要な位置を占めます。グラニでは、今年に入って利用しているログ分析サービスを、 Sumo Logic から Google BigQuery に完全移行しました、 記事は、グラニで議論された「ログ分析サービスとしての SumoLogic と BigQuery」のまとめを推敲、転載したものです。これからログ分析サービスを検討される方々にとって、議論の内容が少しでも参考になることを願い公開します。 アジェンダ まずは文脈を整えるためにアジェンダから。 アジェンダ 日常的なアプリケーション監視フロー APM として盤石な New Relic ログ分析サービスによるアドホックなログ分析 ログ分析サービスに求めること Sumo Logic の利用と課題 Sumo Logic の利点 Sumo Logicで発生した課題 ログ収

    なぜ私たちはSumo Logicを捨ててBigQueryを選んだのか - tech.guitarrapc.cóm
  • スマートニュースの世界進出を支えるログ解析基盤 #jawsdays #tech

    スマートニュースは昨年の 10/1 に米国版をローンチするにあたり、ログ解析基盤のリニューアルを行いました。日に加えて米国やその他の国が入ってくることにより、単なるユーザ数の増加に加え、OS x 国 x タイムゾーン x 多種多様なメトリクスのような集計軸が増えることで、ログの前処理、集計、可視化に様々な工夫が必要になってきます。セッションでは、会社の成長に応じたログ集計基盤の転換を振り返りながら、世界進出にあたってどのようなことを考え、どのようにログ集計基盤をリニューアルしていったか、および、そのログ解析基盤を支える Amazon EMR, Hive, Presto, Azkaban, Shib, Chartio などのツールについてお話します。

    スマートニュースの世界進出を支えるログ解析基盤 #jawsdays #tech
    tune
    tune 2015/04/04
  • 並列データ転送ツール『Embulk』リリース! - Blog by Sadayuki Furuhashi

    こんにちは。古橋です。 先日の*1 データ転送ミドルウェア勉強会で、新しいオープンソースツール Embulk をリリースしました。 Embulk, an open-source plugin-based parallel bulk data loader from Sadayuki Furuhashi Embulk は、リアルタイムなログ収集では常識となった fluentd のバッチ版のようなツールで、ファイルやデータベースからデータを吸い出し、別のストレージやデータベースにロードするためのコンパクトなツールです。 fluentd と同様にプラグイン型のアーキテクチャを採用 しているため、RubyJavaで簡単なコードを書くことで、様々なファイルフォーマットやストレージに対応することができます。一方で fluentd とは異なり、高速性やトランザクション制御、スキーマを使ったデータのバリ

    並列データ転送ツール『Embulk』リリース! - Blog by Sadayuki Furuhashi
  • 1