Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple database support #89

Open
luddevik opened this issue May 16, 2024 · 9 comments
Open

Multiple database support #89

luddevik opened this issue May 16, 2024 · 9 comments
Assignees

Comments

@luddevik
Copy link

Is there any update on this feature from the roadmap?
We have tested the exporter in our environment, but can't really start using it before we have support for multi-target.
Our environment consists of multiple cdbs and pdbs.

@markxnelson
Copy link
Member

I'll increase the priority for that feature. I am planning to get another release out in the next couple of weeks.
Thanks for your interest!
If you have any specific requirements for multi-db please let me know.

@luddevik
Copy link
Author

luddevik commented May 21, 2024

We would like to collect metrics from cdbs and pdbs, so that we can monitor our environment without using the Oracle Enterprise Manager for monitoring.

@savoir81
Copy link

Hi @markxnelson, one question considering Multiple database support. In what way will this be implemented in case I want to monitor CDB and the belonging PDB(s)? Are we going to have 2 entries in service?

sudo systemctl edit oracledb_exporter

[Service]
Environment="DB_USERNAME=db_mon"
Environment="DB_PASSWORD=**********"
Environment="DB_CONNECT_STRING_1=server-name.com:1521/cdbname"
Environment="DB_CONNECT_STRING_2=server-name.com:1521/pdbname"

Or you are going to handle this on a query level? For example, to support CDB and belonging PDB monitoring, I've created CDB queries which also gets the data from PDB.

Example for session query:

[[metric]]
context = "sessions"
labels = [ "container_name", "status", "type" ]
metricsdesc = { value= "Gauge metric with count of sessions by container_name, status and type." }
request = '''
SELECT
    CASE
        WHEN s.con_id = 0 THEN 'Entire CDB'
        WHEN s.con_id = 1 THEN 'CDB$ROOT'
        ELSE p.pdb_name
    END AS container_name,
    --s.con_id,
    s.status,
    s.type,
    COUNT(*) as value
FROM
    v$session s
LEFT JOIN
    cdb_pdbs p ON s.con_id = p.con_id
WHERE s.status='ACTIVE'
AND s.wait_class <> 'Idle'
AND s.username is not null
GROUP BY
    CASE
        WHEN s.con_id = 0 THEN 'Entire CDB'
        WHEN s.con_id = 1 THEN 'CDB$ROOT'
        ELSE p.pdb_name
    END,
    s.status,
    s.type
'''

@markxnelson
Copy link
Member

I am still thinking it through. I think I would definitely want to allow people to run different sets of metrics on different databases. So I think I would want to separate the metrics defintion from the database/connection defintion. I guess I would need some kind of mapping or tagging. I am planning to allow metrics to be annotated to say whether they are applicable for cdb/pdb/adb or what combination of those. Maybe also for version of the DB? I am also planning to add the ability to run metrics at different time intervals, since some might be much more expensive to run, and you might not want to run them on every scrape.

I am happy to take any suggestions :)

@lucian-vanghele
Copy link

I am still thinking it through. I think I would definitely want to allow people to run different sets of metrics on different databases. So I think I would want to separate the metrics defintion from the database/connection defintion. I guess I would need some kind of mapping or tagging. I am planning to allow metrics to be annotated to say whether they are applicable for cdb/pdb/adb or what combination of those. Maybe also for version of the DB? I am also planning to add the ability to run metrics at different time intervals, since some might be much more expensive to run, and you might not want to run them on every scrape.

I am happy to take any suggestions :)

sounds good! different time intervals could be so useful!
question: do you have in your plans to allow also multihost DSNs (dataguard setups)?

@markxnelson
Copy link
Member

Hi @lucian-vanghele, thanks for your input. We'd be happy to add that to our roadmap. If you have any more detail on exactly what you'd like to see, please let us know!

@lucian-vanghele
Copy link

Hi @lucian-vanghele, thanks for your input. We'd be happy to add that to our roadmap. If you have any more detail on exactly what you'd like to see, please let us know!

On short DB_CONNECT_STRING should accept something like host1:1521,host2:1521/freepdb1; that could be useful in active-passive replication setups, when the secondary database is not available while replicating; scraper should automatically fall-back when needed.

@gotsysdba gotsysdba self-assigned this Oct 2, 2024
@lucian-vanghele
Copy link

@markxnelson does the above make sense?

@markxnelson
Copy link
Member

Hi @lucian-vanghele , yep that make sense, hope to get this working in the next couple of weeks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants