Giter VIP home page Giter VIP logo

c-sdk's People

Contributors

fahmy-mohammed avatar jodeev avatar lawngnome avatar lesnyrumcajs avatar miriam-r avatar paperclypse avatar zsistla avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

c-sdk's Issues

v1.2.0 newrelic-daemon fails to run in foreground in Ubuntu xenial docker-container

The following shell script is installed in /etc/service/newrelic/run of an Ubuntu 16.04.2 LTS docker container along with newrelic-daemon built from the source in this repository:

#!/bin/bash
./newrelic-daemon -f --logfile stderr --loglevel "${NEW_RELIC_LOG_LEVEL:-warning}"

Under v1.1.0, the newrelic-daemon process worked as expected.

Under v1.2.0, it appears to fork a process instead of running in the foreground. As a result, runsv starts another one... and then another one... until the container runs out of space!

Here's the log output:

2019/10/21 20:57:37.991708 (452) Info: New Relic daemon version 1.2.0.0-520519d615c0 [listen="/tmp/.newrelic.sock" startup=init pid=452 ppid=451 uid=0 euid=0 gid=0 egid=0 runtime="go1.13.1" GOMAXPROCS=6 GOOS=linux GOARCH=amd64]
2019/10/21 20:57:37.992003 (452) Info: collector configuration is &{CAFile: CAPath: Proxy:}
2019/10/21 20:57:37.992288 (452) Info: daemon listening on /tmp/.newrelic.sock

libnewrelic.so is not linked against libpcre

The libnewrelic.so shared object is not linked against libpcre.so (as shown by ldd), so that when it's loaded into a program such as Chez Scheme, it throws this error:
undefined_symbol: pcre_free

If you add -lpcre to the end of the line that builds the .so, it will build correctly in Linux.

On macOS, you can first extract the members of libnewrelic.a and then build libnewrelic.dylib.

Here's one way to change the Makefile to do this (and you have my permission to use this change):

diff --git a/.gitignore b/.gitignore
index 88d356d..f82297d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -36,6 +36,7 @@ newrelic-daemon
 #
 # Byproducts from make libnewrelic.so
 #
+libnewrelic.dylib
 libnewrelic.so
 
 #
diff --git a/Makefile b/Makefile
index 7fe575d..dc8c472 100644
--- a/Makefile
+++ b/Makefile
@@ -29,6 +29,7 @@ export CMOCKA_INCLUDE
 # OS X 10.11 does not provide pcre-config by default.
 # Check whether it exists, and if not assume a sensible default.
 PCRE_CFLAGS := $(shell pcre-config --cflags)
+PCRE_LIBS := $(shell pcre-config --libs)
 
 #
 # We pull in the current SDK version from the VERSION file, and expose it to
@@ -47,11 +48,13 @@ ifeq (Darwin,$(UNAME))
 # then uses macOS's special libtool to smoosh them together into a single,
 # beautiful library.
 #
+SONAME := libnewrelic.dylib
 LIBTOOL := /usr/bin/libtool
 
 libnewrelic.a: axiom src-static
 	$(LIBTOOL) -static -o $@ vendor/newrelic/axiom/libaxiom.a src/libnewrelic.a
 else
+SONAME := libnewrelic.so
 #
 # This rule builds a static axiom library and a static C SDK library, and
 # then uses GNU ar's MRI support to smoosh them together into a single,
@@ -102,7 +105,7 @@ daemon-clean:
 	rm -f newrelic-daemon
 
 .PHONY: dynamic
-dynamic: libnewrelic.so
+dynamic: $(SONAME)
 
 .PHONY: valgrind
 valgrind: vendor libnewrelic.a
@@ -113,7 +116,12 @@ valgrind: vendor libnewrelic.a
 # the static library and have gcc wrap it in the appropriate shared library
 # goop.
 libnewrelic.so: libnewrelic.a
-	$(CC) -shared -pthread $(PCRE_CFLAGS) -ldl -o $@ -Wl,--whole-archive $^  -Wl,--no-whole-archive
+	$(CC) -shared -pthread -ldl -o $@ -Wl,--whole-archive $^ -Wl,--no-whole-archive $(PCRE_LIBS)
+
+libnewrelic.dylib: libnewrelic.a
+	$(AR) -x $<
+	$(CC) -shared -o $@ *.o $(PCRE_LIBS)
+	rm -f *.o
 
 .PHONY: src-static
 src-static:
