Guys, I’ve some feature requests for the issues se...
# seed
a
Guys, I’ve some feature requests for the issues section in SEED. Please let me know if these would be doable? 1. Issue pinning - to be used for monitoring critical issues that actually matter. 2. Marking issues as similar or a concept of issue groups - basically some issues might be related and fixing them could be a singular task and so grouping would make sense. 3. Ignore issues or a sampling rate - in a high throughput application, even the most trivial of issues will have a lot of events, there might be issues which we’d want to monitor but on lower rate because their actual event count is too high. 4. Changing rate limits of Issue tracking - There might be times we’d want to log issues even beyond the current fair usage limit. Currently, the issue tracking gets deactivated and needs to be activated manually. While I understand the need for it, It’d be great to override this. (Could be a paid feature). These are a lot but these could be quite helpful. I understand SEED isn’t a monitoring solution but I’d be grateful if you could consider these. I like epsagon but adding another lib where cloudwatch can do its magic does not sit right with me. Thank you.
r
I think 3 in particular for us. There also seems to be an issue where there's no way to turn off notifications for a particular app for a particular team member.
Re: 3. Being able to filter and based on HTTP error code would be useful
a
Yep, I would want to achieve this as an issue group. All 500 with xxx message in this group, all 401 with xxx message in another group. Would be an amazing devops experience. My control freak personality is already screaming with joy. 😂
f
Thanks @Ashishkumar Pandey. They make a lot sense! (what one would expect for a basic monitoring service)
Putting them down on our roadmap. We might not be able to get to them right away, but improving issues is pretty high on our priority list. Like you said, surfacing what’s already there in ur CW logs.
As for #4, currently limit is 10k per hour. Feel free to DM me the volume you are expecting. I will see what we can do to accomodate for that.
Hey @Ross Coundon,
turn off notifications for a particular app for a particular team member
Do you mean having each member be able to turn on notifications for issues that are relevant to them?
Being able to filter and based on HTTP error code would be useful
Do you mean something along the line of for Lambdas handling API routes, do not report an issue if the API responded with 200 status code?
r
Hi
turn off notifications for a particular app for a particular team member
We have the situation at the moment where a member of the team is being notified for all errors but he isn't actually working on that app. I can't actually find where it's setup that he should get any notifications at all (which is the issue I mentioned) It'd be great to have a user be able to subscribe to issues for service 1/app A but not service 1/app b or service 2/ app X
Being able to filter and based on HTTP error code would be useful
Basically yes, although I guess I was thinking more about how, in the Epsagon world, any 3rd party API call that results in an error code, even if the ultimate return of the function is non-error, results in an error being logged.
f
Thanks for clarifying!
Yeah we are going to make the Seed roadmap public! It’s something we really want to do, just haven’t been able to prioritize that over some of the initiative on the SST front.
@Ross Coundon It’s on my mind! I will keep you posted on it.