Prometheus Integration

Nantian Gateway exposes Prometheus metrics on the control plane and data plane. The Helm chart can create ServiceMonitor and PodMonitor resources for the Prometheus Operator, so Prometheus discovers and scrapes your gateway automatically.

For a complete list of available metrics, see Metrics Reference.

Enabling ServiceMonitor

The serviceMonitor block controls Prometheus Operator integration. It’s disabled by default so enabling it is explicit:

serviceMonitor:
  enabled: true

When enabled, the chart creates two resources:

• A ServiceMonitor for the control plane, targeting the metrics port (default 18082) at /metrics.
• A PodMonitor for the data plane, targeting the admin port (default 19080) at /metrics.

Both resources carry the chart’s standard component labels, plus any custom labels you add.

ServiceMonitor values

Parameter	Type	Default	Description
serviceMonitor.enabled	bool	false	Create ServiceMonitor and PodMonitor resources for Prometheus Operator
serviceMonitor.labels	object	{}	Extra labels applied to both ServiceMonitor and PodMonitor resources
serviceMonitor.interval	string	"30s"	Scrape interval for metrics endpoints
serviceMonitor.scrapeTimeout	string	"10s"	Scrape timeout for metrics endpoints
serviceMonitor.fromNamespaces	list	[]	Additional namespaces permitted to reach metrics endpoints when NetworkPolicies are enabled

Labels

Prometheus Operator uses label selectors to discover ServiceMonitors. If your Prometheus instance requires a specific label (for example, the kube-prometheus-stack looks for release: kube-prometheus-stack), add it here:

serviceMonitor:
  enabled: true
  labels:
    release: kube-prometheus-stack

Scrape interval and timeout

The default interval of 30s and timeout of 10s work well for most deployments. If your cluster runs many gateways or you want higher resolution for alerting, you can tighten the interval. Keep the timeout shorter than the interval so scrapes don’t pile up:

serviceMonitor:
  enabled: true
  interval: "15s"
  scrapeTimeout: "10s"

Cross-namespace scraping with NetworkPolicies

When NetworkPolicies are enabled (the default), only traffic from the gateway’s own namespace can reach the metrics port. If your Prometheus runs in a different namespace, add it to fromNamespaces:

serviceMonitor:
  enabled: true
  fromNamespaces:
    - monitoring
    - prometheus-operator

This appends ingress rules to the control plane NetworkPolicy so Prometheus pods in those namespaces can scrape metrics. The data plane shares the admin port for both the admin API and metrics, so only grant access to namespaces you trust.

See Network Policies for more on how NetworkPolicies are managed.

Verifying the integration

After applying the values, check that the resources are created and Prometheus discovers them:

kubectl get servicemonitor -n nantian-gw
kubectl get podmonitor -n nantian-gw

From the Prometheus UI, confirm that both the nantian-gw-controlplane and nantian-gw-dataplane targets appear under Status > Targets with state UP.

AlertManager Integration

Prometheus AlertManager routes alerts from Prometheus rules to notification channels (email, Slack, PagerDuty). The Helm chart’s Alerting Rules include pre-built rules for control plane and data plane health.

To connect Prometheus to AlertManager:

prometheus-values.yaml

alertmanager:
  enabled: true
alertmanagerFiles:
  alertmanager.yml:
    global:
      slack_api_url: "https://hooks.slack.com/services/..."
    route:
      group_by: ["alertname", "severity"]
      group_wait: 10s
      group_interval: 5m
      repeat_interval: 4h
      receiver: "slack-notifications"
    receivers:
      - name: "slack-notifications"
        slack_configs:
          - channel: "#nantian-alerts"
            title: "Nantian Gateway Alert"
            text: "{{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}"

Prometheus discovers AlertManager via the alerting configuration:

prometheus:
  prometheusSpec:
    alertingEndpoints:
      - name: alertmanager-operated
        namespace: monitoring
        port: 9093

Recording Rules

Recording rules pre-compute frequently used expressions for faster dashboards and alerting. Add these to your Prometheus configuration:

prometheus:
  prometheusSpec:
    ruleSelector:
      matchLabels:
        role: alert-rules
    ruleNamespaceSelector: {}

Then create a PrometheusRule with recording rules:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: nantian-gw-recording
  namespace: monitoring
  labels:
    role: alert-rules
spec:
  groups:
    - name: nantian-gw
      rules:
        - record: nantian:http_requests:rate5m
          expr: rate(nantian_gw_dataplane_http_requests_total[5m])
        - record: nantian:http_errors:rate5m
          expr: rate(nantian_gw_dataplane_http_requests_total{status_class="5xx"}[5m])
        - record: nantian:error_ratio
          expr: nantian:http_errors:rate5m / nantian:http_requests:rate5m

Recording rules reduce query latency in Grafana dashboards and simplify alerting expressions.

Federation

For multi-cluster deployments, use Prometheus federation to aggregate metrics from multiple gateway instances into a central Prometheus:

scrape_configs:
  - job_name: "federate-nantian-gw"
    scrape_interval: 30s
    honor_labels: true
    metrics_path: "/federate"
    params:
      match[]:
        - '{__name__=~"nantian_gw_.+"}'
    static_configs:
      - targets:
          - "prometheus-cluster-a.monitoring:9090"
          - "prometheus-cluster-b.monitoring:9090"

Federated metrics carry the original labels from each cluster, so use honor_labels: true to preserve cluster identity in your central dashboards.