Monitoring Philter in AWS

A deployment of Philter 4.0 in AWS can be monitored in several ways. This guide covers its application log, its availability, and its metrics, on the AWS Marketplace virtual machine.

Monitoring Philter’s application log with CloudWatch Logs

Although no sensitive information is purposely logged, it is possible for sensitive information to be included inadvertently through some events. Make sure wherever Philter’s log is stored is suitable for sensitive information such as PHI and PII.

Philter writes its log to standard output, which Docker captures. On the virtual machine, read it with:

sudo docker logs philter-philter-1

To centralize the logs of several instances in CloudWatch Logs, use Docker’s awslogs log driver, which sends the container’s output straight to CloudWatch.

First, give the instance an IAM role whose policy allows writing to CloudWatch Logs. The following policy is sufficient:

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

Then add a logging section to the philter service in /opt/philter/docker-compose.yaml, after its restart line, using your region and the log group you want:

    logging:
      driver: awslogs
      options:
        awslogs-region: us-east-1
        awslogs-group: /philter
        awslogs-create-group: "true"

Restart Philter to apply it:

sudo systemctl restart philter

Philter’s log then appears in the /philter log group in the CloudWatch Logs console, with one stream per container.

Monitoring Philter’s availability with an Elastic Load Balancer

Philter’s /api/health endpoint returns HTTP 200 OK with Philter’s status and version when it is running, and needs no API key:

{"status":"UP","applicationVersion":"4.0.0","redactionPolicySchemaVersion":"1.3.0","gitCommit":"e9a6bc0"}

Use it for an Elastic Load Balancer target group’s health checks: protocol HTTPS, port 8080, path /api/health. The load balancer does not validate its targets’ certificates, so the health check works with Philter’s self-signed certificate. Clients that connect to Philter directly do validate it, so for them replace the self-signed certificate with one signed by a trusted authority.

Monitoring Philter’s metrics

Philter serves its metrics in Prometheus format at /actuator/prometheus on port 8080, without an API key. They include redactions by filter type, tokens processed, API requests by method and status, and the asynchronous document queue:

philter_api_requests_total{method="POST",status="200"} 1.0
philter_redactions_total{filter_type="ssn"} 1.0
philter_tokens_total 2.0
philter_async_queue_jobs 0.0

Scrape them with Prometheus, or send them to CloudWatch with the CloudWatch agent’s Prometheus support on EC2. Use them to alert on error rates or a growing queue, or to drive scaling when Philter runs in an Auto Scaling group behind a load balancer. The metrics reveal redaction volume, so restrict /actuator/ to your monitoring network. See Philter’s monitoring and logging documentation for the full list.

Philter is part of Philterd’s open source PII redaction software toolkit.