-
Notifications
You must be signed in to change notification settings - Fork 24
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
metrics default error #32
Comments
Hi, thanks for reporting this issue! Most of the time that message seems to occur when the user does not have permission to run the query, or when the query is only suitable for a CDB and is being run in a PDB, as in the case with ADB. If you could provide me your custom metrics file, and confirm you are using the normal "out-of-the-box" standard metrics, I can try to debug this for you. Please also confirm what version your ADB instance is, and what user you are using to connect to it? Thanks |
Hi Mark, thanks for your time. Regarding the default metrics, I have a problem with two, which causes a lot of noise in the pod log:
First of all, let me tell you that I am not an expert in BBDD.
I have no answer with the "wait_time" and "resource" metrics. And in "resource" likewise the view v$resource_limit does not return data either.
Thank you very much for your interest, |
My deploy is simple:
|
thanks for the info. we are investigating this. some initial comments from my DBA colleague (fyi); v$waitclassmetric is capturing real-time events within the past 1-minute; its _history companion view will hold that data for up to an hour. Being empty is a sign that the database is not being hit hard. I don't see anything that says that view will not populate in an ADB-S environment (they are container aware so there's nothing that would be exposed from other PDBs in the same shared CDB which would warrant disabling). Given ADBs are on Exa it will probably take a lot to make an entry in the view ... so "no rows" output can be expected. However, I did generate a massive amount of I/O to try and trigger a wait event in that view and nothing came of it; checking with ADB team if this is expected v$resource_limit : It looks like it can now only be queried from the CDB; so for ADB's this will always return 0 rows and will only return rows if queried from the CDB in non-ADBs. |
i am going to look at handling this better and supressing the spourious messages |
OK thanks. |
Yes indeed, we are just doing some testing and then will put out an update. |
hi, i did put out a 1.1 release. it will still report when it cannot get a metric, but the output is more useful now, i hope. they look like this now... i was thinking maybe it should be a warning not an error, but its a bit difficult when the query works but no rows are returned to know if that is a good thing or a bad thing. if the query fails its clearly an error.
i am looking into how to throttle these messages - suppress duplicates. i don't think the logging library i am using supports that, so i need to figure out if i should swap to a different one, or build something in. i also changed the wait_class query so it should work fine in both pdbs and cdbs now - but it will still return no rows unless the db is under stress. |
I have problems with some checks against an autonomous database in the standard metrics.
The exporter is deployed in Kubernetes.
I also have the same problem in custom checks such as slow queries.
caller=collector.go:326 level=error Errorscrapingfor=resource _="unsupported value type" 5.687861ms=:
caller=collector.go:326 level=error Errorscrapingfor=wait_time _="unsupported value type" 5.207271ms=:
The text was updated successfully, but these errors were encountered: