Hello,

It seems that for jenkins2.x piepline jobs and multibranch piepline jobs (including github organisation) only job started event is reported. The job.juration and job.completed metrics are not reported at all.

Is there a possible fix to these issues as they both have the effect of rendering jenkins integration quite irrelevant, since there's no metric to report?

Thanks in advance.

Include details on javadoc, line length of 100, etc

In Jenkins2 Pipeline, Datadog Event Monitor is unstable work.
Maybe cause, in Jenkins2 Pipeline, run.getDuration() is always return 0.

If possible let's remove Datadog Build Reporter Plugin from the jenkins repo, because it currently shows both.

Tags such as node, should be made optional

Start, stop event, initialization time...

As discussed in #38 it would be useful to have a the project tag name to be able to group jobs belonging to the same jenkins project and therefore create more meaningful alerts.

I'll try to work on a patch

Allow the ability to somehow constrain the set of jobs we track. This could be a whitelist, or a blacklist. My gut says that default should be all, and we should allow a blacklist of jobs not to be tracked.

Currently it is not possible to isolate data from Jenkins to a Jenkins application key in DataDog, creating a lot of noise for other applications being monitored in DataDog. It would be useful to configure and use the application key to isolate this traffic.

Plugin 0.6.1
Jenkins 2.60.3

Upon upgrading to 0.6.1 we found all metrics apart from jenkins.queue.size missing from DataDog. To enable metrics again we had to specify all job names in the whitelist. This should not be the case according to the docs.

Thanks

I'll start by describing what I want to accomplish first, then suggested fix.

We have two Jenkins clusters, one for QA and one for Prod, and want to separate alerts out based on this environment. The /etc/dd-agent/datadog.conf has this, and is managed through our automation.

The Jenkins plugin, however, does not try to integrate those configured tags. Events emitted by the Jenkins plugin have a fixed set of tags. The old Jenkins integration that parsed build.xml went through the local collector and didn't have this limitation.

Is it feasible to pull the tags from the local agent (if available) and merge those in? Either by checking for the file on disk, parsing and extracting tags: or an action against the agent API?

We're happy to contribute patches to resolve this issue with some guidance.

Thanks!

Jenkins job name of Japanese will raise garbled character in Datadog.

Like this.

There should be is this.

Currently, Datadog logs a lot of information before and after the job starts, prefixed with DatadogBuildListener.java:.

Would be nice to be able to reduce or suppress that logging using an option in the plugin.

Every time I edit and save global settings in Jenkins, the Datadog agent on the master note simply stops reporting Jenkins events. Nothing will get it to resume reporting build events except restarting the Jenkins server.

Anyone else seeing this issue?

Jenkins 2.60.1 here running in Docker.

This is a 'nice to have' feature, but I would like to be able to use the Credentials Plugin to pull my datadog API key from.

In Manage Jenkins -> Configure System -> Datadog -> API Key I would like to see either a form field, or a drop down to use a stored credential.

We upgraded from 0.4.1 to 0.5.2, and we no longer seem to be getting jenkins.job.duration metrics at all. I looked through the changes, but can't seem to see anything that would have obviously caused this. Is there anything I can do to look into this?

I am getting runlistener failed events by the masses and I'm using spot instances.

Mar 05, 2018 5:29:41 PM hudson.model.listeners.RunListener report
WARNING: RunListener failed
java.lang.NullPointerException
at org.datadog.jenkins.plugins.datadog.DatadogBuildListener.onStarted(DatadogBuildListener.java:113)
at hudson.model.listeners.RunListener.fireStarted(RunListener.java:240)
at hudson.maven.MavenBuild$ProxyImpl2.start(MavenBuild.java:609)
at sun.reflect.GeneratedMethodAccessor161.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at hudson.model.Executor$2.call(Executor.java:911)
at hudson.util.InterceptingProxy$1.invoke(InterceptingProxy.java:23)
at com.sun.proxy.$Proxy97.start(Unknown Source)
at sun.reflect.GeneratedMethodAccessor161.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:922)
at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:896)
at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:853)
at hudson.remoting.UserRequest.perform(UserRequest.java:207)
at hudson.remoting.UserRequest.perform(UserRequest.java:53)
at hudson.remoting.Request$2.run(Request.java:358)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at org.jenkinsci.remoting.CallableDecorator.call(CallableDecorator.java:19)
at hudson.remoting.CallableDecoratorList$1.call(CallableDecoratorList.java:21)
at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

I'm using the latest datadog plugin and no luck. What other information can I provide to help fix this? This pretty much dominates my logs at this point.

thanks

