一、前言
在日常个人开发中，有类似vs这样强大的IDE就可以方便地随意跟踪和debug。然而很多时候，错误和异常是发生在生产线上，而且并不是必然重现。对付这种类型的bug，在生产线上又没有（且不能有IDE）的情况下，跟踪和修复是极为困难的事情。因此，日志变得极其重要。
日志好像很简单，就是程序运行到哪里，记录一些文字就ok了，它的实质也的确是如此，但如果不注意细节，到了实际的开发遇到真正问题要找日志的时候，你会遇到很多麻烦。
二、日志记录设计
随着你开发的进度，如果不及时清理旧有无用的日志（有些日志甚至是在开发时临时加上的），会令到你的日志文件变得臃肿、冗余，而且大部分都是无用的记录，这些都会导致定位问题困难。因此在开发时，除了设计程序结构，也要考虑到设计记录日志的地方。日志的设计除了记录日志的地方，还要考虑记录日志的级别，比如log4net就有Info、Debug、Warn、Error、Fatal，根据不同的情况输出不同级别的日志。下面就讲述在程序中使用日志开发应考虑的几点：
1、日志配置文件
一般的日志框架都会有跟随一个配置文件，它可以控制日志的输出内容格式、输出方式（文本）、输出的日志级别等等。通常一个程序对应一个配置文件是正确的。但在web的服务器上，通常我们会使用多台服务器做负载均衡，同样的一个web程序就会放置在不同的服务器上面，那样他们在正常情况读的都是同样的日志配置文件。有的设计为了方便，就把这些日志的配置文件放置到一个地方（如数据库），然后所有web程序都读取这个配置文件。这样做法有利有弊，利就是当修改日志配置文件时，修改一处即可；弊就是无法对个别web程序做差异化配置。
因此我们为了兼顾差异化配置， 可以用如下顺序读取配置文件。
Web程序 -> 先读取web本地的配置文件 -> （如本地文件不存在）再读取公共配置的日志文件。
其实很简单，中间多一步处理就可以兼顾日志文件的差异化配置。
2、记录日志级别
上面也有提到log4net本身就提供Info、Debug、Warn、Error、Fatal 5种的日志级别。但我个人认为，用3种即可：Info、Debug、Error。
Info：记录程序运行是否已到达某处；关键函数的执行始末；调用第三方函数执行的始末；关键函数的执行时间。
Debug：记录每个函数（方法）的输入和输出。
Error：程序异常，除了记录程序的Exception内容之外，还要记录导出此次异常的输入参数。
关于Error，log4net会把整个异常的StackTrace打印出来，因为StackTrace内容太多，我们可以考虑Error也分开2个日志文件，一个放置我们的内容（出错函数名、输入参数、必要信息）；另一个放置Exception的详细内容。
鉴于上面的分析，我们的日志产出的文件可以有3个：
- Info级别的日志
- Debug级别和Error级别（我们自定义内容）
- Error级别，专门存放Exception详细内容的日志。
3、记录日志内容格式
这个一般是按个人喜好和团队习惯来定义，一般一个团队最好都用一个格式来定义，起码大家都能看懂。但无论用什么格式，我对日志格式有几个建议：
- 一条日志内容应该都在一行，无论使用shell的grep还是powershell的select-string、cmd的find，这会都会方便的定位日志内容。
- 日志内容都用英文，因为如果用中文的话，打开日志文件的时候会有可能有了乱码的问题，虽然有些命令行可以指定打开日志的编码，但始终会大为不便。
- 日志文件命名，除了时间，要加上程序和服务器的名称。下载下来的时候，可以一眼知道此日志文件的来源。
4、避免写日志锁定
在记录日志的时候，尽量不要锁定日志文件。有的情景，需要不同程序写入同一个日志文件，这样就会导致文件被一个程序锁死而其他程序无法写入日志的异常。
三、定位日志内容
有了日志记录，有问题的时候，那当然要搜索日志文件。看似很简单，直接打开文本Ctrl + F不就完了吗？其实不是，在实际开发情况日志文件都在远程的服务器，而且日志文件有时大至几百兆，打开很困难。
查看日志的方式有几个：
- 使用shell语言的话，直接使用grep指令即可。使用tail –f 可以跟踪日志文件
- Window2003本身没有tail指令，但可以安装Windows Server
2003 Resource Kit Tools来获取tail指令。Window的远程cmd可以通过psexec来实现。