Monitoring

AWS CloudWatch provides a powerful set of tools for monitoring a software system running on AWS:

  • You can collect and track CloudWatch Metrics – variables that measure the behavior of your system.
  • You can configure CloudWatch Alarms to notify operations or take other automated steps when potential problems arise.
  • You can monitor, store, and search CloudWatch Logs across all your AWS resources.
  • You can create CloudWatch Dashboards that provide a single overview for monitoring your systems.

Datomic is fully integrated with all of these AWS monitoring tools. On the producing side, Datomic creates metrics and logs; and on the consuming side, Datomic organizes metrics in custom dashboards. This document shows how to manage and monitor your Datomic system.

Finding Datomic Resources by Tag

Datomic tags resources it creates with the following tag:

Tag NameTag ValueResources Tagged
datomic:systemSystem Nameall taggable resources

You can use this tag to locate all the resources associated with a Datomic system. From the Tag Editor:

  1. Under Regions, Enter one or more AWS regions
  2. Under Resource types, choose "All resource types"
  3. Under Tags, choose the name "datomic:system" for tag key
  4. Under the same row in Tags, enter a specific System Name for tag value, or leave the tag value blank to find resources for all Datomic Systems.

../images/find-resources-to-tag.png

Searching CloudWatch Logs

To view the CloudWatch Logs for a Datomic system:

  • Open the CloudWatch Logs in the AWS Console
  • Click on the Log Group named "datomic-{System}", where System is your system name

Each EC2 instance will create a separate log stream. Usually you will want to search across all log streams:

  • click the "Search Log Group" button
  • click to the right of the filter box to choose an appropriate time window
  • enter a metric filter pattern to scope your search

Finding Alerts

The search pattern "Alert - Alerts" will find the text of every alert produced by Datomic. The "Alert" matches each alert, and the "- Alerts" filters redundant summary messages.

The example below demonstrates reviewing a week's worth of alerts. The single event that matches is a transient DynamoDB request failure, so not a problem.

../images/search-for-alerts.png

Finding Logs By Message

The image below shows using the CloudWatch Filter and Pattern Syntax to find all logs whose Msg is "CodeDeployEvent".

  • The brackets {} identify the query as a JSON metric filter
  • the $ is a placeholder for log entry as a whole
  • the dot syntax scopes the search to the individual key Msg

../images/cast-event.png

Metrics Produced by Datomic Cloud

Datomic cluster nodes write Cloudwatch Metrics as follows:

  • The namespace is DatomicCloud
  • The dimensions include system, cluster, and group.

In the table below

  • {CacheOp} can be Get or Put
  • {DdbOp} can be Read or Write
  • {Outcome} can be Succeeded or Failed
  • {RefOp} can be Get, Scan, Update
  • {StoreOp} can be Create, Get, Exists, Delete
MetricSubsystemUnitsDescription
AlertsLogcountnumber of alerts written to Cloudwatch logs
CacheKmsEkMapCachecount0 = miss, 1 = hit, average = hit %, KMS Encrypted Key Map
CacheKmsKeyCachecount0 = miss, 1 = hit, average = hit %, KMS Secret Key
DatomsDbcountnumber of datoms in a database, reported when indexer checks for work
Ddb{DdbOp}{Outcome}MsecStoragemseclatency for a ddb operation
Ddb{Op}RetryCountStoragemsecbackoff count for a ddb op
Ddb{Op}RetryDelayStoragemsecbackoff latency for a ddb op
Efs{CacheOp}{Outcome}MsecCachemseclatency for an EFS cache operation
EfsHitsCachecount0 = miss, 1 = hit, average = hit %
EfsRepairCachecountcount of repaired EFS cache hits
EventsLogcountnumber of events written to Cloudwatch logs
HttpEndpointAsyncTimeoutWebcountcount of requests failed by http async timeout
HttpEndpointPingsWebcountcount of healthcheck pings received from e.g. load balancer
HttpEndpointOpsPendingWebcountcount is total number of requests started
HttpEndpointThrottledWebcountrequests rejected because server too busy
ObjectCacheHitsCachecount0 = miss, 1 = hit, average = hit %
IndexClaimRootConflictIndexcountconflict attempting to claim index root, will retry
IndexJobMsecIndexmsecduration of index job
IndexJobDatomsIndexcountnumber of datoms added by an index job
IndexJobStartIndexcountstart of an index job
IndexJobWritesIndexcountnumber of segments written by an index job
IndexMemMbIndexmbtotal size of the in-memory indexes on a node
IndexWriteQueueCountIndexcountcount of index write queue
JvmFreeMb-mbfree JVM memory
KmsGenerateDataKeyLogcountcount of data keys generated
LogCatchupBatchesLogcountnumber of tx batches read to catchup the log
LogCatchupBytesLogcountnumber of tx batches read to catchup the log
LogCatchupMsecLogcountnumber of tx batches read to catchup the log
NanoImplFailedAuthnsAuthcountnumber of failed auth'n AND auth'z attempts
NextForwardCountWebcountnumber of paginated requests forwarded from one node to another
NodeDbCount-countnumber of databases being server by node
Ref{RefOp}MsecRefmseclatency for a ref op
S3{StoreOp}{Outcome}MsecStoragemseclatency for a store op
S3{StoreOp}{Outcome}Storagecountnumber of times current S3 Op has failed, including retries
S3{StoreOp}RetrySucceeddedStoragecountS3 op succeeded on a retry
S3StoreCreateBytesStoragebytesnumber of bytes written to S3
TxBatchCountTxcountnumber of txes batched into a storage write
TxBatchBytesTxbytesnumber of bytes batched into a storage write
TxBatchStoreValTxcountnumber of large tx batches written as vals
Tx{Outcome}MsecTxmsectime from transaction dequeued to notifications enqueued
TxBatchProcessedMsecTxmsectime from first tx dequeued to all notitications enqueued
TxCacheGetMsecTxmsectime to retrieve recent tx from the cache
TxCacheHitsTxcount0 = miss, 1 = hit, average = hit %
TxForwardCountWebcountnumber of tx requests forwarded from one node to another
Valcache{CacheOp}{Outcome}MsecCachemseclatency for a memcached cache operation
ValcacheHitsCachecount0 = miss, 1 = hit, average = hit %
ValcacheRepairCachecountcount of repaired memcached cache hits

Note In order to reduce cost, the Solo Topology reports only a small subset of the metircs listed above: Alerts, Datomic, Events HttpEndpointOpsPending, JvmFreeMb, and HttpEndpointThrottled.

Deprecated Metrics

These metrics are no longer reported, but may appear in the UI until they age out.

MetricSubsystemUnitsDescription
IndexMemBytesIndexbytessize of memory portion of the index
IndexWritesIndexcountnumber of segments written by an index job

Logs Produced by Datomic Cloud

Datomic writes Cloudwatch Logs as follows:

  • The "Log Group" name is the name of the Datomic System
  • Each EC instance will create a log stream named by the convention {system}-{group}-{instance-id}-{timestamp}
SubsystemMsg KeyDetails
Cache"Create object cache"size of object cache
Index"Starting indexer"indexer settings
Index"Root map loaded"contents of an index root
Node"Active database ids"db ids being served by this node
Node"Cluster node starting"includes all configuration for the cluster
{various}"Daemon thread started"thread name identifies subsystem and db
{various}"Daamon thread completed"thread name identifies subsystem and db

Datomic Cloud Dashboards

When you launch a Datomic Cloud system, it automatically creates a dashboard named datomic-(system)-(region) that you can view in the AWS Console.

The Solo Topology creates a basic dashboard:

../images/solo-dashboard.png

The Production Topology creates a much larger dashboard, suitable for viewing on a large ops monitor screen:

../images/production-dashboard.png

Each dashboard widget tells a story. For example, the DynamoDB Usage widget tracks DynamoDB AutoScaling of reads (left axis) and writes (right axis). In the image below you can see DynamoDB write provisioning (the green line) scaling up for a four-hour period during a batch load, and then scaling back down to almost nothing.

../images/ddb-autoscaling.png

The metrics tracked in the dashboards are a subset of the metrics produced by Datomic and described in the table above.