应用日志格式要求
为了更好的监控应用，有效的监控手段之一是日志监控。根据我行的应用特点，应用日志应当分为交易日志、错误日志及批处理日志。
一、分类型监控日志的目的
（一）交易日志：
1、统计交易响应
根据每笔交易的开始、结束时间，分析出交易的响应时间，并实时分析交易响应的变化。
2、统计交易量
根据交易发生的交易报文等信息进行交易量实时分类统计。以交易日志统计的方法，能够完成实时显示应用系统交易量的需求，而又对应用系统的影响最小。
3、分析交易过程
根据交易日志，对交易发生过程进行整理、分析，从交易过程的角度更高效的定位应用问题。
4、分析交易成功率
根据日志中对每个交易的返回信息统计，可以实时计算出单位时间的交易成功率。
（二）错误日志：
1、实时错误报警
实时对错误进行报警，尽早将应用中出现的隐患暴露出来，并根据错误码翻译，在监控平台展示，方便运维人员快速的初步定位问题，与开发人员沟通，在问题排查和解决过程中，尽可能多的争取时间。
2、异常分类及分布分析
根据异常分类，对应用系统发生异常的种类和发生趋势进行分析。
3、与交易过程结合分析
问题排查过程中的重要手段，快速排查交易问题根源。
（三）批处理日志：
1、批处理问题报警
根据日志输出信息，对批处理过程中出现的异常信息进行实时报警。
2、批处理时长分析
根据日志中获取的信息，可以对批处理发生时长进行环比，并可以在批处理时间超过平均时间时进行报警。
3、批处理步骤完成情况分析
二、日志输出要求
根据前述部分的应用日志运维目标，各类日志需要具备如下的要素，以便实现生产环境各类监控、分析目标。
（一）交易日志：交易时间字符串是什么
1、单一的日志输出文件
无论多线程或者多进程架构的程序，需要使用可以控制数量的日志文件记录交易日志，避免产生每个交易生成一个文件，无法预测日志数量及文件名的情况。每个交易都生成一个文件的情况不利于自动的日志收集，需要尽量避免。
例如，JAVA中，经常会使用循环文件记录日志，比如10M一个文件，10个文件为限。这种方式不仅能够控制日志文件个数，且能够控制文件系统的占用。
2、完整的交易开始结束标识
每个交易无论成败或是否出异常，应当具备明确、完整的“开始”、“结束”的标识，能够在日志分析中明确的出每笔交易的开始及结束来区分交易。
3、唯一的交易识别代码
由于日志文件可能是由多个线程或者进程所控制，因此，每个交易日志在开始、结束期间，
每行日志都应当具备唯一识别的交易代码，比如线程ID或者进程ID。
4、交易报文信息或本地交易信息
每个交易可能是联机交易，也可能是本地的交易，对于日志而言，联机交易应当具备交易报文信息，本地交易应当具备交易内容信息。
联机交易需要将报文输出到日志文件，而本地交易应当具备的内容至少要包括本地交易的交易码（或者说，确定交易的字符串）。
5、日志输出时间
我们根据日志输出时间来定义交易时间，因此，每行日志输出应当包括日志记录的时间，时间需要精确到毫秒。
交易日志定义及示例：
日志格式：
<TIMESTAMP><ThreadID/ProcessID><Class/File><Level>[交易信息，可能为开始/结束/报文/异常信息等等]
Timestamp：时间戳，精确到毫秒
ThreadID/ProcessID：线程或者进程ID，确定整个交易开始到结束的唯一标识
Class/File：执行交易的类型或者文件
Level：日志级别
交易信息：
◆开始信息：Transaction Start
◆结束信息：Transaction End
◆报文或其他确认交易信息：Message:xxx|xxx|xxxxx
◆异常信息：级别为Error或以上级别都会认为是异常信息，异常信息的开头必须是异常信息
的错误码。
◆交易中其他信息不做特殊要求
可能输出的示例：
[2012-09-04 17:00:00, 001] [123456] [com.srcb.package.Clazz] [INFO] Transaction Start
[2012-09-04 17:00:00, 011] [523576] [com.srcb.package.Clazz] [INFO] Transaction Start
[2012-09-04 17:00:00, 381] [523576] [com.srcb.package.Clazz] [INFO] Message:xxxxx|xxxxx
[2012-09-04 17:00:00, 998] [123456] [com.srcb.package.Clazz] [INFO] Message:xxxxx|xxxxx
[2012-09-04 17:00:02, 741] [523576] [com.srcb.package.Clazz] [INFO] Transaction End
[2012-09-04 17:00:03, 093] [123456] [com.srcb.package.Clazz] [INFO] Transaction End
（二）错误日志
1、错误码对照
每个应用在设计之初就应当有自己的异常设计，每个抛出的异常应当具备针对所开发应用的错误识别码。其中应当包含业务异常及技术异常。
1）业务异常
标识业务中出现的异常信息，比如，用户余额不足、密码输入错误等等。
2）技术异常
所有的非业务异常，影响到业务正常处理的都应当归类到技术异常当中去。
在项目上线的时候，应当提供完整的异常对照表，根据错误日志中的输出，应当都可以对应到错误码中。每个错误码在对照表中都必须有相关的中文解释，明确可以判断原因的错误必须有相应的解决方法对照（比如，JAVA类程序中OutOfMemory错误在绝大多数情况下都需要重新启动进程；WEB程序中出现Servlet错误可能导致应用不可用，但从进程角度确无法确
定问题）。
2、错误日志内容与交易日志的关系
1）与交易相关的唯一标识
发生在交易过程中的错误信息，在输出错误日志的时候，必须包含程序线程ID或者进程ID，用以标识错误发生的
2）异常发生时间
为了与交易过程进行关联，每个错误输出必须包含异常发生时间，改时间需要精确到毫秒级。
日志示例：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。