过滤日志的工具

⑴ 如何快速过滤出一次请求的所有日志

如何快速过滤出一次请求的所有日志？
前言
在现网出现故障时，我们经常需要获取一次请求流程里的所有日志进行定位。如果请求只在一个线程里处理，则我们可以通过线程ID来过滤日志，但如果请求包含异步线程的处理，那么光靠线程ID就显得捉襟见肘了。
IoT平台，提供了接收设备上报数据的能力， 当数据到达平台后，平台会进行一些复杂的业务逻辑处理，如数据存储，规则引擎，数据推送，命令下发等等。由于这个逻辑之间没有强耦合的关系，所以通常是异步处理。如何将一次数据上报请求中包含的所有业务日志快速过滤出来，就是本文要介绍的。
正文
SLF4J日志框架提供了一个MDC(Mapped Diagnostic Contexts)工具类，谷歌翻译为映射的诊断上下文，从字面上很难理解，我们可以先实战一把。
public class Main {
private static final String KEY = "requestId";
private static final Logger logger = LoggerFactory.getLogger(Main.class);

public static void main(String[] args) {
// 入口传入请求ID
MDC.put(KEY, UUID.randomUUID().toString());

// 打印日志
logger.debug("log in main thread 1");
logger.debug("log in main thread 2");
logger.debug("log in main thread 3");
// 出口移除请求ID
MDC.remove(KEY);
}
}
我们在main函数的入口调用MDC.put()方法传入请求ID，在出口调用MDC.remove()方法移除请求ID。配置好log4j2.xml文件后，运行main函数，可以在控制台看到以下日志输出：
2018-02-17 13:19:52.606 {requestId=f97ea0fb-2a43-40f4-a3e8-711f776857d0} [main] DEBUG cn.wudashan.Main - log in main thread 1
2018-02-17 13:19:52.609 {requestId=f97ea0fb-2a43-40f4-a3e8-711f776857d0} [main] DEBUG cn.wudashan.Main - log in main thread 2
2018-02-17 13:19:52.609 {requestId=f97ea0fb-2a43-40f4-a3e8-711f776857d0} [main] DEBUG cn.wudashan.Main - log in main thread 3
从日志中可以明显地看到花括号中包含了（映射的）请求ID(requestId)，这其实就是我们定位（诊断）问题的关键字（上下文）。有了MDC工具，只要在接口或切面植入put()和remove()代码，在现网定位问题时，我们就可以通过grep requestId=xxx *.log快速的过滤出某次请求的所有日志。
进阶
然而，MDC工具真的有我们所想的这么方便吗？回到我们开头，一次请求可能涉及多线程异步处理，那么在多线程异步的场景下，它是否还能正常运作呢？Talk is cheap, show me the code。
public class Main {
private static final String KEY = "requestId";
private static final Logger logger = LoggerFactory.getLogger(Main.class);
public static void main(String[] args) {
// 入口传入请求ID
MDC.put(KEY, UUID.randomUUID().toString());
// 主线程打印日志
logger.debug("log in main thread");
// 异步线程打印日志
new Thread(new Runnable() {
@Override
public void run() {
logger.debug("log in other thread");
}
}).start();
// 出口移除请求ID
MDC.remove(KEY);
}
}
代码里我们新起了一个异步线程，并在匿名对象Runnable的run()方法打印日志。运行main函数，可以在控制台看到以下日志输出：
2018-02-17 14:05:43.487 {requestId=e6099c85-72be-4986-8a28-de6bb2e52b01} [main] DEBUG cn.wudashan.Main - log in main thread
2018-02-17 14:05:43.490 {} [Thread-1] DEBUG cn.wudashan.Main - log in other thread
不幸的是，请求ID在异步线程里不打印了。这是怎么回事呢？要解决这个问题，我们就得知道MDC的实现原理。由于篇幅有限，这里就暂不详细介绍，MDC之所以在异步线程中不生效是因为底层采用ThreadLocal作为数据结构，我们调用MDC.put()方法传入的请求ID只在当前线程有效。感兴趣的小伙伴可以自己深入一下代码细节。
知道了原理那么解决这个问题就轻而易举了，我们可以使用装饰器模式，新写一个MDCRunnable类对Runnable接口进行一层装饰。在创建MDCRunnable类时保存当前线程的MDC值，在执行run()方法时再将保存的MDC值拷贝到异步线程中去。代码实现如下：
public class MDCRunnable implements Runnable {
private final Runnable runnable;
private final Map<String, String> map;
public MDCRunnable(Runnable runnable) {
this.runnable = runnable;
// 保存当前线程的MDC值
this.map = MDC.getCopyOfContextMap();
}
@Override
public void run() {
// 传入已保存的MDC值
for (Map.Entry<String, String> entry : map.entrySet()) {
MDC.put(entry.getKey(), entry.getValue());
}
// 装饰器模式，执行run方法
runnable.run();
// 移除已保存的MDC值
for (Map.Entry<String, String> entry : map.entrySet()) {
MDC.remove(entry.getKey());
}
}

}
接着，我们需要对main函数里创建的Runnable实现类进行装饰：
public class Main {
private static final String KEY = "requestId";
private static final Logger logger = LoggerFactory.getLogger(Main.class);
private static final ExecutorService EXECUTOR = Executors.newSingleThreadExecutor();
public static void main(String[] args) {
// 入口传入请求ID
MDC.put(KEY, UUID.randomUUID().toString());
// 主线程打印日志
logger.debug("log in main thread");
// 异步线程打印日志，用MDCRunnable装饰Runnable
new Thread(new MDCRunnable(new Runnable() {
@Override
public void run() {
logger.debug("log in other thread");
}
})).start();
// 异步线程池打印日志，用MDCRunnable装饰Runnable
EXECUTOR.execute(new MDCRunnable(new Runnable() {
@Override
public void run() {
logger.debug("log in other thread pool");
}
}));
EXECUTOR.shutdown();
// 出口移除请求ID
MDC.remove(KEY);
}
}
执行main函数，将会输出以下日志：
2018-03-04 23:44:05.343 {requestId=5ee2a117-e090-41d8-977b-cef5dea09d34} [main] DEBUG cn.wudashan.Main - log in main thread
2018-03-04 23:44:05.346 {requestId=5ee2a117-e090-41d8-977b-cef5dea09d34} [Thread-1] DEBUG cn.wudashan.Main - log in other thread
2018-03-04 23:44:05.347 {requestId=5ee2a117-e090-41d8-977b-cef5dea09d34} [pool-2-thread-1] DEBUG cn.wudashan.Main - log in other thread pool
Congratulations！经过我们的努力，最终在异步线程和线程池中都有requestId打印了！
总结
本文讲述了如何使用MDC工具来快速过滤一次请求的所有日志，并通过装饰器模式使得MDC工具在异步线程里也能生效。有了MDC，再通过AOP技术对所有的切面植入requestId，就可以将整个系统的任意流程的日志过滤出来。使用MDC工具，在开发自测阶段，可以极大地节省定位问题的时间，提升开发效率；在运维维护阶段，可以快速地收集相关日志信息，加快分析速度。

