riemann / riemann-nodejs-client Goto Github PK

I'd like someone to review this, Its going to have problems when multi-chunk message frames come through.

Hi,

Big fan of the protocol-buffers update overall as it brings our npm install time down massively as we no longer have to compile anything so thanks for that :). Unfortunately it looks like attributes with values that are not strings are no longer supported - these worked previously. I don't want to convert them to strings as the place they end up handles strings differently for numeric types.

To replicate, you can add something like {key: "response_time", value: 123} to the 'custom attributes' test (around line 72) in test/basic_tests.js and run the tests - this causes a couple of extra failures, although it looks like mocha eats the stacktrace as done gets called twice.

The stack trace we're seeing at application level is:

TypeError: Argument must be a string
    at Object.exports.string.encodingLength (/home/dave/dev/code/webstore/node_modules/riemann/node_modules/protocol-buffers/encodings.js:60:22)
    at Object.encodingLength (eval at <anonymous> (/home/dave/dev/code/webstore/node_modules/riemann/node_modules/protocol-buffers/node_modules/generate-function/index.js:55:21), <ano$
ymous>:8:22)
    at Object.encodingLength (eval at <anonymous> (/home/dave/dev/code/webstore/node_modules/riemann/node_modules/protocol-buffers/node_modules/generate-function/index.js:55:21), <ano$
ymous>:38:24)
    at encodingLength (eval at <anonymous> (/home/dave/dev/code/webstore/node_modules/riemann/node_modules/protocol-buffers/node_modules/generate-function/index.js:55:21), <anonymous>$
28:24)
    at Object.encode (eval at <anonymous> (/home/dave/dev/code/webstore/node_modules/riemann/node_modules/protocol-buffers/node_modules/generate-function/index.js:55:21), <anonymous>:$
:30)
    at _serialize (/home/dave/dev/code/webstore/node_modules/riemann/riemann/serializer.js:11:30)
    at Object.exports.serializeMessage (/home/dave/dev/code/webstore/node_modules/riemann/riemann/serializer.js:30:10)
    at udpSocket.<anonymous> (/home/dave/dev/code/webstore/node_modules/riemann/riemann/client.js:22:30)
    at Client.send (/home/dave/dev/code/webstore/node_modules/riemann/riemann/client.js:136:11)
    at <our app code>

Let me know if there's anything else I can do to help diagnose.

Thanks!
Dave

https://github.com/riemann/riemann-nodejs-client/blob/master/riemann/serializer.js#L17

When bundling, this becomes the directory of the caller, leading to:

(node:17555) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open '/proto/proto.proto'

Just tried out this client for our internal monitoring, followed the install steps, and the sample code to get started.

Noticed that the events emitted only contain service name and state (of "ok"), but no metric is passed along even though it is defined. Happens on Ubuntu Linux on an AWS server, and on my local Mac.

I observe a Wireshark trace looks like this of the UDP data sent out from event emitting host:

mbp.local2D........ok.&service.name.here".daluu-mbp.local2D........ok.&service.name.here".daluu

whereas here's a snippet of my code block:

var monitor = require('riemann').createClient({
host: 'myhost',
port: 5555
});
...
monitor.send(monitor.Event({
service: 'service.name.here',
metric: 10.51,
state: 'ok',
time: timeCurr
}));

What could be the problem? Anyone else have such issues?

As a result of this, our riemann server is getting nil for metric.

I just noticed this commit fd49814 which is in master from a year ago, but the npm does not deliver this fix.

Seems like this library is asynchronously loading /proto/proto.proto, but it doesn't actually wait for it to be loaded when trying to send message. There also doesn't seem to be any api which we can use to detect when it has loaded.

TypeError: Cannot read property 'lookupType' of undefined
    at _serialize (/mnt/c/Users/myPath/riemann-test-client/node_modules/riemann/riemann/serializer.js:26:35)
    at Object.exports.serializeMessage (/mnt/c/Users/myPath/riemann-test-client/node_modules/riemann/riemann/serializer.js:61:10)
    at tcpSocket.<anonymous> (/mnt/c/Users/myPath/riemann-test-client/node_modules/riemann/riemann/client.js:39:30)
    at Client.send (/mnt/c/Users/myPath/riemann-test-client/node_modules/riemann/riemann/client.js:171:18)

I believe this is just a matter of upgrading to a working version of the protobuf module that compiles against 0.8.x node.

If this has lib can simplify deployment, I'm all for it.

https://github.com/fuwaneko/node-protobuf

The Getting Started example doesn't work for me in Node 6.9.4 on Windows 7x64-- it times out. I have a ruby client which is connecting to Riemann just fine, so the problem seems to be the node cient.

Is this client no longer being maintained?

Getting Started Example

var client = require('riemann').createClient({
host: 'some.riemann.server',
port: 5555
});

client.on('connect', function() {
console.log('connected!');
});

I cannot get 2.0.0 to work, it loses the metric value every single time. I've added couple console.log calls here and noticed that it's the serialization that is losing metric field.

contents:

{
    "events": [
        {
            "service": "buffet_plates",
            "tags": [
                "nonblocking"
            ],
            "host": "LAPTOP-91M3C9AJ",
            "time": 1588754603,
            "metric_f": 252.2
        }
    ]
}

After calling Serializer.deserializeMessage(Serializer.serializeMessage(contents)) it becomes:

{
    "events": [
        {
            "time": "1588754603",
            "service": "buffet_plates",
            "host": "LAPTOP-91M3C9AJ",
            "tags": [
                "nonblocking"
            ]
        }
    ]
}

Everything works fine with 1.1.1

Currently used [email protected] isn't compatible with node 0.12.0.

I use Riemann to log non-critical application metrics. If the connection to Riemann fails, I want to ignore it and attempt automatic reconnection. It could perhaps even queue up events.

It seems if you use only one protocol (tcp) each createClient call will cause both a tcp and udp to be opened. However, if you monitor close events, if the udp event is never actually doing anything but sitting there, and the tcp is receiving the close event, the monitorClose will never trigger the disconnect / close of the udp socket, resulting in a memory leak, as assuming you want to reinit a createClient on each failure of the tcp / close - you end up just adding more and more open udp.

I noticed this on a setup where we are pushing an event over strictly tcp, once per second, but the riemann server began losing about half the packets with early close signals.

To include #25. Thanks!

see this page for more information on how queries work:
http://aphyr.github.com/riemann/concepts.html