> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # ArgoCD Metrics Monitoring > How to integrate ArgoCD metrics with Prometheus Operator using ServiceMonitor and PodMonitor to scrape endpoints, generate Prometheus configs, and visualize metrics in Grafana This guide explains how ArgoCD exposes metrics and how the Prometheus Operator discovers and configures Prometheus to scrape those endpoints using custom resources such as ServiceMonitor and PodMonitor. Follow the sequence below to verify and configure scraping for ArgoCD metrics and to visualize them in Grafana. Key concepts covered: * How ArgoCD exposes metrics via Services * How the Prometheus Operator uses ServiceMonitor/PodMonitor CRs to generate scrape configs * Verifying the generated Prometheus configuration and troubleshooting common issues * Visualizing ArgoCD metrics in Grafana Overview of the flow 1. Install the Prometheus Operator and its CRDs (ServiceMonitor / PodMonitor / Prometheus). 2. ArgoCD exposes metrics through Services that use a named `metrics` port and identifiable labels. 3. Create ServiceMonitor resources that select those Services and define scrape endpoints. 4. The Prometheus CR selects matching ServiceMonitors and the operator generates Prometheus `scrape_configs`. 5. The operator triggers a config-reloader sidecar that updates Prometheus and begins scraping the ArgoCD endpoints. Ensure the Prometheus Operator and its CRDs are installed in the cluster before applying any ServiceMonitor or PodMonitor resources; otherwise these custom resources will not be recognized. ## Step-by-step details ### 1) Inspect the generated Prometheus configuration The Prometheus Operator writes generated configuration files into the Prometheus pod via a config-reloader sidecar. To inspect the generated config from the config-reloader container: ```bash theme={null} # Enter the config-reloader container of the Prometheus StatefulSet pod (adjust the pod name if different) kubectl exec -it prometheus-0 -c config-reloader -- /bin/sh # View the generated Prometheus config cat /etc/prometheus/config_out/prometheus.env.yaml ``` Note: pod names, container names, and paths can vary by distribution — adjust `prometheus-0`, `config-reloader`, and the file path to match your deployment. Example snippet from a generated Prometheus config: ```yaml theme={null} global: scrape_interval: 30s rule_files: - /etc/prometheus/rules/prometheus-0/*.yaml scrape_configs: - job_name: serviceMonitor/monitoring/kube-apiserver/0 - job_name: serviceMonitor/argocd/argocd-server-metrics/0 - job_name: serviceMonitor/argocd/argocd-repo-server-metrics/0 - job_name: serviceMonitor/argocd/argocd-metrics/0 - job_name: serviceMonitor/argocd/argocd-applicationset-controller-metrics/0 ``` This shows Prometheus scraping both Kubernetes components and ServiceMonitor-discovered jobs for ArgoCD. ### 2) The Service: how ArgoCD exposes metrics ArgoCD deploys Services that expose metrics on a named port (commonly `metrics`). Confirm the Service exists and inspect it: ```bash theme={null} kubectl get svc argocd-server-metrics -n argocd -o yaml ``` Representative Service manifest: ```yaml theme={null} apiVersion: v1 kind: Service metadata: name: argocd-server-metrics namespace: argocd spec: ports: - name: metrics port: 8083 protocol: TCP targetPort: 8083 selector: app.kubernetes.io/name: argocd-server type: ClusterIP ``` Important: * The Service must expose the metrics port with a name (e.g., `metrics`). * The Service should have labels that a ServiceMonitor can match (see next section). * Ensure the Service’s namespace is within the scope of the Prometheus CR's `namespaceSelector`. ### 3) ServiceMonitor: instruct the operator how to scrape Create a ServiceMonitor that selects the Service by its labels and references the named metrics port. The Prometheus Operator recognizes ServiceMonitors and will include them if the Prometheus CR selects them. Example ServiceMonitor (adjust namespace/labels to your setup): ```yaml theme={null} apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: argocd-server-metrics namespace: argocd labels: release: prometheus-operator spec: selector: matchLabels: app.kubernetes.io/name: argocd-server endpoints: - port: metrics interval: 30s ``` Notes: * `selector.matchLabels` selects the Service resource by its labels (not the Service's pod selector). * `endpoints.port` should reference the named port (`metrics`) whenever possible. * You can configure additional scrape settings inside `endpoints` (path, scheme, honor\_labels, relabeling, etc.). ### 4) Prometheus CR and automatic config reload The Prometheus CR (managed by the operator) uses label selectors to discover ServiceMonitors. When a matching ServiceMonitor is found: * The operator generates the appropriate `scrape_configs`. * The operator writes those configurations into the Prometheus config volume. * A config-reloader sidecar reloads Prometheus with the new configuration automatically. Make sure the Prometheus CR’s `namespaceSelector` includes the namespace where the ServiceMonitor is created (common pitfall). Verify the ServiceMonitor exists: ```bash theme={null} kubectl get servicemonitor argocd-server-metrics -n argocd -o yaml ``` Re-check the generated Prometheus configuration (as in Step 1) to confirm `job_name` entries for your ServiceMonitors appear. If a ServiceMonitor is created before the Prometheus Operator and its CRDs are installed, the resource may be ignored or not processed. Always install the operator and CRDs first, then apply monitoring CRs. ### 5) Visualize ArgoCD metrics in Grafana Once Prometheus is scraping ArgoCD metrics, point Grafana at your Prometheus data source and create dashboards or import community dashboards for ArgoCD. Useful metric types include: * Application sync status and durations * Application health and reconciliation counts * Controller queue sizes and reconcile errors Grafana sources: * Use the Prometheus URL as the Grafana data source. * Search for community dashboards (e.g., “ArgoCD”) to import panels and templates. ## Quick reference table | Resource | Purpose | Example/Command | | --------------- | ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Service | Exposes ArgoCD metrics via a named port | `kubectl get svc argocd-server-metrics -n argocd -o yaml` | | ServiceMonitor | Instructs Prometheus Operator how to scrape a Service | See ServiceMonitor manifest above | | Prometheus CR | Operator-managed Prometheus instance that selects ServiceMonitors | Check Prometheus CR for `namespaceSelector` and label selectors | | Config reloader | Sidecar that reloads Prometheus when the config is updated | `kubectl exec -it prometheus-0 -c config-reloader -- cat /etc/prometheus/config_out/prometheus.env.yaml` | ## Troubleshooting tips * Confirm CRDs are installed: `kubectl get crd | grep servicemonitor` should show `servicemonitors.monitoring.coreos.com`. * Check operator logs for errors: `kubectl logs -l app=prometheus-operator -n ` * Verify labels: `kubectl get svc argocd-server-metrics -n argocd --show-labels` * Ensure Prometheus `namespaceSelector` includes the namespace where ServiceMonitor lives. ## Links and references * Prometheus Operator: [https://prometheus-operator.dev/](https://prometheus-operator.dev/) * ArgoCD (GitOps workshop reference): [https://learn.kodekloud.com/user/courses/bah-gitops-workshop](https://learn.kodekloud.com/user/courses/bah-gitops-workshop) * Grafana: [https://grafana.com/](https://grafana.com/) Wrapping up * ArgoCD exposes metrics via Services with named ports and labels. * The Prometheus Operator discovers those Services via ServiceMonitor (or PodMonitor) CRs and auto-generates Prometheus configs. * Ensure correct labels, port names, and namespace selection so the operator picks up your monitoring resources. * Use Grafana to build dashboards from the scraped ArgoCD metrics.