LogoLogo
Log in|Playground
  • Welcome
    • Introduction
    • FAQ
  • Capabilities
    • Log Management
    • Infrastructure Monitoring
    • Application Performance Monitoring (APM)
      • Application Metrics
      • Traces
      • Supported Technologies
    • Real User Monitoring (RUM)
  • Getting Started
    • Requirements
      • Kubernetes requirements
      • Kernel requirements for eBPF sensor
      • CPU architectures
      • ClickHouse resources
    • Installation & updating
    • Connect Linux hosts
    • Connect RUM
    • 5 quick steps to get you started
    • groundcover MCP
      • Configure groundcover's MCP Server
      • Getting-started Prompts
      • Real-world Use Cases
  • Use groundcover
    • Monitors
      • Create a new Monitor
      • Issues page
      • Monitor List page
      • Silences page
      • Monitor Catalog page
      • Monitor YAML structure
      • Embedded Grafana Alerts
        • Create a Grafana alert
    • Dashboards
      • Create a dashboard
      • Embedded Grafana Dashboards
        • Create a Grafana dashboard
        • Build alerts & dashboards with Grafana Terraform provider
        • Using groundcover datasources in a Self-hosted Grafana
    • Insights
    • Explore & Monitors query builder
    • Workflows
      • Create a new Workflow
      • Workflow Examples
      • Alert Structure
    • Search & Filter
    • Issues
    • Role-Based Access Control (RBAC)
    • Service Accounts
    • API Keys
    • APIs
    • Log Patterns
    • Drilldown
    • Scraping custom metrics
      • Operator based metrics
      • kube-state-metrics
      • cadvisor metrics
    • Backup & Restore Metrics
    • Metrics & Labels
    • Add custom environment labels
    • Configuring Pipelines
      • Writing Remap Transforms
      • Logs Pipeline Examples
      • Traces Pipeline Examples
      • Logs to Events Pipeline Examples
      • Logs/Traces Sensitive Data Obfuscation
      • Sensitive Data Obfuscation using OTTL
      • Log Filtering using OTTL
    • Querying your groundcover data
      • Query your logs
        • Example queries
        • Logs alerting
      • Query your metrics
      • Querying you data using an API
      • Using KEDA autoscaler with groundcover
  • Log Parsing with OpenTelemetry Pipelines
  • Log and Trace Correlation
  • RUM
  • Customization
    • Customize deployment
      • Agents in host network mode
      • API Key Secret
      • Argo CD
      • On-premise deployment
      • Quay.io registry
      • Configuring sensor deployment coverage
      • Enabling SSL Tracing in Java Applications
    • Customize usage
      • Filtering Kubernetes entities
      • Custom data retention
      • Sensitive data obfuscation
      • Custom storage
      • Custom logs collection
      • Custom labels and annotations
        • Enrich logs and traces with pod labels & annotations
        • Enrich metrics with node labels
      • Disable tracing for specific protocols
      • Tuning resources
      • Controlling the eBPF sampling mechanism
  • Integrations
    • Overview
    • Workflow Integrations
      • Slack Webhook Integration
      • Opsgenie Integration
      • Webhook Integration
        • Incident.io
      • PagerDuty Integration
      • Jira Webhook Integration
      • Send groundcover Alerts to Email via Zapier
    • Data sources
      • OpenTelemetry
        • Traces & Logs
        • Metrics
      • Istio
      • AWS
        • Ingest CloudWatch Metrics
        • Ingest CloudWatch Logs
        • Ingest Logs Stored on S3
        • Integrate CloudWatch Grafana Datasource
      • GCP
        • Ingest Google Cloud Monitoring Metrics
        • Stream Logs using Pub/Sub
        • Integrate Google Cloud Monitoring Grafana Datasource
      • Azure
        • Ingest Azure Monitor Metrics
      • DataDog
        • Traces
        • Metrics
      • FluentBit
      • Fluentd
      • JSON Logs
    • 3rd-party metrics
      • ActiveMQ
      • Aerospike
      • Cassandra
      • CloudFlare
      • Consul
      • CoreDNS
      • Etcd
      • HAProxy
      • Harbor
      • JMeter
      • K6
      • Loki
      • Nginx
      • Pi-hole
      • Postfix
      • RabbitMQ
      • Redpanda
      • SNMP
      • Solr
      • Tomcat
      • Traefik
      • Varnish
      • Vertica
      • Zabbix
    • Source control (Gitlab/Github)
  • Architecture
    • Overview
    • inCloud Managed
      • Setup inCloud Managed with AWS
        • AWS PrivateLink Setup
        • EKS add-on
      • Setup inCloud Managed with GCP
      • Setup inCloud Managed with Azure
      • High Availability
      • Disaster Recovery
      • Ingestion Endpoints
      • Deploying in Sensor-Only mode
    • Security considerations
      • Okta SSO - onboarding
    • Service endpoints inside the cluster
  • Product Updates
    • What's new?
    • Earlier updates
      • 2025
        • Mar 2025
        • Feb 2025
        • Jan 2025
      • 2024
        • Dec 2024
        • Nov 2024
        • Oct 2024
        • Sep 2024
        • Aug 2024
        • July 2024
        • May 2024
        • Apr 2024
        • Mar 2024
        • Feb 2024
        • Jan 2024
      • 2023
        • Dec 2023
        • Nov 2023
        • Oct 2023
