Java开发者在某个重大发布后需要使用的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等方面。

可供选择的工具:

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

性能监控:

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

左边为AppDynamics,右边为New Relic的主面板

不 管是初创还是成熟的公司,这两个都能满足不同类型的开发者。但是两个都在走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的使用时间扩展到了两个月

100%发现生产中的错误

发现每个错误后面的参数

使大规模调试变得容易

报警和追踪

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

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

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

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

系统如上图

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

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

可供选择的工具:

  1. PagerDuty
  2. Pingdom

总结

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

  1. 缩短发布周期
  2. 增加日志文件
  3. 增大用户请求
  4. 减小错误
  5. 信息的过载

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

原文链接: takipi 翻译: ImportNew.com - 张 健
译文链接: http://www.importnew.com/14616.html
[ 转载请保留原文出处、译者和译文链接。]

关于作者: 张 健

(新浪微博:@jasper你咋了

查看张 健的更多文章 >>



相关文章

发表评论

Comment form

(*) 表示必填项

还没有评论。

跳到底部
返回顶部