@@ -130,7 +138,7 @@ tests-clean:
 
 .PHONY: clean
 clean: axiom-clean daemon-clean src-clean tests-clean
-	rm -f *.o libnewrelic.a libnewrelic.so
+	rm -f *.o libnewrelic.a libnewrelic.dylib libnewrelic.so
 
 .PHONY: integration
 integration: libnewrelic.so daemon

Overwriting error stacktrace

Hello,

For some context, we are in the process of evaluating New Relic for our new Rust projects. For that, we're using this C SDK along with the crate newrelic.

When using the function newrelic_notice_error(), a stack trace is internally generated with newrelic_get_stack_trace_as_json() and appears like so:

image

Naturally, all the Rust symbols are mangled and there is no mapping to source location (filename and line). We'd like to use the backtrace crate to capture the stacktrace from Rust, proving our developers a more familiar and readable feedback.

It is possible to overwrite the stacktrace today? I did a quick search of source code, but I could not find a way to do it.

If that is not possible, would it be a valid feature to add? Maybe other languages without a dedicated agent could also profit from this pattern of capturing native stack traces and passing it to the C SDK.

Best regards,

[C] C SDK OpenTelemetry Shim - Traces

Build a shim to go along with our C SDK and C OpenTelemetry exporter. It will map NR C SDK instrumentation to OpenTelemetry.

Transactions will map to traces. All attribute data must be applied to spans. Transaction name applied to root span.

Run daemon in its own docker container

Hey there! I was a user of the Agent SDK and noticed the deprecation notice, then found my way here. One important difference in functionality is the (lack of) embedded mode.

For context, the application in question is a http server running in a docker container in k8s. I typically adhere to the best practice of running a single process per container, so I would prefer not to run the daemon in the same container as the application. That in turn means the app needs to talk to the daemon over a network rather than a unix domain socket.

Though I'm no k8s expert, I believe the networking model can be configured such that containers are private within a SDN, so in my specific case this should be ok security-wise, even without any authentication mechanism. Though it may be best to attach a warning to this feature as it should be used with caution.

Is this something you're open to supporting? I got the code working (see the linked PR), but I thought it would be best to have a conversation here before paying too much attention to it.

missing directories in .gitignore

v1.1.0 on Ubuntu 18.04.3 after a clean checkout and make:

$ git status
On branch master
Your branch is up to date with 'origin/master'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	vendor/newrelic/bin/
	vendor/newrelic/pkg/

Please add these directories to .gitignore. Thanks!

Windows support

While we have nothing to announce at this time, we are exploring possibilities to provide C SDK support on Windows in the medium term.

Please reach out to us if you would like to collaborate or have further questions, either here or at the Explorers Hub.

Makefile problems

v1.1.0 on Ubuntu 18.04.3 after a clean checkout and make all:

$ make
make -C vendor/newrelic/axiom
make[1]: Entering directory '/home/rgburger/newrelic/vendor/newrelic/axiom'
cat: ../../VERSION: No such file or directory
make[1]: Leaving directory '/home/rgburger/newrelic/vendor/newrelic/axiom'
make -C src static
make[1]: Entering directory '/home/rgburger/newrelic/src'
make[1]: Leaving directory '/home/rgburger/newrelic/src'
ar -M < make/combine.mri
  • The Makefile is looking for VERSION in the wrong directories.
  • There should be no need to run ar again.

Blocker: SDK infrequently fails to create transactions, no enough information to debug

Describe the bug

In one of our applications we're infrequently seeing failures when calling newrelic_start_web_transaction() we get a NULL pointer, it would be good to get provide more context such that the application can take appropriate action, but also provide more debug logs in the SDK to understand the root cause of the failure. We have no way of figuring out what happened nor how the application logic should deal with this.

Expected Behavior

Creating transactions should never fail after establishing a connection.

Troubleshooting

This is what we see in our logs with debug logging turned on for the SDK after successfully sending thousands of transactions something

[...]
2020-09-03 00:04:59.999 +0000 (5547 5560) verbosedebug: sending transaction message, len=1540
2020-09-03 00:05:00.009 +0000 (5547 5560) error: unable to start transaction
2020-09-03 00:05:00.009 +0000 (5547 5561) verbosedebug: querying app='XXXX_REDACTED' from parent=5
[2020-09-03 00:05:00.009] [thread-5560] [instrumentation] [error] Newrelic: failed to create Transaction (YYYY_REDACTED)
2020-09-03 00:05:00.010 +0000 (5547 5561) verbosedebug: sending appinfo message, len=432

