重大发布后需要使用的15个工具

 

新发布的根本生存装备 

不像玩僵尸毁灭的场景，也不像辩论大刀对抗猎 枪，在Java的生产环境中问题是真实存在的，特别是在一个新的发布之后（有备无患嘛）。更进一步说，比起当时 将编码周期缩短至几周或是几天，甚至一天缩短多次，反而现在更容易陷入麻烦。为了避免这些麻烦，你需要完全理解新的代码会对你的系统产生什么影响。是否会 对原有的系统产生破坏？是否会让系统运行迟缓？怎么去解决这些可能出现的问题呢？下面介绍一些工具和架构来彻底破解这些问题。 

现在开发生命周期非但不会缩短，每天不断膨胀的日志数据 甚至可以达到GB级别的量级。让我们说说在新发布之后的问题：如果你想及时响应，在没有合适的工具的情况下，想要处理多数据源多服务器的GB量级的数据， 几乎是不可能的。在这样的情况下，除开重型企业内部的工具Splunk和他的SaaS中的竞争对手，如Sumo Logic， Loggly等等。我们依然有提供类似功能的其他选择，因此我们对日志的管理做了一个深入的分析，你可以参照这里。 

#1 建立一个可靠的日志管理策略，能帮助你看到的不止是单独的日志文件，能让你在新发布之后快速做出相应。 

我们最后发现，在新发布之后的一个有用的日志框架就是开源的ELK stack。因为它是开源免费的，所以被特别提到。 

 

ELK stack包括 ElasticSearch,，Logstash 和Kibana 

那么我们所说的 ELK到底是什么呢？它是一个混合体，包括用作搜索和性能分析的elasticsearch，用于日志收集的Logstash和用作前端展现的 Kibana。我们已经用过有一段时间了，依靠它和Redis分析我们的Java日志，它也有被用在开发和BI之中。现在，elasticsearch已经内置于Logstash，Kibana也是一个elasticsearch的产品，这样能让集成和安装更容易。 

每当一个新的发布之后，前端会展现出我们对这个应用健康所关心的自定义指标。这些指标会实时更新，并且允许刚交付的代码上传到生产环境后马上就得到监测。 

#2 搜索，可视化以及对多数据源日志的聚合，是决定你日志管理工具选择的第一要素。 

#3 从一个开发者的角度，评估新的发布的影响也包括BI等方面。 

可供选择的工具： 

内置工具: Splunk 
SaaS：Sumo Logic 
3. SaaS：Loggly 
4. 开源：Graylog2 
5. 开源：Fluentd 
6. The ELK stack (开源)： Elasticsearch + Logstash + Kibana 
性能监控： 

发 布周期被缩短，日志文件越来越大，但这并不是全部。随着用户请求的数量急剧增长，他们都希望达到性能的峰值。如果你不努力优化，简单的日志记录让你只能看 到这么多。这样说来，专用应用程序性能管理工具(APM)已不再被认为是奢侈品,它已经迅速成为一种标准。从本质上说，APM意味着时间需要多长时间来执 行不同的地区代码并完成汇报——要达到这个，可以通过代码检测，日志监控或是包括网络/硬件指标。考虑到后台以及用户设备，首先进入我脑中的两个APM工 具分别是New Relic(最近刚IPO)以及AppDynamics。 

 
[align=center]

左边为AppDynamics，右边为New Relic的主面板[/align] 
不 管是初创还是成熟的公司，这两个都能满足不同类型的开发者。但是两个都在走IPO,在经历巨大的增长后，产品线越来越模糊。这个选择不是很清晰，但是你不 能陷入误区，即On premise = AppDynamics。相反，这是一个独立的需求，它依赖于谁更适合你的站点（即它们提供的所有特性就是你实际上想要使用的）。看看我们最近发布的关于二者的分析报告，点击这里。 

我们最近发布的另外两个工具是Ruxit（由Compuware开发）和DripStat（Chronon Systems开发），它们每一个都来自由New Relic开创的尝试自己解决SaaS监控市场的大公司。为了深入JVM硬核内部，jClarity和Plumbr也绝对值得一试。 

