Event Based Reporting System Coming in Version 2.0

Event Based Reporting SystemWe hinted that more details on the upcoming Exceptionless 2.0 release would get announced soon, and here we are! Lets dive in a bit further, shall we?

Many users have asked for ways to use Exceptionless to report additional types of events, rather than just errors. With version 2.0, we are moving to an event based system that will accommodate such requests.

What’s an Event Based Real-Time Reporting Tool Look Like?

  • The new system allows us to receive literally any data people want to send us instead of only allowing errors.
  • Event posts can be as simple as this:
    Post Event Exceptionless
  • You can send log messages or even entire log files.
  • Log messages can contain extended data objects just like errors can now.
  • You can post random JSON objects and the data within them will be treated as extended data.
  • You can post batches of events instead of only being able to send one at a time.
  • You can send feature usage events that let you see how often features of your application are being used. Think about how useful that will be!
  • You can send session start and end events that will enable you to know what percentage of users are affected by errors and enable you to better know what your priorities should be.
  • We will be gathering enough data to make it easy for us to begin putting together some very useful analytic reports.

We’re pretty excited about the switch from error-only to send-us-any-event-you-can-think-of real-time reporting, logging, and notifications. We think it’s going to be awesome, and it’s almost scary how much of a playground Exceptionless is going to turn into for some of our customers. We’re not pushing the limits, we’re pushing for no limits!

Ideas? Concerns? Let us know. We’re working hard to wrap up Exceptionless 2.0, but there’s still a lot more bells and whistles we’re polishing before launch! Keep an eye out for still more sneak peek material in the coming weeks!

11 Responses to “Event Based Reporting System Coming in Version 2.0”

  1. Kelly

    Meh, bad idea.

    Reply
  2. Exceptionless

    Would love to hear more about why you think it’s a bad idea.

    Reply
    • Kelly

      In general I don’t think it’s a bad idea, it just seems that the platform is lacking in so many other ways currently that adding this feature(that to me doesn’t seem to make sense in the scope of this project) kind of takes away from that.

      Like there is no good way to search, or any kind of granularity. I can’t setup specific tags and alerts, or any of that other stuff that would really make this an awesome service for tackling exceptions.

      Adding generic messages is more of a push to make this a logging platform, which it isn’t, and also it seems the UI isn’t really up to par with that(due to lack of granularity, and the way you have to navigate page after page to get to the details).

      Logentries is a logging platform, which I use and love. You guys are a platform for telling me when my software is throwing errors, and you do a pretty ok job at that(mostly I was excited that you guys wrote some code to group exceptions together in a meaningful way, which is a complicated problem. I actually did some research into setting up a system like this, inspired by how googles developer platform can group exceptions together, but I figured it’d be too much work).

      I guess all I’m really saying is, yeah sure it’s cool, but I feel like a lot of other areas have been suffering since I’ve jumped on board and it sucks to not see your platform become a really good exception service before you start expanding out and adding new kind of unrelated features.

      Reply
      • Exceptionless

        Kelly, I completely agree. We want to move to ElasticSearch which will give us the missing search features as well as a bunch of other abilities, but we didn’t want to have to implement it twice. We are changing the format of the data that we are storing to be much simpler which will help tremendously when we move to using ElasticSearch. We will still be focused on exception reporting and it will be a 1st class citizen, but we will also allow other types of data to be sent in as well.

        There were 2 big drivers in making the decision to go ahead and refactor the API and move to a much simpler and more generic event based system.

        1. One of the biggest things that people want is to have clients for other platforms, but our API was too complex and made it too hard to implement clients on non-.net platforms.
        2. We wanted to have a simpler extensible system that would make it easier for people to work on and contribute to the project.

        If we went ahead and implemented ES before we made these changes, we would end up having to do it twice. That is why we decided to go ahead and do it now. So far we are extremely excited about the results of these changes! You can take a look at the code if you want here: https://github.com/exceptionless/Exceptionless

        Reply
        • Kelly

          I can appreciate that, I think I’m just being impatient.

          Reply
          • Exceptionless

            And I can totally appreciate that. 🙂 All I can say is that we are working hard and making good progress.

  3. BC

    On the desktop I’ve got the Windows Event log but, aside from my test users that I personally know, I’ll never directly be able to access the log. So what you’re talking about could being useful for reporting key events (critical, high and maybe medium level).

    My concerns/thoughts are:
    * I hope it doesn’t negatively impact the existing exception handling. That’s why we’re all currently here
    * I’m curious what type of functionality we’ll have to manage/view all the events. I’d like to be able to see my events by type but also be able to view by user so I can see if one particular PC has a recurring issue
    * Impact on pricing, etc

    Reply
    • Exceptionless

      Glad that you think the new features will be useful. 🙂

      1. Exception handling will still be the primary focus and will continue to work like it does now. It will just be MUCH easier to implement error reporting on non-.net platforms.

      2. After we get the event refactor done, the next step will be moving event storage into ElasticSearch which will then give us the ability to search by tags, keywords and anything else we want to do. The new event system also allows us to track events like session start and end which will allow you to not only see everything related to a specific user, but also see everything that happened in each one of their sessions using your app.

      3. Pricing will continue to be based on number of events sent into the system. We have thought about getting rid of the pricing plans and just letting you select how many errors/events you want to be able to send us per month and how long you want us to store them for. I am thinking that would be a much simpler system and allow users to have more control.

      Reply
  4. Aneef

    Any idea when it would be released.

    Reply
    • Exceptionless

      We don’t have a timeline. We are working hard and are hoping to have the server side of 2.0 in beta form soon and then we will be working to update the UI to work with the new REST API after that.

      Reply
  5. John Kattenhorn

    Hi Eric,

    Sounds good, I’ve been taking some to look at the ExceptionLess 2.0 and I like what I see.

    Are you thinking along the same lines as StatD kind of thing ?

    Will I be able to update counts and timings etc. Or are you just talking non exception messages ?

    Reply

Leave a Reply

* Checkbox GDPR is required

*

I agree