クラスタ モニタリングのガイドライン

概要

このガイドでは、Apigee ハイブリッド デプロイのモニタリング対象とモニタリング方法について説明します。このドキュメントは、ハイブリッド クラスタ管理者と組織管理者を対象としています。

Google Cloud Monitoring を初めて使用する場合は、Google Cloud Monitoring のドキュメントで Metrics Explorer を使用したグラフの作成とアラートの仕組みをご覧ください。

Apigee ハイブリッド クラスタが提供する SLI（サービスレベル指標）指標を使用すると、任意の時点でのアプリケーション サービスとシステム サービスのパフォーマンスを把握できます。使用可能な指標の完全なリストは、こちらで確認できます。

Google Cloud Monitoring では、リソースタイプによってすべての SLI 指標が識別されます。すべての Apigee ハイブリッド指標で共通して使用されるリソースタイプは次の 3 つです。

  • システムレベルの指標用の k8s_container
  • Apigee API プロキシ指標用の ProxyV2
  • Apigee API ターゲット指標用の TargetV2

リソースタイプには、関連するすべての指標に適用される共通のラベルがあります。たとえば、k8s_container リソースタイプのすべての指標では、指標ラベルに加えて、cluster_name、pod_name、container_name ラベルを使用できます。リソースタイプのラベルと指標のラベルの組み合わせを使用して、クラスタの健全性とパフォーマンスを効果的にモニタリングする必要があります。

アラートのしきい値: 完璧な状況では、アラートのしきい値は明確であり、提供されるドキュメントに、アラートをトリガーする値の一覧が記載されます。現実には、Apigee でどの程度のパフォーマンスが許容されるか、サービスとインフラストラクチャでどの程度のリソースが使用されたら危険か、を定義するのは困難です。アラートのしきい値は、特定のトラフィック パターンや SLO/SLA 契約によって大きく異なります。

アラートの最適なしきい値は、サービスとインフラストラクチャの使用状況に応じて変化する可能性があるため、その決定は継続的なプロセスとなります。通知とアラートには、警告と重大のしきい値を使用します。

  • 正常: 値が警告しきい値未満。
  • 懸念事項: 値が警告しきい値よりも大きいが、重大しきい値よりも小さい。
  • 重大: 値が重大しきい値より大きい。

お客様は、提供されたツールを使用して最適なしきい値を決定する必要があります。以下で提供される MQL を使用して作成できる Cloud Monitoring ダッシュボード、または Apigee の分析などを使用して、「正常」と思われる状態を識別し、それに応じてアラートしきい値を調整します。

ハイブリッド クラスタのモニタリングは、大まかに分類すると、トラフィック モニタリング、データベース モニタリング、Apigee コントロール プレーン モニタリング、インフラストラクチャ モニタリングの 4 つのグループになります。以降のセクションで、これらのグループについて詳しく説明します。

トラフィック

Apigee プロキシとターゲット SLI の指標は、API プロキシとターゲットのリクエスト / レスポンスの数とレイテンシを提供します。Apigee ポリシー レイテンシ SLI 指標は、ポリシー レスポンスのレイテンシを提供します。これらの SLI 指標は、Apigee API トラフィックのモニタリングに対応しています。

リクエスト率

プロキシのリクエスト数

ユースケース: proxyv2/request_count を使用して、プロキシのリクエスト数をモニタリングします。proxyv2/request_count グラフに、プロキシのリクエスト率が表示されます。このグラフは、高いリクエスト率を受信しているプロキシ、リクエスト率のパターン、特定のプロキシのリクエスト呼び出しの異常な急増を特定するのに役立ちます。API トラフィックの予期しない急増は、bot や API プロキシへの攻撃に関するセキュリティ上の懸念事項になる可能性があります。同様に、トラフィック クラウド全体の大幅な減少は、クライアントまたは Apigee のアップストリーム コンポーネントからの接続に問題があることを示しています。

