You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Importing dashboards, monitors, alerts, notification-channels, anomaly detectors and so on using the operator! Currently there is no possibility to import/export these things via the GUI, nor are there any other systematic ways to import them and the end user is forced to import them via self-made scripts. In other siem solutions, such as grafana it is very easy to import things when the app gets started by simply, for instance, placing dashboards in a specific folder that is mounted into the grafana container. These things can also be imported using the prometheus operator that can set default stuff into grafana as well.
What solution would you like?
We need CRDS for all the possible objects that can be imported into opensearch dashboards. I still have no idea how to import my custom alerts? Even by simply using the opensearch API it is extremely convoluted on how to import these things. A way to implement these would possibly be to use a wrapper around the "python-based opensearch client" and let the operator logic handle this on operator level.
Consider these objects:
OpenSearchNotificationChannelCRD
OpenSearchAlertCRD
OpenSearchMonitorCRD (Imports related alerts and notification channels too)
OpenSearchDashboardCRD (imports related indexpatterns, visualizers too)
OpenSearchIndexPatternCRD (lets you overwrite old indexpatterns, append-new-fields-refresh, drop-fields-refresh etc)
OpenSearchVisualizerCRD
And so on. You can probably guess what these would do.
Also handling the ML related objects for importing default models using operator would be favorable, but that can be done later on.
What alternatives have you considered?
Opensearch has a python library for importing things into opensearch. I have also considered custom shell scrips, but these scripts become extremely ugly and hard to maintain. An operator would make everything much cleaner. Sometimes the so called "Curator" is done for handling parts of default configs for the indexes and snapshots. Perhaps porting all these features to the operator would be an option too, but most of the "curator features" can probably done using the ISM-policies.
Do you have any additional context?
Consider how default data can be easily imported into elasticsearch. Elasticsearch has recently implemented an "Importing API" for elastic and kibana, perhaps this can be considered as a partly new feature for opensearch too..? In that case, it would require a cooperator between the operator devs and the opensearch devs. Either way, It would be highly beneficial if the operator could startup opensearch with any type of initial objects that were previously created via the opensearch dashboards GUI.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?
Importing dashboards, monitors, alerts, notification-channels, anomaly detectors and so on using the operator! Currently there is no possibility to import/export these things via the GUI, nor are there any other systematic ways to import them and the end user is forced to import them via self-made scripts. In other siem solutions, such as grafana it is very easy to import things when the app gets started by simply, for instance, placing dashboards in a specific folder that is mounted into the grafana container. These things can also be imported using the prometheus operator that can set default stuff into grafana as well.
What solution would you like?
We need CRDS for all the possible objects that can be imported into opensearch dashboards. I still have no idea how to import my custom alerts? Even by simply using the opensearch API it is extremely convoluted on how to import these things. A way to implement these would possibly be to use a wrapper around the "python-based opensearch client" and let the operator logic handle this on operator level.
Consider these objects:
And so on. You can probably guess what these would do.
Also handling the ML related objects for importing default models using operator would be favorable, but that can be done later on.
What alternatives have you considered?
Opensearch has a python library for importing things into opensearch. I have also considered custom shell scrips, but these scripts become extremely ugly and hard to maintain. An operator would make everything much cleaner. Sometimes the so called "Curator" is done for handling parts of default configs for the indexes and snapshots. Perhaps porting all these features to the operator would be an option too, but most of the "curator features" can probably done using the ISM-policies.
Do you have any additional context?
Consider how default data can be easily imported into elasticsearch. Elasticsearch has recently implemented an "Importing API" for elastic and kibana, perhaps this can be considered as a partly new feature for opensearch too..? In that case, it would require a cooperator between the operator devs and the opensearch devs. Either way, It would be highly beneficial if the operator could startup opensearch with any type of initial objects that were previously created via the opensearch dashboards GUI.
The text was updated successfully, but these errors were encountered: