Hacker News new | past | comments | ask | show | jobs | submit | shahargl's comments login

thanks! <3


Thanks! what would you expect from dark mode?


There are a lot of studies that proof that darkmode during day is straining eyes much more. In the night dark mode is better. But most of the "day-to-day" user are working during day.


for small teams we mostly see workflow automation on their alerts, for bigger teams it’s also unified API for alerts from many tools and single pane of glass for alerts


ok but what problem does this solve that I can't solve with Slack notifs


With slack you lose history and context. Also collaboration is harder. Also if you have some processes/workflows you want to maintain in some GitHub repo and manage as code/gitops, you can’t do it with Slack. Deduplicating alerts is also a thing. Basically it’s a different use case


Thanks for the clarification. Would you be able to provide a concrete example for this product’s differentiated use case


Np! Company A have 4 monitoring tools and 2 IRM’s. Few dozens of alerts per day. They use Keep to streamline their ticketing routing, enriching the ticket from a prod db, some if/else logic. Every month they do some research on the alerts they had last month with slice and dice per team/app/etc.

Company B, with big operations group, use Keep as single pane of glass where NOC dispatch incidents and sync context from every system.


Thanks. The first example painted a better picture


Yo! I can say that most of our users are open source users. We are community-driven, and like 95% of the features are open source. It’s true that we need something to monetize on but I really feel that we are an open source company.


Kudos. I appreciate the desire to be open source and the need to monetize (and I don't have a golden solution to it, so I would probably do something similar), but I just wish that people clearly define that they are open core because there are a lot of amazing open source projects out there, and it wouldn't be fair to them to be called open source when they aren't.


thanks for the clarification, sorry if it sounded like we’re thinking your comment is not legitimate. It absolutely makes sense.


Interesting! What type of integration do you imagine?


Similar to the other orchestrators, doing restarts and deployments and maybe even scale outs.


I guess you could use the existing SSH functionality to do restarts and deployments.


How does it play with Keycloak's Authorization Services?

Or in other words - why should I choose permify over Keycloak? https://www.keycloak.org/docs/latest/authorization_services/...


Firstly, while IAMs often offer some level of authorization capabilities, they are not as flexible or fine-grained as dedicated authorization systems like Permify.

Therefore, customizing complex permission logic (such as hierarchical relationships, user group, etc.) can be challenging in IAMs. As an example, Keycloak's Authorization Service supports RBAC and ABAC it does not support ReBAC.

Another point is that authorization as a service solutions are focused entirely on authorization. This means they provide not only fine-grained permissions but also tooling and functionality to ease testing and observability of the authorization system.

Also Permify leveraging Google’s Zanzibar scalable data model and unified ACL (Access Control List) approach, enables the creation of a centralized authorization service capable of handling high volumes of data and access checks across your microservices stack.

Still, it's worth mentioning that if you have a basic authorization system or need, it makes total sense to use the solutions you mentioned for handling the authorization part as well. However, if you want to scale your authorization, especially in a microservices environment, I would suggest trying one of the authz providers instead.


https://github.com/keephq/keep (disclaimer - i'm the maintainer)


how is it different from Traceloop and openllmetry (https://github.com/traceloop/openllmetry)?


Broadly, on the monitoring side, we’re more focused on evaluating the quality of the model’s outputs (is it violating your rules, handling specific subpopulations / edge cases correctly etc.). OpenLLMetry is more focussed on telemetry and tracing, whereas for us ‘monitoring’ is a means to running your tests on production data.

Openlayer’s also intended to be used on non-LLM use cases. Here are a few other ways we’re different:

1. Support for other ML task types

2. Includes a development mode for versioning and experimentation

3. Native slack and email alerts (openllmetry might integrate with other platforms that do that, but not sure)

4. Collaboration is deeply embedded into the product


Traceloop's landing page is all about model quality, not metrics. Their open source OpenLLMetry is the metrics part and hooks into the OpenTelemetry ecosystem. There should be no issue with getting alerts via the ecosystem, it's promanent on their pages.

https://www.traceloop.com/


I think the target personas is different. While they might have the same capabilities, but the job-to-be-done is different.

openllmetry is focus on engineers, who wants to use this as more of a piping solution and it sits on top of opentelemtry. While opentelemetry is a popular solution. It is just applying a solution to a new problem.

OpenLayers to me is thinking from the ML/AI problems from ground up and while serving the data scientists and probably prompt engineers.



For one thing, the name is certainly better than the latter's lol


I find OpenLLMetry to be better.

1. OpenLayer does not say metrics or monitoring to me

2. OpenLLMetry builds on OpenTelemetry, which it very much reminds me of as a name. It's also a much easier add-on to our existing stack. I don't want to have to log into some company's website to view metrics for a single part of my stack when trying to understand why things are not working as expected.

3. OpenLLMetry is open core, which is what devs desire. Who is really using closed source software in this space now (the logmon space, not ai, though both are largely chasing after open dreams)


one of the concepts we are trying to push is exactly that - my cofounder actually wrote a blog post about it - https://news.ycombinator.com/item?id=38086082


valid feedback. If a company works only with Datadog it probably doesn't need a unified API for alerts, but what we see is that many companies use more than one. monitoring tool (or even other tools that generates alerts but arent classic monitoring tool)


I agree. I have pager duty, slack, teams, meet, new Relic, azure insights, service now, jira, Prometheus, and solarwinds. Luckily just got rid of prtg.

The issue is showing that to my managers would confuse them. I like the concept but it's just not clear.


So the goal is to have unified interface for every tool you’ve just mentioned


We care more about the data resides versus where it's accessible. A developer knows C++ and a DBA knows SQL so each have their own tools to create monitoring.

I hope your product succeeds but it needs to be easy for useless people and I feel like you are aiming for braniacs like you


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: