444097848c
The Monasca alerting pipeline provides multi-tenancy alerts and notifications. It runs as an Apache Storm topology and generally places a significant memory and CPU burden on monitoring hosts, particularly when there are lot of metrics. This is fine if the alerting service is in use, but sometimes it is not. For example you may use Prometheus for monitoring the control plane, and wish to offer tenants a monitoring service via Monasca without alerting and notification functionality. In this case it makes sense to disable this part of the Monasca pipeline and this patch adds support for that. If the service is ever re-enabled, all alerts and notifications should spawn back automatically since they are persisted in the central mysql database cluster. Change-Id: I84aa04125c621712f805f41c8efbc92c8e156db9
33 lines
909 B
Django/Jinja
33 lines
909 B
Django/Jinja
[DEFAULT]
|
|
log_file = monasca-persister.log
|
|
log_dir = /var/log/kolla/monasca
|
|
debug = {{ monasca_logging_debug }}
|
|
|
|
[influxdb]
|
|
database_name = {{ monasca_influxdb_name }}
|
|
# FIXME(dszumski): This doesn't work with a FQDN so use the VIP directly
|
|
ip_address = {{ kolla_internal_vip_address }}
|
|
port = {{ monasca_influxdb_http_port }}
|
|
|
|
[kafka]
|
|
# NOTE(dszumski): This will become the default in Victoria and can then
|
|
# be removed: https://review.opendev.org/#/c/740966
|
|
legacy_kafka_client_enabled = False
|
|
|
|
[kafka_alarm_history]
|
|
{% if not monasca_enable_alerting_pipeline | bool %}
|
|
enabled = False
|
|
{% else %}
|
|
uri = {{ monasca_kafka_servers }}
|
|
topic = {{ monasca_alarm_state_transitions_topic }}
|
|
num_processors = 1
|
|
{% endif %}
|
|
|
|
[kafka_metrics]
|
|
uri = {{ monasca_kafka_servers }}
|
|
topic = {{ monasca_metrics_topic }}
|
|
num_processors = {{ monasca_metric_pipeline_threads }}
|
|
|
|
[zookeeper]
|
|
uri = {{ monasca_zookeeper_servers }}
|