⑵ android log viewer怎么过滤日志

SLF4J是一套简单的日志外观模式的Java API，帮助在项目部署时对接各种日志实现。 LogBack在运行时使用专JMX帮助修改日志配属置，在生产状态下无需重启应用程序。 SLF4J SLF4J是简单的日志外观模式框架，抽象了各种日志框架例如Logback、Log4j、Commo...

⑶ 怎么使用工具对日志记录进行绕过

查看系统事件日志的方法如下： 1、按快捷键win+Q打开应用界面，选择控制面板，进入控制面板，点击“系统和安全”。 2、点击“查看事件日志”。 3、进入事件查看器的第二种方法：在桌面“计算机”图标上面点击右键，选择“管理”。 4、在计算机管理界面选...

⑷ 怎么用eclipse还有logcat命令的过滤log信息

1. 只显示需要的输出，白名单
最方便的当然是通过管道使用 grep 过滤了，这样可以使用 grep 强大的正则表达式匹配。简单的匹配一行当中的某个字符串，例如 MyApp：
adb logcat | grep MyApp
adb logcat | grep -i myapp #忽略大小写。
adb logcat | grep --color=auto -i myapp #设置匹配字符串颜色。更多设置请查看 grep 帮助。

进阶一点可以使用 grep 的正则表达式匹配。例如上一个例子会匹配一行中任意位置的 MyApp，可以设置为仅匹配 tag。默认的 log 输出如下，如果修改过输出格式相应的表达式也要修改。
I/CacheService( 665): Preparing DiskCache for all thumbnails.

可以看出 tag 是一行开头的第三个字符开始，根据这点写出表达式：
adb logcat | grep "^..MyApp"