リソースタイプ ProxyV2
指標 proxyv2/request_count
グループ化の条件 method とすべての ProxyV2 リソースタイプ ラベル
アグリゲータ sum
アラートに関する考慮事項 異常な request_count spike/drop アラートなどのイベント
アラートのしきい値 なし
Cloud Monitoring ダッシュボードの MQL クエリ:
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/request_count'
| align rate(1m)
| every 1m
| group_by [metric.method],
  [value_request_count_aggregate: aggregate(value.request_count)]

ターゲット リクエスト数

ユースケース: targetv2/request_count を使用して、Apigee ランタイム ターゲットのリクエスト数をモニタリングします。targetv2/request_count グラフには、Apigee ターゲットが受信したリクエスト率が表示されます。このグラフは、リクエスト率が高いターゲット、リクエスト率のパターン、特定のターゲットのリクエスト呼び出しの異常な急増の確認に役立ちます。

リソースタイプ TargetV2
指標 targetv2/request_count
グループ化の条件 method とすべての TargetV2 リソースタイプ ラベル
アグリゲータ sum
アラートに関する考慮事項 異常な request_count spike/drop アラートなどのイベント
アラートのしきい値 なし
Cloud Monitoring ダッシュボードの MQL クエリ:
fetch apigee.googleapis.com/TargetV2
| metric 'apigee.googleapis.com/targetv2/request_count'
| align rate(1m)
| every 1m
| group_by [metric.method, metric.type, metric.endpoint],
  [value_request_count_aggregate: aggregate(value.request_count)]

エラー率

プロキシエラーのレスポンス数

ユースケース: proxyv2/response_count を使用して、プロキシエラーのレスポンス率をモニタリングします。proxyv2/response_count グラフには、API プロキシのリクエスト率が表示されます。このグラフは、リクエスト エラー率が高いプロキシや、特定のプロキシのリクエスト呼び出しの異常なエラー急増を把握するのに役立ちます。

リソースタイプ ProxyV2
指標 proxyv2/response_count
フィルタ条件 response_code != 200

正規表現を使用して 2xx と 3xx の response_code をすべて除外します。例:

"response_code !=~ 1.*| 2.*|3.*"
グループ化の条件 method、response_code、fault_code、fault_source、apigee_fault、およびすべての ProxyV2 リソースタイプ ラベル
アグリゲータ sum
アラートに関する考慮事項 プロキシ レスポンス エラー率: 合計レスポンス エラー数 ÷ 合計レスポンス数。
  • 合計レスポンス エラー数 = response_code != 200 でフィルタした proxyv2/response_count の合計
  • 合計レスポンス数 = proxyv2/response_count の合計
アラートのしきい値 インストールの SLO によって異なります。本番環境へのインストールと非本番環境へのインストールでは、しきい値が異なる場合があります。例: 本番環境で、プロキシ レスポンス 500 のエラー率が 5 分間で 5% の場合にイベント通知をトリガーします。
Cloud Monitoring ダッシュボードの MQL クエリ:
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/response_count'
| filter (metric.response_code != '200')
| align rate(1m)
| every 1m
| group_by
  [metric.method, metric.response_code, metric.fault_code,
   metric.fault_source, metric.apigee_fault],
  [value_response_count_aggregate: aggregate(value.response_count)]
Google Cloud オペレーションのアラート ポリシー MQL の例: 
fetch apigee.googleapis.com/ProxyV2::apigee.googleapis.com/proxyv2/response_count
| {
   filter (metric.response_code == '500')
   ;
   ident
}
| group_by drop[metric.response_code ], sliding(5m), .sum
| ratio
| scale '%'
| every (30s)
| condition val() > 5'%'

ターゲット エラー レスポンス数

ユースケース: targetv2/response_count を使用して、API ターゲットのエラー レスポンス率をモニタリングします。targetv2/response_count グラフには、API ターゲットからのリクエスト率が表示されます。このグラフは、リクエスト率が高いターゲットや、リクエスト呼び出しの異常なエラー急増を特定するのに役立ちます。

