Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Importing a large amount of monitoring config occur poor experience and may trigger a long database transaction #3003

Open
1 task done
MasamiYui opened this issue Jan 20, 2025 · 10 comments
Assignees
Labels
bug Something isn't working

Comments

@MasamiYui
Copy link
Contributor

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

I imported 500 monitoring configuration files, it took 8 minutes.

Expected Behavior

During this time, I didn’t see any data increase on the monitoring center list page, which made me suspect if the process was stuck.

Steps To Reproduce

1.Enter 'monitors' from left menu
2.Select 'Import Monitor'
3.Import a large monitor config file
4.Waiting long time,no data increase

Environment

HertzBeat version(s):1.6.1

Debug logs

No response

Anything else?

I found that MonitorServiceImpl.java used @transactional at the class level,
@Transactional(rollbackFor = Exception.class) public class MonitorServiceImpl implements MonitorService

This occur a poor experience and was unnecessary.

If each configuration import was treated as a separate transaction, I would have seen the data being imported continuously, making me feel that the process was working.

The same issue might also at AlertDefineServiceImpl.java.

@MasamiYui MasamiYui added the bug Something isn't working label Jan 20, 2025
@MasamiYui MasamiYui changed the title [BUG] Importing a large amount of monitoring data results occur poor experience and may trigger a long database transaction [BUG] Importing a large amount of monitoring config occur poor experience and may trigger a long database transaction Jan 20, 2025
@yunfan24
Copy link
Contributor

Hello, I have a question. If each configuration is imported as a separate transaction, how can we ensure the integrity of the imported data? In other words, if one configuration import fails, how should it be handled?

@MasamiYui
Copy link
Contributor Author

Hello, I have a question. If each configuration is imported as a separate transaction, how can we ensure the integrity of the imported data? In other words, if one configuration import fails, how should it be handled?

I think failure can be ignored may be more reasonable ;or adding a progress bar or a place to check the progress will be much better for batch import.

@tomsun28
Copy link
Contributor

The problem may cause by the detect, the will detect all monitors when import.

        try {
            detectMonitor(monitor, params, collector);
        } catch (Exception ignored) {
        }

+1, adding a progress bar or a place to check the progress will be much better for batch import.

@MasamiYui
Copy link
Contributor Author

The problem may cause by the detect, the will detect all monitors when import.

        try {
            detectMonitor(monitor, params, collector);
        } catch (Exception ignored) {
        }

+1, adding a progress bar or a place to check the progress will be much better for batch import.

OK,If possible, assign this task to me to optimize.

@tomsun28
Copy link
Contributor

hi welcome, what the idea to solve it, remove detect or use asynchronous detection? It seems that the real-time status of monitoring will change according to this detect

@zuobiao-zhou
Copy link
Member

hi welcome, what the idea to solve it, remove detect or use asynchronous detection? It seems that the real-time status of monitoring will change according to this detect

Yes, the current process involves performing a detect before creation to obtain the accurate monitoring availability status.

@zuobiao-zhou
Copy link
Member

I think it is essential to correctly display availability after creation; otherwise, it may lead to confusion among users, similar issues were frequently raised in the WeChat feedback group prior to the overhaul of this feature.

@tomsun28
Copy link
Contributor

yes +1

@MasamiYui
Copy link
Contributor Author

My idea is to maintain the synchronization detection;and add 「user task center」 on the page. When batch imported tasks are executing, the task send some message about process and result to notify 「user task center」 , then 「user task center」 update task status . This way, users can obtain task progress and final results even user already leave the import page

@tomsun28
Copy link
Contributor

My idea is to maintain the synchronization detection;and add 「user task center」 on the page. When batch imported tasks are executing, the task send some message about process and result to notify 「user task center」 , then 「user task center」 update task status . This way, users can obtain task progress and final results even user already leave the import page

hi, if user operate in monitors center, but he turn in the「user task center」to see the result, I feel this is a bit of a jump. How about the where to operate, where to obtain? maybe we can add batch import monitors task history page, like the 「user task center」, it show the task status and import result and so on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Development

No branches or pull requests

4 participants