震惊kafka_5个令人震惊的统计数据证明日志不足

震惊kafka

我们都犯有记录不当行为的罪行。 不这样认为吗？ 这些统计数据可能会改变您的想法

我们不会坐在这里问您有明显答案的问题，例如，您是否使用日志文件来监视生产中的应用程序？ 我们所有人都使用日志，并且如果您知道如何查找日志，则会在其中存储有用的信息。 但是，日志远非完美。

在大多数情况下，日志并不指向生产问题的根本原因。 在本文中，我们将研究一些原因，为什么日志文件不足以为您的应用程序创建全面的监视解决方案。

让我们看一下数字。

1. 20％的错误永远不会进入生产日志

我们可以聊到日志让您对生产中的应用程序没有足够的了解为止，直到脸色发白为止，但让我们从现实检查开始。

生产中发生的异常中至少有20％根本不会将其写入日志。 滑铁卢大学的研究人员从超过100万个Java项目中提取了数据，这些项目包括1600万个catch块，并根据所采取的措施将其划分为多个组。

这是他们发现的结果：

我们可以进一步采取这一步骤，将这些动作分为3个主要类别：

1. 通过将某些内容写入日志，打印堆栈跟踪记录或将信息输出到控制台来记录发生的情况。
2. 抛出一个异常，可能是更广泛的抽象，它使调用堆栈中更深的一种方法知道如何处理。
3. 还有……什么都没有 。 吞下该异常，没有任何线索来了解异常来自何处或发生的原因。 而且看起来它甚至至少与记录日志一样频繁，这至少可以说是令人震惊的。

现在，在深入探究原木问题的实质之前，让我们花一点时间仔细阅读一下这里的数字。 在1,600万个捕获块的研究中，出现了3,067,863空块。 大约有20％的异常根本没有出现在日志中。 那不是一个很好的起点。

2.生产中的日志记录语句⅔已关闭

在基于GitHub研究的另一项研究中 ，我们可以看到Java项目的日志级别的分布。 INFO和DEBUG占了饼图的两个最大部分，加起来总共占日志记录语句的57.8％。 但是，我们知道，这些日志记录语句通常在生产中被关闭，而TRACE级别的日志又占了日志的5.2％。

Java平均日志级别分布

根据这种分布以及我们对日志使用方式的了解，我们可以确定63％的日志记录语句不在生产中运行。

到目前为止，我们已经讨论了在鼻子下发生的大量异常而没有写入日志，现在，我们讨论了在生产环境中无法访问的日志数量。

那我们从日志中得到什么呢？

3.发生错误时，超过50％的日志记录语句不包含有关变量状态的任何信息

因此，让我们谈谈我们从日志中获取的信息。

我们对开发人员使用日志的方式感兴趣，首先，确定已发生问题，其次，调查出了什么问题。 我们已经确定，使用日志文件识别错误并不完全是防弹策略。 至少有20％的例外情况根本不会写入日志，并且在生产过程中不会打开我们要添加的日志中的几分之一。 基本上，我们已经有问题了。

但是我们想知道我们应该（或不应该）将什么种类的东西放入日志中，以便当出现问题时，我们将能够对其进行修复。 理解和解决生产中的错误的常见做法是尝试重现它。 为了重现生产中的错误，对可变状态至少有一些了解是有帮助的。 再次查看数字 ，我们发现超过50％的日志记录语句不包含任何变量，其中超过95％的变量具有2个或更少的变量。 kes！

每个记录语句中的平均变量数

这意味着在日志中捕获的有关应用程序状态的信息有限，而找出实际发生的情况可能就像在日志文件中搜索针头一样。 如果它在那里。 如果不是，则必须添加日志记录语句，希望该错误再次发生，提取相关日志，并希望您捕获了正确的上下文。 此过程可能需要数天，甚至数周。

4.开发人员将25％的时间用于故障排除

现在，对于这些惊人的记录数字的含义。 最重要的是，仅仅依靠日志进行生产环境中的监视还不够。 最终，使用日志在生产中进行故障排除意味着识别和调查问题所花费的时间比应该花费的时间长得多。

我们经常听到工程团队的声音，他们的开发人员将20％，40％，50％的时间花在了故障排除任务上，这些任务使他们脱离了正在同时进行的新项目和功能。 上下文切换到故障排除模式的成本是真实的。 通过查看平均值 ，我们发现他们有25％的时间用于解决（或尝试解决）生产问题。 这意味着他们要花整整一天的时间进行故障排除。

没那么糟糕吗？ 等到您看到将大量时间和资源用于故障排除所带来的财务影响。

5.记录违规行为的最终成本

一家与我们进行生产监控主题交流的公司告诉我们，他们有100名开发人员在开发其产品，并且最终他们将大约20％的时间花在了故障排除任务上。 最重要的是，他们还有21位支持工程师，他们将50％的时间用于故障排除。 基本上，这意味着他们要付30名全职开发人员来从事故障排除任务。 加上每年可能达到20万美元或更多的薪金和费用，每年总计约600万美元！

对此进行数学计算并不难。 只有20个开发人员将25％的时间花在调试任务上，这与向5个开发人员支付全职薪水来从事体力劳动并希望解决出现的问题相同。 这可能意味着仅在人工故障排除上一年就花费数十万美元。

显然，25％的时间和资源被伪装成少数人。 25％的时间超出了您一周的工作时间 。 25％意味着每3个开发人员增加一个全职员工。 25％意味着每年可能浪费数百万美元。

最后的想法

显示代码如何执行的日志是理想的选择，但是花太多时间尝试查找不存在的已记录信息是真实的。

我们都使用日志文件，但是似乎大多数人都认为它们是理所当然的。 有了众多的日志管理工具，我们忘记了控制我们自己的代码-并使它对于我们理解，调试和修复很有意义。

翻译自: https://www.javacodegeeks.com/2018/03/5-shocking-stats-that-prove-logs-are-inadequate.html

震惊kafka