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

Adding custom attributes to the logs via the agent #1141

Closed
rajpawar02 opened this issue May 6, 2022 · 16 comments
Closed

Adding custom attributes to the logs via the agent #1141

rajpawar02 opened this issue May 6, 2022 · 16 comments
Assignees
Labels
community To tag external issues and PRs submitted by the community feature request To tag feature request after Hero Triage for PM to disposition

Comments

@rajpawar02
Copy link

rajpawar02 commented May 6, 2022

I am addressing the collection of application logs by New Relic APM agents.

I have referred this document to configure APM agents on one of the application.

However, logs add five attributes by default, namely entity.guid, entity.name, hostname, trace.id, and span.id.

Because we are running several services/containers for the same application, it is extremely difficult to identify a specific ECS service or container log using the above attributes.

Can we use the Ruby APM agent to add custom attributes like container_id, ecs_service_name, and so on? If we do so, it will be extremely beneficial.
Please let us know what you think about this.
Thanks

@rajpawar02 rajpawar02 added the bug label May 6, 2022
@github-actions github-actions bot added the community To tag external issues and PRs submitted by the community label May 6, 2022
@kaylareopelle
Copy link
Contributor

Hi @rajpawar02! 👋

Thanks for submitting this feature request. We're intrigued by your idea to add custom attributes to log events and would like to learn more about how you would like this feature to behave.

I'm hoping you can provide some insight for us on a few questions:

  • How do you expect this feature to behave?

    • For example, we have the ability to add custom attributes to transaction traces by calling the method NewRelic::Agent#add_custom_attributes and to span events using the method NewRelic::Agent#add_custom_span_attributes. Would a method similar to these achieve your goal?

    • Alternatively, we have the ability to set the app name (entity.name in the default attributes) and hostname by configuration in either the newrelic.yml file or by environment variable. Would you prefer to set attributes like container_id and ecs_service_name using this strategy?

  • Is there a specific list of attributes you would always like to have added to a log event?

    • If this is the case, what are your thoughts about having your desired attributes included in log events by default instead of as custom attributes? This feature wouldn't necessarily have to replace custom attributes. Rather, it's helpful for us to know if there's linking metadata customers expect to have on events that we do not currently support
  • Are the custom attributes you're hoping to add static values that could be determined at startup, dynamic attributes that should be added at runtime, or both?

Your responses to these questions would be very helpful! We're investigating this prospect and may have more questions for you as our efforts continue.

Thanks for your support!

@rajpawar02
Copy link
Author

rajpawar02 commented May 12, 2022

Please see my answer to your question below.

How do you expect this feature to behave?

I appreciate both approaches, but I'd prefer to be able to specify generalized custom attributes like ecs service name and container id using an environment variable or the newrelic.yml file.

Is there a specific list of attributes you would always like to have added to a log event?

Because we operate the majority of our applications on the AWS ECS service, having the following attribute with log will be beneficial.

  • ecs_cluster_name
  • ecs_service_name
  • ecs_task_name
  • container_name
  • task_id
  • container_id

Are the custom attributes you're hoping to add static values that could be determined at startup, dynamic attributes that should be added at runtime, or both?

Some properties, such as ecs service name and ecs cluster name, are static. Some are dynamic, such as task id and container id, which are generated once the container is operating.

@kaylareopelle kaylareopelle added feature request To tag feature request after Hero Triage for PM to disposition and removed bug labels May 16, 2022
@kaylareopelle
Copy link
Contributor

Thank you for your responses, @rajpawar02! We'll discuss them during our next team planning session. We'll circle back to you with updates after.

@angelatan2 angelatan2 moved this from Triage to Feature Request in Ruby Engineering Board May 25, 2022
@angelatan2 angelatan2 removed the feature request To tag feature request after Hero Triage for PM to disposition label Sep 12, 2022
@workato-integration
Copy link

@angelatan2 angelatan2 added the feature request To tag feature request after Hero Triage for PM to disposition label Sep 12, 2022
@askreet
Copy link

askreet commented Nov 3, 2022

