目录 一.简介 二.例子 找出程序读取的文件 查看现在程序在做什么 查看程序中哪个部分消耗大量cpu 无法连接服务器查看信息 一.简介 Linux 操作系统有很多用来跟踪程序行为的工具,内核态的函数调用跟踪用「strace」,用户态的函数调用跟踪用「ltrace」 这2个工具可以对系统进程进行跟踪,查看这个进程做了哪些操作和动作.如果strace没获取到数据,可以用ltrace看看. 二.例子 找出程序读取的文件 mysql首先尝试去/etc/mysql/my.cnf读取,没找到继续下一个 st…

转  http://www.cnblogs.com/bangerlee/archive/2012/02/20/2356818.html 引言 “Oops,系统挂死了..." “Oops,程序崩溃了..." “Oops,命令执行报错..." 对于维护人员来说,这样的悲剧每天都在上演.理想情况下,系统或应用程序的错误日志提供了足够全面的信息,通过查看相关日志,维护人员就能很快地定位出问题发生的原因.但现实情况,许多错误日志打印模凌两可,更多地描述了出错时的现象(比如"c…

转自:http://www.cnblogs.com/bangerlee/archive/2012/02/20/2356818.html 引言 “Oops,系统挂死了..." “Oops,程序崩溃了..." “Oops,命令执行报错..." 对于维护人员来说,这样的悲剧每天都在上演.理想情况下,系统或应用程序的错误日志提供了足够全面的信息,通过查看相关日志,维护人员就能很快地定位出问题发生的原因.但现实情况,许多错误日志打印模凌两可,更多地描述了出错时的现象(比如"c…

Java动态,安全追踪工具 在我们日常的开发中,总是难以避免的要解决线上的问题.如果线上的问题我们在本地调试的时候无论调试多少次发现明明本地调用了这个方法呀,怎么线上就是没调呢?还有就是出了问题的时候由于没有打日志,所以不得不去价格logger,然后换个包,然后再重启,然后再调用,如果在用户很多的时候这么搞,无疑面临着巨大的风险,还不得不去处理用户的大量的投诉,在领导面前也只能默默的低着头承受着批评 那么有没有一种方法可以不用重启应用,又可以在线上追踪代码呢? 答案当然是有的,就是使用Btrac…

转载于:https://www.cnblogs.com/lidabo/p/4523755.html 引言 “Oops,系统挂死了..." “Oops,程序崩溃了..." “Oops,命令执行报错..." 对于维护人员来说,这样的悲剧每天都在上演.理想情况下,系统或应用程序的错误日志提供了足够全面的信息,通过查看相关日志,维护人员就能很快地定位出问题发生的原因.但现实情况,许多错误日志打印模凌两可,更多地描述了出错时的现象(比如"could not open file…

一.简介 关于molten的介绍网上有很多,是一个全链路追踪的工具,Molten可以看做是phptrace的的升级版(流行的php问题定位工具譬如phptrace,xhprof,这些工具可以自行Google,看看如何使用) Molten能干啥 molten追踪php核心调用库运行时信息并且按照zipkin/optracing格式输出信息.可以追踪`curl,pdo,mysqli,redis,mongodb,memcached` 这么多的运行信息. 你可以直接看到你耗时比较久的接口的运行信息,调用…

(接触了Zipkin,权将所了解或理解的记于此,以备忘) 分布式追踪系统 随着业务发展,系统拆分多个微服务.此时对于一个前端请求可能需要调用多个后端端服务才能完成,当整个请求变慢或不可用时,我们是无法得知该请求是由某个或某些后端服务引起的.此时就需要有某种方式来定位到故障位,这就是分布式系统调用跟踪的诞生. 分布式服务调用追踪的理论基础是Google 2010年发表的论文<Dapper, a Large-Scale Distributed Systems Tracing Infrastructu…

[前言] 在张银奎老师的<软件调试>一书中,详细地讲解了使用内存的分支记录机制——BTS机制(5.3),并且给出了示例工具CpuWhere及其源代码.但实际运行(VMware XP_SP3 单核)并没有体现应有的效果,无法读取到分支记录.查看了源代码并没有发现任何问题,与书中所讲一致.既然软件本身没有问题,那会不会是在虚拟机中运行的问题呢? 翻出了闲置多年的老机器,奔腾Dual+XP_SP3,在启动配置中增加/numproc=1,设置单核启动,测试结果依然没有什么改变.网上搜索几遍也是无果,毕…

1,别人家的总结: http://www.cnblogs.com/bangerlee/archive/2012/02/20/2356818.html 2,我自己碰到问题: 暂无. 3,使用场景: 程序挂死.命令执行报错,根据程序日志和系统日志无法看出原因.…

一.痛点 目前我司各系统的日志管理比较原始,使用logback打日志到log文件,虽然有服务管理平台,但记录的日志也仅仅是前置机调用后台系统的出入参,当遇到问题时查日志较为麻烦. 登录VPN-打开服务器-找到日志目录-打开日志文件-搜索 而这个过程也仅仅是在一台服务器上的操作,一般需要看前置机.后台系统甚至服务管理平台. 当用户较少时,通过先后顺序等其他标志还能查到,但当调用量稍多后就很难判断哪个日志是哪个操作发出的. 另外,我司产品前台面向用户,后台与多家公司产品有大量互相调用,当用户遇到问题…