Skip to main content

Coroot-cluster-agent

Coroot-cluster-agent connects to Coroot to receive configuration and collects cluster-level telemetry data, including metrics from databases, Kubernetes state metrics, and Kubernetes events.

Cluster Agent Configuration​

You can configure coroot-cluster-agent using command-line flags or environment variables.

FlagEnv VariableDefaultDescription
--listenLISTEN127.0.0.1:10301Listen address - ip:port or :port
--coroot-urlCOROOT_URL–Coroot URL (required)
--api-keyAPI_KEY–Coroot API key
--config-update-intervalCONFIG_UPDATE_INTERVAL60sInterval between configuration updates from Coroot
--config-update-timeoutCONFIG_UPDATE_TIMEOUT10sTimeout for configuration update requests
--config-fileCONFIG_FILE–Path to a YAML file with static configuration (see Configuration file), merged with the configuration received from Coroot
--metrics-scrape-intervalMETRICS_SCRAPE_INTERVAL–Interval between metrics scrapes
--metrics-scrape-timeoutMETRICS_SCRAPE_TIMEOUT10sTimeout for metrics scrape requests
--metrics-wal-dirMETRICS_WAL_DIR/tmpDirectory for the metrics write-ahead log
--profiles-scrape-intervalPROFILES_SCRAPE_INTERVAL60sInterval between profiling scrapes
--profiles-scrape-timeoutPROFILES_SCRAPE_TIMEOUT10sTimeout for profiling scrape requests
--disable-kubernetesDISABLE_KUBERNETESfalseDon't collect anything from the Kubernetes cluster the agent runs in: kube-state-metrics, events, and the databases, custom metrics and profiles discovered from pods. Only the databases defined in the configuration file and the cloud integrations are monitored
--kube-state-metrics-listen-addressKUBE_STATE_METRICS_LISTEN_ADDRESS127.0.0.1:10303Listen address for the kube-state-metrics endpoint
--insecure-skip-verifyINSECURE_SKIP_VERIFYfalseSkip TLS certificate verification
--ca-fileCA_FILE–Path to the custom CA certificate file
--collect-kubernetes-eventsCOLLECT_KUBERNETES_EVENTStrueCollect and forward Kubernetes events
--collect-gcp-logsCOLLECT_GCP_LOGStrueForward the logs of Cloud SQL instances discovered through the GCP integration
--collect-oci-logsCOLLECT_OCI_LOGStrueForward the logs of the DB systems and cache clusters discovered through the OCI integration.
--collect-aws-logsCOLLECT_AWS_LOGStrueForward the logs of RDS Postgres and MySQL instances discovered through the AWS integration
--track-database-changesTRACK_DATABASE_CHANGEStrueTrack schema and settings changes in databases
--track-database-sizesTRACK_DATABASE_SIZEStrueCollect per-database and per-table size metrics
--track-database-bloatTRACK_DATABASE_BLOATtrueEstimate per-database, per-table and per-index bloat (PostgreSQL only)
--max-tables-per-databaseMAX_TABLES_PER_DATABASE1000Skip databases with more tables than this limit
--exclude-databasesEXCLUDE_DATABASESrdsadmin,cloudsqladmin,mysql,information_schema,performance_schema,sys,mysql_innodb_cluster_metadata,mysql_innodb_cluster_metadata_previousDatabases to exclude from monitoring (applies to both PostgreSQL and MySQL). For Postgres no connection, query, transaction ID age, schema or size metrics are collected for them; for MySQL they are excluded from schema and size tracking. MongoDB system databases (admin, config, local) are always excluded regardless of this setting.

Configuration file​

Besides the configuration it receives from Coroot, the agent can read a static YAML file given by --config-file. This is how the Kubernetes Operator passes the clusterAgent.aws and clusterAgent.databases sections of the Coroot custom resource to the agent. Environment variable references (${VAR}) in the file are expanded when it is read, so credentials can be kept out of the file.

# AWS integration settings. When present, they replace the settings made in the Coroot UI.
aws:
region: us-east-1 # Optional: defaults to the region the agent runs in.
accessKeyId: ${AWS_KEY_ID} # Optional: leave both keys out to use the IAM role of the pod or the EC2 instance profile.
secretAccessKey: ${AWS_KEY}
rdsTagFilters: {team: payments}
elasticacheTagFilters: {}

# GCP integration settings (Cloud SQL and Memorystore discovery).
gcp:
projectId: my-project # Optional: defaults to the project of the credentials or of the cluster.
region: us-central1 # Optional: defaults to the cluster's region, "all" scans every region of the project.
credentialsJson: ${GCP_KEY} # Optional: a service account key; leave out to use Workload Identity or the VM's service account.
cloudsqlLabelFilters: {team: payments}
memorystoreLabelFilters: {}

# OCI integration settings (MySQL HeatWave, PostgreSQL and OCI Cache discovery).
oci:
compartmentIds: [ocid1.compartment.oc1..aaaa] # Optional with OKE Workload Identity: defaults to the cluster's compartment.
region: us-ashburn-1 # Optional: defaults to the cluster's region.
tenancyId: ${OCI_TENANCY} # Optional: an API key (tenancyId, userId, fingerprint, privateKey); leave out to use OKE Workload Identity or the instance principal.
userId: ${OCI_USER}
fingerprint: ${OCI_FINGERPRINT}
privateKey: ${OCI_KEY}
dbTagFilters: {team: payments}
cacheTagFilters: {}

# Databases to collect metrics from, in addition to those configured in Coroot. Exactly one of host, rds, elasticache, cloudsql, memorystore, ocidb or ocicache per entry.
databases:
- type: postgres # postgres, mysql, redis, memcached or mongodb.
rds: my-db # An RDS instance discovered by the AWS integration: its endpoint is used.
credentials: {username: coroot, password: ${PG_PASSWORD}}
params: {sslmode: require}
- type: redis
elasticache: my-cache # An ElastiCache cluster: every node is monitored.
- type: postgres
cloudsql: my-db # A Cloud SQL instance discovered by the GCP integration.
credentials: {username: coroot, password: ${PG_PASSWORD}}
params: {sslmode: require}
- type: redis
memorystore: my-cache # A Memorystore instance discovered by the GCP integration.
- type: mysql
ocidb: my-db # A DB system discovered by the OCI integration.
credentials:
username: coroot
password: ${MYSQL_PASSWORD}
- type: redis
ocicache: my-cache # An OCI Cache cluster discovered by the OCI integration.
- type: mysql
host: mysql.example.internal # Re-resolved on every configuration update; every resolved IP address is monitored.
port: "3306"
credentials: {username: coroot, password: ${MYSQL_PASSWORD}}

Targets defined in the file take precedence over the same ip:port targets configured in Coroot. Metrics are attributed to applications by address, so a database configured here shows up under the RDS, ElastiCache, or external service application that Coroot already sees clients connecting to.

Looking for 24/7 support from the Coroot team? Subscribe to Coroot Enterprise:Start free trial