Your data. Anywhere you go.

New Relic for iOS or Android


Download on the App Store    Android App on Google play


New Relic Insights App for iOS


Download on the App Store


Learn more

Close icon

Relic Solution: Using the .NET Core Agent with Linux Service Managers


#1

On Linux, .NET Core applications are simple to start. Just run the “dotnet” command on your project’s .dll:

[root@roger KestrelTest]# dotnet bin/KestrelTest.dll

Our .NET Core Agent is also simple to configure. In the this case, if the appropriate environment variables were set for your bash profile the agent would be loaded in the dotnet process and your app would report data to New Relic. But what if something causes the process to stop? What if you want to run it as a service account?

This is where service managers come into play. These give you familiar commands to stop and start services like httpd or mysqld and can be configured to start services on startup and restart services automatically. Many Linux distros come with a builtin service manager, systemd. The New Relic Infrastructure Agent installer creates a unit file (the config file for a service managed by systemd), /etc/systemd/system/newrelic-infra.service. The problem is that starting a service with systemd won’t pick up your bash profile’s environment variables. For that, we’ll have to tell systemd to load them into the process when it starts. Our dotnet service unit file might look like this:

   [root@roger docker]# vim /etc/systemd/system/kestrel.service
   [Unit]
   Description=Kestrel Server Test
   After=syslog.target
 
   [Service]
   Type=simple
   ExecStart=/usr/bin/dotnet /home/KestrelTest/bin/KestrelTest.dll
   Restart=always
   RestartSec=20
   StartLimitInterval=0
   StartLimitBurst=5
   Environment=CORECLR_NEWRELIC_HOME=/usr/local/newrelic-netcore20-agent
   Environment=CORECLR_ENABLE_PROFILING=1
   Environment=CORECLR_PROFILER={36032161-FFC0-4B61-B559-F6C5D41BAE5A}
   Environment=CORECLR_PROFILER_PATH=/usr/local/newrelic-netcore20-agent/libNewRelicProfiler.so

Then we can start our dotnet service with New Relic monitoring:

[root@roger ~]# systemctl start kestrel

It is similar with Supervisord. Like many Linux applications, the config files can be in one large /etc/supervisord.conf or split by service into separate /etc/supervisord.d/*.conf files. Each service has a tag such as this:

[program:Kestrel]

Which lets you start and stop the service:

   [root@roger ~]# supervisorctl stop Kestrel
   Kestrel: stopped
   [root@roger ~]# supervisorctl start Kestrel
   Kestrel: started

Under this heading is the command to start the process along with a number of optional configuration settings such as the user it runs as, log files, and (important to us) environment variables. Here I have a basic test app with the values set and an app name:

   [program:Kestrel]
   command=/usr/bin/dotnet /home/KestrelTest/bin/KestrelTest.dll
   environment=CORECLR_NEWRELIC_HOME="/usr/local/newrelic-netcore20-agent",    CORECLR_ENABLE_PROFILING="1", CORECLR_PROFILER="{36032161-FFC0-4B61-B559-F6C5D41BAE5A}",    CORECLR_PROFILER_PATH="/usr/local/newrelic-netcore20-agent/libNewRelicProfiler.so",    NEW_RELIC_APP_NAME=“My DotNet Core Service”

Note that the values are in quotes and it is all one comma separated line.

Now we’d expect that this would be picked up next time we ran supervisorctl restart Kestrel but I recommend restarting supervisord to be 100% certain

   [root@roger ~]# kill `pgrep supervisord`   
   [root@roger ~]# /usr/bin/supervisord -c /etc/supervisord.conf

Note that in my environment, killing the supervisord process also kills the dotnot processes but in other environments that has not the case. I’ve had to manually kill the dotnot processes so that they would be restarted in some environments.