Asset Tracking and Monitoring Enhancements

[Ashesh3]

This PR introduces several changes aimed at improving asset tracking and monitoring.

• AssetAvailabilityRecord Model: Introduced a new model AssetAvailabilityRecord in models/asset.py and the corresponding migration file. This model will keep track of the availability status of each asset, which includes not monitored, operational, down, and under maintenance states.

• Asset Monitoring Task: Added a new Celery task in tasks/asset_monitor.py for checking the status of each asset periodically. The task fetches the status from the middleware and updates the AssetAvailabilityRecord accordingly.

• Asset Status Enum: Created a new Enum class AvailabilityStatus in utils/assetintegration/asset_statuses.py to represent the availability status of assets.

• Task Scheduling: Added the new asset monitoring task to the period tasks list in tasks/init.py. This task will be executed every 30 minutes.

• Asset Model Update: Updated the Asset model in models/asset.py to include a reference to the new AssetAvailabilityRecord model.

Celery Task Pseudocode:

The Celery task check_asset_status is set to run every 30 minutes and is responsible for checking and updating the status of all assets.

1. Fetch All Assets: The task begins by fetching all assets from the database.

2. Iterate Over Assets: For each asset, it checks if the asset class is defined and if the local IP address is available in the asset's metadata. If either of these conditions is not met, it continues to the next asset.

3. Get Asset Class: The task then determines the asset class using the AssetClasses enumeration and the asset's metadata, which includes the middleware hostname.

4. Check Cached Results: Before making a request to the middleware API, the task checks if the status of assets for the given hostname is already cached. If it is, the task uses the cached results instead of making a new API call.

5. API Call: If the results are not cached, the task makes a GET request to the middleware API to fetch the status of all devices.

6. Determine New Status: The task then determines the new status of the asset based on the response from the API. If the asset's local IP address is not in the status records returned by the API, the asset's status is set to "not monitored".

7. Get Last Record: The task fetches the most recent status record for the asset.

8. Create New Record: If there is no previous record or if the asset's status has changed, the task creates a new AssetAvailabilityRecord with the new status.

9. Error Handling: If there is any exception during the process, it is caught and printed to the console. The task then proceeds to the next asset.

The purpose of this task is to ensure that the asset status is updated regularly, allowing for efficient management and monitoring of assets.

@coronasafe/care-backend-maintainers @coronasafe/care-backend-admins

[sainak]

@Ashesh3 add tests for api endpoints

[vigneshhari]

Merge all the migrations into a single one

[Ashesh3]

@Ashesh3 add tests for api endpoints

Tests added.

[vigneshhari]

Looks good to me, two things to note, maybe these can be made as issues,

• Make sure that the request to any external API's have a timeout and its reasonable
• Instead of one long celery job to monitor each asset, the master job could spin off multiple jobs per asset that are performed asynchronously, the checks themselves need not be serial.

[sentry-io]

Suspect Issues

This pull request has been deployed and Sentry has observed the following issues:

• ‼️ APIException: care.facility.tasks.asset_monitor.check_asset_s... View Issue

_{Did you find this useful? React with a 👍 or 👎}

[Ashesh3]

Suspect Issues

This pull request has been deployed and Sentry has observed the following issues:

• ‼️ **APIException: ** care.facility.tasks.asset_monitor.check_asset_s... View Issue

Did you find this useful? React with a 👍 or 👎

This is expected. Some middleware endpoints are non functional.