Logging and monitoring

AppSync is integrated with CloudWatch, both Logs and Metrics so it can automatically publish debugging and operational information there. And CloudWatch comes with a rich toolset to analyze and monitor this data, this makes it relatively easy to gain insight of what is happening with the API. And as CloudWatch is a managed serverless solution, you can't overwhelm it with too much data. Provided, of course, that you are willing to pay for that.

In this chapter we'll take a look into how logging and monitoring works for an AppSync API.

Logging

The primary purpose of logging is debugging, and AppSync can publish a good range of information (if configured to do so) to the logs. But, of course, there are edge cases you should be looking out for.

Setup logging

CloudWatch Logs uses a 2-layered system for logs. The top level is the Log Group which is the container for a single entity, such as an AppSync API. It's name is determined by the AppSync service: /aws/appsync/apis/<apiid>.

The lower level is the Log Streams. AppSync automatically creates these streams according to some internal logic, and they contain the actual log messages. In practice, you query the stream with the latest log message to see the most recent log events.

AppSync follows the usual AWS way in regards to permissions: the service needs an IAM role to gain write access to CloudWatch Logs as by default it has no permissions on its own.

The minimal set of permissions give write access to the groups, streams, and messages:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "*"
    }
  ]
}

If you use the Management Console, AWS creates the role with these permissions.