日志管理与分析的十个最佳实践
2016-01-30 18:13:14 来源： mengyidan1988 评论：0 点击：
这是准确管理与衡量日志记录的最高效方式；本文将带你快速了解通常如何利用Docker及容器来创建易于管理、测试及部署的软件镜像包。 过去十年来，随着分布式系统的发展，日志数据管理起来更加复杂。如今，系统中可以容纳数以千计的服务器实例或者微服务容器，而所有这些实例或容器又会生成自己的日志数据。随着以云为基础的系统快速出现并占据主导地位，由机
这是准确管理与衡量日志记录的最高效方式；本文将带你快速了解通常如何利用Docker及容器来创建易于管理、测试及部署的软件镜像包。
过去十年来，随着分布式系统的发展，日志数据管理起来更加复杂。如今，系统中可以容纳数以千计的服务器实例或者微服务容器，而所有这些实例或容器又会生成自己的日志数据。随着以云为基础的系统快速出现并占据主导地位，由机器所生成的日志数据呈爆炸性增长。而日志管理随之成为现代化IT运营中的重要任务，为包括调试、生产监控、性能监控、支持援助与故障查找之类的许多用例提供辅助支撑。
尽管分布式系统在可扩展性方面十分高效，但在日志数据管理方面，甚至在定位所需的日志文件时，都很难确定要从哪开始或者需要花费多少努力。与日志工作连接最紧密的团队，比如IT管理员或DevOps专家面临巨大的挑战：在确保安全与遵守协议的同时，对分散的日志文件进行管理。开发者与工程师在调试应用层的问题时，会因访问生产层日志文件的障碍而受限。另外，运营、开发、数据科学家与支持团队需要从用户行为中分析趋势、查找故障，而这些领域缺少技术专家，有时候需要利用日志数据。基于这些挑战，要为公司选择一个日志实现解决方案，关键在于考虑最佳实践。
1. 设立策略
日志记录不可盲目，要对所记录的内容以及这样做的原因进行仔细考量。就像其他重要的IT组件一样，记录日志是需要策略的。在构建DevOps设置时，甚至只是发布一个单独的新功能时，都要确保做好日志记录的计划。没有明确的战略时，由于最终需要手动管理一个日渐庞大的日志数据集，识别重要信息的过程就会变得极为复杂。
在策划日志战略时，需要从自身角度考虑什么是最重要的，想要从日志中获得什么价值。你的计划应当包含：日志的记录方式与工具，数据托管的位置，以及最重要的——具体要寻找什么信息。
2. 日志数据的结构
除了要制定策略，还要考虑日志格式，这点也很重要。如果日志格式难以理解，想要识别日志，并从中总结出见解就很困难。无论对象是机器还是人类，日志的结构都应当清晰易懂。
管理者能够通过易读的日志更容易地找到故障，有时候还能使用日志管理服务对日志数据做进一步处理，让得出的见解更有深度，数据可视化更为优秀。两种常见的日志结构格式分别是JSON和KVP（主键配对）。两种日志数据均清晰易懂，适合人类理解，并且方便记录日志的软件解决方案从半结构化的格式中提取信息。
3. 日志数据的分离与集中
日志应当由系统自动收集并发送到集中的地点，与生产环境相分离。合并日志数据促进管理的有序与分析能力的增强，管理者能够有效地运行交叉分析，并识别不同数据源之间的关联。将日志数据集中化同时也降低了在自动扩展环境中损失日志数据的风险。
将日志数据转发到统一的位置后，系统管理员可以授权开发者、QA和支持团队访问日志数据，而无需赋予他们访问生产环境的权限。因而，这些团队可以使用日志数据调试，但不会有影响生产环境的风险。复制与独立化的日志数据也解决了相应的安全漏洞，避免攻击者删除日志数据，就算系统被破坏了，日志仍是安全的。
4. 端对端记录日志
为了简化定位故障的复杂度，在应用和系统层面获得更全局化的观点，应当在所有系统组件中监控并记录日志。大多数人都知道要记录服务器日志，比如Windows的安全日志。但是，在底层基础架构、应用层面和终端用户客户端记录所有相关的指标与事件也同样重要。
端对端日志记录让管理者得以从终端用户的角度了解系统性能，比如网络延迟、数据库事务处理延迟与页面加载时间。在这些地方清楚明了有利于提供无缝的用户体验。
5. 相关数据来源
将端对端日志统一记录到集中的地方，就可以动态聚合不同来源的各类数据流，比如来自应用的、服务器的、用户的和CDN的，从而分析得到相应的关键趋势与指标。这些关联的数据可以让管理者快速准确识别并理解导致系统故障的事件。例如，实时发现基础设施资源使用与应用出错率之间的关联，能够协助管理者在终端用户受到影响前先一步识别出异常与影响。
6. 使用唯一标识符
在调试、支持救援与分析中使用唯一的标识符非常有用。通过标识符可以追踪特定的用户会话，并精确地找出某个用户的活动。如果知道用户的唯一ID，就能搜索到某一时段用户的所有活动。一旦用户活动出现中断，可以通过追踪整个事务来查找。
7. 增加背景信息
将日志用做数据时，考虑每个数据点的背景情况非常重要。了解用户点击了一个按钮，也许比不上知道用户具体点击了“购买”按钮。增加额外的背景能够揭示购买模式。如果用户的购买请求出现错误，相应背景也能让问题更快解决。
8. 执行实时监控
服务中断会引发一系列不幸的结果，包括引发用户不满、购买意向流失与数据丢失。一旦出现生产层面的问题，在这个争分夺秒的时刻，实时监控非常重要。
除了发布简单的通知之外，能够实时分析问题与识别重要信息也同样重要。在日志数据中能够查看“实时轨迹”，使开发者和管理者能够在用户与应用或系统互动时分析日志事件。搜索并报告“实时轨迹”还能让支持团队对用户的问题进行分析与解决。
9. 使用日志来识别关键趋势
查找故障和调试只涉及了日志数据提供的表层信息。之前，查找日志曾因过于费劲，而被认为是查找信息的最终手段，而如今的日志服务可以让所有人——包括开发者、数据科学家都能从应用和系统中识别出有用的趋势与关键的见解。
将日志事件当作数据，使得对用户事件和系统活动执行统计分析成为可能。计算平均值可以让管理者更好地识别异常。将事件类型分组并求和，可以按时间线来比较事件。这种程度的分析会让管理者可以更好地基于数据作出商业决策。
10. 增强整个团队
只开放给高级技术团队的日志管理与分析服务严重限制了公司从日志数据中获得好处的机会。日志管理与分析工具应当能让开发者实时追踪调试，让管理者实时收到警报，让数据科学家集合数据并可视化，让支持团队执行实时搜索与筛选，而无需赋予他们访问生产环境的权限。
现在呢？日志管理与分析的未来
随着应用与系统在规模和复杂度上继续扩大，日志解决方案在各类规模的公司中逐渐成为必需。随着日志管理实践的成熟，日志工具的功能——比如集中化日志、搜索、筛选和实时警报都逐渐成为现代化OpsDev团队的需求。越来越多的公司开始执行这些解决方案，真正的企业价值会通过对聚合性的、实时日志数据分析所提供的见解来实现。在传统调试和查找故障之外，分析各系统、各应用与用户的关键趋势能够为提高运营、降低成本和创造新收入项增加机会。数据https://dzone.com/articles/10-best-practices-for-log-management-and-analytics-1就在那里，它们将对公司业务产生最大的影响，现在需要公司来选择是否使用它们。
原文链接：10 Best Practices for Log Management and Analytics（译者/Vera 责编/钱曙光）
过去十年来，随着分布式系统的发展，日志数据管理起来更加复杂。如今，系统中可以容纳数以千计的服务器实例或者微服务容器，而所有这些实例或容器又会生成自己的日志数据。随着以云为基础的系统快速出现并占据主导地位，由机器所生成的日志数据呈爆炸性增长。而日志管理随之成为现代化IT运营中的重要任务，为包括调试、生产监控、性能监控、支持援助与故障查找之类的许多用例提供辅助支撑。
尽管分布式系统在可扩展性方面十分高效，但在日志数据管理方面，甚至在定位所需的日志文件时，都很难确定要从哪开始或者需要花费多少努力。与日志工作连接最紧密的团队，比如IT管理员或DevOps专家面临巨大的挑战：在确保安全与遵守协议的同时，对分散的日志文件进行管理。开发者与工程师在调试应用层的问题时，会因访问生产层日志文件的障碍而受限。另外，运营、开发、数据科学家与支持团队需要从用户行为中分析趋势、查找故障，而这些领域缺少技术专家，有时候需要利用日志数据。基于这些挑战，要为公司选择一个日志实现解决方案，关键在于考虑最佳实践。
1. 设立策略
日志记录不可盲目，要对所记录的内容以及这样做的原因进行仔细考量。就像其他重要的IT组件一样，记录日志是需要策略的。在构建DevOps设置时，甚至只是发布一个单独的新功能时，都要确保做好日志记录的计划。没有明确的战略时，由于最终需要手动管理一个日渐庞大的日志数据集，识别重要信息的过程就会变得极为复杂。
在策划日志战略时，需要从自身角度考虑什么是最重要的，想要从日志中获得什么价值。你的计划应当包含：日志的记录方式与工具，数据托管的位置，以及最重要的——具体要寻找什么信息。
2. 日志数据的结构
除了要制定策略，还要考虑日志格式，这点也很重要。如果日志格式难以理解，想要识别日志，并从中总结出见解就很困难。无论对象是机器还是人类，日志的结构都应当清晰易懂。
管理者能够通过易读的日志更容易地找到故障，有时候还能使用日志管理服务对日志数据做进一步处理，让得出的见解更有深度，数据可视化更为优秀。两种常见的日志结构格式分别是JSON和KVP（主键配对）。两种日志数据均清晰易懂，适合人类理解，并且方便记录日志的软件解决方案从半结构化的格式中提取信息。
3. 日志数据的分离与集中
日志应当由系统自动收集并发送到集中的地点，与生产环境相分离。合并日志数据促进管理的有序与分析能力的增强，管理者能够有效地运行交叉分析，并识别不同数据源之间的关联。将日志数据集中化同时也降低了在自动扩展环境中损失日志数据的风险。
将日志数据转发到统一的位置后，系统管理员可以授权开发者、QA和支持团队访问日志数据，而无需赋予他们访问生产环境的权限。因而，这些团队可以使用日志数据调试，但不会有影响生产环境的风险。复制与独立化的日志数据也解决了相应的安全漏洞，避免攻击者删除日志数据，就算系统被破坏了，日志仍是安全的。
4. 端对端记录日志
为了简化定位故障的复杂度，在应用和系统层面获得更全局化的观点，应当在所有系统组件中监控并记录日志。大多数人都知道要记录服务器日志，比如Windows的安全日志。但是，在底层基础架构、应用层面和终端用户客户端记录所有相关的指标与事件也同样重要。
端对端日志记录让管理者得以从终端用户的角度了解系统性能，比如网络延迟、数据库事务处理延迟与页面加载时间。在这些地方清楚明了有利于提供无缝的用户体验。
5. 相关数据来源
将端对端日志统一记录到集中的地方，就可以动态聚合不同来源的各类数据流，比如来自应用的、服务器的、用户的和CDN的，从而分析得到相应的关键趋势与指标。这些关联的数据可以让管理者快速准确识别并理解导致系统故障的事件。例如，实时发现基础设施资源使用与应用出错率之间的关联，能够协助管理者在终端用户受到影响前先一步识别出异常与影响。
6. 使用唯一标识符
在调试、支持救援与分析中使用唯一的标识符非常有用。通过标识符可以追踪特定的用户会话，并精确地找出某个用户的活动。如果知道用户的唯一ID，就能搜索到某一时段用户的所有活动。一旦用户活动出现中断，可以通过追踪整个事务来查找。
7. 增加背景信息
将日志用做数据时，考虑每个数据点的背景情况非常重要。了解用户点击了一个按钮，也许比不上知道用户具体点击了“购买”按钮。增加额外的背景能够揭示购买模式。如果用户的购买请求出现错误，相应背景也能让问题更快解决。
8. 执行实时监控
服务中断会引发一系列不幸的结果，包括引发用户不满、购买意向流失与数据丢失。一旦出现生产层面的问题，在这个争分夺秒的时刻，实时监控非常重要。
除了发布简单的通知之外，能够实时分析问题与识别重要信息也同样重要。在日志数据中能够查看“实时轨迹”，使开发者和管理者能够在用户与应用或系统互动时分析日志事件。搜索并报告“实时轨迹”还能让支持团队对用户的问题进行分析与解决。
9. 使用日志来识别关键趋势
查找故障和调试只涉及了日志数据提供的表层信息。之前，查找日志曾因过于费劲，而被认为是查找信息的最终手段，而如今的日志服务可以让所有人——包括开发者、数据科学家都能从应用和系统中识别出有用的趋势与关键的见解。
将日志事件当作数据，使得对用户事件和系统活动执行统计分析成为可能。计算平均值可以让管理者更好地识别异常。将事件类型分组并求和，可以按时间线来比较事件。这种程度的分析会让管理者可以更好地基于数据作出商业决策。
10. 增强整个团队
只开放给高级技术团队的日志管理与分析服务严重限制了公司从日志数据中获得好处的机会。日志管理与分析工具应当能让开发者实时追踪调试，让管理者实时收到警报，让数据科学家集合数据并可视化，让支持团队执行实时搜索与筛选，而无需赋予他们访问生产环境的权限。
现在呢？日志管理与分析的未来
随着应用与系统在规模和复杂度上继续扩大，日志解决方案在各类规模的公司中逐渐成为必需。随着日志管理实践的成熟，日志工具的功能——比如集中化日志、搜索、筛选和实时警报都逐渐成为现代化OpsDev团队的需求。越来越多的公司开始执行这些解决方案，真正的企业价值会通过对聚合性的、实时日志数据分析所提供的见解来实现。在传统调试和查找故障之外，分析各系统、各应用与用户的关键趋势能够为提高运营、降低成本和创造新收入项增加机会。数据https://dzone.com/articles/10-best-practices-for-log-management-and-analytics-1就在那里，它们将对公司业务产生最大的影响，现在需要公司来选择是否使用它们。
原文链接：10 Best Practices for Log Management and Analytics（译者/Vera 责编/钱曙光）
上一篇：基于Google Drapper的开源分布式应用追踪分析系统——Sky Walking
下一篇：未来编程的9大猜想
分享到：
收藏
收藏