リソースタイプ TargetV2
指標 targetv2/response_count
フィルタ条件 response_code != 200

正規表現を使用して 2xx と 3xx の response_code をすべて除外します。例:

"response_code !=~ 1.*| 2.*|3.*"
グループ化の条件 method とすべての TargetV2 リソースタイプ ラベル
アグリゲータ sum
アラートに関する考慮事項 プロキシ レスポンス エラー率（例: 合計レスポンス エラー数 ÷ 合計レスポンス数）。
  • 合計レスポンス エラー数 = response_code != 200 でフィルタした targetv2/response_count の合計
  • 合計レスポンス数 = targetv2/response_count の合計
アラートのしきい値 インストールの SLO によって異なります。例: 本番環境で、ターゲット レスポンス エラー率が 3 分間で 5% の場合にイベント通知をトリガーします。
Cloud Monitoring ダッシュボードの MQL クエリ:
fetch apigee.googleapis.com/TargetV2
| metric 'apigee.googleapis.com/targetv2/response_count'
| filter (metric.response_code != '200')
| align rate(1m)
| every 1m
| group_by
  [metric.method, metric.type, metric.endpoint,
   metric.response_code],
  [value_response_count_aggregate: aggregate(value.response_count)]

レイテンシ

プロキシ レイテンシのパーセンタイル

ユースケース: proxyv2/latencies_percentile を使用して、リクエストに対するすべての API プロキシ レスポンスのレイテンシ パーセンタイル（p50、p90、p95、p99）をモニタリングします。proxyv2/latencies_percentile グラフは、API プロキシ リクエスト全体のレイテンシに対する Apigee API プロキシのレイテンシを特定するのに有用です。

リソースタイプ ProxyV2
指標 proxyv2/latencies_percentile
フィルタ条件 percentile = p99
グループ化の条件 method、percentile、およびすべての ProxyV2 リソースタイプ ラベル
アグリゲータ p99（99 パーセンタイル）
アラートに関する考慮事項 p99 latencies_percentile の値が大きい。
アラートのしきい値 インストールの SLO によって異なります。例: 本番環境で、プロキシ p99 latencies_percentile の値が 5 分間で 5 秒の場合にイベント通知をトリガーします。
Cloud Monitoring ダッシュボードの MQL クエリ:
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/latencies_percentile'
| filter (metric.percentile == 'p99')
| group_by 1m,
  [value_latencies_percentile_mean: mean(value.latencies_percentile)]
| every 1m
| group_by [metric.method, metric.percentile],
  [value_latencies_percentile_mean_percentile:
     percentile(value_latencies_percentile_mean, 99)]

ターゲット レイテンシのパーセンタイル

ユースケース: targetv2/latencies_percentile を使用して、リクエストに対するすべての API プロキシ ターゲット レスポンスのレイテンシ パーセンタイル（p50、p90、p95、p99）をモニタリングします。targetv2/latencies_percentile グラフは、Apigee API プロキシ ターゲットがリクエストに応答するまでの合計時間を示します。この値には Apigee API プロキシのオーバーヘッドは含まれません。

リソースタイプ TargetV2
指標 targetv2/latencies_percentile
フィルタ条件 percentile = p99
グループ化の条件 method、percentile、およびすべての TargetV2 リソースタイプ ラベル
アグリゲータ p99（99 パーセンタイル）
アラートに関する考慮事項 p99 latencies_percentile の値が大きい。
アラートのしきい値 インストールの SLO によって異なります。例: 本番環境で、ターゲット p99 latencies_percentile の値が 5 分間で 5 秒の場合にイベント通知をトリガーします。
Cloud Monitoring ダッシュボードの MQL クエリ:
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/latencies_percentile'
| filter (metric.percentile == 'p99')
| group_by 1m,
  [value_latencies_percentile_mean: mean(value.latencies_percentile)]
| every 1m
| group_by [metric.method, metric.percentile],
  [value_latencies_percentile_mean_percentile:
     percentile(value_latencies_percentile_mean, 99)]