根据这个格式也可以设置只显示某个优先级的 log，再匹配行首第一个字符即可。例如仅显示 Error 级别 tag 为 MyApp 的输出：
adb logcat | grep "^E.MyApp"
当然也可以匹配多个，使用 | 分割多个匹配表达式，要加转义符。例如要匹配 tag 为 MyApp 和 MyActivity 的输出：
adb logcat | grep "^..MyApp\|^..MyActivity"
adb logcat | grep -E "^..MyApp|^..MyActivity" #使用 egrep 无须转义符

2. 过滤不需要的输出，黑名单
还是使用 grep，用法也跟上面的一样，加一个 -v 即可。例如要过滤 tag 为 MyApp 和 MyActivity 的输出：
adb logcat | grep -v "^..MyApp\|^..MyActivity"
adb logcat | grep -vE "^..MyApp|^..MyActivity" #使用 egrep 无须转义符

3. 显示同一个进程的所有输出
有时一个程序里面的 tag 有多个，需要输出该程序（同一个 PID）的所有 tag；仅使用 tag 过滤有时也会漏掉一些错误信息，而一般错误信息也是和程序同一个 PID。还是通过 grep 实现，思路是先根据包名找到 pid 号，然后匹配 pid。写成 shell 脚本如下，参数是程序的 java 包名（如 com.android.media）。
查看源代码打印帮助\
#!/bin/bash

packageName=$1
pid=`adb shell ps | grep $packageName | awk '{print $2}'`

adb logcat | grep --color=auto $pid

4. 从当前开始显示
logcat 有缓存，如果仅需要查看当前开始的 log，需要清空之前的。adb logcat -c && adb logcat

5. 过滤 log 文件
有时需要分析 log 文件，过滤 log 文件还是使用 grep。例如 log 文件为 myapp.log，要匹配 tag 为 MyApp 和 MyActivity 的输出，然后输出到 newmyapp.log：cat myapp.log | grep "^..MyApp\|^..MyActivity" > newmyapp.log
Windows 下推荐使用 Notepad++，一个免费强大的记事本，支持正则表达式查找替换。可以高亮显示匹配内容，也可以删除不需要的内容。
以上的技巧主要用到了 grep，其实 logcat 本身也有过滤功能，可以根据 tag、优先级过滤 log，具体请参考 Android 官方文档 Reading and Writing Logs。如果喜欢使用图形界面，请参考 Using DDMS，DDMS 里面的 logcat 也可以同样过滤。

⑸ 查看网络日志的工具（软件）有哪些

有很多，logparser查看iis日志

⑹ 如何过滤一些不需要的log logstash

/var/log/：系统的引导日志:/var/log/boot.log核心启动日志:/var/log/dmesg系统报错日志:/var/log/messages邮件系统日志:/var/log/maillogFTP系统日志:/var/log/xferlog安全信息和系统登录与网络连接的信息:/var/log/secure登录记录:/var/log/wtmp记录登录者讯录，二进制文件，须用last来读取内容who-u/var/log/wtmp查看信息News日志:/var/log/spoolerRPM软件包:/var/log/rpmpkgsXFree86日志:/var/log/XFree86.0.log楼上的要查什么的当然用tail更好

⑺ catlog日志工具怎么使用

首先讨论一下为什么使用Logcat而不使用Java中的System.out.println()方法来输出日志。
System.out.println()方法的优点就是使用很方便，只需要在Eclipse中输入syso，接着按下代码提示，这个方法就自动出来了。但是相比较Logcat,它的缺点也很明显，比如打印时间无法确定、打印内容无法控制、不能添加过滤器、日志级别没有区分等等。

今天重点讨论下log的级别区分，Android中的日志工具类Logcat(android.util.Log)提供了5种方法（对应5种级别），当然如有需要也可以进行重载，这里暂时不谈。先看这五种方法：
1.Log.v()
对应级别verbos，属于Android日志里面级别最低的一种。从名字可以看出，这中方法用于打印哪些琐碎的的、意义最小的日志信息（显然数量较多）。
2.Log.d()
对应级别debug，比verbose高一级。这种方法用于打印调试的相关信息，对调试程序和分析问题用很大帮助。
3.Log.i()
对应级别info，又比debug高一级。该方法用于打印一些比较重要的信息，这些信息有助于帮助分析用户行为。
4.Log.w()
对应级别warn，比info高一级。这个方法用于打印一些警告信息，提示程序在某些部分可能存在潜在的风险，例如程序流会堵死之类。最好将这些部分修复一下。
5.Log.e()
对应级别error，是级别最高的日志信息。这个方法用于打印程序中的错误信息，例如程序进入了catch语句当中（异常处理机制）。当出现E级别的日志信息的时候表示程序出现了很严重的错误，需要尽快修复。

