Skip to content

Configuring an open lineage server

Overview

Each type of OMAG Server is configured by creating a configuration document.

For open lineage server following can be configured:

Configuration for an open lineage server

What are the required configuration elements for this server type?
  • Event Bus Config
  • Audit Log Destination
  • Open Lineage Config

Set the server URL root

Configure the local server URL root with the value of the OMAG Server Platform where the service will run: in particular if the configuration document will be deployed to a different OMAG Server Platform from the one used to maintain the configuration document.

POST - set server URL root

{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/server-url-root?url={{targetPlatformURLRoot}}
Detailed explanation

The {{targetPlatformURLRoot}} gives the location of the OMAG Server Platform on which this configured service is intended to run, while the {{platformURLRoot}} gives the location of the OMAG Server Platform in which this configuration document is maintained.

They could be, but do not need to be, the same location.

Configure the basic properties

The basic properties of the OMAG Server are used in logging and events originating from the server. They help to document the purpose of the server (which helps with problem determination) and enable performance improvements by allowing the server to ignore activity or metadata that is not relevant to its operation.

The basic properties include two unique identifiers:

Property Description
localServerId Unique identifier for this server. By default, this is initialized to a randomly generated Universal Unique identifier (UUID).
localServerName Meaningful name for the server for use in messages and UIs. Ideally this value is unique to aid administrators in understanding the source of messages and events from the server. This value is set to the server name assigned when the configuration is created.

The other basic properties have values that can be changed through the admin services API:

Property Description
localServerType Descriptive type name for the server. Again this is useful information for the administrator to understand the role of the server. The default value is Open Metadata and Governance Server.
organizationName Descriptive name for the organization that owns the local server/repository. This is useful when the open metadata repository cluster consists of metadata servers from different organizations, or different departments of an enterprise. The default value is null.
localServerUserId UserId to use for server-initiated REST calls. The default is OMAGServer.
localServerPassword Password to use for server-initiated REST calls. The default is null. This means that only the userId is sent in the HTTP header.
maxPageSize The maximum page size that can be set on requests to the server. The default value is 1000. A value of zero means unlimited page size. Although supported, the zero value is not recommended because it provides no protection from a large request denial of service attack.

The sections that follow cover how to set up these values.

Set server type name

The server type name should be set to something that describes the OMAG Server's role. It may be the name of a specific product that it is enabling, or a role in the metadata and governance landscape.

POST - set server type

{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/server-type?typeName="{{serverTypeName}}"

Set organization name

The organization name may be the owning organization or department or team supported by the server.

POST - set organization name

{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/organization-name?name="{{organizationName}}"

Set the server's userId and optional password

The server's userId is used when processing requests that do not have an end user, such as receiving an event from a topic. The default value is OMAGServer. Ideally each server should have its own user ID so it is possible to restrict the resources that each server has access to.

If the password is specified as well, the userId and password combination are used to provide authentication information on each REST call made by the server.

POST - set server's userId

{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/server-user-id?id="{{serverUserId}}"

POST - set server's password

{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/server-user-password?password="{{serverUserPassword}}"

Set the maximum page size for REST API requests

The maximum page size value sets an upper limit on the number of results that a caller can request on any paging REST API to this server. Setting maximum page size helps to prevent a denial of service attack that uses very large requests to overwhelm the server. A value of 0 means no limit, and leaves the server open to such attacks.

POST - set maximum page size

{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/max-page-size?limit={{maxPageSize}}

Configure the audit log

Egeria's audit log provides a configurable set of destinations for audit records and other diagnostic logging for an OMAG Server. Some destinations also support a query interface to allow an administrator to understand how the server is running.

If the server is a development or test server, then the default audit log configuration is probably sufficient: the console audit log destination.

POST - set default audit log destination

{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/audit-log-destinations/default

Using this option overrides all previous audit log destinations.

If this server is a production server then you will probably want to set up the audit log destinations explicitly. You can add multiple destinations and each one can be set up to process specific severities of log records. The audit log severities are as follows:

Severity Description
Information The server is providing information about its normal operation.
Event An event was received from another member of the open metadata repository cohort.
Decision A decision has been made related to the interaction of the local metadata repository and the rest of the cohort.
Action An Action is required by the administrator. At a minimum, the situation needs to be investigated and if necessary, corrective action taken.
Error An error occurred, possibly caused by an incompatibility between the local metadata repository and one of the remote repositories. The local repository may restrict some of the metadata interchange functions as a result.
Exception An unexpected exception occurred. This means that the server needs some administration attention to correct configuration or fix a logic error because it is not operating as a proper peer in the open metadata repository cohort.
Security Unauthorized access to a service or metadata instance has been attempted.
Startup A new component is starting up.
Shutdown An existing component is shutting down.
Asset An auditable action relating to an asset has been taken.
Types Activity is occurring that relates to the open metadata types in use by this server.
Cohort The server is exchanging registration information about an open metadata repository cohort that it is connecting to.
Trace This is additional information on the operation of the server that may be of assistance in debugging a problem. It is not normally logged to any destination, but can be added when needed.
PerfMon This log record contains performance monitoring timing information for specific types of processing. It is not normally logged to any destination, but can be added when needed.
<Unknown> Uninitialized Severity

The body of the request should be a list of severities

If an empty list is passed as the request body then all severities are supported by the destination.

Add audit log destinations

There are various destinations that can be configured for the audit log:

POST - add console audit log destination

This writes selected parts of each audit log record to stdout.

{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/audit-log-destinations/console

POST - add slf4j audit log destination

This writes full log records to the slf4j ecosystem.

{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/audit-log-destinations/slf4j

When configuring slf4j as destination you also need to specify auditlog logger category via the application properties. This is described in Connecting the OMAG Audit Log Framework section of the developer logging guide.

POST - add JSON file-based audit log destination

This writes JSON files in a shared directory.

{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/audit-log-destinations/files

POST - add event-based audit log destination

This writes each log record as an event on the supplied event topic. It assumes that the event bus is set up first.

{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/audit-log-destinations/event-topic

POST - add connection-based audit log destination

This sets up an audit log destination that is described though a connection. In this case, the connection is passed in the request body and the supported severities can be supplied in the connection's configuration properties.

{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/audit-log-destinations/connection

POST - add a list of connection-based audit log destinations

It is also possible to set up the audit log destinations as a list of connections. Using this option overrides all previous audit log destinations.

{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/audit-log-destinations

Remove audit logs

The following will remove all audit log destinations:

POST - clear all audit log destinations

Clears the list of audit log destinations from the configuration enabling you to add a new set of audit log destinations.

{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/audit-log-destinations/none

Set up the default event bus

An OMAG Server uses an event bus such as Apache Kafka to exchange events with other servers and tools.

Egeria manages the specific topic names and the event payloads; however, it needs to know where the event bus is deployed and any properties needed to configure it.

Since the event bus is used in multiple places, the configuration document allows you to set up the details of the event bus which are then incorporated into all the places where the event bus is needed.

Important sequencing information

You need to set up this information before configuring any of the following:

The following command creates information about the event bus. This information is used on the subsequent configuration of the OMAG Server subsystems. It does not affect any subsystems that have already been configured in the configuration document and if the event bus is not needed, its values are ignored.

It is possible to add arbitrary name/value pairs as JSON in the request body. The correct properties to use are defined in the connector type for the event bus.

POST - configure event bus

{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/event-bus
Example: Apache Kafka

For example, when using Apache Kafka as your event bus you may want to configure properties that control the behavior of the consumer that receives events and the producer that sends events. This is a typical set of producer and consumer properties:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
{
    "producer": {
        "bootstrap.servers":"localhost:9092",
        "acks":"all",
        "retries":"0",
        "batch.size":"16384",
        "linger.ms":"1",
        "buffer.memory":"33554432",
        "max.request.size":"10485760",
        "key.serializer":"org.apache.kafka.common.serialization.StringSerializer",
        "value.serializer":"org.apache.kafka.common.serialization.StringSerializer",
        "kafka.omrs.topic.id":"cocoCohort"
    },
    "consumer": {
        "bootstrap.servers":"localhost:9092",
        "zookeeper.session.timeout.ms":"400",
        "zookeeper.sync.time.ms":"200",
        "fetch.message.max.bytes":"10485760",
        "max.partition.fetch.bytes":"10485760",
        "key.deserializer":"org.apache.kafka.common.serialization.StringDeserializer",
        "value.deserializer":"org.apache.kafka.common.serialization.StringDeserializer",
        "kafka.omrs.topic.id":"cocoCohort"
    }
}

A different type of event bus would use different properties.

Configuring the Open Lineage Services

POST - Configure Open Lineage Services

{{serverURLRoot}}/open-metadata/admin-services/users/{{userId}}/servers/{{serverName}}/open-lineage/configuration
{
    "class": "OpenLineageConfig",
    "openLineageDescription": "Open Lineage Service is used for the storage and querying of lineage",
    "lineageGraphConnection": {
        "class": "Connection",
        "displayName": "Lineage Graph Connection",
        "description": "Used for storing lineage in the Open Metadata format",
        "connectorType": {
            "class": "ConnectorType",
            "connectorProviderClassName": "org.odpi.openmetadata.openconnectors.governancedaemonconnectors.openlineageconnectors.janusconnector.graph.LineageGraphConnectorProvider"
        },
        "configurationProperties": {
            "gremlin.graph": "org.janusgraph.core.JanusGraphFactory",
            "storage.backend": "berkeleyje",
            "storage.directory": "data/servers/{{ols-server-name}}/repository/berkeley",
            "index.search.backend": "lucene",
            "index.search.directory": "data/servers/{{ols-server-name}}/repository/searchindex"
        }
    },
    "accessServiceConfig": {
        "serverName": "{{server-name}}",
        "serverPlatformUrlRoot": "{{server-platform-url}}",
        "user": "admin",
        "password": "secret"
    },
    "backgroundJobs": [
        {
            "jobName": "LineageGraphJob",
            "jobInterval": 120,
            "jobEnabled": "false"
        },
        {
            "jobName": "AssetLineageUpdateJob",
            "jobInterval": 120,
            "jobEnabled": "false",
            "jobDefaultValue": "2021-01-01T00:00:00"
        }
    ]
}

Configuration reference

Property Description Is mandatory
lineageGraphConnection OCF configuration object that defines the Graph store connector type used. See open-lineage-janus-connector for more details. Yes
accessServiceConfig.serverName the name of the metadata server where paired Asset Lineage OMAS is running. Yes
accessServiceConfig.serverPlatformUrlRoot The URL of the OMAG server platform running the metadata server where paired Asset Lineage OMAS is running. Also see start-up information section. Yes
accessServiceConfig.user The username to access the server running Asset Lineage OMAS. Yes
accessServiceConfig.password The user password to access the server running Asset Lineage OMAS. Can be left out for non-secured access. No
backgroundJobs[n].jobName Key used to match the job name pre-defined in the open lineage server. Supported values LineageGraphJob and AssetLineageUpdateJob No
backgroundJobs[n].jobInterval Interval (seconds) to execute the repetitive task defined by the named job above No
backgroundJobs[n].jobEnabled Controls if the job will be running (enabled) or not (disabled). Omitting the item in the backgroundJobs list had the same effect as setting the job to disable. No
backgroundJobs[n].jobDefaultValue Setting initial value for the task, only used in case of AssetLineageUpdateJob. When configured and not present in the store this value becomes the starting point in time to poll for updates. After successful update initial value is no longer used and last known value form the store. The value should be always specified in standard internet data-time format YYYY-MM-DDThh:mm:ss. See ISO-8601 for more info and examples. No

Removing the Open Lineage Services from the server configuration

DELETE - Remove Open Lineage Configuration from the server

{{serverURLRoot}}/open-metadata/admin-services/users/{{userId]}}/servers/{{serverName}}/open-lineage/configuration

Start up information

Runtime consideration

It is important to consider that, to operate, open lineage server depends on the availability of metadata access server and asset lineage being up and running. This is the case because open lineage server discovers the event bus connectivity and the topic address from asset lineage during start-up. Consequently, it will always wait and retry until this condition is met, and it starts up successfully.

Back to top