What I notice is that we first see error: unable to start transaction and then see verbosedebug: querying app='XXXX_REDACTED' from parent=5 in a new thread, which is something we typically only see once at the start of the application. It suggest it lost the connection to the agent, but it's running on localhost....

Steps to Reproduce

Send a bunch of metrics from various threads, eventually creating a web tx fails.

Your Environment

SDK v 1.3.0

Feature Request

Instead of just returning a pointer from newrelic_start_web_transaction() take in a pointer to a structure that will be filled in with the pointer to the new transaction or optionally an error message and code such that the application can judge what to do next. Eg. crash hard if it's a fatal error or buffer metrics for some time if only temporary, etc....

bash: ./newrelic-daemon: No such file or directory

Describe the bug

For some unknown reason, daemon file is not available after the installation process.
Two processes were tried; through New Relic UI wizard, and through the docker image, but the same issue was found.

Expected Behavior

Basic installation completed.

Troubleshooting

No log files were generated after installation

Steps to Reproduce

  1. Using NR UI:
    1.1. Application name (works)
    1.2. git clone https://github.com/newrelic/c-sdk &&
    cd c-sdk &&
    make (works)
    1.3. ./newrelic-daemon -f -logfile stdout -loglevel debug (didn't work)

  2. Using Container:
    2.1. Container installed end running (works)
    2.2. Running ./newrelic-daemon (didn't work)

Your Environment

Attached
c_plus

Additional context

Add any other context about the problem here. For example, relevant community posts or support tickets.

How to free a distributed tracing payload?

newrelic_create_distributed_trace_payload and friends return string that the caller is supposed to free.

Unless I'm missing something, which is entirely likely, the library doesn't export a way to free this string and depends on the the caller being able to do so using the same allocator.

This presents a problem in bindings for something like rust.

"make daemon" doesn't build on Go 1.16 due to changes to its module system

Describe the bug

If you have Go 1.16 installed, the Go portions of the project no longer build. For example, make daemon. This is because Go 1.16 switched to requiring Go modules by default.

pronto /tmp/c-sdk (main)$ make daemon
/Applications/Xcode.app/Contents/Developer/usr/bin/make USE_SYSTEM_CERTS=1 -C vendor/newrelic daemon
go install -ldflags '-X newrelic/version.Number=1.3.0.0 -X newrelic/version.Commit=fe05ae84e4fe -X newrelic/secrets.NewrelicCollectorHost= -X newrelic/secrets.NewrelicLicenseKey= -X newrelic/secrets.NewrelicCollectorKeys=' -tags='use_system_certs' ./...
go: cannot find main module, but found .git/config in /private/tmp/c-sdk
	to create a module there, run:
	cd ../.. && go mod init
make[1]: *** [daemon] Error 1
make: *** [newrelic-daemon] Error 2

pronto /tmp/c-sdk (main)$ go version
go version go1.16.2 darwin/amd64

Your Environment

I'm running this on MacOS 11.3 (Big Sur) with Go 1.16.2, but this also happens on Linux.

Additional context

A summary of the modules changes is available on the Go blog: https://blog.golang.org/go116-module-changes

A temporary workaround is to set GO111MODULES=auto. However, non-modules (aka GOPATH-mode) is scheduled to be dropped in Go 1.17.

The build system of Go code in this repository is very unusual, and doesn't follow best practices. For example, overriding GOPATH and not namespacing package import paths. One of the reason why projects did this, however, is because GOPATH was global on a user's machine. The Go module system makes this a lot cleaner and allows you to specify your dependencies more exactly.

My suggestion is to bump the minimum required Go version to 1.13 (the first one where modules were enabled and auto-detected) and switch to using Go modules. Go 1.13 was released in September 2019.

Multi-threading performance issue

We are trying to get New Relic integrated with a new service written in rust, and so we are using a rust wrapper over NR's C SDK, info about which is at https://docs.rs/crate/newrelic/0.2.2. We have noticed a pretty sharp decline in throughput when New Relic was integrated and enabled.

We ran some basic load testing with and without New Relic enabled.

We dropped from roughly 49k req/sec down to about 4700 req/sec, more than a 90% decrease. When profiling the runtime, we found that a lot of time was spent waiting for mutex locks/unlocks when creating a transaction, thus reducing the effectiveness of our multithreaded application. Does the New Relic team have any advice on how to improve performance?

See more details in ticket: https://newrelic.zendesk.com/agent/tickets/445508

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.