Powered by GitBook
On this page
  • How does it work
  • Things to know
  • Ingestion interval
  • Data storage
  • Metric Statistics
  • Supported AWS services
  • Setting up the integration
Export as PDF
  1. Integrations
  2. Data sources
  3. AWS

Ingest CloudWatch Metrics

Last updated 1 month ago

groundcover supports ingesting CloudWatch metrics directly into our platform, allowing you to visualize them using dashboards and create alerts.

How does it work

CloudWatch integration is done by deploying a service called integrations-agent which is responsible for pulling metrics from CloudWatch using periodic polling of these APIs:

The integration is setup using the following steps:

  1. Create a role with permissions to access the metrics on the target AWS account

  2. Provide the needed permissions to allow the integrations-agent service account to assume the new role

  3. Select the AWS namespaces you wish to collect metrics from

  4. Deploy the integrations-agent service and start collecting metrics

The actual steps differ for inCloud Managed and inCloud deployments. Follow the instructions below depending on your deployment type.

Things to know

Ingestion interval

The integration pulls data from CloudWatch every five minutes.

Data storage

Data fetched is stored in the Victoria Metrics database, meaning metrics are queried via the CloudWatch API only one time per data point.

Metric Statistics

Supported AWS services

Click to Open
AWS/AOSS
AWS/ApiGateway
AWS/AppRunner
AWS/AppStream
AWS/AppSync
AWS/ApplicationELB
AWS/Athena
AWS/AutoScaling
AWS/Backup
AWS/Bedrock
AWS/Cassandra
AWS/CertificateManager
AWS/CloudFront
AWS/Cognito
AWS/DDoSProtection
AWS/DMS
AWS/DX
AWS/DocDB
AWS/DynamoDB
AWS/EBS
AWS/EC2
AWS/EC2Spot
AWS/ECR
AWS/ECS
AWS/EFS
AWS/ELB
AWS/ES
AWS/ElastiCache
AWS/ElasticBeanstalk
AWS/ElasticMapReduce
AWS/FSx
AWS/Firehose
AWS/GameLift
AWS/GlobalAccelerator
AWS/Glue
AWS/IoT
AWS/KMS
AWS/Kafka
AWS/Kinesis
AWS/KinesisAnalytics
AWS/Lambda
AWS/MWAA
AWS/MediaConnect
AWS/MediaConvert
AWS/MediaLive
AWS/MediaPackage
AWS/MediaTailor
AWS/MemoryDB
AWS/NATGateway
AWS/Neptune
AWS/Network Manager
AWS/NetworkELB
AWS/NetworkFirewall
AWS/PrivateLinkEndpoints
AWS/PrivateLinkServices
AWS/RDS
AWS/Redshift
AWS/Route53
AWS/S3
AWS/SES
AWS/SNS
AWS/SQS
AWS/SageMaker
AWS/Sagemaker/ModelBuildingPipeline
AWS/Sagemaker/Endpoints
AWS/Sagemaker/ProcessingJobs
AWS/Sagemaker/TrainingJobs
AWS/Sagemaker/TransformJobs
AWS/States
AWS/StorageGateway
AWS/TransitGateway
AWS/TrustedAdvisor
AWS/VPN
AWS/WorkSpaces
ECS/ContainerInsights

