Looks like a tangled mess of a decision engine. Why would anyone want this? Surely, there are other solutions out there that are more mature? (nagios comes to mind but is a poor example)
Any and all answers to this question would be appreciated, even those that just qualify as 'promising' and 'active' (as opposed to mature). All I know of is nagios really.
Stack Exchange's monitoring system is now open source
31–40 of 57 posts
Re: Stack Exchange's monitoring system is now open source
#32Easy to deploy as it's written in C# :)
Just because you're already on a .NET stack, or is there another reason?
Actually, this was irony, as all the systems that I have currently deployed run a classical Linux stack and I would have to think a long time to start deploying a .NET / Mono app if it's worth the integration effort.
Re: Stack Exchange's monitoring system is now open source
#33I understand that it's not worth the cost to cleanup the history, but it's always frustrating to see such a project come with a 100kloc "initial" commit.
Please consider that this project started internal only, so there may be sensitive information in the full history.
Re: Stack Exchange's monitoring system is now open source
#34I understand that it's not worth the cost to cleanup the history, but it's always frustrating to see such a project come with a 100kloc "initial" commit.
Interesting. Why? What would be valuable about the commit history for you?
I think that the commit history says a lot about the development process and the company culture. First, is that it's interesting to see how these companies work internally. Second, it's easier to dive into the code by reading the latest commits. You can see what's going on and what pieces are changed together. Finally, there is a substantial difference between:
- a repository that's handled as a first class "source code ledger" (pick one or several of: proper branching/merging, atomic commits, issues referenced in commit messages, etc).
- a repository full of "git commit -a -m 'ill fix this bug later, TGIF'" whose history makes no sense.
I don't want to open the debate on which one is preferable or not (most people agree that git bisect is handy, but it is open to debate whether it's worth the cost).
What I'm wondering is how it looked and why it was rewritten. The most probable reason is that they wanted to make sure that nothing sensitive was exposed (non-redistributable embedded dependencies, information on their infrastructure, ...). But it's also possible that this was started as a type-2 repository and they don't want to expose this image.
I tend to think that every code should be written (and developed) as it was open sourced one day, but as always there's a cost trade-off in here.
Anyway, thanks for open sourcing this piece of software!
Re: Stack Exchange's monitoring system is now open source
#35The anti .net kneejerk reactions on HN really disturbs me. You spend all day on stackoverflow then blindly bash their tech stack. Developing, deploying, and hosting .net apps is just fine. Many brilliant people choose .net and are plenty happy with it. Maybe rather than jumping to conclusions, you could give it a shot.
Many of us have .NET experience, really like C# but have sensible reasons for not recommending it. A Microsoft only stack is nowhere near as flexible as Linux and if you were to reach Stack Overflow's levels of traffic you'll not be able to avoid the need to run a part of your infrastructure on Linux. I seriously doubt Stack Overflow is running Redis, ElasticSearch & HAProxy* on Windows. Unless you already have a team proficient in .NET, there are few good reasons to use it instead of a JVM language.
*https://github.com/opserver/Opserver/tree/master/Opserver.Co...
Re: Stack Exchange's monitoring system is now open source
#36Earlier quoted context omitted.
Interesting. Why? What would be valuable about the commit history for you?
I think that the commit history says a lot about the development process and the company culture. First, is that it's interesting to see how these companies work internally. Second, it's easier to dive into the code by reading the latest commits. You can see what's going on and what pieces are changed together. Finally, there is a substantial difference between: - a repository that's handled as a first class "source…
Guy who wrote it here...the only reason this isn't public is security, at a few points there were various passwords in the repository. Also, the internal repository is Hg (still is, though this may change). I still want to dogfood major changes before breaking others. We could convert this history, sure...but the security reason remains.
There were many commits that don't make a lot of sense to anyone but me probably, since they were so massive in scale...especially leading up to this release. For example, moving the configuration from web.config-ish xml style to JSON in preparation for a larger system I wanted to have done before open sourcing it to not hose adopters later.
That being said, most commits are decent size features or several every day or two. This was completely a side-project for me, happening while waiting on something or in the evening. Going forward, we're shifting focus to monitoring and will be giving some real dedicated time to it. We will be building our own monitoring system as a whole, polling, push, agents, etc...and Opserver is a large part of that big picture. Those commits will be much more interesting, and you're going to see them all.
If there are any questions though, I'm happy to answer them...we're pretty wide open, just short of sharing logins and passwords.
Re: Stack Exchange's monitoring system is now open source
#37The anti .net kneejerk reactions on HN really disturbs me. You spend all day on stackoverflow then blindly bash their tech stack. Developing, deploying, and hosting .net apps is just fine. Many brilliant people choose .net and are plenty happy with it. Maybe rather than jumping to conclusions, you could give it a shot.
Many of us have .NET experience, really like C# but have sensible reasons for not recommending it. A Microsoft only stack is nowhere near as flexible as Linux and if you were to reach Stack Overflow's levels of traffic you'll not be able to avoid the need to run a part of your infrastructure on Linux. I seriously doubt Stack Overflow is running Redis, ElasticSearch & HAProxy* on Windows. Unless you already have a tea…
I imagine the Stackoverflow guys are familiar with Linux architectures, they also run the open source forum Discourse[1] which is a Ruby on Rails app that comes with a recommendation to set up and develop in a *NIX environment[2].
Certainly the point is to use the right tool for the job, and I wouldn't dismiss your final comment: having a team proficient in .NET is a great reason to build your tools with/for that platform.
But no, I don't think it would be fair to reply to this article saying "Why didn't they build this for [my preferred language]?"
[1]: http://www.discourse.org/ [2]: http://blog.discourse.org/2013/04/discourse-as-your-first-ra...
Re: Stack Exchange's monitoring system is now open source
#38The anti .net kneejerk reactions on HN really disturbs me. You spend all day on stackoverflow then blindly bash their tech stack. Developing, deploying, and hosting .net apps is just fine. Many brilliant people choose .net and are plenty happy with it. Maybe rather than jumping to conclusions, you could give it a shot.
Many of us have .NET experience, really like C# but have sensible reasons for not recommending it. A Microsoft only stack is nowhere near as flexible as Linux and if you were to reach Stack Overflow's levels of traffic you'll not be able to avoid the need to run a part of your infrastructure on Linux. I seriously doubt Stack Overflow is running Redis, ElasticSearch & HAProxy* on Windows. Unless you already have a tea…
Just because you use c# doesn't mean your whole stack needs to be Microsoft. No reason why you could have Windows web-servers running asp.net/c#, but have postgres DB, nginx, memcache etc on linux. Azure seems to be actually encouraging this.
The cost of windows licenses for web-servers is not that much. Avoiding SQL Server is the big win in reducing cost.
Re: Stack Exchange's monitoring system is now open source
#39The anti .net kneejerk reactions on HN really disturbs me. You spend all day on stackoverflow then blindly bash their tech stack. Developing, deploying, and hosting .net apps is just fine. Many brilliant people choose .net and are plenty happy with it. Maybe rather than jumping to conclusions, you could give it a shot.
Maybe you're being over-sensitive as I don't see anything hostile to .NET. The closest I saw was the comment that reading C# seemed odd compared to most of today's start-ups (which you could probably say about Java as well).
EDIT: Somehow I had showdead off, and now see the "punched in the gut comment" ... the fact that it's dead shows that the community doesn't really put up with non-productive comments.
Re: Stack Exchange's monitoring system is now open source
#40Earlier quoted context omitted.
Many of us have .NET experience, really like C# but have sensible reasons for not recommending it. A Microsoft only stack is nowhere near as flexible as Linux and if you were to reach Stack Overflow's levels of traffic you'll not be able to avoid the need to run a part of your infrastructure on Linux. I seriously doubt Stack Overflow is running Redis, ElasticSearch & HAProxy* on Windows. Unless you already have a tea…
Just because you use c# doesn't mean your whole stack needs to be Microsoft. No reason why you could have Windows web-servers running asp.net/c#, but have postgres DB, nginx, memcache etc on linux. Azure seems to be actually encouraging this. The cost of windows licenses for web-servers is not that much. Avoiding SQL Server is the big win in reducing cost.
All true but there is still quite a bit of inefficiency involved if you need a team that is both proficient in deploying & running Linux infrastructure tools as well as Windows servers.
And given that this discussion is taking place in the comments section of a link to a custom-made monitoring dashboard that quite possibly wouldn't be needed* if SO was a Linux-only shop doesn't exactly devalue my previous statement.
*I have no idea whether this could be replaced with Nagios or Munin