Vista211
日志的作用是非常强大的，类似一个指引，留下蛛丝马迹，让运维人员根据线索找到出问题的地方。日志作用主要体现在以下地方:
1.记录各种操作记录。用户的登录、注册、页面调转、点了什么按钮、返回什么消息，都会被详细记录在系统日志中，这种日志类似于监控，能谁来谁去都能理清楚。
2.记录问题。系统出问题后，系统会将错误记录在日志中，同时结合用户至少得操作记录，就能比较容易还原错误发生过程，判断错误出现的地方。
日志对于系统来说是非常重要的，特别是银行机构，支付宝这类系统，日志都要备份并且长时间保存。还要定期对日志进行分析，发现潜在问题，因为有的bug不会导致系统崩溃，但是会留下系统隐患。有需要的还是最好安装日志分析软件，全方位监控。
学会用日志分析吧。
我是ppt小助手，有问题可以一起讨论。
PPt小助手
日志分析是IT运维领域非常重要的一部分工作。
甚至可以说，在平台化、模块化、服务化盛行的今天，这部分工作的重要性已经逼近传统的设备监控。
不过日志由于来源、使用者、管理者都比设备指标要复杂，导致日志分析的功能需求，也庞大很多。
而且国家市场监督管理总局、国家标准化管理委员会发布了《GB/T22239-2019网络安全等级保护基本要求》等标准（以下简称：等保2.0），并将于2019年12月1日正式实施。《网络安全法》中要求相关网络日志留存不少于6个月，而在等保2.0中对日志管理要求更加严苛，三级通用要求中新增了日志集中管控及分析。
国家对日志管理要求的升级，意味着公共通信和信息服务、能源、交通、水利、金融、公共服务、电子政务等重要行业和企业，均须开展日志合规留存管理工作。安全合规要求改变了日志在IT运营管理中作为“事后追责”助手的定位，日志将成为构建“事前预防、事中响应，事后审计”动态保障安全体系的关键工具。
根据IT运维管理的安全建设需求，在日志采集阶段就需要做好统一规划，使得采集后的日志数据能够满足监管部门的合规审计。
- 按照日志来源主机不同设定主机及主机分组计划；
- 在日志数据采集模块为日志做好标签管理规范，记录其所属分类，以便后期进行日志分组和统一管理；
- 按照日志数据来源分类进行日志分组管理：安全设备、网络设备、应用系统、数据库等；
- 日志数据采集后，按需对源端日志做好备份或者清除工作。
基于安全可控的日志数据集中留存管理
IT管理部门需要做好日志数据的合规留存，方便监管部门进行安全事件事后审计和取证工作。
通过对日志数据的集中管理，为安全事件提供日志视角的端到端可见性，简化安全事件运维管理工作流程，快速定位事故根源。
- 按照用户部门和角色设定不同的日志数据管理权限，并根据故障定位、风险预测、安全事件事后定责等不同使用场景，设计多索引日志数据处理流程，满足各部门用户对日志数据的分析需求。
- 通过对已留存的安全事件日志进行关联分析，快速定位事件根源，满足事后审计和追溯取证的需求。
- 基于对日志数据的全程监控，可设置可触发故障和安全事件的告警规则，实现安全事件的实时响应。
- 可构建基于对过往告警日志、异常日志等全量日志的机器学习算法模型，实现事前预防：预测异常，及时采取措施进行防范。
莫非8125
一个成功的软件，全力开发的时间可能占其整个生命周期的1/4还不到，软件发布后要运维（Operation），运维的视角和开发的视角是很不一样的，但是有一点，运维的数据能反哺开发，同时，开发的时候也得考虑可运维性，其中非常重要的一点是日志，没有日志，运维就瞎了大半。怎么写日志，就得从运维的需求来看了，通常会有以下一些常见的场景（已典型互联网应用为例）：
1. 访问来源，包括访问量，访问者数据，如用户名、IP等等。
2. 基于上一点细化，访问的接口，读、写、删……
3. 软件系统内部的核心链路，比如我这有个系统要在中美直接同步文件，那同步的情况运维的时候就要掌握。
4. 软件系统对其他所依赖系统的访问情况，比如我这个系统依赖一个分布式缓存，那访问缓存的量、是否超时等情况需要了解。
5. 系统异常，比如磁盘满了。
记录这些信息的目的大抵有：帮助分析系统容量方便扩容；在系统某些部分工作不正常的时候及早发现；发生严重故障后方面定位问题原因。认识到这些需求后，下一步就是怎么实现的问题了。
前面提到的5点，有些可以通过抛异常实现，例如访问分布式缓存超时，有些则显然不是异常，例如就是正常的缓存访问。我觉得可以用一种统一、规范的方式记录，这种方法就是打码。我记得以前用Windows 98/2000的时候，经常会遇到蓝屏，蓝屏上会有一堆我看不懂的英文，并且总是伴随着一个错误码。
wKiom1NXNhnx3_ZtAAEhc2Zcxtc720.gif
虽然我看这玩意儿没一点好心情，但我相信微软的工程师肯定能从那个奇怪的状态码上判断出是哪里出了问题，硬盘坏道？光驱卡死？诸如此类……其实类似的做法数据库也用，比如MySQL。
用统一的代码表示错误（也可以表示正常但核心的业务点）最大的好处就是便于搜索、统计和分析，在动辄数以万行记的日志文件中寻找感兴趣的信息，一页一页翻看是不现实的，稍微做过点运维的必然会用上 grep,awk,wc 等工具，这个时候如果信息都有代码标识，那真是再方便不过了！例如，我用代码 FS_DOWN_200 表示对系统的正常下载访问，日志是写在 monitor.log 文件中的，我就可以使用一行shell统计4月22号5点到6点之间的正常访问量：
$ grep FS_DOWN_200 monitor.log | grep "2014-04-22 05:" | wc -l
具体每条日志记录什么，那就是更详细的了，基本就是时间、日志编码、额外的有用信息，如：
2014-04-22 05:06:18,561 - FS_DOWN_200 216 UT8TFSDXc8XXXagOFbXj.jpg
除了时间和日志编码外，还有响应时间（216ms）和具体访问的文件名。
当然如果你有日志监控和分析系统就更棒了！你就可以在系统中录入关键字监控，比如每分钟统计次数，然后看一天、一周的访问量趋势图。进一步的，如果这个量发生异常，让系统发出报警。如果没有关键字，从海量日志中分析纷繁复杂形态各异的信息，再监控，是非常难的一件事情。
为什么要把日志代码设计成 FS_DOWN_200 这样子的，下面稍微解释下，这个代码分成三段：
1. FS： 表示我们的系统，这是最高的级别，公司中有很多系统，那各自定义自己的标识。
2. DOWN： 表示我们系统中的一个核心业务点或者对其他依赖系统的访问，还可以是UP（上传），SYNC（同步），或者TAIR（对缓存系统访问）。
3. 200： 具体健康码，参考HTTP规范，200表示OK，其他包括404（不存在），504（超时）等等。
有了这些代码，再结合公司的监控系统，我们做统计分析就非常方便了，每天多少下载、多少上传、多少成功、多少失败、对其他依赖系统访问多少量、多少失败率，一目了然。进一步的加上监控，当某些值突然发生变化，比如下载量/上传量暴跌、访问其他系统依赖超时大量增多，就能及时响应。
日志对于运维实在太重要了，而如果不接触运维，又怎能理解其真正的需求，因此我说，不做运维，不懂日志。
不一样的程序猿
通过查看日志数据，运维人员能够了解服务器、软硬件、用户行为等详细信息，从而快速发现故障原因或者对未发生的故障进行预警，提升运维的效率。云帮手通过采集从源头请求到底层系统的所有中间环节日志数据，方便运维人员随时追踪查看，帮助快速找到系统性能消耗的原因、定位异常并解决问题。
云帮手官网地址https://www.cloudx.cn/?utm_source=wu-wk
cloudman
开发人员在查找问题时最为关键的一环，如果没有日志信息，再牛逼的开发者也无法定位到准确的原因，从而去解决它
