Monitoring Microservices with Cumulocity Alarms

Knowledge Base
1

products versions - Cumulocity 10.18

Introduction

In scenarios where monitoring specific aspects of a microservice and generating events or alarms within the Cumulocity platform is required, there are multiple approaches to consider. A commonly suggested method is to create an associated managed object dedicated to these events and alarms. While this approach is effective, let’s explore an alternative strategy.

When a microservice encounters issues, such as going offline, the administration app displays an alarm directly on the microservice. This functionality opens the possibility of utilizing the microservice’s associated managed object to generate alarms that are natively visible within the platform. Let’s delve into how this can be implemented.

Step 1: Find out Microservice Application ID

Within our code we will first identify the ID for the microservice itself.

@Autowired
private ContextService<MicroserviceCredentials> contextService;
@Autowired
private PlatformProperties platformProperties;
@Autowired
private ApplicationApi appApi;

public ApplicationRepresentation getCurrentApplication() {
	return contextService.callWithinContext((MicroserviceCredentials)platformProperties.getMicroserviceBoostrapUser(), () -> {
		return appApi.currentApplication().get();
	});
}

Step 2: Identify Microservice Associated Managedobject

Each microservice in Cumulocity has an associated managed object identified by a specific type:

c8y_Application_{microservice_id}

Once the microservice ID has been identified, use the Inventory API to retrieve the managed object associated with the given type

	private ManagedObjectRepresentation getAssociatedManagedObject(String applicationId) {
		InventoryFilter filter = new InventoryFilter();
		filter.byType(APPLICATION_PREFIX + applicationId);
		Iterator<ManagedObjectRepresentation> i = inventoryApi.getManagedObjectsByFilter(filter).get().elements(1)
				.iterator();

		if (i.hasNext()) {
			return i.next();
		} else {
			throw new IllegalStateException(
					"Unable to determine microservice associated managed object. Can not continue");
		}

	}

Step 3: Create Alarms on the Microservice

Once the managed object responsible for the microservice is retrieved, alarms can be created directly on this object. These alarms will then be displayed on the microservice’s page in the administration app, providing seamless visibility.

alarm
alarm1615×642 78 KB

Practical Use Case: WebSocket Disconnects

One common scenario where this approach is beneficial is handling WebSocket disconnects. For instance, when using the Notification 2.0 API, a WebSocket may disconnect unexpectedly. If the connection is not restored, notifications will accumulate in the platform, potentially leading to memory issues.

To address this, you can:

  • Raise an alarm on the microservice object when a disconnect is detected.
  • Configure SmartRules to notify or email users, ensuring prompt action.
  • Clear the alarm when the WebSocket connection is restored.

This method not only centralizes monitoring but also streamlines issue resolution by leveraging existing platform capabilities. While creating an associated monitoring managed object for the microservice might be a viable option, the key advantage of this approach is that it raises the alarm directly on the microservice, making it visible in the administration app. Ultimately, it’s a matter of preference.

Useful links | Relevant resources

Getting microservice id
Here is a sample project that you can simply run:
Sample alarm monitoring project

3 Likes