Closed emiller42 closed 3 years ago
Some screenshots of this in action:
metric_type
Testing today @emiller42
An example of some metrics we are trying to send
3 Jun 18:51:05 - DEBUG: airflow.scheduler_heartbeat:1|c
3 Jun 18:51:05 - DEBUG: airflow.scheduler.critical_section_duration:6.958220|ms
3 Jun 18:51:06 - DEBUG: airflow.scheduler.critical_section_duration:6.989922|ms
3 Jun 18:51:08 - DEBUG: airflow.scheduler.critical_section_duration:7.694453|ms
3 Jun 18:51:09 - DEBUG: airflow.scheduler.critical_section_duration:7.632654|ms
3 Jun 18:51:10 - DEBUG: airflow.scheduler.critical_section_duration:7.189173|ms
3 Jun 18:51:10 - DEBUG: airflow.scheduler.critical_section_duration:6.864361|ms
@lewismc How is testing going?
Hi @emiller42 testing is ongoing. We have been unsuccessful so far but we think it has something to do with SSL configuration. Still investigating and I will provide an update here once we get further. Thanks for checking in...
@emiller42 I confirm that this PR allows us to send events into Splunk Enterprise v8.0.6 with the following configuration
{
debug: true,
dumpMessages: true,
flushInterval: 10000,
backends: ['splunk-statsd-backend'],
splunk: {
splunkHost: '...',
splunkPort: 8088,
useSSL: true,
strictSSL: false,
splunkToken: '...',
index: '...',
source: 'statsd',
sourcetype: '_json',
useMetrics: false
},
servers: [
{
server: './servers/tcp'
},
{
server: './servers/udp'
}
]
}
This is exactly what we were looking for. Thank you for working so proactively on this PR.
Some more info, the above config results in metricName
instead of metric_name
.
We are experimenting setting useMetrics: true
That sounds right. Behavior should be unchanged when useMetrics: false
. The difference between metricName
and metric_name
only matters when you're sending to a Metrics index. (and thus should have useMetrics: true
)
Everything appears to be in good order @emiller42
@lewismc This PR adds support for Splunk Metrics. Can you review and see if it suits your purposes?