在 SRE/DevOps 工程师的环境中，如果有一天客户端（或监控系统）出现并报告“一切都丢失了”，任何人都不会感到惊讶：网站无法工作，付款无法完成，生活正在衰退...无论您多么想在这种情况下提供帮助，如果没有简单易懂的工具，都很难做到这一点。 通常，问题隐藏在应用程序代码本身中；您只需对其进行本地化即可。
并在悲伤和喜悦中……
恰巧我们已经深深地爱上了New Relic。 它过去是、现在仍然是监控应用程序性能的优秀工具，并且还允许您检测微服务架构（使用其代理）等等。 如果不是服务定价政策的变化，一切都会很棒： 成本 增长了3倍以上。 此外，从去年开始，获得试用帐户需要与个人经理沟通，这使得向潜在客户展示产品变得困难。
通常的情况：New Relic 并不是“永久”需要的；他们只在问题开始时才记住它。 但您仍然需要定期付费（每台服务器每月 140 美元），并且在自动扩展的云基础设施中，这笔费用加起来相当大。 虽然有即用即付选项，但启用 New Relic 将要求您重新启动应用程序，这可能会导致丢失所有启动时出现的问题情况。 不久前，New Relic推出了新的资费计划—— ， - 乍一看似乎是专业版的合理替代品...但经过仔细检查，发现缺少一些重要功能（特别是，它没有 关键交易, 跨应用跟踪, 分布式跟踪).
因此，我们开始考虑寻找更便宜的替代方案，我们的选择落在了两项服务上：Datadog 和 Atatus。 为什么要针对他们？
关于竞争对手
我马上说，市场上还有其他解决方案。 我们甚至考虑了开源选项，但并非每个客户都有空闲能力来托管自托管解决方案...... - 此外，它们将需要额外的维护。 我们选择的这对夫妇是最接近的 我们的需求:
- 对 PHP 应用程序的内置和开发支持（我们客户的堆栈非常多样化，但在寻找 New Relic 替代方案的背景下，这是一个明显的领导者）；
- 负担得起的成本（每个主机每月低于 100 美元）；
- 自动仪表；
- 与 Kubernetes 集成；
- 与 New Relic 界面的相似性是一个明显的优点（因为我们的工程师已经习惯了）。
因此，在最初的选择阶段，我们排除了其他几种流行的解决方案，特别是：
- Tideways、AppDynamics 和 Dynatrace - 出于成本考虑；
- Stackify 在俄罗斯联邦被屏蔽，并且显示的数据太少。
本文其余部分的结构是，首先简要介绍所讨论的解决方案，然后我将讨论我们与 New Relic 的典型交互以及在其他服务中执行类似操作的经验/印象。
选定参赛者的介绍
Про ，想必大家都听说过吧？ 这项服务于 10 多年前（即 2008 年）开始开发。 自 2012 年以来，我们一直在积极使用它，并且在 PHP、Ruby 和 Python 中集成大量应用程序时没有出现任何问题，而且我们也有与 C# 和 Go 集成的经验。 该服务的作者提供了用于监控应用程序、基础设施、跟踪微服务基础设施、为用户设备创建方便的应用程序等的解决方案。
但是，New Relic 代理在专有协议上运行，不支持 OpenTracing。 高级仪器需要专门针对 New Relic 进行编辑。 最后，Kubernetes 支持仍处于实验阶段。
2010年开始研发 就 Kubernetes 环境中的使用而言，它看起来明显比 New Relic 更有趣。 特别是，它支持与 NGINX Ingress、日志收集、statsd 和 OpenTracing 协议集成，这使您可以跟踪用户请求从连接到完成的那一刻起，以及查找该请求的日志（都在 Web 服务器端）以及消费者的）。
在使用Datadog时，我们遇到了它有时会错误地构建微服务地图，以及一些技术缺陷。 例如，它错误地识别了服务类型（将 Django 误认为是缓存服务），并在使用流行的 Predis 库的 PHP 应用程序中导致了 500 个错误。
— 最年轻的乐器； 该服务于2014年推出。 它的营销预算显然不如列出的竞争对手，提及的次数也少得多。 然而，该工具本身与 New Relic 非常相似，不仅在功能上（APM、浏览器监控等），而且在外观上也是如此。
一个显着的缺点是它仅支持 Node.js 和 PHP。 另一方面，它的实现明显优于 Datadog。 与后者不同的是，Atatus 不需要应用程序对代码进行修改或添加额外的标签。
我们如何与 New Relic 合作
现在我们来了解一下我们一般如何使用New Relic。 假设我们有一个需要解决的问题：
从图表上很容易看出 溅 - 我们来分析一下。 在 New Relic 中，立即为 Web 应用程序选择 Web 事务，所有组件都在性能图表中指示，有错误率、请求率面板...最重要的是，您可以直接从这些面板在不同的面板之间移动。应用程序的部分（例如，单击 MySQL 将进入数据库部分）。
由于在所考虑的示例中我们看到活动激增 PHP，点击该图表，自动跳转至 交易:
事务列表本质上是 MVC 模型中的控制器，已按以下顺序排序： 最耗时，这非常方便：我们立即看到应用程序做了什么。 以下是 New Relic 自动收集的长查询示例。 通过切换排序，很容易发现：
- 负载最多的应用程序控制器；
- 最常请求的控制器；
- 最慢的控制器。
此外，您可以展开每个事务并查看执行代码时应用程序正在执行的操作：
最后，应用程序存储长请求（花费超过 2 秒的请求）的跟踪示例。 这是长交易的面板：
可以看到两个方法花费了很多时间，同时还显示了请求执行的时间，它的URI和域。 通常这有助于在日志中查找请求。 即将 追踪详情，您可以看到这些方法是从哪里调用的：
而在 数据库查询 — 评估对应用程序运行时执行的数据库的查询：
有了这些知识，我们就可以评估应用程序速度变慢的原因，并与开发人员合作制定解决问题的策略。 事实上，New Relic 并不总能给出清晰的画面，但它有助于选择调查方向：
- 长
PDO::Construct引导我们了解 pgpoll 的奇怪功能； - 随着时间的推移不稳定
Memcache::Get提示虚拟机配置不正确； - 模板处理时间的可疑增加导致嵌套循环检查对象存储中是否存在 500 个头像；
- 等等…
也有可能是与外部数据存储相关的内容出现在主屏幕上，而不是执行代码 - 无论它是什么：Redis 或 PostgreSQL - 它们都隐藏在选项卡中 数据库.
您可以选择特定的研究基础并对查询进行排序 - 类似于事务中的操作方式。 通过转到请求选项卡，您可以看到该请求在每个应用程序控制器中发生了多少次，并估计了它被调用的频率。 非常舒服：
该选项卡包含类似数据 对外服务，它隐藏对外部 HTTP 服务的请求，例如访问对象存储、向哨兵发送事件等。 该选项卡的内容与数据库完全相似：
竞争对手：机会和印象
现在最有趣的事情是将 New Relic 的功能与竞争对手提供的功能进行比较。 不幸的是，我们无法在生产中运行的一个应用程序的一个版本上测试所有这三种工具。 然而，我们尝试比较尽可能相同的情况/配置。
1.数据狗
Datadog 用一个带有服务墙的面板来迎接我们：
它尝试将应用程序分解为组件/微服务，因此在示例 Django 应用程序中，我们将看到 2 个到 PostgreSQL 的连接（defaultdb и postgres），还有 Celery、Redis。 使用 Datadog 需要您对 MVC 原则有最低限度的了解：您需要了解用户请求通常来自哪里。 这通常有帮助 服务地图:
顺便说一句，New Relic 中也有类似的内容：
...在我看来，他们的地图变得更简单、更清晰：它不显示一个应用程序的组件（这会使其过于详细，就像 Datadog 的情况一样），而只显示特定的服务或微服务。
让我们回到Datadog：从服务图中我们可以看到用户请求来到了Django。 我们去Django服务，最后看看我们期望的是什么：
不幸的是，这里默认没有图表 网络交易时间，类似于我们在 New Relic 主面板上看到的内容。 但是，可以配置它来代替计划 所花费时间的百分比。 把它切换到就足够了 按类型划分的每个请求的平均时间...现在熟悉的图表正在看着我们！
为什么 Datadog 选择不同的图表对我们来说是个谜。 另一个令人沮丧的事情是系统不会记住用户的选择（与两个竞争对手不同），因此唯一的解决方案是创建自定义面板。
但我很高兴 Datadog 能够从这些图表切换到相关服务器的指标、读取日志并评估 Web 服务器处理程序 (Gunicorn) 上的负载。 一切都与 New Relic 中的几乎相同......甚至更多（日志）！
下图是与 New Relic 完全相似的交易：
在Datadog中，交易被称为 资源。 您可以按请求数、平均响应时间以及选定时间段内花费的最长时间对控制器进行排序。
您可以扩展资源并查看我们在 New Relic 中已经观察到的所有内容：
其中有资源的统计信息、内部调用的通用列表以及可以按响应代码排序的请求示例……顺便说一句，我们的工程师非常喜欢这种排序。
Datadog 中的任何示例资源都可以打开和研究：
提供了请求参数、每个组件所花费时间的汇总图表以及显示调用顺序的瀑布图。 您还可以切换到瀑布图的树视图：
最有趣的是查看执行请求的主机的负载并查看请求日志。
伟大的整合！
您可能想知道选项卡在哪里 数据库 и 对外服务，如《新遗物》中那样。 这里没有：由于Datadog将应用程序分解为组件，因此将考虑PostgreSQL 单独的服务，而不是外部服务值得寻找 aws.storage （对于应用程序可以访问的所有其他外部服务来说，这都是类似的）。
这是一个例子 postgres:
基本上我们想要的一切都有了：
您可以看到请求来自哪个“服务”。
值得提醒您的是，Datadog 与 NGINX Ingress 完美集成，允许您从请求到达集群的那一刻起执行端到端跟踪，还允许您接收 statsd 指标、收集日志和主机指标。
Datadog 的一个巨大优点是它的价格 正在形成 从基础设施监控、APM、日志管理和综合测试，即您可以灵活选择您的计划。
2.状态
Atatus 团队声称他们的服务“与 New Relic 相同，但更好”。 让我们看看这是否属实。
主面板看起来确实相似，但无法确定应用程序中使用的 Redis 和 memcached。
APM 默认选择所有事务，但通常只需要 Web 事务。 与 Datadog 一样，无法从主面板导航到所需的服务。 而且，事务是在错误之后列出的，这对于 APM 来说似乎不太符合逻辑。
在 Atatus 交易中，一切都尽可能与 New Relic 相似。 缺点是每个控制器的动态不是立即可见的。 您必须在控制器表中查找它，按排序 消耗最多的时间:
选项卡中提供了常用的控制器列表 浏览:
在某些方面，这张表让人想起 Datadog，而且我比 New Relic 中的类似表更喜欢它。
您可以展开每个事务并查看应用程序正在做什么：
该面板也更让人想起 Datadog：有许多请求，以及调用的总体情况。 顶部面板提供了一个错误选项卡 HTTP 失败 以及慢查询的示例 会话跟踪:
如果您转到事务，您可以看到跟踪示例，您可以获取对数据库的请求列表并查看请求标头。 一切都与 New Relic 相似：
总的来说，Atatus 对详细的跟踪感到满意 - 没有典型的 New Relic 将调用粘合到提醒块中：
然而，它缺少一个可以切断超快请求（<5ms）的过滤器（如 New Relic）。 另一方面，我喜欢显示最终的交易响应（成功或错误）。
面板 数据库 将帮助您研究应用程序对外部数据库发出的请求。 让我提醒您，Atatus 只发现了 PostgreSQL 和 MySQL，尽管 Redis 和 memcached 也参与了该项目。
请求根据通常的标准进行排序：响应频率、平均响应时间等。 我还想提一下查询最慢的选项卡 - 它非常方便。 此外，PostgreSQL 的此选项卡中的数据与扩展中的数据一致 - 优异的成绩！
插页 外部请求 与数据库完全相同。
发现
两种工具都在 APM 方面表现良好。 他们中的任何一个都可以提供所需的最低限度。 我们的印象可以简单概括如下：
Datadog
优点：
- 方便的资费表（APM 每个主机的费用为 31 美元）；
- 与 Python 配合良好；
- 与 OpenTracing 集成的可能性
- 与 Kubernetes 集成；
- 与 NGINX Ingress 集成。
缺点：
- 唯一导致应用程序由于模块错误（predis）而变得不可用的APM；
- PHP 自动检测功能较弱；
- 服务及其目的的定义有些奇怪。
阿塔图斯
优点：
- 深入的 PHP 检测；
- 用户界面类似于New Relic。
缺点：
- 不适用于较旧的操作系统（Ubuntu 12.05、CentOS 5）；
- 自动仪表功能弱；
- 仅支持两种语言（Node.js 和 PHP）；
- 界面缓慢。
考虑到 Atatus 每台服务器每月 69 美元的价格，我们宁愿使用 Datadog，它与我们的需求（K8s 中的 Web 应用程序）很好地集成，并且具有许多有用的功能。
PS
另请阅读我们的博客：
- «“;
- «“;
- «“。
来源： habr.com