Setting up the integration

The integration is supported for both inCloud Managed and inCloud deployments, by following slightly different steps. Make sure to select the deployment relevant for you.

Not sure? Contact us on slack!

inCloud Managed

In this setup, the integrations-agent is deployed inside the managed backend. A service account is automatically provisioned inside the managed account, so the installation mainly requires creating a role in the target AWS account with the correct trust relationship.

Create an IAM role and policy

The following part requires two parameters:

  • YOUR_GROUNDCOVER_SITE_ID - your unique groundcover endpoint ID:

    • The ID is the first part marked above as <SITE_ID>

  1. Click on Roles in the side bar

  2. Click on Create Role

    1. Select Custom trust policy

    2. Paste the following policy:

      {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "AWS": "arn:aws:iam::<YOUR_GROUNDCOVER_ACCOUNT_ID>:role/groundcover-integrations-agent-<YOUR_GROUNDCOVER_SITE_ID>-sa"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
      
    3. Click on Next twice (we'll attach permissions later)

    4. Provide a name for the role

    5. Click on Create Role

  3. Go to your newly created role

    1. In the Permissions section, click on Add permissions and then Create inline policy

    2. Click on JSON and paste the following:

      {
          "Version": "2012-10-17",
          "Id": "groundcover-integrations-agent",
          "Statement": [
              {
                  "Action": [
                      "tag:GetResources",
                      "storagegateway:ListTagsForResource",
                      "storagegateway:ListGateways",
                      "shield:ListProtections",
                      "iam:ListAccountAliases",
                      "ec2:DescribeTransitGatewayAttachments",
                      "ec2:DescribeSpotFleetRequests",
                      "dms:DescribeReplicationTasks",
                      "dms:DescribeReplicationInstances",
                      "cloudwatch:ListMetrics",
                      "cloudwatch:GetMetricStatistics",
                      "cloudwatch:GetMetricData",
                      "autoscaling:DescribeAutoScalingGroups",
                      "aps:ListWorkspaces",
                      "apigateway:GET"
                  ],
                  "Effect": "Allow",
                  "Resource": "*"
              }
          ]
      }
    3. Click on Next

    4. Give the policy a name

    5. Click on Create Policy

Choosing namespaces to ingest

Share details with groundcover

Share the following details with the groundcover team to complete the integration:

  1. The ARN of the role created above

  2. The list of namespaces you wish to ingest

  3. The region of the account you wish to ingest metrics from

inCloud

Create an identity provider (OIDC) for your EKS cluster

If you already have an identity provider set up in the account where the EKS cluster is set up, skip this stage

Create an OIDC provider for the EKS cluster where groundcover resides in. Once created, the details you will need in the next steps are:

  • Provider Name

  • Provider ARN

  • Namespace - the namespace where groundcover is installed (default: groundcover)

Create an IAM role and policy

  1. Click on Roles in the side bar

  2. Click on Create Role

    1. Select Custom trust policy

    2. Paste the following policy:

      {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Principal": {
                      "Federated": "{Provider ARN}"
                  },
                  "Action": "sts:AssumeRoleWithWebIdentity",
                  "Condition": {
                      "StringLike": {
                          "{Provider Name}:sub": "system:serviceaccount:{Namespace}:integrations-agent"
                      }
                  }
              }
          ]
      }
      
    3. Click on Next twice (we'll attach permissions later)

    4. Provide a name for the role

    5. Click on Create Role

  3. Go to your newly created role

    1. In the Permissions section, click on Add permissions and then Create inline policy

    2. Click on JSON and paste the following:

      {
          "Version": "2012-10-17",
          "Id": "groundcover-integrations-agent",
          "Statement": [
              {
                  "Action": [
                      "tag:GetResources",
                      "storagegateway:ListTagsForResource",
                      "storagegateway:ListGateways",
                      "shield:ListProtections",
                      "iam:ListAccountAliases",
                      "ec2:DescribeTransitGatewayAttachments",
                      "ec2:DescribeSpotFleetRequests",
                      "dms:DescribeReplicationTasks",
                      "dms:DescribeReplicationInstances",
                      "cloudwatch:ListMetrics",
                      "cloudwatch:GetMetricStatistics",
                      "cloudwatch:GetMetricData",
                      "autoscaling:DescribeAutoScalingGroups",
                      "aps:ListWorkspaces",
                      "apigateway:GET"
                  ],
                  "Effect": "Allow",
                  "Resource": "*"
              }
          ]
      }
    3. Click on Next

    4. Give the policy a name

    5. Click on Create Policy

Choosing namespaces to ingest

Deploy the changes

Add the following overrides to your groundcover installation. You will need the following:

  • Region - The region of the account you wish to ingest metrics from

  • NamespaceA, NamespaceB... - the AWS namespaces you chose

  • RoleARN - the ARN of the role created above

Note: the roleArn section in the configuration below is optional, and only required when using cross-account scraping. If you are scraping metrics inside the same account as the EKS cluster where groundcover is deployed, do not add the roleArn part.

In that scenario, you will need to define a role in each account with the permissions above, and enable cross-account access to assume the role from the RoleARN created above. The cross-account role appears below as otherAccountRole

global:
  integrations:
    agent:
      enabled: true
      
integrationsAgent:
  serviceAccount:
      annotations:
        eks.amazonaws.com/role-arn: {RoleARN}
  targets:
    cloudwatch:
    - stsRegion: "{Region}"
      regions:
        - "{Region}"
      namespaces:
        - "{NamespaceA}"
        - "{NamespaceB}"
      # optional - only for cross-account scraping, see note above
      roleArn: "{otherAccountRole}"

For example:

global:
  integrations:
    agent:
      enabled: true
      
integrationsAgent:
  serviceAccount:
      annotations:
        eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/groundcover-cw-metrics
  targets:
    cloudwatch:
    - stsRegion: "us-east-1"
      regions:
        - "us-east-1"
      namespaces:
        - "AWS/Lambda"
        - "AWS/ApiGateway"

Each metric has a label called stat which denotes the used during querying. Some metrics have multiple stats which are useful for different cases.

YOUR_GROUNDCOVER_ACCOUNT_ID - the AWS account id hosting the groundcover backend,

Fetch your inCloud Site from It will look like <SITE_ID>.platform.grcv.io

Go to

Select the AWS namespaces you wish to ingest metrics from. The list of supported services is .

In this setup, the integrations-agent is deployed inside your cluster. The deployment comes with a built-in service account, and permissions will be provided to it using . Afterwards you will need to create a role + trust policy to allow the integrations-agent service account to assume the role and query the metrics.

The recommended way to give the integrations-agent the ability to interact with AWS resources inside an EKS cluster is using . The deployment comes in with a built-in service account, which can be used alongside OIDC to provide it with AWS permissions.

Go to

Select the AWS namespaces you wish to ingest metrics from. The list of supported services is . These will be provided as a list in the next stage.

ListMetrics
GetMetricData
GetMetricStatistics
AWS statistic
Amazon IAM
IRSA
IRSA
Amazon IAM
here
here
these docs
created during onboarding