新部署的生存工具包:适用于Java开发人员的工具,这些工具经常将代码部署到生产中!
Takipi会检测生产中的所有错误,并像发生错误时一样显示变量值
立即部署并获得免费的T恤
适用于新部署的终极生存套件
与在僵尸末日场景下玩弄,用砍刀和the弹枪争论不一样,Java生产环境中的麻烦是很真实的,尤其是在新部署之后(但也准备好接受僵尸是一件好事)。 如果将新的代码发布周期缩短到几周,有时甚至是几天甚至一天多次,那么比以往任何时候都更容易陷入麻烦。 为避免被僵尸撞倒,这里是生存套件的设置,您需要充分了解新代码对系统的影响。 有什么事吗 它在减慢你的速度吗? 以及如何解决? 这是一劳永逸地破解它的工具集和体系结构。
记录中
除了缩短发布周期外,现代开发生命周期的另一个特性是不断扩展日志文件,每天可以达到GB。 假设新部署后出现了一些问题:如果您想及时做出响应,那么在没有适当工具的情况下,处理来自多个源和计算机的非结构化数据的GB几乎是不可能的。 在此空间中,我们可以将工具本质上划分为重型企业本地Splunk及其SaaS竞争对手,例如Sumo Logic,Loggly等。 类似的产品有很多选择,因此我们编写了更深入的日志管理分析,您可以在此处阅读。
要点1:设置合理的日志管理策略,以帮助您查看裸日志文件之外的内容,并在新部署后快速做出反应。
开源ELK堆栈是我们发现的一种在部署新代码后非常有用的日志记录体系结构。 值得一提的是它是开源和免费的。
那么我们在谈论什么ELK? Elasticsearch的搜索和分析功能的组合,Logstash作为日志聚合器,Kibana用于精美的仪表板可视化。 我们使用它已经有一段时间了,它通过日志和Redis从Java中获取它,开发人员和BI都在使用它。 如今,elasticsearch几乎是Logstash内置的,而Kibana也是elasticsearch的产品,使集成和设置变得容易。
当新的部署推出时,仪表板将遵循我们针对应用运行状况设置的自定义指标。 这些指标实时更新,可以在新交付的代码上载到生产环境后的第一步时进行密切监视。
要点2:搜索,可视化以及从多个来源汇总日志的简便性是确定日志管理策略的关键因素。
要点3:从开发人员的角度来看,评估新部署的影响还可以包括BI方面。
检查工具:
- 本地: Splunk
- SaaS: Sumo Logic
- SaaS: Loggly
- 开源: Graylog2
- 开源: Fluentd
- ELK堆栈 (开源): Elasticsearch + Logstash + Kibana
性能监控
因此,发布周期缩短了,日志文件也越来越大,但这还不是全部:用户请求的数量呈指数增长,并且他们都期望达到最佳性能。 除非您努力优化它,否则简单的日志记录只会带您到此为止。 话虽如此,专用的应用程序性能管理工具已不再被视为一种奢侈,而是Swift成为一种标准。 本质上,APM意味着定时执行代码中的不同区域并完成事务所需的时间-这可以通过检测代码,监视日志或包括网络/硬件指标来实现。 无论是在后端还是在用户的设备上。 我想到的头两个现代APM工具是最近刚进行首次公开募股的New Relic和AppDynamics。
传统上,每个企业都针对不同类型的开发人员,从企业到初创企业。 但是,随着两家公司都开始进行首次公开募股,并且在经历了巨大的增长之后,两者之间的界限越来越模糊。 选择不明确,但您不会出错–前提是= AppDynamics,否则,这是一个单独的调用,具体取决于哪个更适合您的堆栈(以及它们提供的所有功能中的哪些是您实际上想使用的功能) )。 看看这两个头部比较头,我们最近发布的分析就在这里 。
最近发布的另外两个有趣的工具是Ruxit(由Compuware公司提供)和DripStat(由Chronon Systems公司提供),每种工具均来自大型公司,他们试图解决由New Relic率先开发的SaaS监控市场。 考虑到核心JVM内部组件,jClarity和Plumbr也绝对值得一试。
要点4:新部署可能会影响您应用程序的性能并降低其性能,APM工具可以提供有关应用程序运行状况的全面概述。
检查工具:
- AppDynamics
- 新遗物
新玩家:
- j清晰度
- 铅锤
- 鲁克西特
- 滴灌
生产调试
发布周期缩短,日志文件变大,用户请求爆炸,并且……错误的余地根本不存在。 当出现错误时–您需要立即解决它。 大型生产环境每天可能在代码中的数百个不同位置产生数百万个错误。 尽管有些错误可能是微不足道的,但有些错误会破坏关键的应用程序功能并在您不知情的情况下影响最终用户。 传统上,要识别和解决这些错误,您甚至必须依靠日志文件或日志管理工具来知道发生了错误,更不用说如何解决了。
使用Takipi,您可以知道哪些错误构成最高风险,应该对其进行优先级排序,并获得有关如何解决每个错误的可行信息。
考虑到新部署后出现的错误,Takipi解决了3个主要问题:
- 知道哪些错误对您的影响最大 –在生产中检测100%的代码错误,包括JVM异常和日志错误。 使用智能过滤可消除噪声并关注最重要的错误。 超过90%的Takipi用户报告在使用的第一天就发现了至少一个关键错误。
- 花费更少的时间和精力进行调试 – Takipi自动重现每个错误并显示导致错误的代码和变量,即使在服务器之间也是如此。 这消除了手动重现错误的需要,节省了工程时间,并大大减少了解决问题的时间。
- 毫无风险地进行部署 –当新版本引入错误,并且固定错误再次困扰您时,Takipi会通知您。
要点5:使用Takipi,您可以Swift采取行动解决任何问题,而在新版本发布后,您将不再处于黑暗之中。
检查工具:
- 塔基皮
警报和跟踪
发布周期,日志文件,用户请求,没有差错的余地……等等。 您可能会认为此类别与其他类别重叠,事实是您可能是对的,但是当所有这些工具都有自己的管道来让您知道发生了什么时,它就会变得很混乱。 尤其是在新部署后的软弱环境中,很容易发生各种意外的事件(这是更柔和的说法…… 所有地狱都破灭了)。
解决这一问题的领先事件管理工具之一是PagerDuty:从监视工具收集警报,创建时间表以协调团队并通过文本,电子邮件,短信或推送通知将每个警报传递给合适的人。
要点六:考虑使用事件管理系统来处理信息过载。
我们真正喜欢在这里使用的一种专用工具是Pingdom(它也与Pagerduty集成了)。 它的作用非常简单并且可以正常工作:24/7跟踪和提醒我们网站的响应时间。 回答一个看似微不足道的关键问题:网站可用吗? 从全球各地进行探测。
解决信息过载的另一个角度是错误跟踪,它超出了日志分析器的功能:智能仪表板可管理异常和日志错误。 通过日志事件或其他来自代码的插件,将所有服务器和计算机中的数据聚合到一个位置。 要深入了解错误跟踪工具的情况, 请查看这篇涵盖最流行选项的文章。
要点7:代码错误有各种形式和大小,值得使用错误跟踪工具对其进行一些特殊处理(在我们使用它时,粉碎一些错误,穆哈哈)。
检查工具:
- PagerDuty
- 平度
结论
我们已经亲身体验了现代软件开发如何影响发行版生命周期,并深入了解了如何评估新快速部署的影响-在甚至完全了解上次更新的影响之前就可以引入新代码的时间。 在总体方案中,您考虑使用的任何工具都应满足以下5个特征:
- 收缩释放周期
- 扩展日志文件
- 越来越多的用户请求
- 误差较小
- 信息超载
最重要的是,请考虑一下您今天如何处理这些问题,这会占用您太多时间。 很有可能有解决该问题的工具。
Takipi会检测生产中的所有错误,并像发生错误时一样显示变量值
立即部署并获得免费的T恤
翻译自: https://www.javacodegeeks.com/2014/12/15-tools-java-developers-should-use-after-a-major-release.html