feat: Add staging OTel log synthesis rule for POSTGRESQLINSTANCE#3074
feat: Add staging OTel log synthesis rule for POSTGRESQLINSTANCE#3074mraju1 wants to merge 1 commit into
Conversation
Adds definition.stg.yml with a new synthesis rule that associates OTel log events (db.server.top_query, db.server.query_sample) with the existing POSTGRESQLINSTANCE entity. Uses db.system.name: postgresql as the discriminator — receiver-agnostic and always present when log events are enabled. Identifier is service.instance.id (host:port) to match the existing OTel metric rule, ensuring logs resolve to the same entity GUID. Also adds tests/Log.json covering both log event types for CI validation.
entityBot
left a comment
entityBot
left a comment
There was a problem hiding this comment.
beep boop bop.
I have found some errors processing these changes:
- Error VALIDATING domainType: 'INFRA-POSTGRESQLINSTANCE' on synthesis - Exception: No entity matches 'INFRA-POSTGRESQLINSTANCE' synthesis rules for the given test data: 'Log.json file - #1' data point. Please review test data and synthesis rules.
- Error VALIDATING domainType: 'INFRA-POSTGRESQLINSTANCE' on synthesis - Exception: No entity matches 'INFRA-POSTGRESQLINSTANCE' synthesis rules for the given test data: 'Log.json file - #2' data point. Please review test data and synthesis rules.
- We don't think these changes require an API Review Board (ARB) review, so it is not required to merge this PR. Note that all API changes do require one: if you believe this PR needs an ARB review, please create the ticket and add the
ARB:pendinglabel. Reach#api-review-boardin case of doubts.
| cloud.provider: | ||
| cloud.account.id: | ||
| cloud.region: | ||
| otel.library.name: |
There was a problem hiding this comment.
@mraju1 Can we update the tags for both metrics and logs?
- Add
otel.library.versionso we can identify customer collector versions. - Remove
host.type, cloud.provider, cloud.account.id, and cloud.regionsince they aren't present in the PostgreSQL receiver's metadata.yaml.
There was a problem hiding this comment.
Remove host.type, cloud.provider, cloud.account.id, and cloud.region since they aren't present
I think these are useful tags.
They are coming from the resourcedetectionprocessor and are all very popular.
There was a problem hiding this comment.
@nr-ksteinbach Thanks for the clarification!
One thing worth flagging though, resourcedetectionprocessor actually detects the collector's own VM/host, not the database's. It reads from the collector's local environment (EC2/GCP/Azure/system metadata).
So these tags are accurate only when the collector runs on the same VM as Postgres. If it runs on a separate VM (e.g. a centralized collector, or a managed/remote Postgres instance), host.type, cloud.provider, cloud.account.id, and cloud.region would describe the collector's VM, not the DB's - which could be misleading on POSTGRESQLINSTANCE.
Given that's a pretty common setup, I'd lean toward dropping them. Happy to hear your thoughts on this!
There was a problem hiding this comment.
if a value for the a tag attribute entry is not present, does it ignore tagging it or creates a tag with empty value?
There was a problem hiding this comment.
@mraju1 As per the synthesis docs: a tag is only created if the attribute is present on the matching data point. If it's absent, no tag gets written (not an empty-value tag).
So keeping host.type/cloud.provider/etc. in the rule is safe when the attribute is missing - the real risk we were discussing is only when the attribute is present but describes the wrong VM (collector's, not the DB's).
Also, can you please fix the errors thrown by entityBot?
4 participants
Relevant information
Api Review Board (ARB)
Any pull request with changes to this repository has to be linked with an ARB ticket, which has to be approved before merging.
If you are an external contributor please contact New Relic Support.
If you don't know about the ARB process check this
ARB Jira ticket:
https://new-relic.atlassian.net/browse/NR-XXXX
Checklist
identifierwill be unique and valid.