访问日志的格式：
源、目标IP、目标端口、用户名、程序名、资源对象（文件或目录）、传入或传出字节、时间
日志的记录机制：
- 传输
- 语法与格式
- 事件分类学
- 日志记录的设置、配置和建议
日志格式：
各种日志机制的优缺点
良好的日志记录标准
- 发生了什么 What 适当的细节信息
- 何时发生 When 开始时间和结束时间
- 发生在何处 Where 哪台主机、什么文件系统、哪个网络接口
- 谁参与其中 Who
- 参与者来源 Where
日志的级别：debug、info、notice、warn、error、critical（临界条件）、alert、amergency
使用logrotate进行日志切割和压缩。使用syslog-ng进行syslog日志同步、匹配、处理.并且支持db日志解析、非结构文本、消息队列等日志解析。
日志挖掘
日志法则：
- 收集法则：不要收集你从不计划使用的日志数据。不要收集觉得以后会使用的日志
- 留存法则：只要觉得有可能用到，就尽可能长时间地留存日志数据，如果有法规规定，还应该保留更长的时间。
- 监控法则：记录你所能记录的一切（尽可能多），但是只在你必须响应时发出的警报（尽可能少）。
- 可用性法则：不要花费精力，将你的日志记录或监控系统的可用性提高到超过业务系统水平
- 安全性法则：不要花费比保护业务数据更多的精力去保护你的日志数据。
- 不断变化法则：日志记录、管理、分析领域中唯一不变的是日志来源、日志类型和日志消息都在变化。
日志错误
- 不记录日志，甚至不知道日志是什么，等到想起来时一切已经太迟了。
- 不查看日志数据，应定期查看日志数据。或者设置监控
- 保存时间太短。在经济条件允许的情况下，尽可能时间长的保留日志。
常见的角色和职责：
工程师角色与职责
日志类型的基本原则
日志轮转机制
- 使用日志轮转（logrotate）管理日志何时轮转，何时存档到某个外部存储位置
- 应用程序本身负责处理日志轮转，这可以通过定制编写的应用程序代码，或者使用第三方日志记录库的内建功能。
- 可以基于时间、大小、大小和时间
日志记录的坏习惯
who：日志的发起人
what：对象有助于指出受到影响的系统组件或者对象是什么
status：针对对象的操作是成功还是失败
where：系统、应用程序或者组件有助于回答何地的问题，必须提供相关应用程序的上下文。
from：对于和网络连接性或者分布式应用程序操作相关的消息，源有助于回答来自何处
time：时间戳和失去回答何时问题，时区对分布式应用不可或缺的，对于某些高容量系统还使用事务ID
reason：原因有助于回答“为什么”问题，这样日志分析就不需要深入地挖掘潜在的原因
operation：操作有助于回答“如何”的问题，他提供了事件的特性。
level：优先级有助于表明事件的重要性。
session_id:唯一的会话ID有助于集合不同线程和进程的相关信息
process_id/thread_id:关联运行应用程序以及日志记录
不应记录到日志中：
- 密码（数据库，用户）
- 社会安全号、身份证、学号
- 生日、电话号码、全名、信用卡号码、驾驶证号码、基因信息、保险信息、任何类型的标示号码、生物计量学信息
日志级别
INFO、DEBUG、WARN、ERROR、FATAL。其中debug的日志可以通过参数打开或关闭。
INFO：用于记录常规处理消息和应用状态，譬如：初始化、关机、持久化资源分配。属于正常操作项。每个软件至少应该有以下几项：
- 系统何时启动初始化
- 何时变的可操作
- 何时关闭
- 终止之前的信息
日志实践清单
创建日志
- 使用标准并且配置简单的日志框架。譬如：log4j, log4net,zap 。 修改配置要比硬编码要快
- 使用具有灵活选项配置输出的框架。这样就能更好的集中注意力开发，不用写额外的日志插件
- 使用标准结构的数据格式：JSON。自定义的数据格式和文本不利于数据ETL分析。统一日志结构也利于阅读。
- 为数据字段添加标准的scheme，统一日志格式。
- 不要让日志阻塞应用程序正常运行；使用异步写日志
- 避免被vendor锁定（厂商陷阱）。不要直接使用标准库或者是包装器来保证可移植。
- 注意PaaS或基于容器的环境中的限制。譬如容器对主机syslog访问限制
- 不要忘记旧的应用程序日志。旧的应用程序也需要跟踪
- 尽可能全的提供此条日志的上下文，帮助使用者理解是如何产生的
- 使用日志级别区分日志
- 日志应注意是写主要的日志，不要累赘。日志的质量应和代码一样重要
- 给日志添加唯一标识符。（分布式链路跟踪，在大规模系统中很重要）
传输日志的最佳做法
- 使用可容错的协议。使用TCP或RELP协议代替UDP，毕竟UDP会丢包
- 发送失败自动重试。不可靠的协议和编写不正确的库可能会意外丢失日志。
- 日志支持本地存储，网络中断时也能保证不丢日志。同时可以缓轻服务端压力。好的日志收集agent支持本地存储队列
- 不要让日志应用程序用完所有的内存或者存储空间。（资源限制）
- 传输过程中使用数据加密（HTTPS）
- 传输前要过滤掉敏感数据（通过不记录敏感数据或者是，进行数据清洗）
- 日志发送时要裁剪为小日志，防止日志文件。日志发送应只发送增量数据，已经发送的不重复发送
- 监控是否有日志积压(Backlogs)（防止因为网络问题导致数据丢失）
- 配置代理和防火墙。检查syslog防火墙端口和路由配置，让可以访问网络
- 使用配置管理系统来管理日志应用。譬如使用Ansible, Puppet来管理大规模日志服务
日志管理
-
预先检查IT的安全要求，防止日志记录一些敏感信息
-
将日志存储在数据中心之外。（在停电和火灾期间，你可能也需要日志，将它们存储在其他可用区域）
-
比较自己维护，云托管和SaaS的服务。那种成本低或者可靠。开源不是免费，要考虑存储、计算、维护、带宽成本
-
在作出决定之前，先争取系统用户的同意。（让最终用户尝试这些选项，而不是做出自上而下的购买决定）
-
请记住，用户体验问题是破坏交易的因素（如果最终用户发现难以使用的工具，他们将避免使用该工具）
-
日志收集的延迟要尽量的小。实时日志（低延迟对于实时监控和故障排除很重要。）
-
尽量支持日志的复杂查询和查询性能。（小规模的日志查询测试是没有意义的，要多点日志测试）
-
何时自建或者云服务，优化查询性能（没有人希望性能降低。添加热/冷节点并优化分片大小和索引以提高速度。）
-
提取时自动解析日志。在搜索时解析日志特别的慢，自动规则比自定义规则节省时间
-
尽可能的可以继承到用户的工作流（workflow）中。可用性！=有效使用。用户需要理解它并使之适合他们的工作流程。
-
为您的团队设置常见的搜索，仪表板和警报。如果您的团队看到日志是有价值的，并且可以在此基础上继续发展，那么更容易从您的团队获得支持。
-
日志的核心是指标。指标是属性在特定时间内的特定值，通常以固定间隔进行测量。
- Timer-测量某些程序花费的时间（例如您的网络服务器响应时间）
- Meter-衡量事件发生率（例如，您网站的访问者比率）
- Counter-记录数量（例如：访问用户数）
- Gauge - 定时记录使用率。 譬如CPU