odpi / egeria

Egeria core
https://egeria-project.org
Apache License 2.0
807 stars 261 forks source link

Introduce an API to server author to return the audit log supported severities for a server #5597

Closed davidradl closed 3 years ago

davidradl commented 3 years ago

The server audit logs have supported severities per server that will be returned in the storedServer in the Platform.

We will configure each audit log separately so we can handle errors better.

mandy-chessell commented 3 years ago

Note that the same audit log destination type may be used multiple times with different log categories and destination details.

davidradl commented 3 years ago

@mandy-chessell I am not sure how to set different log categories and destination details using the rest calls. I see the rest calls in ConfigRepositoryServicesResource for example '/audit-log-destinations/console' which only take a list of supported severities. What am I missing?

I see there is a call '/audit-log-destinations/connection'. If we could name these new custom audit log destinations so I do not have to supply a connection java class and then reference these custom audit log destinations by that name; that would be easier for the server author to reference. I also wonder if these custom log-destinations could be included with the default names in a MDS call getDefinedAuditLogDestinations or the like.

Maybe the server author view Platform object could contain a list of supported audit log destinations - I then show the user only these audit log destinations to choose from - this should allow me to switch out to use the MDS content with minimal changes to the view service API.

mandy-chessell commented 3 years ago

The audit log destinations are connectors - so there is no definitive list. We have helper methods for the connectors supplied with Egeria. The categories of log messages (severities) are specfied in the request body.

Here is the documentation https://egeria.odpi.org/open-metadata-implementation/admin-services/docs/user/configuring-the-audit-log.html

mandy-chessell commented 3 years ago

The helper methods use default values for the destination. If you want to do something fancy such as send one set of serverities to one event topic and another set of severities to another, it is necessary to use the connection version of the command and call it multiple times. If you want I could add calls that allow the destination to be supplied in the request body allong with the severities?

davidradl commented 3 years ago

in the server author view service I was thinking of returning an array of AuditLogDestination in the getPlatform that returns the Platform object with the stored servers and registered services for the platform.

AuditLogDestination being a server author object of shape (with fields to help it display nicely without needing to hard code in the UI) public class AuditLogDestination { private String auditLogName; private String auditLogDescription; private String auditLogDisplayName; private List<String> supportedSeverities; ...

Then on the post to supply the severities I was thinking of supplying a list of AuditLogDestination with the name and supportedSeverities. It would only send up audit logs destinations and severities that the platform said it supported. If there was a way to name a custom connection then I could have included this in the list with the supported severities.

There is a case to put this API into the admin layer as well - so I could just make one backend call from the view service; I can make the individual calls otherwise.

davidradl commented 3 years ago

On discussion, it is not appropriate to associate the audit log destinations with the platform, these are server audit logs. The server audit logs have supported severities per server that will be returned in the storedServer in the Platform.

We will configure each audit log separately so we can handle errors better.

thanks for your help @mandy-chessell

davidradl commented 3 years ago

@mandy-chessell @planetf1 I have the following situation:

The server author exposes a call to get the Platforms , within each platform object are a list of stored servers. We decided that we would not return the server status. This issue is to amend the server object to add in the audit log severities that could be different for each server.

In general the code uses the PropertyServerException SERVICE_NOT_AVAILABLE(404, "OMAG-MULTI-TENANT-404-002".

I have the situation where there is a server cocoMDS4 that is not available. When I issue the call to the repository services, I get a response with an invalid parameter exception (as the server name could be incorrect) with message SERVER_NOT_AVAILABLE(404, "OMAG-MULTI-TENANT-404-001",. The current view service logic bombs out with this error - I could look for the message in the invalid exception response, or change the exception to a PropertyServerException - which would make the calling code less sensitive to message changes.

Though it would be nice to move to the new Exception type - I suspect I need to keep the API the same and not change the exception (which could have an impact or existing callers) and look for the message by number - do you agree?

davidradl commented 3 years ago

I am thinking of doing this as the only parameters are server name and userid. AuditLogServicesClient auditLogServicesClient = new AuditLogServicesClient(serverName, platFormEndpoint); List<OMRSAuditLogReportSeverity> severities; try { severities = auditLogServicesClient.getAuditLogSupportedSeverities(userId); } catch (InvalidParameterException error) { // cannot contact the server, so default the severity list severities = OMRSAuditLogRecordSeverity.getSeverityList(); } storedServer.setAuditLogSupportedSeverities(severities);

I will proceed with this unless there are concerns.

davidradl commented 3 years ago

I am repurposing this issue again to only introduce an audit client API to get the supported severities using the interface and to then amend the server author view to use this client