Observability in Billing Data Service
Learn about the logs, metrics, and alerts you should monitor for Billing Data Service.
Private edition services expose metrics that can be scraped by Prometheus, to support monitoring operations and alerting.
- As described on Monitoring overview and approach, you can use a tool like Grafana to create dashboards that query the Prometheus metrics to visualize operational status.
- As described on Customizing Alertmanager configuration, you can configure Alertmanager to send notifications to notification providers such as PagerDuty, to notify you when an alert is triggered because a metric has exceeded a defined threshold.
The services expose a number of Genesys-defined and third-party metrics. The metrics that are defined in third-party software used by private edition services are available for you to use as long as the third-party provider still supports them. For descriptions of available Billing Data Service metrics, see:
See also System metrics.
Billing Data Service works as a short living cronjob, so it uses Pushgateway for providing metrics. To enable pushing metrics, find the following Helm values as an example:
bdsApp: container: env: pgValue: http://prometheus-pushgateway.monitoring.svc.cluster.local:9091
|Service||CRD or annotations?||Port||Endpoint/Selector||Metrics update interval|
|Billing Data Service||n/a||n/a||n/a||n/a|
The metrics that are exposed by Billing Data Service are available by default. No further configuration is required in order to define or expose these metrics. You cannot define your own custom metrics.
Private edition services define a number of alerts based on Prometheus metrics thresholds.
For descriptions of available Billing Data Service alerts, see:
Private edition services define a number of alerts by default (for Billing Data Service, see the pages linked to above). No further configuration is required.
The alerts are defined as PrometheusRule objects in a prometheus-rule.yaml file in the Helm charts. As described above, Billing Data Service does not support customizing the alerts or defining additional PrometheusRule objects to create alerts based on the service-provided metrics.
BDS writes all logs to the standard output.
- Execute the following command to get the pod name:
kubectl -n bds get po
NAME READY STATUS RESTARTS AGE bds-t2023-2023-1624633200-w8nh5 0/1 Completed 0 34m
- Where the NAME string is composed of the following elements: bds-t<tenant id>-<tenant id>-<job start linux time>-<random value>
- Execute the following command to check the logs:
kubectl logs bds-pod-<name>
- Where <name> is the pod name.
- For example:
kubectl logs bds-pod-wn8bx
Setting the log level
Optionally, you can set the log level using the BDS_LOG_LEVEL environment variable. Acceptable values are:
CRITICAL, 50, ERROR, 40, WARNING, 30, INFO, 20, DEBUG, 10,NOTSET, 0.
If you do not set a value, BDS reads the default value from gvars.py. If gvars.py contains no value, BDS uses the default value (DEBUG).