The core engine providing runtime insights to the Sysdig platform

The core engine providing runtime insights to the Sysdig platform
Often times, the production system network is inaccessible from the local development environment. If issues are encountered in production systems, it is impossible to use IDEs to debug the application remotely. More importantly, debugging in production environment is unacceptable, as it will suspend all the threads, resulting in the suspension of business services. Developers could always try to
At Fosdem we had a talk on dtrace for linux in the Debugging Tools devroom. Not explicitly mentioned in that talk, but certainly the most exciting thing, is that Oracle is doing a proper linux kernel port: commit e1744f50ee9bc1978d41db7cc93bcf30687853e6 Author: Tomas Jedlicka <tomas.jedlicka@oracle.com> Date: Tue Aug 1 09:15:44 2017 -0400 dtrace: Integrate DTrace Modules into kernel proper This ch
CloudWatch Logs へジャンプ re:Invent 2017 で発表された AWS Lambda の新機能です。 Lambda コンソールから CloudWatch Logs への遷移が簡単に行えるようになりました。 手順 Lambda 関数のログがワンタッチで確認できるようになったので、デバッグが捗りそうです。 なお、グラフはマウスでドラッグすることによりズームインすることができます。(ダブルクリックでズームアウト) お試しください。 ↓ リンク AWS re:Invent 2017: What's New in Serverless (SRV305) | YouTube ミレニアム・ファルコン製作日記 #100 100 号 表紙 パーツ 完成!! 今回の作業は以下の 2 つでした。 ディテールパーツを取り付ける リモートコントロールをセットする 完結号の今号では、これまでに
debugCSS: (X)HTML debugging tool built with CSSdebugCSS is meant to be loaded on an existing page to highlight potentially broken, malformed or legacy (X)HTML. Not all "errors" are created equally, so they are color coded to highlight severity. Green is "probably not a big problem", yellow is "worth looking at" and red is "you really should fix this." Click and drag the link below to your bookmark
Something that often, uh... bugs[1] Go developers is the lack of a proper debugger. Sure, builds are ridiculously fast and easy, and println(hex.Dump(b)) is your friend, but sometimes it would be nice to just set a breakpoint and step through that endless if chain or print a bunch of values without recompiling ten times. CC BY 2.0 image by Carl Milner You could try to use some dirty gdb hacks that
JavaScript のデバッガ、便利ですよね。つかって、ますよね! Chrome, Firefox 両方の Developer Tool (Web Inspector) には JavaScript デバッガが付属しています。両者には Event Listener Breakpoints 機能が存在し、特定イベントのリスナ全部にブレークポイントを仕掛ける事が可能です。 しかし、jQuery の $.on, $.bind, その他 $.click(fn) 等でイベントハンドラを定義すると jQuery の中で addEventListeners が呼ばれ内部で処理をした後に実際に jQuery に渡した関数が呼ばれます。 そのため、JavaScript デバッガは jQuery 内部でブレークし本来飛んでほしいはずの関数に一発で飛んでくれません。 そこで Firefox には Library
株式会社クリアコード > ククログ > segv-handler-gdb:Rubyスクリプトがクラッシュしたときにより詳しくCレベルのバックトレースを出力するgem Rubyで拡張ライブラリーを使っているとクラッシュすることがあります。自分が開発している拡張ライブラリーならどうにかして直したいものです。そのときに役立つのがGDBなどのデバッガーです。Cレベルのより詳細な情報を取得できるため、問題の特定に役立ちます。しかし、次のようにデバッガー上でクラッシュさせることが難しいことがあります。 GDB上で動かすとクラッシュしない 消極的な理由ですが次のようなケースもあります。 なかなかクラッシュしないので、ずっとGDB上で動かしているわけにもいかない SIGPIPEなどを捕まえて止まって欲しくない。「handle SIGPIPE nostop」などをするのが面倒。 クラッシュしたら自動で起動し
gdbperl.plというスクリプトがあります。そんkする樋口証さん作の、gdbを操作してPerlのプロセスのバックトレースを取るツールです。生きているプロセスだけではなく、coreを取っておけばそのcoreからバックトレースが取れるのが特徴です。 gcoreというコマンドが/usr/binあたりにあって、これを使えば走っているプロセスのcoreを取得することができます。よって、本番環境で気軽にcoreを取ってgdbperl.plにかけることによって、刺さっているポイントを見つけたりすることができます。超便利。 くわしくは、Perlスクリプトをgdbでデバッグを参照ください。 んで、その便利なgdbperl.plをRubyに移植してみました。その名もgdbruby.rb。単純。 gdbruby.rb 使い方とか Rubyはデバッグシンボル付きのものをご用意ください。 生きているプロセスにア
#!/usr/bin/env perl use strict; use warnings; use Getopt::Long qw(:config posix_default no_ignore_case no_ignore_case_always permute); use Pod::Usage; use Carp; my $PROG = substr($0, rindex($0, '/')+1); my $Debug = 0; sub dprint (@) { return unless $Debug; my @m = @_; chomp @m; print STDERR @m,"\n"; } MAIN: { my $target_pid; my $mode; GetOptions( 'pid|p=i' => \$target_pid, 'mode|m=s' => \$mode, 'd
Since we don’t have any nice NMT (Native Memory Tracking) MBean in HotSpot (yet), and therefore not in the JMC console, I thought I’d show how it can be done using command line arguments and JCMD. Please note that you’ll get a 5-10% performance hit if you enable this. Step 1 – Enabling NMT This is done by using the following command line: -XX:NativeMemoryTracking=[off|summary|detail] Where the dif
注意 このページにアクセスするには、承認が必要です。 サインインまたはディレクトリの変更を試すことができます。 このページにアクセスするには、承認が必要です。 ディレクトリの変更を試すことができます。 この記事は、「Windows の限界に挑む」シリーズの 5 回目の投稿です。この一連の記事では、物理メモリ、仮想メモリ、プロセス、スレッドなど、Windows で管理できるリソースの数量とサイズの上限について扱ってきました。 Windows の限界に挑む: 物理メモリ Windows の限界に挑む: 仮想メモリ Windows の限界に挑む: ページ プールと非ページ プール Windows の限界に挑む: プロセスとスレッド 今回は、ハンドルの実装の限界を探り、解説します。ハンドルは、アプリケーションが操作する基本的なオペレーティング システムのオブジェクト (ファイル、レジストリ キー、
はじめに つい最近知った便利なデバッグ方法 (長年シェルスクリプトを書いているのに知らなかった。これが常識だったら恥ずかしい…) シェルスクリプトのデバッグでは echo で変数の中身を見るという原始的な方法をよく使うかと思います。 いわゆる プリントデバッグ というやつですね。 もう少し詳しいデバッグが必要な場合は、 set -x と set +x でデバッグしたい部分を囲むという方法もあります。 今回は プリントデバッグ で使う echo の代わりに typeset or declare を使うと良いというお話です。 プリントデバッグは typeset or declare を使おう typeset or declare は変数宣言などでよく使うコマンドですが、変数の中身を見るのにも使えます。 echo と比べて何が良いのかというと、変数の中身はもちろん変数名や変数の型も表示してくれ、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く