Troubleshooting
Workflow Deployment Error
If there were any errors during the workflow deployment process, the Ingestion Pipeline Entity will still be created, but no workflow will be present in the Ingestion container.- You can then Edit the Ingestion Pipeline and Deploy it again.
- From the Connection tab, you can also Edit the Service if needed.
Connector Debug Troubleshooting
This section provides instructions to help resolve common issues encountered during connector setup and metadata ingestion in OpenMetadata. Below are some of the most frequently observed troubleshooting scenarios.How to Enable Debug Logging for Any Ingestion
To enable debug logging for any ingestion workflow in OpenMetadata:- Navigate to Services Go to Settings > Services > Service Type (e.g., Database) in the OpenMetadata UI.
- Select a Service Choose the specific service for which you want to enable debug logging.
- Access Agents Tab Go to the Agents tab and click the three-dot menu on the right-hand side of the ingestion type, and select Edit.
- Enable Debug Logging In the configuration dialog, enable the Debug Log option and click Next.
- Schedule and Submit Configure the schedule if needed and click Submit to apply the changes.
Permission Issues
If you encounter permission-related errors during connector setup or metadata ingestion, ensure that all the prerequisites and access configurations specified for each connector are properly implemented. Refer to the connector-specific documentation to verify the required permissions.Snowflake Sink Lineage Is Missing
OpenMetadata writes Snowflake sink lineage only when the target table resolves to exactly one Snowflake service. For more information about how that service is chosen, see Snowflake Sink Lineage. When the table doesn’t resolve, the Kafka Connect Metadata Agent still succeeds. The lineage summary at the end of the run log lists the connector asFAILED with the reason Missing table, or Missing both table and topic when the topic isn’t ingested either. The log also carries one of the following warnings. Two of them name Db Service Names by its YAML key, lineageInformation.dbServiceNames.
The Table Isn’t in the Checked Services
The run log shows:- The table isn’t ingested yet. The Snowflake Metadata Agent might not have run since the connector created the table. Its filter patterns might also exclude the table’s database, schema, or table.
- Db Service Names lists only other services of the same account, so the service holding the table isn’t checked.
- The service holding the table spells its Account in the other identifier form, while another service’s Account matches
snowflake.url.name. Only the matching service is checked.
- Run the Snowflake Metadata Agent for the service that holds the table.
- Confirm the table appears under the database and schema named in the warning.
- If that service isn’t in the parentheses and its Account uses a different form from
snowflake.url.name, change its Account to the same form. - If that service isn’t in the parentheses and Db Service Names lists other services of this account, add it to Db Service Names.
- Re-run the Kafka Connect Metadata Agent.
The Table Is in More Than One Service
The run log shows:- In the Kafka Connect Metadata Agent, make sure Db Service Names lists the service that should carry the lineage and no other service that holds the table.
- Re-run the Kafka Connect Metadata Agent.
No Snowflake Service Matches the Account
The run log shows an informational line followed by a warning:- The service’s Account and the connector’s
snowflake.url.nameuse different identifier forms, such as an account locator in one and an organization and account name in the other. - No Snowflake service in OpenMetadata ingests the account the connector writes to.
- If a Snowflake service ingests the account, add it to Db Service Names in the Kafka Connect Metadata Agent.
- If none does, create a Snowflake service for the account.
- Run that service’s Metadata Agent.
- Re-run the Kafka Connect Metadata Agent.