Observability in Billing Data Service

Learn about the logs, metrics, and alerts you should monitor for Billing Data Service.

Related documentation:

• Suite-level guide
• All services
• Billing Data Service Release Notes

RSS:

• For private edition

Monitoring

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.

Enable monitoring

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
	N/A	N/A	N/A	N/A

Configure metrics

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.

Alerting

Private edition services define a number of alerts based on Prometheus metrics thresholds.

Important

You can use general third-party functionality to create rules to trigger alerts based on metrics values you specify. Genesys does not provide support for custom alerts that you create in your environment.

For descriptions of available Billing Data Service alerts, see:

Configure alerts

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.

Logging

BDS writes all logs to the standard output.

Viewing logs

1. 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>

2. 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).