New Relicの開発ツールキットは、開発者の労苦を軽減するために構築された一連のツールを提供しています。「Terraformを使用したNew Relic Alertポリシーの定義」では、New Relic Terraformプロバイダーを使用して、インフラストラクチャおよびアプリケーションコードと一緒にモニタリングおよびアラート構成をコードで管理し、デプロイする方法について説明しました。現在、Kubernetesについても同じことを行うことができます。
この投稿では、Kubernetes Operatorとその有用性について簡単に説明し、New Relic KubernetesOperatorがKubernetesデプロイメントと一緒にNewRelicリソースをシームレスにデプロイする方法をご紹介します。
Kubernetes Operatorとは？
Kubernetes Operatorは、カスタムリソースを利用してアプリケーションとそのコンポーネントを管理する、Kubernetesの拡張機能です。Kubernetes Operatorは、Kubernetesの原則、特にコントロールループに従います。
Kubernetesは、クラウドでコンテナ化されたサービスをデプロイするためのデファクトスタンダードになりつつあります。Kubernetesはバージョン1.7でOperatorパターンを導入し、サードパーティサービスの設定やプロビジョニングなどのドメイン固有の操作を実行できるカスタムKubernetesオブジェクトを定義することでKubernetesを拡張できるようにしました。
New Relic Kubernetes Operatorについて
New Relic Kubernetes Operatorは、Kubernetes設定を管理するのと同じ方法でNewRelicリソースを設定する機能を提供します。
たとえば、クラスターにオペレーターをインストールすると 、NewRelicのカスタムKubernetesオブジェクトを使用してNewRelicアラートポリシーを作成できます。NRQLアラート条件を使用してオブジェクトを構成することもできます。スタンドアロンのNewRelic NRQLアラート条件を構成し、それを既存のアラートポリシーに適用することも可能です。
注： この投稿は、New Relic KubernetesOperatorバージョンv0.0.2およびKubernetesバージョン1.18.2で作成されました。
やってみましょう
このウォークスルーは、Kubernetesクラスターが既にデプロイされていることを前提としています。また、kubectlをインストールし、正しいクラスターを操作できるように設定されていることを前提として話を進めます。
New Relic Kubernetes Operatorのインストール
NewRelic Kubernetes Operatorのインストールは2段階のプロセスです。
まず、KubernetesでTLS証明書を自動的にプロビジョニングおよび管理するcert-managerをインストールします。
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.0/cert-manager.yaml
次に、New Relic Kubernetes Operatorをインストールします。
kubectl apply -k github.com/newrelic/newrelic-kubernetes-operator/config/default
インストールが成功したことを確認するには、いくつかのkubectlコマンドを実行してステータスを確認します。
New Relic Kubernetes Operator用の名前空間newrelic-kubernetes-operator-systemが作成されていることを確認します。
kubectl get namespaces
出力は、newrelic-kubernetes-operator-systemを含む以下の例のようになります。
NAME STATUS AGE cert-manager Active 4m35s default Active 20m kube-node-lease Active 20m kube-public Active 20m kube-system Active 20m newrelic-kubernetes-operator-system Active 3m48s
New Relic Kubernetes Operatorのコントローラーマネージャーが実行されていることも確認しましょう。
kubectl get pods --namespace newrelic-kubernetes-operator-system
注：正しい名前空間内のリソースを確認するために、実行時にオプションを含めることを忘れないでください。--namespace (shorthand -n)kubectl get pods
次のような出力が表示されます。
NAME READY STATUS RESTARTS AGE newrelic-kubernetes-operator-controller-manager-7b9c64f58crwg9j 2/2 Running 0 157m
上記のような出力が表示されたら、次のステップに進む準備ができています。newrelic-kubernetes-operator-controller-manager-<hash>という名前のPodが表示されない場合は、kubectlやKubernetes構成を再確認して、コンテキストに間違いがなく、kubectlが正しいクラスターを指していることを確認してください。
New Relic Kubernetes Operatorの使用
無事にNew Relic Kubernetes Operatorがクラスターにデプロイされました。これで、アラートポリシーやコンディションなどのNRQLアラート条件の設定を、マニフェストでデプロイ・管理することができます（他のKubernetes設定を作成するのと同じ方法で管理できます）。
ワークフローの概要
通常は、以下の3段階で適用します。
- 宣言型のアプローチを使用して、アラートポリシー構成ファイル（マニフェスト）を作成します。
- NewRelicパーソナルAPIキーを構成に追加します。
- 準備ができたら
kubectl applyを実行します。
最初のアラートポリシーを作成する
物事を開始するには、小さく始めます。まず、必要最小限の構成でアラートポリシーを作成してから、NRQLアラート条件をポリシーに追加します。これにより、NewRelicのポリシーにコンディション条件が追加されます。
最小限のアラートポリシー構成は、以下のコードで表されます。このウォークスルーのために、このファイルに名前を付けますnew_relic_alert_policy.yaml。
new_relic_alert_policy.yaml
apiVersion: nr.k8s.newrelic.com/v1 kind: AlertsPolicy metadata: name: my-policy spec: account_id: <your New Relic account ID> # New RelicアカウントIDを指定します api_key: <your New Relic personal API key> # personal API keyを指定します name: "Alert Policy Created With k8s" # アラートポリシー名を指定します region: "us"
注：personal API keyについては、NewRelicのドキュメントをご覧ください。
キーなどのセンシティブな情報をマニフェストに直接記述するのはリスクが高いので、Secretを利用することもできます。
予めSecretを作成しておきポリシーのマニフェストからSecretを参照することで、アカウントIDやpersonal keyを隠蔽することができます。サンプルはこちらにあります。
次に、kubectl applyコマンドを実行してアラートポリシーを作成します。
kubectl apply -f ./new_relic_alert_policy.yaml
次のような出力が表示されます。
alertpolicy.nr.k8s.newrelic.com/my-policycreated \
New Relic上でポリシーを表示し、アラートポリシーが作成されたことを確認します。名前で新しいポリシーを検索できます。この場合、ポリシー名は「Alert Policy Created With k8s」で検索します。
これで新しいアラートポリシーが作成されました。
次に、同じ構成ファイルを使用して、ポリシーにNRQLアラート条件を追加してみしょう。
NRQLアラート条件をアラートポリシーに追加する
アラートポリシーを作成したので、ポリシーにいくつかのアラート条件を追加して、特定のメトリックがラインから外れたときにアラートをトリガーできるようにします。
new_relic_alert_policy.yamlファイルで、NRQLアラート条件をポリシーに追加します。これは、アプリケーションの全体的な平均応答時間が3分間で5秒を超えたときにアラートを出すものです。
new_relic_alert_policy.yaml
# The policy from the previous steps
apiVersion: nr.k8s.newrelic.com/v1
kind: AlertsPolicy
metadata:
name: my-policy
spec:
account_id: <your New Relic account ID>
api_key: <your New Relic personal API key>
name: "Alert Policy Created With k8s"
incidentPreference: "PER_POLICY"
region: "us"
# 先ほどのファイルに以下を追加します。
conditions:
- spec:
type: "NRQL"
name: "NRQL Alert Condition Created With k8s"
nrql:
query: "SELECT average(duration) FROM Transaction WHERE appName = 'YOUR APP NAME'"
evaluationOffset: 3
enabled: true
terms:
- threshold: "5"
threshold_occurrences: "ALL"
threshold_duration: 180
priority: "CRITICAL"
operator: "ABOVE"
violationTimeLimit: "ONE_HOUR"
valueFunction: "SINGLE_VALUE"注：アラートがトリガーされたときに通知を受信するには、アラートポリシーに通知チャネル を追加する必要があります。
この状態で再度 kubectl applyコマンドを実行し、アラートポリシーを更新します。これにより、NRQLアラート条件が作成され、ポリシーに追加されます。
kubectl apply -f ./new_relic_alert_policy.yaml
NRQLアラート条件が正常に作成されたことを確認するには、アラートポリシーを更新します。アラートポリシーに新しいアラート条件が追加されていれば成功です。
最後に 通知チャネルを作成してアラートポリシーに追加します。たとえば、アラート条件がトリガーされたときにチームにメールを送信する場合などです。github上にサンプルがありますので、ぜひチャレンジしてみてください。
まとめ
Kubernetesワークフロー内にシームレスに統合されるコードを使用して、NewRelicアラートポリシーとNRQLアラート条件を管理できるようになりました。これにより、ドメイン固有のパターンでアラートを構成および管理し、一貫性と保守性を提供できます。また、今後の潜在的な変更に対するコードレビューのメリットも得られます。New Relic Kubernetes Operatorは、コードとしての可観測性を促進することを目的としたNew Relic DeveloperToolkitのいくつかのツールの1つとして提供されています。
New Relicオープンソースでは、New Relic KubernetesOperatorだけでなく、ワークフローを自動化するのに役立つ様々なツールを提供しています。ぜひ他のツールも確認してみてください。
Happy monitoring!!!
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