We are contemplating moving to NewRelic Logs and have hit a similar question in testing the default integration with newrelic_rpm. For us, we set DYNO to the name of the deployment for historical reasons (we have migrated from Heroku to Kubernetes), which is quite convenient because we now have hostname set as the deployment name.

However, we would also like the container name for specific troubleshooting situations. I'm surprised there doesn't appear to be a way to attach attributes to logs.

I'd be happy with any of the solutions above, such as putting the following in a Rails initializer:

# An environment variable we already provide to our containers, for example:
NewRelic::Agent.add_logging_attribute(pod_name: ENV.fetch('POD_NAME'))

@kaylareopelle
Copy link
Contributor

Thanks for your interest, @askreet! It's great to hear about your use case (and see the ❤️ support so far from @joshbranham and @rajpawar02)! We're talking about this as a team and hope to have more information soon.

If anyone else comes across this post and is interested in this feature, please respond using a comment or an emoji. This feedback is a huge help for our team to understand interest for custom attributes in logs and prioritize this work.

@santanaguy
Copy link

santanaguy commented Nov 25, 2022

In our case we are using a forwarder in older agents that adds the custom tag of environment. Then we have partitions per environment.

Example, we configure the forwarder to tail logfiles and all the messages from a certain logfile will be tagged as env:dev. This is useful because sometimes in a single machine we have multiple environments.

Our previous use case was using VMs, and we hoped to have the same behavior now that we are moving newer services to Docker. We don't want the full fledged infrastructure integration with Kubernetes, the .NET Docker agent along with the app in the container is sufficient.

Have we lost that ability now with the automatic forwarding?

@kaylareopelle
Copy link
Contributor

Hi @santanaguy. Unfortunately, automatic forwarding in the Ruby agent does not have the ability to add custom attributes, such as environment, to log events at this time. This feature request is the perfect place to express your interest in this capability.

Some language agents for New Relic have already added this feature. If you have agents in multiple languages you may be able to add custom attributes to automatically forwarded log events using those agents today.

@santanaguy
Copy link

santanaguy commented Nov 29, 2022 via email

@kaylareopelle
Copy link
Contributor

@santanaguy - the .NET agent team is currently working on adding support for custom attributes with logs.

@kaylareopelle
Copy link
Contributor

@santanaguy - The .NET agent's 10.4.0 release includes custom attributes for logging.
https://github.com/newrelic/newrelic-dotnet-agent/releases/tag/v10.4.0

@santanaguy
Copy link

Hey, thanks for the heads up. I tried to enable the environment variable NEW_RELIC_APPLICATION_LOGGING_FORWARDING_CONTEXT_DATA_ENABLED but I did not get anything new on my logs. I am using the default Microsoft.Extensions.Logging library, not sure if I should be seeing something.

Another thing (not entirely related) is that the agent simply doesn't map correctly the INFORMATION logging level. Is this a limitation of using the Microsoft.Extensions.Logging lib?

@kaylareopelle
Copy link
Contributor

Hi @santanaguy, glad to hear you're testing out the new instrumentation!

Unfortunately I don't know much about how the .NET agent works. Could you post your questions in a new issue in the .NET agent repository? https://github.com/newrelic/newrelic-dotnet-agent

The .NET agent engineers should be able to help you there!
cc @JcolemanNR

@angelatan2
Copy link
Contributor

@kaylareopelle kaylareopelle self-assigned this Jun 13, 2023
@kaylareopelle kaylareopelle moved this from Feature Request to In progress in Ruby Engineering Board Jun 13, 2023
@kaylareopelle
Copy link
Contributor

Hi folks! We've added two new features to support custom attributes on New Relic log events:

These features will be included in our next release. Thank you all for sharing your ideas and thoughts to design a solution!

cc: @rajpawar02 @askreet @santanaguy @joshbranham @erdzan12 @murkitsa

@kaylareopelle
Copy link
Contributor

Version 9.3.0 of the agent, which includes this feature, has been released! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community To tag external issues and PRs submitted by the community feature request To tag feature request after Hero Triage for PM to disposition
Projects
Archived in project
Ruby Engineering Board
  
Code Complete/Done
Development

No branches or pull requests

6 participants