Skip to content

QFw: say what a Qiskit client's logs tier sends #49

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.

Sign up for GitHub

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

Merged
DougSO merged 1 commit into from
Oct 10, 2026
Merged

QFw: say what a Qiskit client's logs tier sends #49

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions telemetry/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -186,8 +186,11 @@ at every tier. DEFw's own levels are categories, and its work-request and
RPC chatter, hundreds of lines per job, stays local unless the tier is
`all`. `error` is the production setting. Whatever a process logs at the
chosen tier leaves it, so review a service's log before raising the tier on
a shared collector. A process whose DEFw log level selects nothing exports
nothing: a Qiskit client out of the box, for one. The site services report
a shared collector. A process's own logging level still gates everything
outside QFw's `qfw.*` loggers, which the tier opens to its level: a Qiskit
client out of the box, root logger at Python's default `WARNING`, sends its
story lines and the warnings and errors of everything else, nothing more.
The site services report
once the image carries a QFw with the tier and `qfw-site-services` has
forwarded the variable to them.

Expand Down