Error stores for cloud-hosted services

[ThomasArdal]

I was playing around with implementing an error store for elmah.io during the weekend. While I could get it working, I stumbled across a couple of issues that needed "hacks" in order to implement. Like error stores need a connection string, which doesn't make a lot of sense for cloud-hosted services. These typically use some kind of authentication and an API to log errors.

What are your thoughts about this? Does it make sense to implement cloud-hosted error stores or is Exceptional geared towards databases only? Also, cloud services typically have their own UI to present errors why implementing all of the getters and deletes feels redundant. Would give the user a choice to use either the cloud service UI or something like Opserver, of course.

[NickCraver]

I'd say you can store them anywhere :) The ErrorStore base class is meant to be flexible (e.g. memory, Mongo, or RDBMS), so if you want to store them in a cloud database system, or even say translate Error to someone else's format and store it so it's visible/usable in another dashboard - that's all on the table!

[ThomasArdal]

Yeah ok. The reason I'm asking is that it looks like you either log in a store without a connection string (like memory) or a store with a connection string (like mongo). A cloud service usually doesn't have a connection string, but an API key, an OAuth token, or similar.

If I wanted to, I guess I could wrap the elmah.io API key and log id in a connection string:

api-key=API_KEY;log-id=LOG_ID

or something like that 👍

[NickCraver]

Yep, that's how we do Redis and such and what I'd recommend, but any approach works in code as well (it just wouldn't be easy to configure via web.config/app.config)

[ThomasArdal]

👍 It would be awesome to be able to define custom properties besides a connection string and make it available through web/app.config. Like in NLog.

I'll think about it. Thank you very much for your input 🙌