New Relic offers a variety of mechanisms by which you can gather telemetry data from open-source software and send it back to New Relic One for analysis.
New Relic’s various agents include built-in instrumentation for many popular parts of their respective ecosystems. The Java Agent, for instance, includes built-in instrumentation for many open-source libraries and frameworks such as Grails, Hibernate, Hystrix, Play, the Spring Framework, Spring Boot, Thrift, and Vert.x. Likewise, the node.js agent includes telemetry for Express, Restify, Connect, Hapi and Kora, while the .NET agent supports both .NET Framework and .NET Core, and so on.
New Relic also offers a number of additional integrations for many popular open-source applications and frameworks including Elasticsearch, Consul, MongoDB, PostgreSQL, RabbitMQ, Memcached, Apache, Kafka and more. The source for these integrations is available on the New Relic GitHub and they are licensed under the MIT license. The information captured by them is often extensive: for Kafka, for example, data is collected on brokers (both ZooKeeper and Bootstrap), producers, consumers, and topics.
In many cases, therefore, you will probably find the built-in instrumentation gives you all the information you need. However, if you find that it doesn't, then you also have the option of building custom integrations using the New Relic telemetry SDKs. These are open-source, language-specific libraries for reporting metrics, trace data, and other telemetry data to New Relic, and are available for Java, Node/TypeScript, Python, Go and .NET via New Relic's GitHub. The .NET SDK is also available as a NuGet package. They are licensed under the Apache v.2 license.
A final, new option to consider is the OpenTelemetry project that started from a merger of OpenTracing and OpenCensus and is currently incubating at the Cloud Native Computing Foundation (CNCF). This project is in beta, and therefore not yet recommended for production use, but it is particularly interesting since it represents a vendor-neutral standard for gathering telemetry data. As John Watson and Lavanya Chockalingam have commented, OpenTelemetry thereby offers a means of future-proofing your instrumentation. It also, they write, provides a number of benefits:
- Simplified choice. You don’t need to decide between one standard or the other. Are you currently using OpenTracing or OpenCensus? Don’t worry, OpenTelemetry offers backward compatibility for both projects.
- Cross-platform. OpenTelemetry supports a variety of languages and back ends. It represents a vendor-neutral path to capturing and transmitting telemetry to back ends without altering existing instrumentation. This is an important project that satisfies developers looking for this kind of freedom.
- Streamlined observability. As OpenTelemetry puts it, "Effective observability requires high-quality telemetry." Expect to see more vendors move toward OpenTelemetry, as it’s far easier to accommodate and test against a single standard.
Equally important, OpenTelemetry means that you are not locked in to a single vendor’s agent for collecting telemetry data.