总结：

通过引入NewRelic，我们能够在食べログ的Kubernetes迁移中创造出使工程师能够专注于根本问题的时间。虽然使用开源软件似乎是免费的，但建立起来会以工程师的时间成本形式体现，因此我们从NewRelic中感受到了超过金钱成本的价值，这就是故事的内容。

引入的背景和效果

在聚类可视化领域出现的问题

从2020年开始，我们在食べログ开始向Kubernetes平台进行迁移。到了2021年，我们终于投入了真正的精力进行迁移工作，并成功将一些生产服务迁移至新平台。然而，在使用Prometheus/Grafana进行集群可视化的领域中，我们遇到了以下问题：

• 複数のデータソースが存在し、ダッシュボードの管理が煩雑化

 

Grafanaダッシュボードの作成が職人芸化

这些复杂性也出现在将应用程序编写为Kubernetes清单的过程中。

• Manifest の記述が大変

 

動作確認にも手間がかかる

引起了各种问题。

使用 NewRelic 的好处

对此，NewRelic 提供了以下优势。

• すでにあるプラクティスを導入することで、自前でゼロから考えるよりも、Kubernetesクラスタを可視化する手間を削減できる

 

• 導入が容易。Kubernetesインテグレーションを使うことで、数ステップで導入できる

 

Prometheusよりも多くの情報が収集される（Deployment名などの情報を自動付与してくれる）

引入效果

能够简化Kubernetes集群可视化的工作量

简化基础设施配置

与之前使用的“灭霸”相比，基础设施配置变得更加简单了。

灭霸的形成

Thanos需要进行SideCar和查询最近的数据，需要编写Manifest并进行操作验证等工作。此外，由于存储在GCS上还需要支付费用，因此使用OSS构建的成本优势也逐渐减弱。

NewRelic的协作配置

在NewRelic中，只需将Kubernetes集群信息作为Manifest配置，即可收集Kubernates集群信息的集成。

对于其他独特的指标，我们使用了Prometheus的remote write集成功能，只需要从原先的Prometheus远程写入（remote_write）到New Relic中来，因此迁移过程几乎没有任何工作量。

只需要在Prometheus的配置文件中添加几行用于远程写入，就可以将数据发送到NewRelic。

remote_write:
  - url: https://metric-api.newrelic.com/prometheus/v1/write?prometheus_server=my-cluster
    authorization:
      credentials_file: /etc/newrelic-secrets/NRIA_LICENSE_KEY
      # 別途 Secret などのマウントも必要です

简化 Kubernetes 配置文件

由于基础设施结构更简单，我们可以减少清单的编写量，并且相应地减少了测试的目标数量。

简化仪表板创建的工作量

Grafana是一款非常出色的可視化开源软件，但要设置动态过滤器，必须在PromQL中指定变量，如下的$host。为了使该设置正常工作，需要与其他图表协调一致，同时在增加条件时也需要修改所有图表的PromQL，考虑事项非常多，创建仪表板变得需要非常熟练的技艺。

在NewRelic中，您可以先绘制基本图表，然后可以通过对话框设置将后续条件应用于所有图表。

多亏了这个过滤器功能，我们不仅简化了仪表板操作，还能够通过多种方式将集群可视化（类似于 Kibana 的操作性）。

为了提高NewRelic的使用效率的方法改进

用 Terraform 将配置代码化

通过使用 New Relic 提供者，您可以在 Terraform 中管理 NewRelic 的警报、仪表板、Synthetics 等配置。

由于能够使用编辑器一次性修改设置文件，使得管理设置更加高效。
如果不能这样做，当需要更改的设置很多时，工作量将非常庞大（需要一个个地点击屏幕），Terraform 能够与 NewRelic 兼容，这是一个令人高兴的特点之一。

然而，由于需要学习NewRelic和Terraform两者，所以在适应之前可能会有些困难，但一旦能够创建一定程度的设置，之后只需要参考并增加配置，所以学习成本很快就可以收回。（我认为只需设置2到3个警报就能感受到）

通过对仪表板URL进行分析，创建链接集合。

新Relic的仪表板URL中实际上包含可以进行Base64解码的参数，通过更改这些参数，可以将任意搜索过滤器设置为初始显示。

https://one.newrelic.com/.....&pane=eyJuZXJkbGV0SWQiOiJk

↑仪表板面板参数的部分

食べログ通过使用此规范，在事先准备各种切入点的仪表盘链接，以提高对系统信息的可访问性。

通过应用DROP规则来优化运营成本

NewRelic拥有一个名为drop filter rules的功能，可以从传递给NewRelic的指标中排除不需要的内容。通常情况下，我们应该在发送方的Prometheus中排除不需要的内容，但是在Prometheus中编写relabel_configs会导致配置文件变得难以阅读，所以NewRelic提供了DROP规则功能，这对用户非常友好，非常出色。

然而，据说如果在NewRelic端设置过多的DROP规则，则可能会影响信息的更新速度，因此最好尽可能地减少发送不必要的内容。

我现在正在努力的事情

除了Kubernetes之外的指标操作

像MySQL这样的数据存储

• スロークエリ

 

• レプリケーション遅延

 

Performance Schema

我希望通过获取各种信息，可以着眼于数据库的改进。

将NewRelic Alert与Opsgenie进行集成和协同运作。

大家是通过什么方式收到警报的呢？是通过邮件吗？还是通过Slack之类的平台呢？

电子邮件通知的缺点

我不知道收到的警报的情况

• この問題は今も継続しているのか？

 

誰か対応を開始しているのか？

当同一个警报多次出现时，其他信息会被掩盖

大量のCPUアラートに埋もれて、ディスク枯渇を見落としてしまった

有诸如下列的不利之处：

• 同じことを複数のエンジニアがやってしまった

 

そもそも対応を忘れてしまう

可能的連接到一些問題。透過使用 NewRelic 和 Opsgenie 來解決這個問題。

• Policyベースでのアラートの集約

受け取る通知数を種類ごとに限定できる

アラートの自動クローズ

通过这些方式，你会发现除了紧急警报以外，每天早上的会议上你也可以确认状态。 （我认为Slack等工具也可以实现警报情况的可视化）

新颖瑞士公司很难受。

NRQL的聚合功能有一些特殊之处。

由于NewRelic是为处理多个数据源而设计的，所以可能会出现某些指标的重复计算。有一些情况很难知道准确的值（即使在这种情况下，也可以了解趋势，并且如果采用适当的方法，也许可以参考准确的值，但这将在以后再讨论）。

我未来想做的事情

部署标记器的运营

错误发生和性能下降等通常是由部署引起的。通过使用部署标记与监控一起进行，我们可以确定是哪次部署引起了问题，并尽早发现和改进有问题的逻辑，以便解决问题。

合成物质

在服务监视中，对SLI/SLO的可视化表示

目前，在食べログ上使用nagios进行死活监测，但是通过使用NewRelic Synthetics，还可以按时间序列查看延迟和错误率。也可以通过长期回顾来了解SLO的状况，并通过与Terraform结合使用来监测更多的端点，从而进一步观测服务的可用性。

利用 NewRelic Minion 进行内部基础设施的监测。

即使是未向外部公开的后端服务（如内部API），通过监控其个别服务水平是否有下降，并通过改进，可以提高整体服务水平。

实施通过APM进行绩效改善活动。

食べログ是一个每月拥有13亿页面浏览量的高流量服务。因此，即使只是稍微改善访问量较大的页面，也可以期待到巨大的改善效果。APM已经不再是特殊的东西了，所以我们希望在食べログ上推广使用它，并改善服务的性能。

然而，由于APM的数据很快膨胀，所以在使用开源软件时存在较高的运营难度，而在使用软件即服务（SaaS）时费用往往是个瓶颈，因此需要有效解决这些问题。

总结

TL;DR 新增的总结是，NewRelic 不仅仅是一个 SaaS 平台，还有非常丰富的周边工具，比如 Terraform。掌握它并不容易，而且价格也并不便宜，但只要明确目标并运用得当，可以做很多事情，是一款很有效的工具。

最终

SRE团队正在招聘工程师！即使没有基础设施或DevOps经验，只要您是软件工程师，都可以在这个环境中蓬勃发展。
在云原生领域仍然有许多可以做的事情，所以如果您有兴趣，请务必申请加入我们。
当然，如果您只是希望进行非正式的面谈并进行信息交流，我们也欢迎。在申请时，请在自由文本框中注明”希望进行非正式的面谈”。

明天将会有@tsukasa_oishi的「关于食べログ的Cloud Native CI/CD流水线」的讲座。敬请期待!