feat: support HYPERDX_LOG_LEVEL env var
#66
Conversation
🦋 Changeset detectedLatest commit: 563ac75 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| @@ -185,6 +185,15 @@ comprehensive documentation on how we balance between cloud-only and open source | |||
| features in the future. In the meantime, we're highly aligned with Gitlab's | |||
| [stewardship model](https://handbook.gitlab.com/handbook/company/stewardship/). | |||
|
|
|||
| ## Frequently Asked Questions | |||
There was a problem hiding this comment.
Just throwing this out there - we should probably have a separate deployment guide to wrap up some of the new stuff around custom URLs, log levels, etc. that we get from users that need to customize their deployment beyond a local stack. And help keep the readme lean to mainly for quick start + project overview.
Not something we need to do this minute.
There was a problem hiding this comment.
Good stuff. Yeah we should put all custom deployment things together
README.md
Outdated
| #### How to suppress all logs from HyperDX itself ? | ||
|
|
||
| To suppress logs of a service, you can comment out the `HYPERDX_API_KEY` | ||
| environment variable in the docker-compose.yml file. Logs mainly come from |
There was a problem hiding this comment.
Logs mainly come from
app,apiandminerservices.
I'm not sure if this blanket statement is true, I think otel collector and vector are even more spammy and probably the thing I'd want to tune with log level the most. I think we can just omit this line for now since users can likely find which log source they're interested in muting anyways if they find it spammy.
There was a problem hiding this comment.
Correct, the logs here are those you can see within HyperDX. Let me update it
No description provided.