客户在项目中常会遇到一些难题，多数情况是由于对产品理解或使用方法不当导致的，这些问题常常通过技术支持的热线电话就能解决。
但有些问题现象并不是很容易被描述清楚，或者产品或系统一般情况下都能正常运行，有时冷不丁的出现一两次问题，然后又正常运行一段时间，然后又出问题，虽然发生频率不高但却周而复始，令人头疼。这种问题常常在办公室内又很难复现。
尤其一些大一点的scada系统经常处在开放的、复杂的it环境中，操作系统、各种服务、网络、防火墙、软件间兼容性、bug、编程或逻辑错误等等问题相互关联，想要一下寻找到问题原因，有时确实不是一件容易的事。
很多时候，这种问题凭经验可以大概圈定问题的范围，但有些时候仅凭经验也有不管用的时候，这是只能必须根据现象，一步一步的推理证明，最后发现真正原因。-----说起来容易，但做起来还是有点难度。
好在绝大多数问题或故障都会在日志中留下蛛丝马迹。依靠这些线索，复杂问题的解决，变得有章可循，好比顺藤摸瓜，这样的解决方式要比靠发散思考寻找问题的方式在实际操作层面要容易很多。
所以日志分析变成了技术支持工作的一项重要的内容。
上次有个最终客户在现场打电话说，有部分的pvss数据不更新了，无法监控这些数据，其他数据正常。
我询问是否最近有过什么变动吗? 他说之前打过几个最新的补丁，打完补丁也没注意，好像也没有发现有什么问题。这位客户对现场的情况也说不清楚。
于是索要相关计算机的日志。
发过来的系统日志包含和两台冗余服务器，客户端以及操作系统日志，解压后大概有两三百兆的大小，单一个pvss服务器的日志数目超过两百个。
用过pvss的同志们应该知道，pvss的日志系统比较有特色，会记录每个管理器非常详尽的运行信息，同时生成大量相对小尺寸的文件。
这样做的好处是可以高性能的记录系统运行细节，但却给手工日志分析带来了麻烦 ----- 有效的条目淹没在大量的日志海洋中，用眼睛筛选简直变成了一件不可能完成的任务。
这时需要借助工具来辅助分析。
pvss安装完后，就直接可以在命令行下使用功能强大的 grep 命令，再加上变化多端的正则表达式，可以实现相当灵活方便的日志查询。
先把日志集中存在一个文件夹里，比如：c:\mylog， 每个计算机的日志分别保存在这个文件夹下自己的目录中， grep可以遍历所有子目录：
例1：c:\mylog>grep 2013.10.25 10: * > c:\result.txt
查找所有含有2013.10.25 10: 的行，即2013年10月25日 10点发生的所有日志 ，输出至c:\error.txt
例2：c:\ >grep “error” result.txt > c:\error.txt
查找所有含有“error”的行，输出至c:\error.txt
例3： c:\> grep -v pvss00pmon c:\error.txt > c:\result1.txt
接上例，查找结果中，所有不含有 pvss00pmon 的行，输出至c:\result.txt
例4： c:\> grep pvss00mod result1.txt > c:\result2.txt
查找结果中，所有含有 pvss00mod 的行，输出至c:\result2.txt
根据客户给的时间范围，初筛后发现除了大量的系统信息和零星的错误，日志量还是太大，无法清晰看出脉络。
再对初筛结果进行细筛，先筛掉和本问题不相干的大量“pvss00pmon”等日志条目，这时modbus和其他一些模块的一些编程组态错误日志较频繁的出现在筛选后的结果中。
再次筛选，选条件为pvss00mod，筛掉和modbus不相关的内容后，这时清晰地看到modbus模块发生问题的来龙去脉。
最后根据日志分析，发现原来问题是：新补丁中对modbus内部dp点的数据结构走了升级，在打完补丁后，需要对该dp点的数据结构也进行升级。
经查，客户反应的scada中无法监控的数据也确实都来自于modbus驱动。
找到问题后，手动升级了相应dp的数据结构后，问题得以解决。
grep这样的工具给我们提供了很大的便利。而且它不仅适用于pvss，也可以分析各种产品的文本日志文件，多文件间的关联查询。当然除了grep外，还可以使用第三方的图形化日志分析工具。
但grep命令的好处是可以在各种操作系统中直接使用，比如solaris，redhat系统自身直接带有这个命令，和 pvss的安装没有关系，只是windows下本身没有这个命令。