细想一下，Log和Logcat配合之下会有怎样的效果，今天先说下给Logcat添加过滤器的方法。
正常刚打开Eclipse会有一个All message过滤器（其实就是没过滤），他会把所有的五种日志全部打印出来。另外当我们创建项目的时候，会产生一个com.xxx.xxx的过滤器，这是运行项目时自动创建的，点击这个过滤器就能看到这个项目的日志信息。这里我们尝试添加一个自定义的过滤器。

当前我们选择的级别是verbose，是前面讲过的五种级别中最低的等级，也就是说无论我们用Log.v()、Log.d()、Log.i()、Log.w()、log.e()当中的哪一种方法，这条日志都会被打印出来。以此类推，如果我们选择的控制级别是debug的话，那么使用Log.v是无法打印出这条语句的，只有用debug及以上的方法才可以。换个角度说，如果我们将当前的等级控制选择在info、warn或者error，那么上面的语句也不会打印出来，因为代码中我们使用的打印方法是Log.d()。通过日志控制可以很快的定位到我们需要的信息，有效地提高解决问题的效率，确实比System.out.println()好用多了。

⑻ 请教个问题：日志文件的过滤器怎么使用啊

过滤... 按钮可选择要包括在日志中的特定类型的记录。日志有五个级别：严重警告 –最小的详细版日志记录级别权，其中包含重要系统错误（如病毒防护未能启动，个人防火墙不起作用等）错误 – 诸如“下载文件时出错”之类的错误和严重错误警报 – 警告消息和错误信息性记录 - 包括成功更新、警报和错误在内的信息性消息诊断记录 - 最详细的级别，包括程序微调需要的信息和上述所有记录

⑼ Windows10事件查看器->Windows日志->系统->筛选日志，然后我想搜索一下开关机记录。

如果你只是想查看一下，从昨天关机到今天开机之间有没有人使用我的计算机， 那么使用“查日志”的方法就可以了。在“开始”菜单的运行”中输入“eventvwr.msc”， 打开事件查看器，在左侧窗口中选择“系统”，从右侧系统事件中查找事件ID为6005、6006的 事件（事件ID号为6005的事件表示事件日志服务已启动，即开机，同理事件ID：6006表示关机）， 它们对应的时间就分别是开机时间和关机时间。 如果你觉得从这么多事件中找开关机事件太费事，你可以使用“筛选”来使内容简洁。 在事件查看器的“查看”菜单中选择“筛选”选项，在属性对话框中选择“筛选器”选项卡， 并在其中勾选“信息”、“警告”、“错误”三项，在“事件来源”下拉列表中选择“eventlog”， 单击“确定”按钮后，系统事件中的内容就少了很多，我们可以轻易找到最近的开关机时间。 如果你依旧觉得太费事，那在“开始”菜单中的“运行”中 输入“C:\WINDOWS\schedlgu.txt”，在打开的schedlgu.txt文件中有“任务计划程序服务” 已启动于和“任务计划程序服务”已退出于的时间，分别对应着开机和关机时间，是不是很方便呢？ 天天备案也不难 如果你想每一次开关机都能清楚地记录在案，那可以用“脚本+批处理”的方法。不过你要亲自动手了， 我们使用“脚本+批处理”的方式来实现。只需在开机、关机脚本上添加两个记录时间的批处理命令， 让它们随系统启动或关闭记录当时的时间到C:\aaa.txt文件中。 首先新建两个文本文档，分别用来记录开机和关机信息，输入以下的命令，然后另存为“.bat”文件 就可以了。其中开机批处理（start.bat）如下： @echo off (echo ***开机记录*** echo.&echo %date% %time:~0,-3% %username% echo.&echo ************** )>>c:\aaa.txt 而关机批处理(shutdown.bat)命令只要把start.bat中的“***开机记录***”改为“***关机记录***”即 可，其余不变。将上面的两个批处理命令做好后，在“开始”菜单中的“运行”中输入gpedit.msc， 打开组策略，依次找到“计算机配置→windows设置→脚本(启动和关机)”，双击“启动”， 在属性对话框中单击“添加”按钮，并在“脚本名”一栏中填入“start.bat”的绝对路径， 单击“确定”按钮。同理设置好关机脚本。这样可以了，开关机做个实验， 打开C:\aaa.txt文件，是不是记录了你刚才的关机和开机时间呢？