ポリシー レイテンシのパーセンタイル

ユースケース: policyv2/latencies_percentile を使用して、すべての Apigee ポリシーの処理レイテンシのパーセンタイル（p50、p90、p95、p99）をモニタリングします。policyv2/latencies_percentile グラフは、お客様の API プロキシ リクエスト全体のレイテンシに対する Apigee API ポリシーのレイテンシを特定するのに有用です。

リソースタイプ ProxyV2
指標 proxyv2/latencies_percentile
フィルタ条件 percentile = p99
グループ化の条件 method、percentile、およびすべての ProxyV2 リソースタイプ ラベル
アグリゲータ p99（99 パーセンタイル）
アラートに関する考慮事項 p99 latencies_percentile の値が大きい。
アラートのしきい値 インストールの SLO によって異なります。例: 本番環境で、プロキシ p99 latencies_percentile の値が 5 分間で 5 秒の場合にイベント通知をトリガーします。
Cloud Monitoring ダッシュボードの MQL クエリ:
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/policyv2/latencies_percentile'
| filter (metric.percentile == 'p99')
| group_by 1m,
  [value_latencies_percentile_mean: mean(value.latencies_percentile)]
| every 1m
| group_by [metric.policy_name, metric.percentile],
  [value_latencies_percentile_mean_aggregate:
     aggregate(value_latencies_percentile_mean)]

データベース

Cassandra

Apigee Cassandra データベース サービスには、複数の Cassandra SLI 指標があります。これらの SLI 指標により、Apigee Cassandra サービスを包括的にモニタリングできます。Cassandra サービスの正常性を確認するため、少なくとも、Cassandra リソースの使用量（CPU、メモリ、ディスク ボリューム）とともに、クライアントの読み取りと書き込みのリクエストのレイテンシをモニタリングする必要があります。

Cassandra の読み取りリクエスト率

ユースケース: cassandra/clientrequest_rate（scope=Read を含む）の SLI 指標により、任意の時点での Cassandra サービスの読み取りリクエストの平均レートに関する分析情報が提供されます。この指標は、クライアントの読み取りリクエストのアクティビティ レベルの傾向を把握するのに役立ちます。

リソースタイプ k8s_container
指標 cassandra/clientrequest_rate
フィルタ条件 scope = Read と unit = OneMinuteRate
グループ化の条件 scope、unit、およびすべての k8s_container リソースタイプ ラベル
アグリゲータ sum
アラートに関する考慮事項 潜在的なクエリの問題や、クライアントのクエリパターンの大幅な変化（読み取りリクエスト率の突然の予期しない急増や減少など）。
アラートのしきい値 なし
Cloud Monitoring ダッシュボードの MQL クエリ:
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Read' && metric.unit == 'OneMinuteRate')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Cassandra の書き込みリクエスト率

ユースケース: cassandra/clientrequest_rate（scope=Write を含む）の SLI 指標により、任意の時点での Cassandra サービスの書き込みリクエストの平均レートに関する分析情報が提供されます。この指標は、クライアントの書き込みリクエストのアクティビティ レベルの傾向を把握するのに役立ちます。

リソースタイプ k8s_container
指標 cassandra/clientrequest_rate
フィルタ条件 scope = Read と unit = OneMinuteRate
グループ化の条件 scope、unit、およびすべての k8s_container リソースタイプ ラベル
アグリゲータ sum
アラートに関する考慮事項 追加の調査が必要な、書き込みリクエストの突然の予期しない急増や急激な減少など、クライアント クエリパターンの潜在的な問題や大きな変化。
アラートのしきい値 なし
Cloud Monitoring ダッシュボードの MQL クエリ:
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Write' && metric.unit == 'OneMinuteRate')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Cassandra の読み取りリクエストのレイテンシ

ユースケース: cassandra/clientrequest_latency（scope=Read を含む）の SLI 指標により、Cassandra サービスの読み取りリクエストのレイテンシ（99 パーセンタイル、95 パーセンタイル、または 75 パーセンタイル）が提供されます。これらの指標は、Cassandra のパフォーマンスを包括的に把握するのに役立ち、使用パターンの変化や、時間の経過とともに現れる問題を示すことができます。

リソースタイプ k8s_container
指標 cassandra/clientrequest_latency
フィルタ条件 scope = Read と unit = 99thPercentile
グループ化の条件 scope、unit、およびすべての k8s_container リソースタイプ ラベル
アグリゲータ sum
アラートに関する考慮事項 読み取りリクエストのレイテンシ SLI が、99 パーセンタイルのレイテンシで継続的に上昇傾向にあることを示す場合。
アラートのしきい値 Cassandra サービスの SLO によって異なります。たとえば、本番環境で、clientrequest_latency 99 パーセンタイル読み取り値が 3 分間で 5 秒の場合にイベント通知をトリガーします。
Cloud Monitoring ダッシュボードの MQL クエリ:
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Read' && metric.unit == '99thPercentile')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Cassandra の書き込みリクエストのレイテンシ

ユースケース: cassandra/clientrequest_latency（scope=Write を含む）の SLI 指標により、Cassandra サービスの書き込みリクエストのレイテンシ（99 パーセンタイル、95 パーセンタイル、または 75 パーセンタイル）が提供されます。これらの指標は、Cassandra のパフォーマンスを包括的に把握するのに役立ち、使用パターンの変化や、時間の経過とともに現れる問題を示すことができます。

リソースタイプ k8s_container
指標 cassandra/clientrequest_latency
フィルタ条件 scope = Write と unit = 99thPercentile
グループ化の条件 scope、unit、およびすべての k8s_container リソースタイプ ラベル
アグリゲータ sum
アラートに関する考慮事項 書き込みリクエストのレイテンシ SLI が、99 パーセンタイルのレイテンシで継続的に上昇傾向にあることを示す場合。
アラートのしきい値 Cassandra サービスの SLO によって異なります。たとえば、本番環境で、clientrequest_latency の 99 パーセンタイル書き込み値が 3 分間で 5 秒の場合にイベント通知をトリガーします。
Cloud Monitoring ダッシュボードの MQL クエリ:
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Write' && metric.unit == '99thPercentile')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Apigee コントロール プレーン

Apigee Synchronizer サービスの SLI 指標は、リクエストとレスポンスの数、および Apigee コントロール プレーンとハイブリッド ランタイム プレーン間のレイテンシを提供します。ランタイム プレーンで実行中の Synchronizer インスタンスは、コントロール プレーンを定期的にポーリングし、契約をダウンロードして、ローカル ランタイム インスタンスでも使用できるようにします。

リクエスト率

アップストリーム リクエスト数

ユースケース: upstream/request_count 指標は、Synchronizer サービスから Apigee コントロール プレーンに対して行われたリクエストの数を示します。

リソースタイプ k8s_container
指標 upstream/request_count
フィルタ条件 container_name = apigee-synchronizer と type = CONTRACT
グループ化の条件 method、type、container_name、およびすべての k8s_container リソースタイプ ラベル
アグリゲータ sum
アラートに関する考慮事項 request_count の異常な急増や減少のアラートなど、トラフィックの異常に対して使用します。
アラートのしきい値 なし
Cloud Monitoring ダッシュボードの MQL クエリ:
fetch k8s_container
| metric 'apigee.googleapis.com/upstream/request_count'
| filter
  (resource.container_name == 'apigee-synchronizer')
  && (metric.type == 'CONTRACT')
| align rate(1m)
| every 1m
| group_by [metric.method, metric.type, resource.container_name],
  [value_request_count_aggregate: aggregate(value.request_count)]

エラー率

アップストリーム レスポンス数

ユースケース: upstream/response_count SLI 指標は、Synchronizer サービスが Apigee コントロール プレーンから受信したレスポンス数を示します。このグラフは、Apigee ハイブリッド ランタイム プレーンとコントロール プレーン間の接続または構成の問題を特定するのに役立ちます。

リソースタイプ k8s_container
指標 upstream/request_count
フィルタ条件 method、response_type、container_name、およびすべての k8s_container リソースタイプ ラベル
グループ化の条件
アグリゲータ sum
アラートに関する考慮事項 Apigee コントロール プレーンから返された 200 以外のレスポンス コードを持つ upstream/response_count 指標にエラーがあり、それらのエラーについてさらに調査が必要な場合。
アラートのしきい値 Cassandra サービスの SLO によって異なります。例: 本番環境で、Synchronizer が 3 分ごとに 2 つ以上の response_code エラーを検出した場合にイベント通知をトリガーします。
Cloud Monitoring ダッシュボードの MQL クエリ:
fetch k8s_container
| metric 'apigee.googleapis.com/upstream/response_count'
| filter
  (resource.container_name == 'apigee-synchronizer')
  && (metric.response_code != '200' && metric.type == 'CONTRACT')
| align rate(1m)
| every 1m
| group_by
  [metric.method, metric.response_code, metric.type, resource.container_name],
  [value_response_count_aggregate: aggregate(value.response_count)]

インフラストラクチャ

GKE やその他の Kubernetes プラットフォームは、システムレベルの SLI 指標を提供します。SLI 指標ラベルをフィルタリングしてグループ化することで、特定のコンテナとそのリソース使用量をモニタリングできます。Apigee ランタイム クラスタのインフラストラクチャの正常性と可用性をモニタリングするために、クラスタ管理者はコンテナと Pod の共通リソース使用量（CPU、メモリ、ディスク、コンテナの再起動数など）をモニタリングできます。使用可能な指標とラベルの詳細については、GKE のドキュメントをご覧ください。

次の表に、一部のサービスと、各サービスでモニタリングできるコンテナを示します。

サービス名 コンテナ名
Cassandra apigee-cassandra
Message Processor（MP） apigee-runtime
Synchronizer apigee-synchronizer
Telemetry apigee-prometheus-app
apigee-prometheus-proxy
apigee-prometheus-agg
apigee-stackdriver-exporter

コンテナ / Pod

再起動回数

ユースケース: システム SLI 指標である kubernetes.io/container/restart_count は、コンテナが再起動した回数を示します。このグラフは、コンテナのクラッシュ / 再起動が頻繁に発生しているかどうかを特定するのに役立ちます。特定のサービス コンテナは、特定のサービスのコンテナ モニタリングの指標ラベルでフィルタできます。

以下に、Cassandra コンテナの kubernetes.io/container/restart_count 指標を使用する方法を示します。この指標は、上記の表の任意のコンテナに使用できます。

リソースタイプ k8s_container
指標 kubernetes.io/container/restart_count
フィルタ条件 namespace_name = apigee と container_name =~ .*cassandra.*
グループ化の条件 cluster_name、namespace_name、pod_name、container_name、およびすべての k8s_container リソースタイプ ラベル
アグリゲータ sum
アラートに関する考慮事項 コンテナが頻繁に再起動する場合は、根本原因についてさらに調査する必要があります。OOMKilled、データディスクの空き容量なし、構成の問題など、コンテナが再起動する理由は複数あります。
アラートのしきい値 インストールの SLO によって異なります。例: 本番環境で、コンテナが 30 分以内に 5 回以上再起動した場合にイベント通知をトリガーします。
Cloud Monitoring ダッシュボードの MQL クエリ:
fetch k8s_container
| metric 'kubernetes.io/container/restart_count'
| filter
  (resource.container_name =~ '.*cassandra.*'
   && resource.namespace_name == 'apigee')
| align rate(1m)
| every 1m
| group_by
  [resource.cluster_name, resource.namespace_name, resource.pod_name,
   resource.container_name],
  [value_restart_count_aggregate: aggregate(value.restart_count)]