この記事では、 Azure Monitor Application Insights 内で OpenTelemetry ベースのデータ収集を有効にして構成する方法について説明します。 Azure Monitor OpenTelemetry Distro では: Azure Monitor に固有の機能のサポートを含む OpenTelemetry ディストリビューション を提供します。 トレース、メトリック、ログ、例外を収集するための OpenTelemetry インストルメンテーション ライブラリを含めることで、 自動 テレメトリを有効にします。 カスタム テレメトリの収集を許可します。 ライブ メトリックをサポートし、ライブの運用中の Web アプリケーションからより多くのテレメトリを監視および収集します。 Azure Monitor OpenTelemetry Distro を使用する
一つのJavaプログラムについて、処理をマルチスレッドで並行性を持つように記述し、複数CPU(マルチコア)上でそのプログラムを実行することにより並列処理を実現しようとした際、ログ出力が実行性能にどれだけ影響を及ぼすのかを把握したい、と考えています。 プログラムの開発(特にデバッグ)においては、ログが使えないと苦労します。ただし、ログを埋め込むと、性能に影響を及ぼします。また、ログレベルを抑制し、実際にはログ出力がなかったとしても、ログレベルの判定処理が動くことで、多少の影響はあります。 最近のログ出力ライブラリはスレッドセーフに作られていますが、それは内部で排他区間を持つことになるので、並列処理においては排他による性能への影響は無視できません。 そこで、同一プロセス内でマルチスレッドにより並行実行するプログラムを作成・実行し、複数スレッドからログを出力すると、実行性能にどれだけ影響を及ぼす
最初は誰しもがファッ!?となるんですよねロガーって。 いずれtree-tipsで公開しようと思っている、solrのプロジェクトを今作っています。mavenでjarを管理している訳ですが・・ なんだこのロガーの数は!! commons-logging、log4j、slf4j-api、jcl-over-slf4j、logback-classic・・・・、こいつら一体何が違うんだ!どう使い分けるんだ!そもそも必要なのか!?となりました。 昔はcommons-logging+log4jというのがトレンドだった訳ですが、今はslf4j+logbackがトレンドになり、jdkも1.4から1.7になり、これらトレンドが推移する過程で、いろいろなjarが旧式に依存してしまい、旧式依存を解決するためにアダプタが登場し始め、mavenでjarを収集すると大抵両方入ってしまい、カオスになっているのです。 特にs
Overview This is the top level section for all Flume NG (developer) documentation. Flume NG is a refactoring of Flume and is tracked in FLUME-728. From the JIRA's description: To solve certain known issues and limitations, Flume requires a refactoring of some core classes and systems. This bug is a parent issue to track the development of a "Flume NG" - a poorly named, but necessary refactoring. S
■ flume NGを動かしてみた fluent(ruby)が盛り上がってそうなので、ここはあえてflume(java)を使ってみた flume 本家サイト ■ fluentとの比較 ログを収集するこの手のツールは、scribe, flume, fluentなどいくつかある それらの比較表を拾ってたのが下の図 参考: http://blog.treasure-data.com/post/13047440992/fluentd-the-m... この図を見ると、flumeの行数がすごい事になっている ただここに書かれているのは、古いflumeなのでflume NGではない (現在は0.9.Xまでの古いflumeはflume OGと呼び、あたらしい、1.0.0以降のflume NGをflumeと呼ぶらしい) じゃぁ、flume NGではどうなのか? ざっくり行数を調べてみる # wget ht
LOG.debug("nice catch!") - connpass 2012/06/27 java-ja 『LOG.debug("nice catch!")』#java_ja #javaja - Togetterまとめ blogエントリを書くまでがjava-jaだと聞いたのでとりあえず書く。超まとまってません。各スピーカーの話の内容については他の人のblogに(たぶん)書いてあるのでそっちを見るとかTogetterを眺めるとかすればよいのではないでしょうか。 主催のみなさま、および会場提供のGREEさま、ありがとうございました。そういえばGREEでの勉強会って初めて参加した気がする。六本木ヒルズの入館、だいぶ簡単になりましたね。 いってきた どっちかというとアプリケーションのコード書く人が多かったんですかね。という感じで、アプリケーションコードからいかにして例外を投げるか、それをどのよ
業務で使うplay! 所属 生息地 私のJava経験 クラシックなstrutsを新人の頃使ってた EJB3.0をちょっと使ってた s2系のフレームワークをちょっと使ってた JPAは知らない 今回の経緯 自分 ちょっと前に入社 Frameworkが クラシックAsp ベース 高性能だが工数が掛かる アプリケーション基盤を 自分で用意する事にした 案件内容 中小企業の基幹システム 比較的小規模(20∼30画面) 既存システムからのフルリプレイス 物流系システム 要件ヒヤリング 画面サンプル DB設計など 3∼9月 顧客 最終レビュー 10月 業務プログラ ム実装開始 11月∼ 案件全体の進 状況 Frameworkの 選定/実現性分析 8月中∼ アプリケーション部の進 状況 共通処理の先行 開発 9月中∼ Play!を採用した理由 初期導入コストが掛からない →マニュアルも日本語化されている
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く