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

Global attributes + field mapping #14

Closed
ewrogers opened this issue Oct 31, 2023 · 2 comments
Closed

Global attributes + field mapping #14

ewrogers opened this issue Oct 31, 2023 · 2 comments

Comments

@ewrogers
Copy link

ewrogers commented Oct 31, 2023

We have a single Axiom dataset for our application, and typically use the environment field to separate dev, stage, and prod.

There are two problems I am facing currently:

  1. Global attributes, I want to essentially have environment in every event logged throughout the application. I am just reading this from ENVIRONMENT env var. Since my entire application is very async via tokio, including tokio::spawn for child tasks... it's difficult to get this to "stick". I had thought about a custom layer but it seems events are immutable?

  2. Mapping of fields, which seems to always be attributes.custom.[field]. In the case of environment, I want it to be top-level and not nested within custom attributes. How can I get it to be like this?

I have tried many things but nothing seems to work, and it's a bit confusing considering I am able to get it to work fairly easily with other axiomhq libs (like pino in JS).

Addendum

Turns out, #13 would solve the global attribute issue via with_tags(). The mapping of fields is due to Axiom's backend gRPC layer automatically nesting "non-blessed" attributes into attributes.custom, which is a bit annoying.

I spun up a simple HTTP proxy to compare why this works fine in JS land with pino. Turns out the JS library sends raw events as application/json to /datasets/:name/ingest which handles these differently than the /api/v1/traces gRPC one.

@darach
Copy link
Contributor

darach commented Nov 30, 2023

Hey @ewrogers Erik,

We have merged #13 so give it a whirl and let us know if it works for your use case.

We're also looking at #12 with an eye to enhancing that as well.

Cheers,

Darach.

@ewrogers
Copy link
Author

ewrogers commented Dec 5, 2023

Thanks, I appreciate it! Will definitely be taking a look at this soon.

@ewrogers ewrogers closed this as completed Dec 5, 2023
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

2 participants