ども、cloudpack の かっぱ (@inokara) です。

はじめに

Amazon ElastiCache 用の CloudWatch メトリクスについてドキュメントが程よく整理されていますが、自分用にチートシート的にメモっておきたい。そのまま写経はダルいので必要（そうな）ものだけを写経する。

参考

概要

メトリクス

以下のメトリクスが提供される

  • ホストレベルのメトリクス
  • キャッシュエンジン（Redis や Memcached）固有のメトリクス

監視間隔

  • 60 秒毎

Namespace と Dimensions

Namespace

  • AWS/ElastiCache

Dimensions

Dimensions は CacheClusterId と CacheNodeId を合わせて指定することが重要！

  • CacheClusterId
  • CacheNodeId

自分はそれを知らずに半日程ハマった。

メトリクス

モニタリングするべきメトリクス

こういう情報有難い！

自分なりに整理した。

メトリクス メトリクスの種類 詳細 閾値 備考
CPUUtilization ホストレベル CPU 使用率 memcached = 90(%)
Redis = 90/CPU コア数(%)
SwapUsage ホストレベル Swap 使用量 memcached = 50(MB)を超えないこと
Redis = アラーム設定不可
Evictions エンジンレベル 新しい領域を確保する為に排除されたキー、項目の数 任意の閾値
CurrConnections エンジンレベル クライアントからの接続数 任意の閾値 memcached = memcached の仕様上、常に 10 以上の数が返される
Redis = リードレプリカからの接続を除く

上記は最低限設定しておきたい。

ホストレベル

以下、ドキュメントへのリンク。

Redis

以下、ドキュメントへのリンク。

Memcached

以下、ドキュメントへのリンク。

Tasseo で可視化

せっかくなので可視化。モニタリングすべきメトリックスとホストレベルのメトリックスを ElastiCache for Redis と ElasiCache for memcached でそれぞれ Tasseo で可視化してみる。Tasseo を選んだのは単なる好み。

Tasseo のような補助的なツールだけではなく基本的に CloudWatch からメトリクスを取得する際には…

  • Namespace
  • Dimensions
  • Metrics Name

を指定刷る必要があるので注意すること。例えば、Tasseo の場合には以下のような JS ファイルを用意することになる。

var period = 60;
var refresh = 1 * 60 * 1000;
var usingCloudWatch = true;
var metrics = [
  {
    "target": "CPUUtilization(%)",
    "Namespace": "AWS/ElastiCache",
    "MetricName": "CPUUtilization",
    "Statistics": [
      "Average"
    ],
    "Dimensions": [
      {
        "Name": "CacheClusterId",
        "Value": "kappa-test"
      },
      {
        "Name": "CacheNodeId",
        "Value": "0001"
      }
    ]
  }
]

メトリクスを提供するサービス（AWS のサービス）によっては Dimensions を複数定義する必要があるので更に注意しましょう。

今回はそれぞれにベンチマークツールで適当な負荷を掛けた状態を見てみる。

ElastiCache for Redis

ElastiCache for Redis のモニタリングすべきメトリックスを Tasseo で可視化

ElastiCache for memcached

ElastiCache for memcached のモニタリングすべきメトリックスを Tasseo で可視化

おまけ

各サービスの Namespace と Dimensions

余談…それぞれのページに別れているのを一覧化。

サービス Namespace Dimensions
Auto Scaling AWS/AutoScaling Auto Scaling group
Billing AWS/Billing N/A
Amazon DynamoDB AWS/DynamoDB TableName, GlobalSecondaryIndexName(Require “TableName”), Operation
Amazon ElastiCache AWS/ElastiCache CacheClusterId, CacheNodeId(supply both the CacheClusterId and CacheNodeId)
Amazon Elastic Block Store AWS/EBS Volume ID
Amazon Elastic Compute Cloud AWS/EC2 AutoScalingGroupName, ImageId, InstanceId, InstanceType
Elastic Load Balancing AWS/ELB LoadBalancerName, AvailabilityZone
Amazon Elastic MapReduce AWS/ElasticMapReduce JobFlowId, JobId
AWS OpsWorks AWS/OpsWorks StackId, LayerId, InstanceId
Amazon Redshift AWS/Redshift NodeID, ClusterIdentifier
Amazon Relational Database Service AWS/RDS DBInstanceIdentifier, DatabaseClass, EngineName
Amazon Route 53 AWS/Route53 HealthCheckId
Amazon Simple Notification Service AWS/SNS Application, Application,Platform, Platform, TopicName
Amazon Simple Queue Service AWS/SQS QueueName
Amazon Simple Workflow Service AWS/SWF Domain, WorkflowTypeName, WorkflowTypeVersion(Workflow Metrics) / Domain,　ActivityTypeName, ActivityTypeVersion(Activity Metrics)
AWS Storage Gateway AWS/StorageGateway GatewayId,GatewayName, VolumeId

最後に

それぞれのサービスを同じインターフェースで確認出来る CloudWatch ってスゴイなあと思った次第。同じインターフェースで見ようとする弊害が無いとも言えなそう。ElastiCache に限らずだが、モニタリングすべきメトリックスのような情報が各サービス毎にまとまっていたりすると嬉しい。また、ELB のように各メトリクス毎の「推奨統計」（Average や Sum 等）も整理されていると嬉しいかな。

元記事はこちらです。
「ElastiCache の CloudWatch メトリクス、おれんチートシート」