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

Standardize enabled, transmit, output and verbose configuration options #453

Closed
ArturMoczulski opened this issue Apr 26, 2019 · 2 comments · Fixed by #456
Closed

Standardize enabled, transmit, output and verbose configuration options #453

ArturMoczulski opened this issue Apr 26, 2019 · 2 comments · Fixed by #456
Assignees
Labels
Type: Enhancement Changes that add to, improve upon, enhance, or extend the existing component.

Comments

@ArturMoczulski
Copy link
Contributor

ArturMoczulski commented Apr 26, 2019

There has been much confusion around enabled and verbose config options available across Rollbar SDKs. It is not clear to the users what each does versus what it is actually doing. We identified four different parameters that should control the behavior of the SDK in regards to it being enabled and how the logging is performed.

The new suggested configuration options authored by @rokob are:

I propose we have the following settings which are all independent of one another:

  • enabled
    • If this is false then do absolutely nothing, try to be as close to the scenario where Rollbar did not exist at all in the code.
    • Default: true
  • transmit
    • If this is false then we do everything except make the post request at the end of the pipeline.
    • Default: true
  • output
    • If this is true then we output the payload to standard out or a configured logger right before transmitting.
    • Default: false
  • verbose
    • If this is true then we output messages related to the processing of items that might be useful to someone trying to understand what Rollbar is doing.
    • Default: false
      • I would actually prefer this to be a level in increasing level of severity:
        • trace
        • debug
        • info
        • warn
        • error
        • none
      • The SDK would then have internal messages of different log levels and based on what you pick we would output only what you want to see, i.e. trace prints everything, error prints only the worst errors, and none prints nothing.
@ArturMoczulski ArturMoczulski added the Type: Enhancement Changes that add to, improve upon, enhance, or extend the existing component. label Apr 26, 2019
@ArturMoczulski ArturMoczulski self-assigned this Apr 26, 2019
@ArturMoczulski
Copy link
Contributor Author

When this is finished documentation for the SDK needs to be amended.

@ArturMoczulski
Copy link
Contributor Author

I recommend using the standardized https://tools.ietf.org/html/rfc5424 protocol for the verbose levels. @rokob what do you think?

ArturMoczulski added a commit that referenced this issue Apr 30, 2019
add output config option; implement transmitting based on the transmit
config option and outputting based on the output config option; add
internal logger to print to the chosen log outlet

Closes re #453
ArturMoczulski added a commit that referenced this issue Apr 30, 2019
ArturMoczulski added a commit that referenced this issue Apr 30, 2019
ArturMoczulski added a commit that referenced this issue Apr 30, 2019
ArturMoczulski added a commit that referenced this issue Apr 30, 2019
ArturMoczulski added a commit that referenced this issue Apr 30, 2019
ArturMoczulski added a commit that referenced this issue Apr 30, 2019
ArturMoczulski added a commit that referenced this issue Apr 30, 2019
ArturMoczulski added a commit that referenced this issue Apr 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Enhancement Changes that add to, improve upon, enhance, or extend the existing component.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant