Repository navigation
also support SIDs when getting instance from Oracle jdbc connections - #2709
Conversation
|
👋 @wolframhaussig Thanks a lot for your contribution! It may take some time before we review a PR, so even if you don’t see activity for some time, it does not mean that we have forgotten about it. Every once in a while we go through a process of prioritization, after which we are focussing on the tasks that were planned for the upcoming milestone. The prioritization status is typically reflected through the PR labels. It could be pending triage, a candidate for a future milestone, or have a target milestone set to it. |
There was a problem hiding this comment.
I think for now it should be fine to just capture the SID to provide better granularity when only SID is used.
Regarding the non-uniqueness of the SID and the visible impact in Kibana map, it is something that also happens with other databases when the same database name is used on two distinct hosts or in a clustered database, they will be displayed as if it was a single node. This is a known limitation of the current approach, thus I think that merging this contribution as-is should already provide some benefit for your use-case.
|
@elasticmachine run elasticsearch-ci/docs |
What does this PR do?
I found that the Kibana service map only shows services of oracle database with its name when using the service_name. When connecting using the SID it only shows as
oracle.Possible workaround: Set the servicename for the database and use the servicename
This PR gathers the low-hanging fruit: It reads the instance from the SID the same way as from SERVICE_NAME.
To discuss: This really was the lowhanging fruit - as the SID (e.g. DB instead of servicename DB.COMPANY.COM) may not be unique. I am not sure if we should add the hostname to the instance to make it unique - e.g. host:port/SID - what o you think?
Checklist