This document gives a quick overview of how to run veneur for exploration, and trying out new features under development.
If you're interested in writing (or reading!) code in the veneur code base, please see internals.md!
While veneur has decent test coverage, sometimes you'll want to run it
on a development machine (as opposed to your production infra). Since
veneur is written in go, you can use go run
in the veneur project
root directory to start a development instance, with the
provided dev.yaml file:
go run ./cmd/veneur/main.go -f docs/dev.yaml
This will start a veneur that listens for statsd packets on UDP port
8200, and for framed SSF data on the UNIX domain socket
/tmp/veneur.sock
.
Note that veneur does no hot code reloading - if you change source code, you have to Ctrl-C the running veneur server and restart it.
In order to see how your veneur instance behaves in development (and
to allow your production shell scripts to submit data too), we ship a
tool called veneur-emit
. Much like veneur itself, you don't need to
compile it before running either.
veneur-emit
has a bunch more options, check out the usage for it
with go run ./cmd/veneur-emit/main.go -help
!
Submit a metric named service.requests
:
go run ./cmd/veneur-emit/main.go \
-hostport 127.0.0.1:8200 \
-mode metric \
-name service.requests \
-gauge 10 \
-tag 'env:test' \
-debug
This will time the command /usr/bin/true
and submit an SSF span
concerning the run time of this process to veneur.
go run ./cmd/veneur-emit/main.go \
-ssf \
-hostport 127.0.0.1:8128 \
-trace_id 999 \
-parent_span_id 9999 \
-name hi.there \
-span_service veneur_ssf_investigation \
-debug \
-command /usr/bin/true
go run ./cmd/veneur-emit/main.go \
-mode event \
-hostport 127.0.0.1:8200 \
-e_event_tags 'service:airflow,host_type:qa' \
-e_source_type 'test_source' \
-e_text 'text blah' \
-e_title 'some title' \
-debug
go run ./cmd/veneur-emit/main.go \
-mode sc \
-hostport 127.0.0.1:8200 \
-sc_msg 'message of sc' \
-sc_name 'my-service-check' \
-sc_status 0 \
-sc_tags 'env:prod' \
-debug
When your tests depend on data files, put them into a testdata
directory next to the test file, and use relative paths to refer to
them.