One of the features that's really starting to be used often is the Workflow plugin, a part of that functionality is "Multibranch" (explained here) which creates a "Folder" with jobs in it for each branch which contains a Jenkinsfile (example of such a job here).

When the plugin reports job statistics it is only reporting the job name, which means that all "Workflow Multibranch" or any other jobs within Folders which share the same name will be largely indistinguishable inside of the Datadog UI.

This is particularly problematic if one wants to set up a monitor based on a specific job failing :(

Mike would like statistics from the master Manage Jenkins -> Monitoring of Jenkins master

Currently, the config panel is populating a previously entered API key incorrectly. This is because it's showing the redacted hash of the users API key, rather than the redacted API key. By-products of this include if a user presses 'Test Key' after they have already saved a key, it will fail, because the hash itself, is not a valid API key. This could present problems if one were to save the hash, which would be incorrect. This isn't a security problem, just incorrect.

Mike would like cluster statistics Manage Jenkins -> Cluster Statistics

I'd like jenkins.job.duration to have the tags that everything else coming out of my jenkins master does, but it seems to completely bypass the datadog agent (how else could it skirt those tags?)

Hi,

It seems the "results" tag is not anymore passed with jenkins.job.status because of a recent commit.
As a result we can't anymore count easily the number of failed and successful jobs and the two related widgets default dashboard jenkins don't work anymore.

Is it possible to add back the result tag or to have the appropriate metric to extract this information ?

Thanks in advance.

Yann

I need to change a tag value based on what triggered the build (i.e. what's the build cause). After a lot of tinkering, I'm doing something like this:

def cause = 'something' // actually comes from currentBuild.rawBuild.getCause...
properties([
  [
    $class: 'DatadogJobProperty',
    tagProperties: "cause=${cause}"
  ]
])

And this sort of works, but isn't really reliable. It causes issues when multiple jobs run concurrently. The current DatadogJobProperty value is used whenever a build finishes. That means that if job A starts with cause "A" and job B starts with cause "B" before A finishes running, then both jobs will use the last DatadogJobProperty which has "B" configured as the cause.

I also tried the following, but this fails to set the value altogether. The tag ends up as cause=_cause.

env.CAUSE = 'something' // actually comes from currentBuild.rawBuild.getCause...
properties([
  [
    $class: 'DatadogJobProperty',
    tagProperties: 'cause=${CAUSE}'
  ]
])

Any chance we could get tags for the release changeset ids for the last couple of releases? Would make it easier for those who have to git clone && git checkout releases.

thx!

This behaviour will continue until Jenkins runs out of file descriptors, rendering it completely inoperable. Jenkins will then fill the disk at a very rapid rate with logs explaining it's out of file descriptors.

Here's the output of netstat and tcpdump confirming this.

tcpdump

21:07:22.531862 IP (tos 0x0, ttl 64, id 58450, offset 0, flags [DF], proto UDP (17), length 90)
    127.0.0.1.39127 > 127.0.0.1.8125: [bad udp cksum 0xfe59 -> 0xb716!] UDP, length 62
        0x0000:  0000 0304 0006 0000 0000 0000 6f6e 0800  ............on..
        0x0010:  4500 005a e452 4000 4011 583e 7f00 0001  E..Z.R@[email protected]>....
        0x0020:  7f00 0001 98d7 1fbd 0046 fe59 6a65 6e6b  .........F.Yjenk
        0x0030:  696e 732e 6a6f 622e 636f 6d70 6c65 7465  ins.job.complete
        0x0040:  643a 317c 637c 2362 7261 6e63 683a 6f72  d:1|c|#branch:or
        0x0050:  6967 696e 2f64 6576 656c 6f70 6d65 6e74  igin/development
        0x0060:  2c6a 6f62 3a55 492d 5141                 ,job:UI-QA
21:07:27.421957 IP (tos 0x0, ttl 64, id 59563, offset 0, flags [DF], proto UDP (17), length 110)
    127.0.0.1.34209 > 127.0.0.1.8125: [bad udp cksum 0xfe6d -> 0xfecf!] UDP, length 82
        0x0000:  0000 0304 0006 0000 0000 0000 0000 0800  ................
        0x0010:  4500 006e e8ab 4000 4011 53d1 7f00 0001  E..n..@[email protected].....
        0x0020:  7f00 0001 85a1 1fbd 005a fe6d 6a65 6e6b  .........Z.mjenk
        0x0030:  696e 732e 6a6f 622e 636f 6d70 6c65 7465  ins.job.complete
        0x0040:  643a 317c 637c 2362 7261 6e63 683a 7061  d:1|c|#branch:pa
        0x0050:  6769 6e61 7465 2d74 6865 2d6f 7267 616e  ginate-the-organ
        0x0060:  697a 6174 696f 6e73 2d6c 6973 742c 6a6f  izations-list,jo
        0x0070:  623a 496e 7472 616e 6574 2050 5273       b:Intranet.PRs
21:07:45.624593 IP (tos 0x0, ttl 64, id 62489, offset 0, flags [DF], proto UDP (17), length 113)
    127.0.0.1.33975 > 127.0.0.1.8125: [bad udp cksum 0xfe70 -> 0x6cfc!] UDP, length 85
        0x0000:  0000 0304 0006 0000 0000 0000 0000 0800  ................
        0x0010:  4500 0071 f419 4000 4011 4860 7f00 0001  E..q..@[email protected]`....
        0x0020:  7f00 0001 84b7 1fbd 005d fe70 6a65 6e6b  .........].pjenk
        0x0030:  696e 732e 6a6f 622e 636f 6d70 6c65 7465  ins.job.complete
        0x0040:  643a 317c 637c 2362 7261 6e63 683a 6f72  d:1|c|#branch:or
        0x0050:  6967 696e 2f70 6167 696e 6174 652d 6f72  igin/paginate-or
        0x0060:  6761 6e69 7a61 7469 6f6e 732d 6c69 7374  ganizations-list
        0x0070:  2c6a 6f62 3a49 6e74 7261 6e65 7420 5052  ,job:Intranet.PR
        0x0080:  73                                       s
21:08:01.167220 IP (tos 0x0, ttl 64, id 64502, offset 0, flags [DF], proto UDP (17), length 117)
    127.0.0.1.35373 > 127.0.0.1.8125: [bad udp cksum 0xfe74 -> 0x8de8!] UDP, length 89
        0x0000:  0000 0304 0006 0000 0000 0000 0000 0800  ................
        0x0010:  4500 0075 fbf6 4000 4011 407f 7f00 0001  E..u..@.@.@.....
        0x0020:  7f00 0001 8a2d 1fbd 0061 fe74 6a65 6e6b  .....-...a.tjenk
        0x0030:  696e 732e 6a6f 622e 636f 6d70 6c65 7465  ins.job.complete
        0x0040:  643a 317c 637c 2362 7261 6e63 683a 6f72  d:1|c|#branch:or
        0x0050:  6967 696e 2f70 6167 696e 6174 652d 7468  igin/paginate-th
        0x0060:  652d 6f72 6761 6e69 7a61 7469 6f6e 732d  e-organizations-
        0x0070:  6c69 7374 2c6a 6f62 3a49 6e74 7261 6e65  list,job:Intrane
        0x0080:  7420 5052 73                             t.PRs

netstat

The values in the Recv-Q column are due to me using netcat to prod the ports

root@ip-10-0-103-29:/var/lib/jenkins# netstat -nape | grep java | grep udp6
udp6       0      0 :::35373                :::*                                106        2770877827  20518/java
udp6    3840      0 :::60431                :::*                                106        2770521115  20518/java
udp6       0      0 :::5353                 :::*                                106        2770515125  20518/java
udp6       0      0 :::39127                :::*                                106        2770877557  20518/java
udp6       0      0 :::33848                :::*                                106        2770515122  20518/java
udp6     768      0 :::58444                :::*                                106        2770831899  20518/java
udp6       0      0 :::33975                :::*                                106        2770877724  20518/java
udp6       0      0 :::34209                :::*                                106        2770877594  20518/java
udp6    1536      0 :::34463                :::*                                106        2770624072  20518/java
udp6       0      0 :::34679                :::*                                106        2770559677  20518/java
unix  2      [ ]         STREAM     CONNECTED     2770016066 20518/java
unix  2      [ ]         STREAM     CONNECTED     2770506247 20518/java

As you can see, the source ports in tcpdump match up with bound ports in the netstat output. I don't expect Jenkins to require non-blocking statsd sends, perhaps that's the easiest way to fix this?

Currently it is possible to know if a job failed, but it would be interesting to know in what stage of the pipeline the job failed.

Example of use case:
Jenkins job is devided into the following stages:

• lint
• build
• test backend
• test frontend
• functional tests

Knowing that a job fails during build or during functional tests requires very different actions to fix.

We're using a shared Jenkins Server/Cluster and like to have the ability to integrate with different DataDog Accounts on a per job basis. Can this plugin also be configured on a per job basis?

When used in combination with GitHub Organization Folder Plugin, a lot of jobs are tagged as #job:master in datadog. This is due to the folder structure set up by this plugin (GitHubOrganizationName>ProjectName>BranchName).

This makes it hard to distinguish and collect metrics on specific projects in a github organization.

I'm thinking that a feasible approach would be adding another tag to jobs that specify parent folder or something similar. So that it won't interfere with regular nested folders.

The agent currently has the option to allow adding a hostname indatadog.conf. Let's add this option to the configuration screen for the plugin as well.

We run our Jenkins v1.596 server in a lab that lives behind proxies. From the CLI, replacing real values with dummy values here, I can successfully run

export http_proxy=http://myproxy.foo.com:80/
export https_proxy=http://myproxy.foo.com:80/
wget https://app.datadoghq.com/api/v1/validate?api_key=1234key

The wget completes in just a second and returns the following body content: {"valid": true}

But when I run a Jenkins job, the plugin just hangs and then times out (after several minutes) with output like this, and we never see events in our DataDog dashboard

DatadogBuildListener.java: Started build!
DatadogBuildListener.java: Using hostname set in 'Manage Plugins'. Hostname: myhostname.foo.com
DatadogBuildListener.java: Sending event

Similarly, in the Manage Jenkins > Configure System page, we have the same proxies set in the Global properties section. In the Datadog Plugin, when I enter my key and click "Test", it spins for a while and then gives me "ERROR".

I also tried adding the following arguments to the CLI where I launch Jenkins: -Dhttp.proxyHost=myproxy.foo.com -Dhtttps.proxyHost=myproxy.foo.com -Dhttps.proxyPort=80

Same (bad) behavior from the plugin.

From a general Java perspective, these links may be useful: http://docs.oracle.com/javase/8/docs/technotes/guides/net/proxies.html and http://stackoverflow.com/questions/2430142/java-app-behind-proxy-to-use-http-proxy-variable-in-linux. But I've never written a Jenkins plugin before, so I'm not sure whether there's anything special the plugin needs to do to pick up the proxy settings.

Currently we are shipping with the package name datadog-build-reporter, however this should be datadog. This is because the hosted repository on jenkinsci is called datadog-plugin, where the -plugin is a typical appending that jenkinsci does for all plugins. Hence, this change helps to keep things consistent.

As soon as we are installing this plugin into our Jenkins, any job takes around 2 minutes to start and after it gets start also performance remains slow through out the job flow. Job which usually takes 5 minutes to complete is taking more than double of that time.

Currently, we are sending build started events without the Jenkins source type to keep started builds from being rolled up with build result events.

Once Jenkins event rollups have been updated to allow for proper rolling up of started builds, then the started build events need to start using the Jenkins source type again.

(internal) https://github.com/DataDog/dogweb/issues/9887

This appears to be a new issue that seems to have shown up after the upgrade of the datadog plugin to version .5

A lot of our jenkins job now crashes right at a beginning, with a NPE exception....

java.io.IOException: java.lang.NullPointerException
16:53:52 at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:614)
16:53:52 at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
16:53:52 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
16:53:52 at hudson.model.Run.execute(Run.java:1738)
16:53:52 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
16:53:52 at hudson.model.ResourceController.execute(ResourceController.java:98)
16:53:52 at hudson.model.Executor.run(Executor.java:410)
16:53:52 Caused by: java.lang.NullPointerException
16:53:52 at org.datadog.jenkins.plugins.datadog.DatadogSCMListener.onCheckout(DatadogSCMListener.java:47)
16:53:52 at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:612)

Unfortunately, this is causing a lot of our jobs to be unusable.....

Hi! We think it would also be useful to report a service check when the job is currently running, so we can monitor that too in our dashboard. Main problem is, what status should it emit? AFAIK there only 4 possible statuses and I'm not sure if a "Running Job" would better qualify as a WARNING or UNKNOWN, I'm not 100% happy with any of them, opinions?

On occasion I've had issues with posts to the API timing out and then "failing" what would have otherwise been a successful build. Since I'm generally running the agent somewhere nearby Jenkins anyway, it'd be nice to leverage that to have a little safety against hiccups in API availability.

The simplest solution would be to add a configuration option to each jobs config page where an admin could enter in a set of tags to tag the job with. However a static list of tags, while useful, is not sufficient for us.

We us parameterized jobs extensively. For example the same job builds all of our dropwizard projects in different configuration such as snapshot builds, release, builds, builds targeting platform X, targeting platform Y, etc. At the very least we would need to be able to specify that certain build parameters, or even certain environment variables, need to be set as the values of certain tags. For example set the #release tag to the value of the $DO_RELEASE env variable, and the #project tag be set to something based on which git repository we built from.

One possibility that would provide for maximum flexibility would be to be able to read in a set of tag values from a specified file in the workspace. This way we could use any sort of post build script to programmatically setup our tags.

Have Jenkins public javadoc

We would like to graph failed jobs, grouped by job, on our Jenkins dashboards. It doesn't look like it's possible to add the count of each event on a dashboard, and looking at other plugins using a count metric is the typical method for doing this.

With a jenkins.job.completed counter, we can use sum and filter accordingly and then add the graph as expected.

We use the service checks for monitors, which are working fine, but we can't add that graph to a dashboard.

The main source at DatadogBuildListener.java is approaching 800 lines. Let's break this into multiple files in a way that makes sense.

Use case: I only want to report on branches that can harm my production environment (ie. merges/deploys to branch "master") I'd like to whitelist those and have all others ignored.

The current blacklist doesn't help as each team/feature branch has different naming and it doesn't scale.

Blacklist feature added here:
#6

Based on line 175 it would seem this is already in place but we are not seeing any node tag and this would be very useful for us in alerting when a particular slave is having problems.

Total number of defined jobs in a jenkins instance is easy to acquire but also essential for monitoring long term performance of Jenkins.

There are huge performance impacts between an instance with 10, 100, 500, or 3000 jobs defined.

Hi there,

Can you consider to support to specify job name prefixes for white/black lists? Aka. exclude jobs in a "sandbox/" folder? Thanks.

Wei

To be clear I'll explain the issue first.

Let's assume that we have a Github organization/Bitbucket organization folder where all Jenkins jobs are created automatically for every new repository with Jenkinsfile or repo branches. This setup is pretty popular for now. But how can we tag the builds for Datadog? For now there is no clear option for this. Every job has Datadog tagging parameters, but they couldn't be modified because the organization folder jobs are immutable. Also the tags couldn't be appended at any folder level.

Also here is the issue out of such setup. Even if we manually create Jenkins job, we have to always make sure that the "Add tags from file in workspace" option is filled and we can't inherit any default settings. Which sometimes seems pretty useful due to organisation standards (e.g. have a tags.dd file in every repo/project with tags declaration). And, if you want to migrate to Datadog - it means that you have to setup this parameter manually on all existing jobs (that's probably wrong, but all my attempts to do this through XML reconfig&reload and Groovy scripts were failed).

If we could append the option in "Manage Jenkins → Configure System → Datadog Plugin" the option to declare the default file in workspace and inherit this parameter for every job. This feature would make the tagging setup much easier.

Please, let me know if something isn't clear at this issue.

java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
at java.security.cert.PKIXParameters.(PKIXParameters.java:120)
at java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:104)
at sun.security.validator.PKIXValidator.(PKIXValidator.java:88)
Caused: java.lang.RuntimeException: Unexpected error
at sun.security.validator.PKIXValidator.(PKIXValidator.java:90)
at sun.security.validator.Validator.getInstance(Validator.java:179)
at sun.security.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:312)
at sun.security.ssl.X509TrustManagerImpl.checkTrustedInit(X509TrustManagerImpl.java:171)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:184)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1496)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:961)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
Caused: javax.net.ssl.SSLException
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1906)
at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1889)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1410)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1546)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
at org.datadog.jenkins.plugins.datadog.DatadogBuildListener$DescriptorImpl.doTestConnection(DatadogBuildListener.java:440)
Caused: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1926)
at sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1921)
at java.security.AccessController.doPrivileged(Native Method)
at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1920)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1490)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
at org.datadog.jenkins.plugins.datadog.DatadogBuildListener$DescriptorImpl.doTestConnection(DatadogBuildListener.java:456)
at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627)
at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:343)
at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:184)
at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:117)
at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:129)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:715)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:845)
at org.kohsuke.stapler.MetaClass$5.doDispatch(MetaClass.java:248)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:715)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:845)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649)
at org.kohsuke.stapler.Stapler.service(Stapler.java:238)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:841)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:135)
at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:138)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:85)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:90)
at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:171)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:82)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
at org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:564)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:317)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)

I am using the datadog plugin version 0.5.1 with jenkins version 2.9, and in the jenkins log I see the following. Although my API key seems to check out fine using the system control panel, no events make it to DataDog. Any suggestions?

WARNING: RunListener failed java.lang.NullPointerException at org.datadog.jenkins.plugins.datadog.DatadogUtilities.parseTagList(DatadogUtilities.java:105) at org.datadog.jenkins.plugins.datadog.DatadogBuildListener.onStarted(DatadogBuildListener.java:103) at hudson.model.listeners.RunListener.fireStarted(RunListener.java:240) at hudson.model.Run.execute(Run.java:1716) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:410)