#4新的发布有可能影响你应用的性能使之运行变慢。APM工具可以提供你应用健康的总体情况。 

可供选择的工具： 

1.AppDynamics 
2.New Relic 
新的成员： 

1.jClarity 
2.Plumbr 
3.Ruxit 
4.Dripstat 
产品调试 

发布周期短了，日志文件变大了，用户请求增多……允许犯错误的余地几乎不存在了。但当错误真的到来时，你需要能够马上解决掉。大规模的生产环境，每天可以从 成百上千个不同的代码处产生无数的错误。虽然有些错误时不重要的，但有些可能对你的应用产生致命的影响，并影响你所接触不到的终端用户。另外，为了鉴别和解决这些错误，你必须依赖于你的日志或是日志管理工具去查看错误的发生，更不用说如何修复它。 

有了Takipi，你能够知道最有可能出问题且需要优化的地方，并且能得到怎么取解决每个问题的可行的信息。 

 

为了关注新发布后的危机，Takipi解决了三个主要问题： 

1.了解哪些错误最有可能影响你——在生产中发现100%的代码错误，包括JVM异常和记录的错误。使用智能过滤以减少噪音使之专注于最重要的错误。超过90%的Takipi用户报告说，在他们使用的第一天，至少在生产中找到了一个严重的bug。 

2、在调试上花更少的时间和精力——Takipi再现了每个错误并显示出代码和导致它产生的变量，甚至可以跨服务器。这消除了手动复制错误的必要，节省了工程时间,显著降低时间。 

3. 没有风险的发布——当新的版本中有错误，或是已经解决的错误又重现时，Takipi都会提醒你。 

#5：运用Takipi你能很快地解决任何问题，以至于不让你在新的发布之后一无所知。 

可选择的工具： 
1.Takipi 
从这篇文章之后，Takipi的使用时间扩展到了两个月。 

 

报警和追踪 

发布周期，日志文件，用户请求，零错误……你怎么才能全部跟进呢？你可能认为这一类和其他的重叠了，可能你是对的，但是当所有的这些工具都有他们自己的流水 线时，你可能会意识到自己哪里错了——这将变得很混乱。特别是在各种意想不到的事情都可能发生的新发布后（也就是整个灾难降临）。 

满足这个的事件管理工具之一的就是PagerDuty：它能从监控工具收集报警，创建时间表来协调你的团队，或是通过文本、邮件、短信或是推送通知，把每个报警发给特定的人。 

#6：考虑使用一个事件管理系统来处理信息过载。 

在这里我们真正喜欢使用的专业工具是Pingdom（也是和Pagerduty的结合）。它所做的很简单而且有用：即对你的站点的响应时间做24*7小时的追踪和告警。它能回答一个看起来微不足道，实则至关重要的问题：从世界各地检测来看，当前的站点可用吗？ 

 

 

系统如上图

另一个角度来解决信息过载的方法，是通过对日志分析来进行错误的跟踪:管理异常和日志错误的智能展现。从多个服务器聚合数据到一个地方，即使你的日志事件或是其他插件来自你的代码。为了更深入地错误追踪，点击这篇文章可以得到更多的信息。 

#7 代码层的错误来源各种各样，在选用追踪工具时，应该给予特别的对待（在我们关注他们的时候就修复一些bug，哈哈） 

可供选择的工具: 

1.PagerDuty 
2.Pingdom 
总结 

我们亲身经历，现代软件开发如何影响发布生命周期，放大如何评估新的快速部署的影响——在你部署之前，你应该完全了解最后更新的影响。从长远来看,任何工具都应该拥有这五个特点: 

• 缩短发布周期
• 增加日志文件
• 增大用户请求
• 减小错误
• 信息的过载

最重要地是，思考一下现在你是怎么解决这些的，哪一个花了你更多的时间。很可能就有一个工具适合解决这个问题。