Understanding Microservice Pipelines

An Oracle Communications Unified Assurance microservice pipeline is a series of microservices, typically connected by a message bus, that work together to achieve a common goal, such as discovering devices or adding events to the database.

The microservices in Unified Assurance work together in the following pipelines:

• Discovery: Discovers the devices on your network and adds them to the Graph and Assure1 databases so that they can be monitored and polled by microservices in other pipelines.

  See Understanding the Discovery Pipeline for information about the pipeline components and flows.

• Event: Adds events from discovered devices to the Event database to enable monitoring for devices and network events.

  See Understanding the Event Pipeline for information about the pipeline components and flows.

• Flow: Enables Flow Analytics to monitor network bandwidth consumption.

  See Understanding Flow Analytics for more information.

• Topology: Adds devices to the Graph database to monitor network topology.

• Metric: Adds metrics to the Metrics database to enable monitoring for device performance.

Some microservices perform tasks or have a supporting role in multiple pipelines. For example, several poller microservices work in the Event, Topology, and Metric pipelines, and the Pulsar microservice supports the messaging that connects the microservices in most pipelines.

Supporting Microservices

These microservices play supporting roles in the microservice pipelines:

• Pulsar: By default, Unified Assurance microservices communicate by publishing and reading messages on Apache Pulsar topics. For many microservices, you can customize the input and output topics, and you can add new subscribers to topics. The Pulsar microservice enables this functionality. See Pulsar in Unified Assurance Implementation Guide.

  You can also optionally use the Pulsar Tester microservice to debug and test your Pulsar workflows. See Pulsar and Pulsar Tester in Unified Assurance Implementation Guide.

• Prometheus: Prometheus scrapes all Unified Assurance microservices for self-monitoring metrics and adds them to the Metrics database, where you can use them to monitor microservice health and scale resources appropriately. The self-monitoring metrics are different from the metrics collected by the poller and collector microservices, which you use to monitor network devices.

  The Prometheus microservice includes a full Prometheus stack, and is deployed automatically when you create a microservice cluster. It automatically includes the Kube State Metrics microservice as a pod within the deployment.

  You can optionally deploy the Prometheus Metrics Processor microservice to filter Prometheus metrics according to rules you configure. See Prometheus Metrics Processor in Unified Assurance Implementation Guide.

• Telegraf: The Metric Sink and Prometheus Metrics Processor microservices use Telegraf to insert metrics into the Metric InfluxDB database. Telegraf is automatically included as a pod within the deployment when you deploy either of the other two microservices. You do not need to deploy it separately.

• KEDA: Some Unified Assurance microservices use the Kubernetes Event Driven Autoscaler (KEDA) to handle load balancing and scaling. This microservice is deployed automatically when you create a microservice cluster, and autoscaling is enabled by default for the microservices that support it. You can optionally disable autoscaling for individual microservices when deploying them. See Configuring Autoscaling in Unified Assurance Implementation Guide for information and a list of microservices that autoscaling is supported for.

• Kafka Bridge: The Kafka Bridge microservice provides bidirectional communication between Pulsar and Kafka. You can configure the Kafka Bridge microservice to read from Pulsar topics and publish to a Kafka URI, or the reverse. By default, the TMF688 Event Processor microservice does this. See Kafka Bridge in Unified Assurance Implementation Guide.

  Note:

  This microservice was previously called Kafka Adapter.

• ActiveMQ Bridge: The ActiveMQ Bridge microservice provides bidirectional communication between Pulsar and ActiveMQ. You can configure the ActiveMQ Bridge microservice to publish messages from ActiveMQ to Pulsar and the reverse, from Pulsar to ActiveMQ. See ActiveMQ Bridge in Unified Assurance Implementation Guide.

• Webhook Collector: The Webhook Collector microservice exposes a custom endpoint where you can send messages. The microservice sends the messages to a Pulsar topic. See Webhook Collector in Unified Assurance Implementation Guide.