Raygun Feature Request

Can we have a simple logging that can output messages.. this is handing for tracing

so instead of an exception.. just a lot.. I want to log web service timings when i uplload to aws s3

Would it be possible to return a reference number back also? This means a Customer would be able to provide this and finding the traced information would be easier.

Would a reference number be able to be used for tracing events across any application? For example on-premise application calls multiple cloud services and a particular reference number links the traced events together. I've never seen this before and not sure how this might work but these are the types of features that appeal to me.

Any progress on this? It will be a huge help. It would be awesome if you could link your logging in a method with any errors thrown in that same call / method.

You might like to look at: https://github.com/gkopff/logback-raygun

Greg, can you communicate the details of communicating with the API for logging. I love to have this feature available in the js client.

@it-ony: ah - I think you're out of luck. This implementation is a logback (a Java logging framework) appender which posts exceptions as well as warnings to raygun.

@Greg: I got this, I just wanted to know how the payload must be structured to post log messages to raygun. If I know the structure, I could add it to the raygun js binding.

@it-only: Everything there is to know is contained in this file: https://github.com/gkopff/logback-raygun/blob/master/src/main/java/com/fatboyindustrial/raygun/RaygunAppender.java

I use the raygun Java library to build their objects, and use their sending mechanism. This means I don't have to worry about the underlying message serialisation.

The raygun Java classes are very much centred around logging exceptions - the constructors for creating their objects often take a Throwable and then extract the details out internally. For me, this means I have to create an initial raygun object with a dummy exception, and then use the setters to adjust the fields to their required values. (@Raygun: it would help me out if your constructors allowed me to set the field values, and not be tightly bound to Throwable).

If you have a look at the appender, you can see what I do to log a standalone message versus a message with a stack trace. When I log a message without a real stack trace, I generate a 1 line long trace which contains the callsite where the message originated.

We need to have some sort of tracing logging available to make Raygun a viable long term solution for us. @greg is right. Having to create a dummy Exception (in the case of Raygun4Net) to log anything is too limiting. Adding general logging in the usual simple and intuitive Raygun way will make it a truly great product for our needs.

+1

Concur. We need tracing for a full diagnostics experience. Errors are the first line, but I have many processes that need to spit out some verbose logging from time to time. We also just like to have certain apps send messages when processes complete or messages for auditing purposes.

The trick may be the billing model though. With this type of logging, apps could generate an awful lot of messages, so i would like this to be separate from the Error counts and retention. These log messages could be large in quantity but have a far shorter retention policy.

It sounds like there is more than one suggestion in these comments that could be called a "logging feature." My opinion is that RayGun is Exception Tracking software and should continue to focus on exception tracking, and not logging. There are plenty of services that already do focus on logging (i.e. Loggly, PaperTrail, etc.).

With that being said, I'm not sure if this is what someone was suggesting, or just my adaptation of it, but it could be relevant to log messages that would be included in some kind of "log output" section of an Exception if and when it does occur. The question is how you determine where that log starts. In a web application it would be simple enough - start it with the request, or in the case of a background job, start it with the job. In some other long-running application, it would be more difficult to determine how much of the log output to include. The log data could be ridiculously long for a long-running application, and how do you decide how much of it is relevant? Perhaps it's a stack-like structure rather than a simple sequential log? Where the log data from each iteration of a loop replaces the data from the previous iteration?

In any case, I agree with the original staff post that it is too big to be simply bolted on to the side. I'd prefer not to see a half-implemented logging solution in an Exception Tracking application. I would like to see either a very focused implementation, relevant to exception tracking (as above) or a full-featured logging solution that integrates with, but is separate from the Exception Tracker.

+1 for general logging in raygun.

Yes, this would be a really useful feature. In some cases, the stacktrace just doesn't have enough information, and a little more info surround the trace could be really helpful.

Are there any news on this one?

This would be a great feature.

any updates on this?

Hi all,

Just a quick update - a full logging service is far more than just a feature, but an entire product in its own right. We may add this eventually but it's not on the near term road map unfortunately.

Best bet is to log any log lines at the time of an error in the custom data block.

Sorry I don't have better news for you at this time!

Thank you all for your feedback and suggestions.

Kind regards,

Yosan